QSPI / MIPI Support for LovyanGFX #663
Replies: 4 comments 5 replies
-
|
Thank you @tobozo .... |
Beta Was this translation helpful? Give feedback.
-
|
Would love proper support for QSPI displays as they seem to be getting more common. And i really like this library. :) And it would be very useful because a lot of projects out there use TFT_eSPI (which doesn't support it) or LFGX (which i prefer) as it's basically the same but better. For my particular display, the JC3248W535EN with the AXS15231B controller as i mentioned in my request for help works with Arduino_GFX and esp-idf Some more info on the screen here and the controller datasheet and some more here. So yeah I'm willing to test whatever i can throw at my screen, my coding skills aren't great but i can get by. I'm more of a tinkerer that likes making things and sometimes destroying things. 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
That AXS15231B datasheet is both fascinating and scary 😅
"if it ain't broken, fix it until it is" |
Beta Was this translation helpful? Give feedback.
-
|
Came across this while seeing if anything new/interesting to do with my screen had popped up. Probably not really helpful in any way but thought it was cool even though I don't really like python lol micropython_lcd |
Beta Was this translation helpful? Give feedback.
-
|
@tobozo I also find it interesting that so many of the once MIPI only amoled displays are now supporting QSPI. Could it be a nod to the ever growing maker community? Companies like DWO now not only offer QSPI variants but they also integrate the power driver circuitry so we don't have to. nik |
Beta Was this translation helpful? Give feedback.
-
|
@Shadowtrance Lovyan does offer proper support for QSPI displays - just maybe not the specific model the developer chooses. One thing I really like about Lovyan is that it exposes the hardware config (pin map, timings etc) at the sketch / main() level. You only need to delve into the library code to modify the init code sequence for a particular display (minimal modification at worst in my experience for amoled displays). And of course you'd need to make this modification to any GFX library which didn't have a specific template for your chosen display. For those using LVGL then all GFX lib options are overkill as the drawing functions are redundant since only the 'write pixels from frame buffer' function is utilized. In this case it makes more sense to distill the bus / pin / qspi setup functions from your preferred lib and roll your own driver. I have examples of this - largely drawn from Lovyan - on my github (which needs updating BTW) nik |
Beta Was this translation helpful? Give feedback.
-
|
I guess "proper" was the wrong word (either way, i didn't mean it in a bad way). But i guess i meant just more support for these displays in general. And i dug into the code a lot and other code too and the result is only partially functional on my display. See my discussion asking for help. :) |
Beta Was this translation helpful? Give feedback.
-
|
No this is all productive talk. nik |
Beta Was this translation helpful? Give feedback.
-
|
#660 Goal... to be able to use LGFX (and sorta TFT_eSPI) and all the cool projects out there that use them, bus type QSPI, display type ?, IDE platformio arduino. One project I'd like to get running is FreeTouchDeck...but it uses TFT_eSPI for some parts but there are LGFX forks floating around. It's a nice little screen but the display/touch controller is a pain in the butt...atm anway. I don't know if it's a reasonably new chip or not but I'd never heard of it before buying this screen. |
Beta Was this translation helpful? Give feedback.
-
This post was created in order to keep track of the progress with all QSPI panel device requests and related information.
You can contribute to the discussion by extending the devices/products list.
Valid QSPI support for LovyanGFX only exists as a proof of concept on a heavily modified fork.
An attempt was made at merging those changes back into LovyanGFX (see QSPI branch), but the arduino SPI library and the esp-idf underlying SPI functions evolved since the Monica project was created, and the backported QSPI implementation no longer works with recent versions of espressif core.
The default strategy is to wait for espressif to implement QSPI support with arduino-esp32 3.1.0, however espressif missed that milestone. That strategy requires to find a workaround for the missing initQuad() in Arduino SPI library.
The alternate strategy is to follow @moononournation's Arduino_GFX implementation, where QSPI uses esp-idf functions instead of relying on Arduino SPI library. However, that strategy requires that any non-panel bus driver also bypasses the Arduino SPI library to prevent any bus conflict. Consequently, going into that direction creates a significant tech debt and adds some limitations.
QSPI Panel devices
MIPI Panel devices
Known products
Pull Requests
Issues
Discussions
Persons of interest
Beta Was this translation helpful? Give feedback.
All reactions