Qmk_firmware: [Feature Request] Port Adafruit ST7565 LCD code

Created on 28 Feb 2019  路  13Comments  路  Source: qmk/qmk_firmware

Feature Request Type

  • [ ] Core functionality
  • [X] Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
  • [X] Alteration (enhancement/optimization) of existing feature(s)
  • [ ] New behavior

Description

So we can shuck the chains of uGFX (namely, the licensing issues that it has with distribution).

Adafruit seems to have some sample code for AVR, that appears to be LGPL licensed, so compatible with distribution. I'm not a lawyer, nor familiar with licensing enough. Somebody that is should verify this.

https://www.adafruit.com/product/250

And sample code here:
https://github.com/adafruit/ST7565-LCD/tree/master/c

This would (in theory, and according to skully) would allow us to discontinue use of the uGFX library finally, and "ship" the firmware on the configurator.

enhancement help wanted to do

All 13 comments

So did a review of what is using uGFX in source and why. There are two keyboards that use it today: Ergodox Infinity & Whitefox. The Ergodox Infinity uses it for LED & LCD support, while the Whitefox uses it for just LED support. Looking at the adafruit sample code, I think it can be converted, however the ST7565 LCD or anything similar to that is no longer available to purchase. So testing / supporting this is going to be quite a pain. I'll still be giving it a shot, but those keyboards still need to be switched to led matrix or something else as well.

@skullydazed @jackhumbert, if we can get this working, and tested, would it be okay/good to convert the boards using uGFX to the LED Matrix and this code and completely gut uGFX?

This issue has been automatically marked as resolved because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.

@firetech Since you've been doing some cleanup of the ergodox infinity...

I don't know your skill level, but if you want to take a hand at this, it would help us get off of uGFX. If it's too much for you, don't worry about it, at all.

@drashna In theory, I might be able to do it (no idea where to start, though). In practice, I rarely have the free time to take on such big projects...

~Also, porting just the LED matrix stuff wouldn't completely gut uGFX, Ergodox Infinity uses it for its LCD displays as well. Not sure how everything clicks together there...~

EDIT: I see now that the linked sample code is related to LCD displays and not the LED control, so I guess porting that would (in theory) solve the display issue, but I don't see any example code for LED control there?

The LED matrix control I believe is for the IS31FL3731C; it seems to be almost identical to the IS31FL3731, which we appear to already have a monochrome LED matrix driver for: https://github.com/qmk/qmk_firmware/blob/master/drivers/issi/is31fl3731-simple.c

http://www.issi.com/WW/pdf/31FL3731.pdf
http://ams.issi.com/WW/pdf/IS31FL3731C.pdf

So if we can reuse that, this part may be easier than originally thought.

Exactly. The Jed matrix may be tricky. But the harder part is the LCD, imo.

But if you don't have the free time, don't worry about it! Only try if it doesn't interfere.

It is an intriguing project, but after looking at the code a bit, I must admit that some of the involved magic is (currently) a bit beyond me... That usually doesn't stop me from trying, but it'll probably take me a while to understand how everything works here. While I do like low-level coding, I'm usually more of a high-level guy.

I have some high-level questions though. If the LED control can be switched to the LED matrix driver, I guess the LED parts of the visualizer system becomes more or less obsolete and can be scrapped? What about the LCD (and LCD backlight) parts? Should the visualizer be ported away from uGFX but otherwise left as is or should the LCD support be handled more like OLED support, deprecating/scrapping the visualizer system? Both choices would probably be breaking changes, since a few custom visualizers use uGFX functions directly. It might, however, be interresting to make the visualizer system more generic and (in theory) usable for OLED displays as well?

It might, however, be interresting to make the visualizer system more generic and (in theory) usable for OLED displays as well?

And that's kinda what I was aiming for with the Quantum Painter API:
https://github.com/tzarc/qmk_build/tree/master/inject-root/drivers/quantum_painter

The intention there is to provide a replacement for uGFX, with low-level backends that can be abstracted away using a common API... maybe it's worth deferring until I get that finalised?

And that's kinda what I was aiming for with the Quantum Painter API:
https://github.com/tzarc/qmk_build/tree/master/inject-root/drivers/quantum_painter

The intention there is to provide a replacement for uGFX, with low-level backends that can be abstracted away using a common API... maybe it's worth deferring until I get that finalised?

That sounds like a plan, but what I see in your code there doesn't really replace the visualizer system. That's more high-level (on top of uGFX, currently), for handling animations and display updates (cycling between multiple screens, for example). As I see it, the visualizer system could (should?) probably be updated to work on top of Quantum Painter.

As I see it, the visualizer system could (should?) probably be updated to work on top of Quantum Painter.

Bingo, you got it.

"LED" in the title should probably be replaced with "LCD", btw. 馃槈

Maybe slightly off-topic for this issue, but I've got LED_MATRIX running on my Ergodox Infinity now (instead of uGFX), using the already existing is31fl3731-simple driver mentioned above, i2c support from #7591 and some configuration. I created a draft pull request with the changes I made so far, as seen above (#9657). That part was, as @fauxpark suspected, quite easy.

It makes sense to wait for the Quantum Painter API before trying to ditch uGFX for the LCD displays, though.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

henrebotha picture henrebotha  路  4Comments

vokeio picture vokeio  路  3Comments

michaeldauria picture michaeldauria  路  3Comments

helluvamatt picture helluvamatt  路  4Comments

jmagee picture jmagee  路  3Comments