Skip to content

Conversation

straga
Copy link
Collaborator

@straga straga commented Sep 9, 2025

  • Add SPIBusFast bus driver with partial updates support
  • Enable LVGL partial mode instead of full frame updates
  • Implement 90° rotation with pixel coordinate transformation
  • Add RTOS task for double buffering
  • Support QSPI 4-wire interface for AXS15231B controller

New SPI python driver:
https://github.com/straga/micropython_lcd/tree/master/device/JC3248W535/new_SPI

  - Add SPIBusFast bus driver with partial updates support
  - Enable LVGL partial mode instead of full frame updates
  - Implement 90° rotation with pixel coordinate transformation
  - Add RTOS task for double buffering
  - Support QSPI 4-wire interface for AXS15231B controller
@kdschlosser
Copy link
Collaborator

I really like that you took the initiative with this.. I am sure it has given you a much better understanding of how the software rotation works and how to manage keeping the tasks in synchronization with each other to keep from corrupting the buffer data...

There is always a but... so here it is....

I would really like to provide the software rotation across all of the different available busses. The hitch is adding it without adding new bus classes to facilitate it and to only use a single set of rotation functions and task codes for all of the busses.

would you be willing to assist me with doing this? I have started doing on it several different occasions but I ended up getting interrupted with something else and didn't finish or I thought of a better way to go about it...

an additional argument would need to be passed to the init function of the bus drivers that would signal that software rotation needs to be used. that would then cause the bus driver to do the rotation. I want to move all IO related operations over to the other core so all bus types would need to run a task where the buffer gets passed over to that task to be sent to the display. that flag that gets passed to the init function would be for determining whether or not the buffer needs to get rotated while being copied to an intermediate buffer that is used for transmit. We would need something that would instruct the bus driver on how large to allocate that destination frame buffer.

@straga
Copy link
Collaborator Author

straga commented Sep 10, 2025

The approach you outlined makes perfect sense - using a single set of rotation functions and moving all IO operations to the other core will be much cleaner than having separate bus classes.

@kdschlosser
Copy link
Collaborator

It's a big overhaul of the code to make it work. If I had some help with it that would help out greatly. I started to do it on more than one occasion and ended up scraping it because I ended up making it overly complicated. I want to keep the code as simple as possible and that's the hard part. Maintainability needs to be high on the priority list.

@kdschlosser
Copy link
Collaborator

I didn't dive too deep into the code you wrote in this PR. Does it work like the RGB driver where you now have the ability to set partial buffers with LVGL or does it still need to render full framebuffers?

@straga
Copy link
Collaborator Author

straga commented Sep 14, 2025

@kdschlosser: yes, I use RGB as reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants