touch and display example for STM32F469I-DISCO B08 board revision (NT35510 LCD controller)#843
touch and display example for STM32F469I-DISCO B08 board revision (NT35510 LCD controller)#843Amperstrand wants to merge 2 commits intostm32-rs:masterfrom
Conversation
Works and tested on STM32F469I-DISCO B08 board Resolves stm32-rs#842 Based on STMicroelectronics/STM32CubeH7@1c84713
Now also with touch support. To see touch inputs, run with ``` cargo run --release --example f469disco-lcd-test --features="stm32f469,defmt" ``` stm32-rs#842
tegimeki
left a comment
tegimeki
left a comment
There was a problem hiding this comment.
Glad to see support for the newer display, and have some comments on compatibility with the older one. A more modular BSP-level display support approach might resolve these issues, allowing code to first probe the display type with a minimal DSI host config and then initialize for the specific display from there.
| // Try to read RDID1 register - we don't care about the data, just if the command responds | ||
| // This matches the C reference behavior: nt35510_read_reg with length 0 |
There was a problem hiding this comment.
Note that the OTM8009A display does actually respond to this query, and returns 0x40. To make this example run on a board with that display (the only one I have), it was necessary to check the value... but since I don't have the NT35510 display I can't tell what the expected value actually is. The ST Micro C code looks incorrect though, as it seems to check against 0x00 so maybe the check should be explicit here.
| None, | ||
| PixelFormat::ARGB8888, | ||
| DISPLAY_CONFIGURATION, | ||
| NT35510_DISPLAY_CONFIG, // NT35510 timing works for both controllers |
There was a problem hiding this comment.
Based on the one board I tested on, it's true that this config works for ORM8009A, but is probably not optimal for that display given the longer sync times v.s. the spec. Since probing can't be done until the DSI interface is up, which requires the timing to already be known, I wonder if a #[cfg] for the display type would be better, even though it's not dynamic (i.e. you would need to target specific hardware v.s. detect at runtime)?
2 participants
NT35510 could possibly be its own create like otm8009a is.
Alternatively it could be part of stm32f4xx-hal in src/nt35510, kind of like there is a module for src/fsmc_lcd
I'm not much of a rust person, and my main goal was just trying to get it to work (which it seems to)