4.3" and 5.0" IPS TFT 16bpp adapters for Platform/Eval/Edge
Rayman
Posts: 14,752
Just got to work testing some prototype TFT LCD adapters for two header Platform/Eval/Edge type setups.
A very long time ago did something like this in 24 bpp with 480x272 resolution, using two octal buffer to help hold the data from 8-bit bus.
That was fine, but now there are 800x480 resolutions version of the 4.3" and 5.0" IPS TFT displays.
P2 isn't fast enough to do 24 bpp on these.
So, new version is 16bpp with just one octal buffer chip. This should let us do 800x480, if math was done right...
Thinking this will work great with the 16bpp PSRAM GUI also being worked on...
Idea was for this to work on the new Platform board, but also the Eval and Edge.
Now that have it though, it's pretty clear that the header side interferes with stuff on Eval and Edge.
Have to remember to fix that in next version...
Comments
Some perhaps questionable additions to the design are Nunchuck and QWIIC connectors on the outside edge.
Thinking about dropping that... But, might keep as Nunchuck is basically free and QWIIC is fun and cheap to add...
These give additional purpose to the I2C bus...
Is there a way to layout the QWIIC and Nunchuck connectors such that you can't plug into the QWIIC when the Nunchuck is plugged in?
Guess could add a solder bridge for power…
Is there a problem with both connected?
Bus speed limit maybe?
Need to get one of those new round displays too…
Maybe can adapt this to work with that…
Just found a "feature" in the 800x480 resolution screens that didn't expect...
Was thinking the pinout was the same, except for Pin#35 that was Analog Vdd for a resistive screen now being N/C because there is no resistive version.
First page of datasheet looks like this.
But, second page of datasheet says the Pin#35 is Built In Self Test, that is activated when high.
Was wondering at first why the screen was showing some test patterns that wasn't programmed...
So now have a bit of a quandary... If want to support the resistive touch version of 480x272 screens, will need a different version of the board or a solder switch...
Hmm... Also just realized that 800x480 resolution without PSRAM might not be possible.
At least, not without major modifications.
Would need to be 8bpp with LUT for sure. And, that is slow without streamer...
Depending on the resistance it expects and current requirement, perhaps the P2 IO pin can source the Vdd for the resistive touch and behave as an input when first powered to somehow auto detect the type of screen, or manually drive it from settings for the type of LCD fitted. You can just add a pull down low resistance to this pin via IO port settings, to keep BIST low.
Typically the resistive touch panels just have X+/X- and Y+/Y- pins you can control directly with P2 IO and read back with ADC's, so not sure what this Vdd is unless it powered an on board touch controller reporting via I2C perhaps?
@rogloh These are good ideas, but there are no free pins here.
Well, actually in DE mode, vsync and hsync may not actually be needed.
So, if gave up I2C also, would have 4 free pins. But, still not enough to both power resistive touch and make measurements on it....
Actually suppose 4 free pins might be enough…. Might have to try that one day…
In a desperate attempt to avoid using the streamer here, appear to have found a way to use the smartpins to pulse the pixel clock and upper data latch pins:
So now, only need one instruction to toggle the LatchPin and PClkPin instead of two inside the main visible data output loop:
DAT 'HVisible - Visible data output HVisible drvh #DePin 'can have 9 instructions besides the drvh/l and have ~10 MHz dotclock with 250 MHz clock 'RJA 21Dec24: Attempting to use smartpins to speed loop rep @.end,#xpixels rfbyte clr2 rfbyte clr1 setbyte baseport,clr1,#basebyte wypin #1, #LatchPin waitx #0 setbyte baseport,clr2,#basebyte wypin #1, #PClkPin waitx #0 .end drvl #DePinThis is letting us get 62 Hz refresh @180 MHz P2 clock.
Will have to tweak the waitx values for higher P2 clocks...
This is for the 480x272 resolution IPS display.
This should let me do the 800x480 version at a reasonable P2 clock and refresh (hopefully).
Got 800x480 working with 54 Hz refresh at 320 MHz P2 clock.
It looks good and really don't see any flicker with much lower clock rates.
Had a bit of trouble making it work, but inverting pulse polarity and triggering before setting the data seems to be working:
DAT 'HVisible - Visible data output HVisible drvh #DePin 'can have 9 instructions besides the drvh/l and have ~10 MHz dotclock with 250 MHz clock rep @.end,##xpixels rfbyte clr2 'Note: 24 bit bitmap is stored in order: blue, green, red (but we need to reverse that) rfbyte clr1 wypin #1, #LatchPin setbyte baseport,clr1,#basebyte wypin #1, #PClkPin setbyte baseport,clr2,#basebyte .end drvl #DePinPracticality of the 800x480 driver/display is questionable without PSRAM.
This test image takes up most of hub ram and only covers half the screen.
Could working in 8bpp and have another cog convert from 8bpp to 16bpp by scanline though.
https://en.wikipedia.org/wiki/Blue_jay#/media/File:Cyanocitta_cristata_cyanotephra,_Lubbock,_Texas_2.jpg
Hard to get a good photo of screen with iPhone... Screenshot below shows some hashing that isn't really there...
Yeah half size on screen is not ideal. Might be better to line double in that case - though that gives non square pixels of course. PSRAM is the way to go for higher resolutions & depths. A single 4 bit PSRAM is probably good enough too. In my prior P2 LCD "tablet" project, I designed in a single 4 bit PSRAM with that use in mind in order to avoid excessive hub RAM use. Have to get back to that at some point once I release my video driver with parallel LCD RGB mode and can test it out again.
https://forums.parallax.com/discussion/comment/1532340/#Comment_1532340
That is another way to go... Using just one PSRAM chip would free up plenty of pins for direct 16-bit interface, instead of this multiplexed 8-bit bus... That would make 70 fps easy... (Think this display does 70 Hz, but maybe not, have to check...)
Just remembered that perhaps a better option for all of this is just to use the HDMI version...
But, that is $112 vs $72. Guess that's the major reason not to...
Working on an 8bpp version for the 800x480 displays.
Having to create a 16-bpp line buffer for this and will use another cog to translate from 8bpp to 16bpp on the fly.
Don't want to have to require PSRAM to be able to use the display...