Shop OBEX P1 Docs P2 Docs Learn Events
24-bit color on 4.3" TFT using just 16 pins — Parallax Forums

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

RaymanRayman Posts: 13,797
edited 2019-01-15 13:03 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:

«1

Comments

  • jmgjmg Posts: 15,140
    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: 13,797
    edited 2019-01-14 22:24
    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
  • 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: 13,797
    edited 2019-01-14 22:40
    This is just one cog... Cutting back to 16-bits might make sense in some situations. But, this seems like a nice space here...
  • jmgjmg Posts: 15,140
    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: 15,140
    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.
  • RaymanRayman Posts: 13,797
    Might work but refresh rate might not get to 60 hz
  • RaymanRayman Posts: 13,797
    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...
  • roglohrogloh Posts: 5,122
    edited 2019-01-15 00:51
    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: 13,797
    edited 2019-01-15 00:53
    I’d go 5:6:5 and use 16 color pins for that one
    Perhaps with one octal flop to save pins
  • Yeah I guess I could do that. It's already just a 18 bit panel anyway.
  • jmgjmg Posts: 15,140
    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: 5,122
    edited 2019-01-15 03:26
    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: 15,140
    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 !
  • RaymanRayman Posts: 13,797
    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...
  • RaymanRayman Posts: 13,797
    edited 2022-08-27 19:59

    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.

    756 x 1008 - 1M
  • Wuerfel_21Wuerfel_21 Posts: 4,369
    edited 2022-08-27 20:16

    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?

  • RaymanRayman Posts: 13,797

    @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.

  • RaymanRayman Posts: 13,797

    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.

    621 x 309 - 41K
  • 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.

  • RaymanRayman Posts: 13,797

    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...

  • RaymanRayman Posts: 13,797

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,369
    edited 2022-09-04 18:07

    @Rayman said:
    It is 480x272. In fact, the display drivers I make for this are typically just the VGA driver with 640-->480 and 480-->272.
    Think I could do it myself, but not sure about scaling...

    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.

  • RaymanRayman Posts: 13,797

    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.

    480 x 640 - 114K
  • Wuerfel_21Wuerfel_21 Posts: 4,369
    edited 2022-09-04 19:24

    @Rayman said:
    I don't think timing will be an issue.

    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?

  • RaymanRayman Posts: 13,797

    240 looks OK, although blanked likes on top and bottom have junk now.
    120 doesn't work, images is all red, strange...

    480 x 640 - 113K
Sign In or Register to comment.