RFI(nput): RGB Backlight Support

[skullydazed]

I'm beginning work on a PCB that supports fully addressable RGB backlighting. This seems to be new territory for a QMK keyboard, so I'd like to get the community's thoughts to make sure it's implemented in a way that's supportable long term.

There aren't any shipped examples I can find yet, but I have not done an exhaustive search. So far RGB support seems limited to commercial keyboards.

Project Aurora was created and published on github, it uses the 31FL3732 to control the RGB matrix. I think that two 31FL3737's would suit my purposes better, but other than addresses being different they're the same basic protocol. MCU communicates with the chip over i2c to set individual LED brightnesses or activate certain modes by writing to registers.

Another option I have looked at is the WS2811. However, they're $0.49/ea, unless you buy a very large number directly from the manufacturer. This is attractive because I can use the existing ws2812 support for this. It's a tight fit, but I should be able to route the board with one of these next to every switch. If I can buy them in bulk the cost per PCB is only $2 more than 2 31FL3737's.

I think this may intersect with #717 and #895.

[fredizzimo]

I can't give any comments about the hardware, but a little bit about the software.

The Infinity Ergodox do have fully addressable backlighting, but not RGB, just for a a single color. Currently the support is only halfway there in QMK and not properly integrated, but in the port of TMK I had it working. But even if it's not in use, the code is included in QMK , the led_test.c file has the example code that I wrote, and the file gdisp_IS31FL3731C.c contains the code for the actual LED driver.

The code exposes the LEDs as a virtual ugfx display, which makes it possible to use higher level functions like drawing circles, or even text. The same approach would work with RGB as well, we would just expose RGB "pixels" instead of grayscale ones.

This was integrated into the visualizer system, which is not fully ported to QMK. I still haven't got the fully working new effect system working though, mostly because I keep changing my mind about the code design for it. However I think I have managed to simplify the design enough now, so I hope to get something running during the Christmas holidays. Before that I can describe my current design in more detail in #717, it will be much more simple than what I previously proposed there.

UGfx will use quite much memory though, and the effect system will use threading to make sure that the scan loop is unaffected by complex visual effects. So you would most likely need some more powerful micro-controller, probably some of the ARM ones that are supported by ChibiOS.

[wilba]

I used 2x 31FL3731 (almost identical to the 31FL3732) on the Zeal60, since the package was slightly smaller and it's more available. The charlieplex matrix is a little bit harder to route optimally, but does result in less tracks. Adafruit makes breakout boards and there's driver code for Arduino, so it's a little bit easier to get started. However, they make an audible buzz around 8kHz which is a little bit annoying. I am looking at alternatives for Zeal60 rev 2 and other designs... 31FL3737 looks promising, but most likely I won't be able to route this in 2 layers.

WS2811 for every switch is crazy ;-) Someone on GH did a 40% board like this, but it's a brute-force solution that's way more expensive than it needs to be, should you get to a point of a production run, where there's the added cost of placing the parts (note: you would also need one resistor per IC to control current, plus bypass capacitor).

FWIW my Zeal60 code will be available soon should you want to have a look. It is all at the keyboards/zeal60 level (no impact on QMK) but some of that could be refactored if there are other PCBs that want to use some or all of that code.

[skullydazed]

@fredizzimo: I'm already planning to use arm for this board. Figuring out which mcu to use is my next big task. :)

@Wilba6582: I was talking to zeal about that problem earlier. It makes me think that finding a different led matrix controller family is a good idea.

[skullydazed]

For the sake of completeness I should probably describe another option- rolling my own. I could use a separate arm or avr processor and write a dedicated firmware to handle the lighting. This approach is fraught with problems and more work than using a pre-canned LED controller, but it gives us ultimate flexibility.

[wilba]

@skullydazed May not need to, 31FL3737 is running a different frequency so won't have a noise issue. Roll your own has it's own set of problems - PCB space, complexity... how to get the 2nd microcontroller programmed by user (or is it factory programmed and "locked in"), etc.

[priyadi]

My handwired keyboard uses SK6812mini LED strip for indicator lights and per switch RGB LEDs.

I propose that we create a standard interface for controlling individually addressable LEDs. QMK would provide the interface and generic implementation for supported controllers if possible. Keyboard designer would provide keyboard specific information: controller types, LED names, type of LEDs being used (single color, RGB, RGBW), etc. In keymap level, then there should be minimal differences across keyboards of different type.

On top of that layer, then we can have things like generic layer indicator, backlit modes, interface with client software, etc.

[PureSpider]

Do you absolutely need to use a matrix controller?
Why not use LEDs that have the controller onboard, like the WS2812 or SK6812mini like @priyadi said?

Would it be a good idea to build LED support on top of fastled.io for QMK?

[skullydazed]

@PureSpider: My goal is to use 4 pin THT RGB LED's in this board. That precludes a WS2812 or similar device. We did explore the WS2811 but the overall cost for parts is $2 more, and that doesn't include PnP time. I don't want to use SMD LED's that shine through the switch housing because I want to use either selective soldering or wave soldering in the future and that limits my choices when it comes to switch housings.

We already have support for RGB underlighting via WS2812 strips. It may be a good idea to replace that with fastled.io, but we should open a separate issue to talk about that.

[skullydazed]

I'm going to close this issue for now. Thanks everyone for weighing in. I'll focus on the 31FL3737 for now, and when it's time to do the software side I will use @fredizzimo's effect system. Now to go figure out which arm processor best meets my needs. :)

[PureSpider]

I'll leave this here ;)

[fredizzimo]

Another thing that comes to my mind is that, it would be really cool if the LED controller would be 16 bit per channel instead of 8 bit. Or alternatively if it already did some lightness linearization process (commonly wrongly called gamma correction) in hardware.

8-bit looks very bad especially at lower brightness, since the steps becomes too big, and the human eye can easily see the smallest possible changes.

But we should probably implement temporal dithering, and then it wouldn't be a problem any more. More CPU power has to be used to refresh the LEDs frequently though, so a powerful CPU is needed. The Infinity Ergodox is already quite busy at 72Mhz without that, but mostly because there's no DMA transfers implemented(missing from ChibiOs) for the various communication buses that it uses. So support for that is probably another thing to look for when choosing the CPU. That means that some of the STM CPUS are a better bet than the Kinesis ones, as STM is officially suported while Kinesis is community supported.

[skullydazed]

@PureSpider: If only I could use 5mm in a keyboard switch. :)

[wilba]

My implementation of RGB backlight is here, in case anyone is interested:

https://github.com/Wilba6582/qmk_firmware/tree/zeal60

[joedevivo]

@Wilba6582 I've heard the buzzing from the IS31FL3731 on the Adafruit breakout board, but I don't hear it on the rev2 Zeal60. How were you able to stop the buzzing in rev2?

[wilba]

@joedevivo for caps >1uF, switch to tantalum instead of MLCC (ceramic). Zeal60 has three 10uF tantalums, one near each IS31FL3731 plus one near the USB connector.

[joedevivo]

Ahh, the Adafruit breakout has some 10uFs. I made my own based on the reference implementation in the IS31FL3731 datasheet, and the largest cap is 1uF and it's also quiet. Thanks for the explanation.