24-bit color on 4.3" TFT using just 16 pins
Rayman
Posts: 14,640
This is pretty neat... Layout of P2Eval board forced me to think about how to use less pins.
I thought I'd try 3 octal D flip-flops... Thanks to jmg for thinking of the FIFO arrangement with shared latch pin and also that only need 2 octal flip-flops as can drive 8 bits directly.
The design files are in this thread (maybe I shouldn't have started a new one, but wanted people to see this!):
https://forums.parallax.com/discussion/169490/breakouts-for-p2-eval
At 250 MHz I have just enough time to get 60 Hz refresh and very close datasheet timings.
There's probably margin to work with a lower clock rate.
I ordered SSOP instead of TSOP flip-flip flops, so had to bend some pins to make it work..
Here's a couple photos and the P2 source code:
I thought I'd try 3 octal D flip-flops... Thanks to jmg for thinking of the FIFO arrangement with shared latch pin and also that only need 2 octal flip-flops as can drive 8 bits directly.
The design files are in this thread (maybe I shouldn't have started a new one, but wanted people to see this!):
https://forums.parallax.com/discussion/169490/breakouts-for-p2-eval
At 250 MHz I have just enough time to get 60 Hz refresh and very close datasheet timings.
There's probably margin to work with a lower clock rate.
I ordered SSOP instead of TSOP flip-flip flops, so had to bend some pins to make it work..
Here's a couple photos and the P2 source code:
Comments
A separate thread for specific LCD drive is a good idea. You should copy the design info here too.
What is the LCD resolution, and clock speeds ?
Did you try overclocking the LCD to see what it can run up to ? - some report quite high over-clock headroom.
Two of the 16 pins used are actually I2C for the resistive touchscreen controller.
It'd be interesting to see if could use P2 pins for the touchscreen instead, but need 2 more pins that way...
refresh rate?
You mean using a QuadSPI type transfer ? 'C161/'C163 parts are quite low cost, as are 'C595
The 'C161/3 series would allow a single-gate clock inverter to load DDR style, so halve the clock rate.
A 15MHz pixel rate, would need a 90MHz nominal data rate and 45MHz shift clock, assuming LCD loads on a spare 6th slot.
Or maybe 8 slots could be used to give more Tsu,Th on the LCD, for 32b shifts on a 120M data rate and 60MHz shift clock.
That could share nicely with QuadSPI memory too. (Tho an octal bus can shares with OctaSPI too..)
though it would mean a couple less pins?
' 6 sets of 4 bits from 4 Prop pins' is QuadSPI.
I could give some away for free.
Or maybe can find partner who could sell board with free lcd...
Update: I guess the speed of the latches will limit this and they won't run at 120MHz unless they are in a CPLD or something.
Perhaps with one octal flop to save pins
Nexperia spec 74LVC574 to 300MHz typ, and 74LVC377 to 330MHz typ, the 74LVC377 is a slight variant, with Data Enable, but in the older pin out.
An appeal of the Data Enable is it could allow better tsu,th specs on a slower LCD without pausing a Clock.
The appeal of a CPLD, is you could fine-tune SDR/DDR and finer timing delays, to suit the P2 ports, but it's not as cheap/simple as 'a couple of octals'
The streamer can output faster, but with caveats - ie I think you can go
Streamer -> LUT -> Pins (or DACs),
but I don't think you can do
Streamer -> LUT -> PinMUX at streamer speeds, to compress the data onto fewer pins.
ie the hardware is designed to get wider, it cannot then pin-compress after the LUT onto fewer pins.
Maybe a line buffer is needed ? Here, you would need 928 x 16b arranged ready to stream, or, you might use nearly the whole HUB for pixels ?
Another approach would be to shift the LUT into the external fanout device, using maybe QFN32 or QFN48 FPGA ?
That allows HW streaming, of pre-LUT width from P2.
Fantastic !
It's actually a very high quality LCD.
TomTom used them in handheld GPS units...
Working on what might be a nicer board for these screens...
Just put this one together but color came out in black and white!
Took me a little while to realize I got the wrong octal D chips for it.
Schematic says SN74AHC573PW but it's really SN74AHC574PW that is needed.
Been so long, I forgot... Made a note in the schematic this time...
This one will also have the Nunchuck + QWIIC connectors like the 2.4" version does.
Want to switch out the headers for that bottom feed kind that Parallax uses.
Also, do some gold flash next time.
If you're gonna do more LCD boards, I looked around at some point, they(tm) do apparently make 320x240 IPS screens with ILI-ish controller (no internal buffer though) Would be neat to mess with those (though the listed 30ms response time is a bit questionable). Would need to bring out DG0..DG7, HSync, VSync, Dotclk and the three serial pins.
Now when are they gonna make OLEDs in useful resolutions?
@Wuerfel_21 I've got boxes of new LCDs I'm going to try to get rid of first... This 4.3 one probably isn't IPS, but it's very good.
Seems @jmg is correct and this scheme only works with the '574 chips.
Got it going now.
Had some trouble with the new backlight driver circuit too. Seems I had both an inductor that wasn't good enough and a Schottky diode that wasn't good enough. Had to piggy back two of the diodes I had around to make it work. But, the version recommended in the datasheet is available, so all good.
I am slightly confused by the datasheet - it seems to use vertical subpixels, but scans horizontally (i.e 480x272, not 272x480)?
Also, the datasheet seems to indicate that the vertical timing could be bent into being vaguely SDTV compatible. Can you test what happens when you send less than 272 lines? does it center it or does it stick to the top? The former would be preferrable...
If all that is correct and you send me one, I could try adding support for this to the emulator video driver.
It is 480x272. In fact, the display drivers I make for this are typically just the VGA driver with 640-->480 and 480-->272.
I guess I could send you one of these prototypes in exchange for getting it to work with xYume.
Think I could do it myself, but not sure about scaling...
Here it is in glorious 24-bpp. Also, with proper proportions.
Happily, Irfanview can save as bmp in 24 bpp (and not using 32 bits for each pixel).
Guess I forgot that BMP format has the pixels stored backwards with blue first, but this seems to be the case and what wikipedia suggests too.
The driver needs a lot of work though. It's extremely basic and from when the chips first came out.
Right now, on works with basepin==0. Also, it's 100% assembly. At least I upgraded it with "asmclk".
Bitmap is 383 kB in 24bpp. Fits fairly comfortably in P2 Hub.
I wouldn't do scaling, I'd just put window it in the center (scaling at that resolution ratio with the kinda resources we have would just be uggo af). Which is why I asked what happens when you reduce the total line count - the emulators require the vertical timing to be SDTV-like (i.e. 15.7 khz Hsync, ~60Hz vsync) because reasons.
I did a quick test... If you do 240 visible lines and don't change anything else, you get junk at the bottom of the screen.
If you adjust top and bottom blanks, you can center the image, as show.
I don't think timing will be an issue. Display is fairly flexible with that.
You could probably do the top and bottom blanks faster, to make up speed, if needed.
Yes it will be - the rendering code can just barely deliver worst-case lines on time at 15.7kHz (bottleneck is sprite/fix blitting for NeoYume, layer compositing for MegaYume). If the line timing becomes any faster that's a big issue.
If you change blanking lines to be half/quarter the usual length (240/120 active clocks), does it still work?
240 looks OK, although blanked likes on top and bottom have junk now.
120 doesn't work, images is all red, strange...