STM32: Displayio #2352
STM32: Displayio #2352
Conversation
|
Please post the full Saleae captures somewhere. I usually start at the reset and compare from there. Make sure the capture has the Reset and Data/Command lines as well as Clock, Enable (aka Chip Select) and MOSI. |
Hmm. On my M4 Express, I don't see any activity on the reset line, when operating or soft/hard rebooting. |
|
Saleae Captures (for REPL screen shown on keyboard interrupt): Seeing some pretty clear differences that could be related to pin pull settings. Digging. |
|
I'd suggest slowing down the display when debugging to 1 mhz. If it works then you know it's a speed issue which I've seen when using jumper wires to a display. It also ensure the Saleae can keep up. Pin pull settings should be off because SPI doesn't use pulls at all. |
|
@tannewt I mentioned pin pullups since looking at the data it was one of the few differences between the two implementations on the MOSI line. Atmel brings the line up by default, while STM32 just kind of leaves it wherever the last bit was. After doing some reading, though, I see there's really nothing in any spec that indicates it would matter. I'm more concerned about the clock line: I'm kind of confused about the Atmel one - if you showed me that signal by itself, I'd assume it was badly out of sync. But evidently it works. And in at least the clock signal is broken into bytes. The STM32 clock seems pretty off to me, though. In the 25MHz sample it's grouped in 16 bit intervals, despite the SPI peripheral being correctly set to 8 bit words. And in the 1MHz example, it doesn't appear differentiated into bytes at all. I assume that's an issue? |
|
@hierophect It does look weird. Is that in the file you sent me? What display breakout are you testing with? Some that support I2C will tie MOSI and MISO together for SDA. The gap between clock bursts is an artifact of the internal memory transfer rate and size. That is why the STM is 16bit bursts, internally the driver is writing two bytes at a time. It disappears in the 1mhz example because the internal transfer is faster than the SPI. Does the screen still fail at the 1mhz rate? Could you send me a capture of that? Try adding a reset pin if you can too. That way you know the display's controller chip is in a known state. |
|
Fixed. It turned out to be a phase issue. Unlike flash, DisplayIO doesn't currently specify the polarity, but instead fetches whatever the "default" is, which isn't a defined property. In the STM32 implementation, that default wasn't 0,0, which is required for the TFT to work. @tannewt I've changed the default, but I'd suggest we either add phase and polarity to the Fourwire construct like Baudrate, or make sure they're set to 0,0 by default as a safety measure. |
|
@ladyada bin 4 u |
|
woot testing nao! |
|
@hierophect This looks good to me. Let's also make sure that the SPI objects always default to 0,0 as well. If they had, then this would have worked. |
|
tested bin with 2.4" featherwing. REPL terminal and drawing work well - nice work :) |
DisplayIO is back! And... still buggy. Works for the SSD1306, but not the ILI9341 TFT as used on the TFT Featherwing.
A control Saleae for the Atmel M4 Express Feather looks like this:
One block of data:
Subblock
SPI on the Feather looks a bit different:
Subblocks are a lot larger, and send different (wrong?) data
I'm concerned it might be trying to go too fast. The Atmel version is only going at 1MHz, while the STM32 is at 4MHz. The datasheet for the ILI9341 says it should be good up to 10M on writing only, though. I presume the settings for speed are handled by the ILI9341 library, since it isn't exposed in the python code.Wasn't running Saleae fast enough, I see in FourWire that the display is substantially overclocked at 25MHz on both devices.I'd welcome more input from anyone more familiar with the ILI9341 screen and any quirks it might have with regard to SPI operation.
This should resolve #2308 when solved.