Alternate Controllers/MCUs

[HeroXLazer]

What other MCUs are good alternatives to the ATMEGA32U4? I want to build a custom RGBW PCB with USB C 3.0 or 3.1. I got the RGBW part almost down, but I need to know what MCUs will work with USB 3.0 or 3.1, I need it for the higher power through USB from 500ma to 900ma. Which controller are the best for that application? I am going to use PWM pins for the RGBW LEDs, but still...

[Engicoder]

Yes, there are many controllers. You might want to check out this thread:
workshop-f7/can-we-design-the-teensy-al ... 13662.html

You don't necessarily need USB 3.0 for the higher current limit. You could use two USB 2.0 connections or a device that supports the type C connector and version 2.0 of the USB Power Delivery spec. Both 3.0 and more so USB C will limit those who can use your keyboard.

[HeroXLazer]

Yes, there are many controllers. You might want to check out this thread:
workshop-f7/can-we-design-the-teensy-al ... 13662.html

You don't necessarily need USB 3.0 for the higher current limit. You could use two USB 2.0 connections or a device that supports the type C connector and version 2.0 of the USB Power Delivery spec. Both 3.0 and more so USB C will limit those who can use your keyboard.

I'm the only one who's going to use the keyboard, but do you know any of the controller I should use? I looked at the thread you posted, and I was a little confused.

[pomk]

mkl27 in 128/256k variety is a relatively good option, requires very little external components and comes with a USB bootloader. TMK port for it exists already.

[vvp]

Mkl27 is Usb 2.0 controller. It will not handle power deliver negotiations without external hardware. And HeroXLazer wants at least 900 mA.

I do not know what are the defaults for maximum current when the device does not support USB power delivery specification. I would say un-marked type A/B cables will support only 500 mA maximum as the default (though they can support up to 1.5A if they negotiate it with the host using the USB Power Delivery protocol).

Will type C cable default to more than 500 mA when communicating with only a Full Speed v2.0 device which does not support USB Power Delivery protocol? I doubt that but maybe they will. Despite the fact that un-marked type C cables can handle up to 3 A.

I doubt HeroXLazer will get a good proposal for MCU since his requirements are completely unusual compared to other deskthority users.

[vvp]

There is one more option for HeroXLazer which would easily work with our common controllers. He can use USB Charging Downstream Port (CDP) on the host side and then he can use even a simple type A/B cable. That will give him 1.5 A even without power negotiation. And then he can use the common controllers people on deskthority use.
I do not know now common the CDP ports are on computers.

[pomk]

It seems that you are correct on this. I thought that the kinetis SDK would allow for a 'battery charging' device to be developed regardless of the MCU used, but it seems that that specific service is not allowed for MKL2X devices. The USB2.0 battery charging service would have allowed for 1,5A current negotiations from the host.

There are dedicated USB3.0 passthrough chips that will handle the power acquisition and pass the data lines to the MCU of your choice, maybe you should look for a suitable one from those, it would allow you to use any USB MCU without having to limit yourself to MCUs no one has built keyboards for yet.

edit: something like TUSB320 would work just fine I guess. It allows you to use a USB 2.0 MCU and handles the power negotiations on your behalf. You can then ask the current allowed from that chip and then power on/off back lighting regulators accordingly.

One could also look at the design files for whitefox or some other USB-C connected keyboard and check if the MCUs used would suffice and also allow for the power draw you require.

[HeroXLazer]

It seems that you are correct on this. I thought that the kinetis SDK would allow for a 'battery charging' device to be developed regardless of the MCU used, but it seems that that specific service is not allowed for MKL2X devices. The USB2.0 battery charging service would have allowed for 1,5A current negotiations from the host.

There are dedicated USB3.0 passthrough chips that will handle the power acquisition and pass the data lines to the MCU of your choice, maybe you should look for a suitable one from those, it would allow you to use any USB MCU without having to limit yourself to MCUs no one has built keyboards for yet.

edit: something like TUSB320 would work just fine I guess. It allows you to use a USB 2.0 MCU and handles the power negotiations on your behalf. You can then ask the current allowed from that chip and then power on/off back lighting regulators accordingly.

One could also look at the design files for whitefox or some other USB-C connected keyboard and check if the MCUs used would suffice and also allow for the power draw you require.

They all use MK127, and they are only USB C 2.0

[vvp]

Well, if you care not only about power delivery but also want to use USB 3.x Super Speed for your keyboard then I think you will be the very first one who is going to try it

[Findecanor]

OK. I saw on Geekhack that you just want to backlit 40 keys. What kind of LEDs have you found? They must fit inside or below (SMD) the switch you want to use.
Most full-spectrum (...) LEDs are RGB, not RGBW. Red, green and blue together makes white. That would be 40×3 = 120 LEDs.

LEDs are usually not powered all the time - instead they flicker really fast. Without flickering them, the LED light would be much too bright. It is by changing the frequency and/or period of the flickering that you would be able to adjust brightness.
On large keyboards you would flicker them by organizing them in a matrix of U columns and V rows and power only maybe one or a few columns at a time. That is also how you reduce power consumption to fit into 500 mA for USB 2.0.
A RGB LED would most likely have a common anode for all three colours, which means that they would all have to be on the same row. (Cathodes on columns, anodes on rows)

For more info, you could look at the Infinity keyboards with backlighting and how the Kiibohd firmware does it. I think there are also forks of TMK and/or QMK with backlighting.
I have also seen LED matrices driven in various ways by an Arduino, which are AVR microcontrollers: those could give you inspiration, but I would not recommend the Arduino software framework for applications with critical timing. Make sure to put the code that updates the LEDs into a timer interrupt routine.
There are also dedicated LED matrix driver chips available that could interface with the microcontroller through SPI or I²C.

