You need to locate where it is locking up exactly. It it happening when making the callback to tell LVGL the display has been flushed? Or is it locking up when reading the touch? So much takes place internally in LVGL when the task_handler is called I really need specifics on where the lockup is actually happening.
Thanks, Iāll try it today.
Yeah, Iāve been trying to figure out how to troubleshoot it. Iāll let you know what I figure out tomorrow. When it happened, I repeated it a few times checking the Python code along the way, but I just moved on to working on drivers.
Iām pretty confident it isnāt during the touch read since it doesnāt do it in blocking mode. Thatās about all I know, though.
Yes you are right. The rotation should be determined not by changes in width and height, but rather by the rotation parameter. And this must happen in one place. The problem was that in the driver it was not necessary to change the width and height, it was enough to indicate the rotation. But LVGL knows nothing about this.
@bdbarnett In the current implementation, in order to rotate the screen from portrait to landscape, I had to:
- In board_config.py when creating ST7796, pass rotation=-2
- In lv_driver_framework.py, swap the width and height when creating the display:
self._disp_drv = lv.display_create(self.display.height, self.display.width)
It seems to me that screen rotation needs to be set when creating the DisplayDariver, or should it analyze whether rotation is set in the passed driver and, based on this, set the width and height in lv?
ŠŠ½Šµ ŠŗŠ°Š¶ŠµŠøŃŃ
The way Iāve been doing it in testing is when rotation is odd (-1 and -3), width is 320 and height is 480, and when rotation is even (-2 and -4), width is 480 and height is 320, all in board_config.py. I havenāt had to change anything anywhere else. Iām in the process of implementing your suggestion for keeping the width and height set to always 320w x 480h and only changing the rotation. Should have it to you tomorrow (itās 1:00am here).
I have an idea about how to make setting the orientation possible. I am going to have a better look at it and see what I can come up with.
I was thinking just save the settings as self._width and self._height that never change, then create @property functions for .width() and .height() that return their associated setting (_width for width()) when rotation is odd, and return the opposite (_height for width()) when rotation is even. I just started implementing that, but Iāll wait if youāre going to do it. The only issue with that is if for some reason the rotation is set by madctrl directly (positive value) instead of from the lookup table as a negative value.
That was easier than I thought. @Alexandr, please download busdisplay.py again. You should be able to set the rotation but leave width=320, height=480.
I am working on the display rotation as well. You are going to love the solution I am putting in place for this. It is going to allow dynamic rotation of the display taking care of LVGL, the touch driver as well as the display driver all using a single entry point.
Hey man, a few things to catch up on.
As you know, I split your display_driver_framework.py into 2 files a few weeks back: busdisplay.py and lv_driver_framework.py. I have been keeping them updated with the changes you make to display_driver_framework.py, but Iām not going to incorporate your latest changes regarding rotations because I donāt think itās necessary to be able to change rotations on the fly. I may do that later, but I donāt want to make the 2 files any more complicated than they need to be. Changing the rotation=x parameter in setting up the display with my 2 files also changes the rotation of the touchscreen AND doesnāt require changing width and height. The only disadvantage is you canāt change them on the fly.
I changed rotation to be 0, 90, 180 and 270 integers instead of negative values in both the display and touch classes. Just makes more sense to me. It will actually accept any positive or 0 integer and round down to the closest increment of 90. It will also accept rotations greater then 270 and wrap them around based on the number of rotations in the rotations table, so if the rotations table has 4 entries, 360 becomes 0, 450 becomes 90, and so on. Completely unnecessary, but it didnāt require any extra work and it allows for any positive or 0 integer to work.
I came across a display that was mirrored using the existing 4 rotations, so I created a second rotation table and added a mirrored=bool parameter to the display that chooses one or the other of the rotation tables. The way it is implemented, it also allows being overridden with a custom rotation table in the display driver. It also accommodates projects that may need the display mirrored, such as a heads up display that needs to be reflected off a windshield. (My son had a car with a HUD and I thought this would be a perfect application.)
Iāve posted over a dozen board configs and over a dozen display drivers, along with 3 touch drivers (one simple one that I wrote) and rotary encoder drivers from Mike Teachman.
I put the 3 required files (busdisplay.py, lv_driver_framework.py and lv_config.py) and 2 optional test files (lv_touch_test.py and display_simpletest.py) in the lib folder to make it convenient to download.
Iām still using my modification to micropython.cmake at the root of lv_binding_micropython as well as new a manifest.py at the root in order to get lv_utils.py as a frozen module since Iām not using make.py. I know how to put the lv_utils.py into a modules folder thatās already being compiled in default MicroPython, but Iām hoping you will make this change in the binding.
set(MICROPY_FROZEN_MANIFEST ${CMAKE_CURRENT_LIST_DIR}/manifest.py)
I made some comments in busdisplay.py regarding extra options that will be required to support some popular SPI OLEDS. A couple of the changes, single_byte_bounds and data_as_commands, seem fairly simple to implement and would enable supporting SSD1351 and SSD1331 16-bit color OLEDs. The others donāt look so easy to implement, which means monochrome OLEDs arenāt supported. The only I2C displays I have been able to find are monochrome OLEDs, so I havenāt been able to test I2C.
I didnāt get very far troubleshooting what is happening when blocking=False. Iāve just left it at True and been working on other things. Likewise, I havenāt tested RGB displays yet. I have an Adafruit Qualia ESP32-S3 board already and have a 720x720 display that doesnāt require an init string due to be delivered Tuesday. Most RGB displays Iāve found require using either the XL9535 or PCA9554 IO expanders, but I wanted to tackle getting a display without an expander working first. Iāve already posted the XL9535 driver I found and an implementation using it in the T-RGB board config and ST7701 driver, but havenāt tested it yet. The Qualia board has a PCA9554 expander, so Iāll need to port the CircuitPython driver for it to MicroPython before I can test any other displays on the Qualia. I have a few other RGB displays on hand, but Iāll wait until I get the display coming in Tuesday working before trying any more RGBs.
The only SPI or I80 board Iām having trouble with is the T-Embed. It has a resolution of 320x170 but uses a controller capable of doing 320x240, so it has an offset of 35. I had it working on my port of Russ Hughesā drivers, but canāt figure out what I have wrong in the board config with your drivers. The display has speckled noise and lines through it, with nothing that is supposed to be shown identifiable. Iāll circle back to that board at some point.
My only big ask from you is that you spin lcd_bus into its own repo and make it a submodule of lv_binding_micropython. I think weāll be able to get more help adding bus drivers for other platforms that way, plus Iām still hoping (even if itās a pipe dream) that the drivers get picked up by MicroPython as a bundled module. @matt.trentini said the MP core devs are already looking to tackle the issue, and I think starting from what you have in place already is probably the best route.
Maybe we can meet with @kisvegabor, @matt.trentini and @andrewleech again after the first of the year, although finding a time of day that works for everyone is tough.
Continued in a new thread at MicroPython Display Drivers part 2