24-bit color on 4.3" TFT using just 16 pins

RaymanRayman Posts: 9,682
edited 2019-01-15 - 13:03:20 in Propeller 2
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:

Prop Info and Apps: http://www.rayslogic.com/

Comments

  • jmgjmg Posts: 13,845
    Rayman wrote: »
    This is pretty neat... Layout of P2Eval board forced me to think about how to use less pins.
    Looks cool :)
    Rayman wrote: »
    The design files are in this thread (maybe I shouldn't have started a new one, but wanted people to see this!):
    At 250 MHz I have just enough time to get 60 Hz refresh and very close datasheet timings.
    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.

  • RaymanRayman Posts: 9,682
    edited 2019-01-14 - 22:24:22
    Here are the Eagle design files and screenshots of designs.
    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...
    656 x 944 - 97K
    1535 x 1158 - 39K
    Prop Info and Apps: http://www.rayslogic.com/
  • magnificent!! :)
  • Nice - how many cogs? I wonder if 5 quad DQ fflops (or 4 octal shift regs) and no touch interface allows an 8 bit version with still excellent
    refresh rate?
  • RaymanRayman Posts: 9,682
    edited 2019-01-14 - 22:40:43
    This is just one cog... Cutting back to 16-bits might make sense in some situations. But, this seems like a nice space here...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,845
    Mark_T wrote: »
    Nice - how many cogs? I wonder if 5 quad DQ fflops (or 4 octal shift regs) and no touch interface allows an 8 bit version with still excellent
    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..)
  • No, 24 bit parallel, but 6 sets of 4 bits from 4 Prop pins, rather than 3 lots of 8. If SPI is fast enough
    though it would mean a couple less pins?
  • jmgjmg Posts: 13,845
    Mark_T wrote: »
    No, 24 bit parallel, but 6 sets of 4 bits from 4 Prop pins, rather than 3 lots of 8. If SPI is fast enough
    though it would mean a couple less pins?

    ' 6 sets of 4 bits from 4 Prop pins' is QuadSPI.
  • Might work but refresh rate might not get to 60 hz
    Prop Info and Apps: http://www.rayslogic.com/
  • I still have plenty of these lcds.
    I could give some away for free.
    Or maybe can find partner who could sell board with free lcd...
    Prop Info and Apps: http://www.rayslogic.com/
  • roglohrogloh Posts: 1,181
    edited 2019-01-15 - 00:51:13
    What do you think the maximum LCD resolution is Rayman for 60Hz? I have a nice WVGA panel that does 928 x 525 x 60 Hz timing with a 29.23MHz dot clock. I wonder if this HW latch approach allows that type of pixel rate? If I clocked a P2 at 240MHz can I get 30Mpixels/second with your design (120M/4) or is it just half that, or something else?

    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.
  • RaymanRayman Posts: 9,682
    edited 2019-01-15 - 00:53:14
    I’d go 5:6:5 and use 16 color pins for that one
    Perhaps with one octal flop to save pins
    Prop Info and Apps: http://www.rayslogic.com/
  • Yeah I guess I could do that. It's already just a 18 bit panel anyway.
  • jmgjmg Posts: 13,845
    rogloh wrote: »
    What do you think the maximum LCD resolution is Rayman for 60Hz? I have a nice WVGA panel that does 928 x 525 x 60 Hz timing with a 29.23MHz dot clock. I wonder if this HW latch approach allows that type of pixel rate? If I clocked a P2 at 240MHz can I get 30Mpixels/second with your design (120M/4) or is it just half that, or something else?

    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.

    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'
  • roglohrogloh Posts: 1,181
    edited 2019-01-15 - 03:26:03
    Looking at Rayman's demo code, it would appear that there are not enough clock cycles per pixel for higher resolution panels to do what I was thinking, at least the way it is currently implemented. The LUT RAM is used to hold the palette, and each colour is shifted out separately (byte banging). Maybe multiple COGs...?
  • jmgjmg Posts: 13,845
    rogloh wrote: »
    Looking at Rayman's demo code, it would appear that there are not enough clock cycles per pixel for higher resolution panels to do what I was thinking, at least the way it is currently implemented. The LUT RAM is used to hold the palette, and each colour is shifted out separately (byte banging). Maybe multiple COGs...?

    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.
  • Yes jmg, something like we came up with for bit banging HDMI could possibly be used. It may require a dual COG implementation to create the line buffer. Be nicer if it could fit in just one COG though.
  • Hot Rocking Rayman !

    Fantastic !
  • I've attached the LCD datasheet to the first post.
    It's actually a very high quality LCD.
    TomTom used them in handheld GPS units...
    Prop Info and Apps: http://www.rayslogic.com/
Sign In or Register to comment.