-
Notifications
You must be signed in to change notification settings - Fork 71
feat: implement SPIBusFast driver with 90° rotation for AXS15231B QSPI #451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- 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
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. |
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. |
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. |
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? |
@kdschlosser: yes, I use RGB as reference. |
I was able to compile a firmware with the new SPI driver and the 90° rotation works! Thank you both for your work. |
New SPI python driver:
https://github.com/straga/micropython_lcd/tree/master/device/JC3248W535/new_SPI