-
Notifications
You must be signed in to change notification settings - Fork 8.4k
drivers: display: features for ILI9341 driver #99267
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?
drivers: display: features for ILI9341 driver #99267
Conversation
| enum madctl_cmd_set { | ||
| CMD_SET_1, /* Default for most of ILI9xxx display controllers */ | ||
| CMD_SET_2, /* Used by ILI9342c */ | ||
| CMD_SET_2, /* Used by ILI9342c & ILI9341 */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you verified that display orientation works with this change? Assuming that is why it was made
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using CMD_SET_2 the display orientation works as described on the documentation . To verify it, I set a small delay between the squares rendering, comment the display_blanking_off and put it at the beginning. It was shown how each square was appearing according with the order set up on the script, showing the behaviour described on the document: clockwise, from TOP_LEFT(RED) to BOTTOM_LEFT(GRAY SCALE). I used RGB888 for the example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should add the delay between the squares in the sample, seems useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do that on this PR? or is better left it for another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do that on this PR? or is better left it for another PR?
Out-of-scope for this one
b56244b to
26a3faf
Compare
57da9df to
4515947
Compare
d61b23e to
f2934f8
Compare
|
@JarmouniA All checks have passed |
| mipi-max-frequency = <30000000>; | ||
| reg = <0>; | ||
| pixel-format = <ILI9XXX_PIXEL_FORMAT_RGB565>; | ||
| pixel-format = <0x20>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use the macros PANEL_PIXEL_FORMAT_...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I used the macro, all the of the boards with this macro didn't compile, that was causing the CI failures. All of these files had the panel.h header but the macro wasn't recognized. That's why I used the hardcoded hex value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these files had the panel.h header but the macro wasn't recognized.
That's strange. Push a commit on top with the macros and I will have a look at the errors in CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The errors in Twister Build 2 are unrelated to the PR https://github.com/zephyrproject-rtos/zephyr/actions/runs/19791231302/job/56721806874?pr=99267
arch.arm.interrupt.no_optimizations on bl5340_dvk/nrf5340/cpuapp error (Build failure - collect2: error: ld returned 1 exit status)
INFO - 2) arch.arm.swap.common.fpu_sharing.no_optimizations on bl5340_dvk/nrf5340/cpuapp error (Build failure - collect2: error: ld returned 1 exit status)
INFO - 3) arch.arm.swap.common.no_optimizations on bl5340_dvk/nrf5340/cpuapp error (Build failure - collect2: error: ld returned 1 exit status)
INFO - 4) arch.arm.interrupt.no_optimizations on bl5340_dvk/nrf5340/cpunet error (Build failure - collect2: error: ld returned 1 exit status)
The same for Build 3 https://github.com/zephyrproject-rtos/zephyr/actions/runs/19791231302/job/56721806879?pr=99267
arch.arm.swap.common.no_optimizations on bl5340_dvk/nrf5340/cpunet error (Build failure - collect2: error: ld returned 1 exit status)
The way forward is to check if there are already open issues regarding these failures, and comment on them to notify the people involved that the issues are CI Blocker so they get prioritized.
Otherwise create new bug issues for each test failure and I will mark them as CI blockers.
f2934f8 to
7f69175
Compare
ff4ccbc to
7c7a41c
Compare
7c7a41c to
b0f5090
Compare
ILI9341 is not deploying correctly the display sample. The screen looks mirrored vertically and the color doesn't match with the sequence expected. To fix it, change the Memory Access Control configuration data. Signed-off-by: Nicolas Moreno <[email protected]>
Replaced display-controller.yaml with lcd-controller.yaml Deleted pixel format property, replacing it with the property on lcd-controller.yaml. Replace ILI9XXX RGB macro with PANEL RGB macro. Also, added condition to verify pixel format is RGB565, BRG565 or RGB888, otherwise it will show error Replaced <zephyr/dt-bindings/display/ili9xxx.h> with <zephyr/dt-bindings/display/panel.h> and ILI9XXX_PIXEL with PANEL_PIXEL in some Devicetrees and files that contained both elements. Fixed some script sintax. Deleted drivers/display/display_ili9xxx.c Signed-off-by: Nicolas Moreno <[email protected]>
Added documentation for doc/releases/migration-guide-4.4.rst in reference with the changes on ili9xxx and ili9341 controllers Signed-off-by: Nicolas Moreno <[email protected]>
b0f5090 to
293722a
Compare
|
I'm currently having issues locally trying to compile
These are failing on the CI. I pushed the code to see if these issues persists. In that case, Should I add another commit or create another PR to fix them? |
|
See #99267 (comment) the Assert failure is already addressed in main I believe #100769, and the PSA one as well #100835 |
|
@JarmouniA it worked, all checks have passed |
JarmouniA
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!




Overview
This PR adds some features on
zephyr/driver/displayfiles related withili9xxxheaderFeatures Implemented
modification on
display_ili9xxx.canddisplay_ili9xxx.hfilesadd condition to select BGR/RGB color order depending on pixel format
change CMD_SET for ILI9341
Files Modified/Added
zephyr/drivers/display/display_ili9xxx.c- changes made on MADCTL registerzephyr/drivers/display/display_ili9xxx.h- Comment modifiedzephyr/dts/bindings/display/ilitek,ili9xxx-common.yaml- Added BGR565 value on enumzephyr/include/zephyr/dt-bindings/display/ili9xxx.h- addedILI9XXX_PIXEL_FORMAT_BGR565on pixel formatFixes #99134