BTW, you don't need USB Type C to get a reversible plug. These days there are cables with reversible Micro USB plugs available. I did not know about them myself until I saw some in a store the other day. Apparently they were first introduced through a crowdfunded venture in August 2015.

[HeroXLazer]

OK. I saw on Geekhack that you just want to backlit 40 keys. What kind of LEDs have you found? They must fit inside or below (SMD) the switch you want to use.
Most full-spectrum (...) LEDs are RGB, not RGBW. Red, green and blue together makes white. That would be 40×3 = 120 LEDs.

LEDs are usually not powered all the time - instead they flicker really fast. Without flickering them, the LED light would be much too bright. It is by changing the frequency and/or period of the flickering that you would be able to adjust brightness.
On large keyboards you would flicker them by organizing them in a matrix of U columns and V rows and power only maybe one or a few columns at a time. That is also how you reduce power consumption to fit into 500 mA for USB 2.0.
A RGB LED would most likely have a common anode for all three colours, which means that they would all have to be on the same row. (Cathodes on columns, anodes on rows)

For more info, you could look at the Infinity keyboards with backlighting and how the Kiibohd firmware does it. I think there are also forks of TMK and/or QMK with backlighting.
I have also seen LED matrices driven in various ways by an Arduino, which are AVR microcontrollers: those could give you inspiration, but I would not recommend the Arduino software framework for applications with critical timing. Make sure to put the code that updates the LEDs into a timer interrupt routine.
There are also dedicated LED matrix driver chips available that could interface with the microcontroller through SPI or I²C.

BTW, you don't need USB Type C to get a reversible plug. These days there are cables with reversible Micro USB plugs available. I did not know about them myself until I saw some in a store the other day. Apparently they were first introduced through a crowdfunded venture in August 2015.

They are RGBW LEDs, and I will have holes in the PCB and mount them in the PCB. RGB doesn't have the best white by itself. I was thinking about using a LED driver, but the problem is I can't find any really thin RGBW LEDs without ICs. The reason I wanted Type C, was USB 3.0/3.1. I don't really care about the reversibility,

[pomk]

What benefits do you see from using USB 3 protocol for your keyboard? The power transfer does not require you to use USB 3 protocol for the keyboard communication, at least for USB Type C.

[vvp]

I can imagine only two reasons to go with USB 3:

• The keyboard is used by an avid gamer who already uses latency free hall switches (or something similar) and also wants interrupt transfer latencies smaller than 1 ms.
• The keyboard si going to serve also as e.g. a mass storage device and one just wants bigger speeds for it.

[pomk]

Ah, yes, the interrupt like protocol. I would really like to see how the entire thing would work. I guess a custom driver plus some kind of a virtual HID to get the operating system to work with it. I'm not sure if going past the 1 ms latency is really worth it, considering that the operating system might have already some HID related interfaces capped to some frequency that is not easy to modify, at least on a windows machine. On linux one might actually get better performance if you go deep enough with the OS side integration.

[vvp]

Well, I'm planing to stick with simple Full Speed USB. Trying anything else sounds like waste of money to me. I'm also quite satisfied with Cherry MX switches which themselves debounce in 5 ms (if one wants to be very conservative about switch state changes and keep more resistance from noise). I only pointed out what may be the reasons to go for SuperSpeed(+). I'm definitely not going to do it myself in the foreseeable future.

Based on a simple google search, people reported interrupt latency times in the range of 30 - 50 µs with USB 3. This excludes HID drivers on the host. I did not do anything with USB 3 myself. I use only off-the-shelf USB 3 mass storage devices.

I do not know whether USB 3 keyboard may need a new OS driver. I kind of assume the standard HID drivers would work also with USB 3. If a new driver is needed then it is a complete deal breaker for me. I do not want a keyboard which requires special drivers.

[pomk]

I haven't been able to find any HID examples that would use USB 3+, so I just assumed that it might require custom drivers. I guess we will see as razer must eventually create a 100 W LED monster keyboard with 'turbo interrupts (tm)'.

[Sigmoid]

Well as far as I understand, USB is mostly built on backward compatibility... I guess the main reason there isn't much talk about USB 3.1 HID is that HID is still probably mostly happy even on USB 1, let alone 2.0. I'd assume if the mcu itself is USB 3.1 compliant, and the computer / OS too, then from a programming perspective, the HID protocol should be identical to HID on 2.0...

I do wonder though btw, have any of you looked at the possibility of adding a built-in USB hub to a keyboard? I am a huge fan of the extra USB port for the pointing device on old Apple keyboards.

[vvp]

I guess we will see as razer must eventually create a 100 W LED monster keyboard with 'turbo interrupts (tm)'.

ROFL, nice one!

I do wonder though btw, have any of you looked at the possibility of adding a built-in USB hub to a keyboard? I am a huge fan of the extra USB port for the pointing device on old Apple keyboards.

I looked at it about 2 years ago and I did not find cheap enough chip in small quantities to do it on farnell at that time. It looked like getting a small 4 port hub and mount it into a keyboard would be cheaper. But farnell does not stock much and I may have been unlucky.

[pomk]

For usb 1.1 and 2.0 there is a separate communications channel, meaning that even if a usb 3 controller can implement a backwards compatible HID, it will just run on the old protocol without any of the improved features. There are some examples of this in cypress usb 3.0 sample library.

[Sigmoid]

But power is independent of the data exchange protocols, isn't it? You can negotiate 3.1 power delivery and talk 2.0 HID protocol, no?

[pomk]

yes, and for that you don't even need a usb 3 mcu, as the power delivery negotiation is sort of separate. A 70 cent chip like tusb320 from TI is enough for that.