generic st77xx, xpt2046 driver; rp2 DMA driver; example

[eudoxos]

This PR contains

• generic pure-python driver for st77xx (7789 and 7735), with 3 models tested. The driver was written from scratch for the most part, with inspiration from drivers floating around the internet. This video only displays an arrangement of triangles, the same test is done for 3 displays, starting from the left; the other ones get artifacts, ofc, their backlight is on the same pin as I have them connected.

  

• generic driver for xpt2046 (touchscreen), created from scratch using datahseets and looking at various other driver;

• an example of using Waveshare Pico-ResTouch-LCD-2.8 (st7789+xpt2046) with lvgl;

  • the display driver can optionally use rp2-specific DMA (provided, disabled by default as it might have issues and does not seem to improve the performance — did not measure, though); the DMA driver was written by @jgpeiro.

  

Thanks to @jgpeiro for the initial implementation, @amirgon for help in this discussion.

[eudoxos]

All the points resolved, except:

• resolution being passed as a tuple, where I just find it less confusing than width+height as that depends on orientation;
• uasync is still there, as I never used LVGL without uasync.

I added the constants for rotation even though I don't find them much useful, and they are now defined independently (thoguh identically) for ST77XX_ and XPT2046_.

[eudoxos]

@amirgon no pressure, just let me know if there is something more to do. I will be happy if the PR is merged (even with some small TODOs for later) so that my brain can mark it as done and drop it from the hot storage :)

[amirgon]

just let me know if there is something more to do

I actually wasn't sure if you are still working on that or if you are done.
Could you please go over our open discussions above and comment on each? (for example, you can write you implemented something as suggested, or differently, or not at all etc.)
Then we could either continue our discussions or resolve them when we come to an agreement.

I will be happy if the PR is merged (even with some small TODOs for later)

I would very much like to see this PR merged, but I want to merge it as cleanly as possible and not to leave TODOs for later, if we can avoid that. If we leave TODOs, there is a good chance some of them will never be addressed.

Another challenge for me is that I'm reviewing most of this "blindly" without testing (because I'm not using rp2). The best thing could be to have one more reviewer go over your PR, someone who is familiar with rp2 and able to test your code independently.

[eudoxos]

Thanks for your explanation. I added explanations to resolved conversations, still see some pending comments which I wrote though (they are marked as such by github, not sure what that means).

Outstanding points:

• should hardware-driver tests (lo LVGL involved) go to example/test/st77xx-test.py or to e.g. driver/generic/st77xx-test.py? They are an important part of the driver, for the future, as any modifications/extensions to the driver later first need to be tested on the lower level, before running LVGL on it. The internet is full of drivers which don't have such testing code and it is quite frustrating. Before I put it into if __name__=='__main__': of the driver and put it in separate files on your request.
• Passing the resolution as tuple or width / height separately - I left it as a tuple for now, just for my convenience. Width/height assumes orientation whether the tuple is just sorted ascending.
• There is rp2-specific bit in the st77xx generic driver (the rp2_dma object) which is entirely optional, even on rp2. If you are not happy with the rp2-specific bit, I am happy to drop the DMA entirely from the generic driver, as I have no knowledge of the low-level stuff to do something more with that (written by @jgpeiro; this is also related to whether DMA is limited to SPI1; I don't know)
• I added the driver registration into classes ctor, it makes actually sense and makes the app code much cleaner. I use the lv_utils.event_loop now in generic-st77xx-with-2046.py but it only works with asynchronous=True for reasons I don't understand (with timer-based loop, the screen shows what it should the first time but is then unresponsive).
• The driver runs with advanced_demo (added the platform setup in there) but does not work at all, sync or async (the screen is garbage).

[eudoxos]

And yes, I understand it would be good if someone with the hardware could test and have a look, for sure. I appreciate your effort without having the hardware, really.

[embeddedt]

still see some pending comments which I wrote though (they are marked as such by github, not sure what that means).

Perhaps try to submit a review on your own PR using the "Review changes" button in the Files changed section. It seems that you have indeed left pending review comments, because we cannot see them. :slightly_smiling_face:

[eudoxos]

advanced_demo.py works nicely now. Just the colors seem to be wrong (blue shows red gradient, green shows green, red shows blue). Is it because I compiled with LV_COLOR_16_SWAP and should not, for this hardware?

[amirgon]

Just the colors seem to be wrong (blue shows red gradient, green shows green, red shows blue). Is it because I compiled with LV_COLOR_16_SWAP and should not, for this hardware?

The color distortion issue needs to be addressed.
LV_COLOR_16_SWAP is explained in the docs, and is usually needed when sending 16-bit values through SPI interface.

Your driver should verify the correct settings of LV_COLOR_DEPTH and LV_COLOR_16_SWAP and throw an error if they are incorrectly set. See an example of doing that in ili9XXX driver.

Color distortion may be a result of an error in your driver init sequence. For example selecting RGB/ BGR order. Please consult the display datasheet.

[eudoxos]

The color distortion issue needs to be addressed. LV_COLOR_16_SWAP is explained in the docs, and is usually needed when sending 16-bit values through SPI interface.

This is fixed now:

[amirgon]

Merged!

Thank you very much for this contribution.