SPI to drive LCD at 60hz?
Wallaby
Posts: 10
in Propeller 1
I spent a few weeks learning a Prop and really enjoyed it. One thing I couldn't easily crack was getting an LCD to update at 60hz @320x240x16 using an 8 bit bus. So I put the Prop down and tried a few Cortex-M7 boards. They are powerful, but I had a lot of issues with really shoddy example code and hardware development boards. I gave up on them for now.
So now I'm looking back at my beloved Prop and wondering - could it drive 128x128x16 pixels at 60hz? That would be 15,728,640 bits per second. As close as I got with 320x240, I figure it could do it with a 16-bit bus, or possibly even an 8 bit bus, but what about SPI? What I'm thinking now is - instead of a single 320x240 LCD, I'll try 3 128x128 LCDs in an array. Use one core per LCD to drive it. Since I'd want to drive 3 LCDs, I couldn't wire them all as a parallel bus as there aren't enough pins when considering the other command and control pins needed.
The other issue is Cog RAM. I'd need an off-screen buffer and it would be too large to hold in Cog RAM so it would have to stream it from some other source. The entire screen would be 384x128. 49,152 pixels. Maybe an 8-bit color pallet so 393,216 bits of RAM. 12,288 longs.
Is it possible?
So now I'm looking back at my beloved Prop and wondering - could it drive 128x128x16 pixels at 60hz? That would be 15,728,640 bits per second. As close as I got with 320x240, I figure it could do it with a 16-bit bus, or possibly even an 8 bit bus, but what about SPI? What I'm thinking now is - instead of a single 320x240 LCD, I'll try 3 128x128 LCDs in an array. Use one core per LCD to drive it. Since I'd want to drive 3 LCDs, I couldn't wire them all as a parallel bus as there aren't enough pins when considering the other command and control pins needed.
The other issue is Cog RAM. I'd need an off-screen buffer and it would be too large to hold in Cog RAM so it would have to stream it from some other source. The entire screen would be 384x128. 49,152 pixels. Maybe an 8-bit color pallet so 393,216 bits of RAM. 12,288 longs.
Is it possible?
Comments
The simplest would be to use a 64Kx8 external ram for video memory, a counter for addressing the ram, and have a Prop generate the signals that control that counter. That takes care of generating the video signal. Now you need to add circuitry and code that allows the Prop to write to the ram so it can update the image
PS: HDMI, DP and DVI almost works just like this, but at very much higher clock rates.
As above, it's not possible without some external help.
As mentioned, it's hard to go past the EVE/EVE2, as it does a whole lot more than just pump pixels to the display, and has ample headroom.
That series is $4~$5.50/1k, and the alternatives could be :
Multiple Quad-SPI memories - these keep getting larger, and now 2M and 4M show up, with 45MHz speeds.
examples:
2M IS62WVS2568GBLL-45NLI-TR SRAM 2Mb 256Kx8 45MHz 2.2-3.6V Serial SRAM $2.47/1k
1M 23LC1024T-I/SN 1M SPI 20MHZ 8SOIC $1.998/3k
512k 23LC512-I/SN 512K SPI 20MHZ 8SOIC $1.431/1k
Those quickly get tricky, as whilst you can now stream easily at almost any MHz, you need to flip each memory from read, to write, to write new data, finding some time slots to do so.
Another approach is to interleave 2 memories, so one is driving the LCD for 50% of frame, allowing 100% access to the other half, but that doubles the chip count, and adds some MUX.
Or, you could look at FPGA helpers... ?
Digikey now shows 59 FPGAs in QFN48, from this
ICE5LP1K-SG48ITR50 39 I/O 48QFN $2.76/1k 138MC 1100LUT 65536bRAM 1.14 V ~ 1.26 V
to this
ICE40UP5K-SG48ITR50 ICE40-ULTRAPLUS, 5280 LUTS $5.05/1k 1171456b RAM 1.14 V ~ 1.26 V
The first part could manage colour palette, and some line-buffering, and could push to the 45MHz of the new SPI memory.
The ICE40UP5K has 128KBytes, so that can displace the SPI memory entirely on smaller displays.
That still leaves the bottleneck of Prop1 pixel massaging, and transfer to the display, but the 60Hz refresh it taken care of.
Or, you could wait for P2 release ?
Depends how many you want to make, and what your time is worth ? EVE looks quite appealing on the 'get it done' front.
Many of the smaller LCDs (eg 128 x 128) now come with drivers included. What specific LCD(s) are you needing to use ?
So I'd only need a few pins? R,G,B, vsync and hsync? I thought the video driver in the Prop only allowed a limited color pallet. I'm not entirely sure how to use them but having the ability to drive an LCD with that would be a great feature.
The biggest issue with the EVE2 displays is the cost. One design goal I'm pursing is as low cost as possible. The cheapest display on Digikey is still something like 20-50 times the cost of an OLED screen from somewhere like Alibaba at least as far as I can tell.
Regarding FPGAs. I haven't had a lot of luck with development environments for them. Anything from Xillix, for example, is bloated and slow. I feel that, at least with regards to FPGAs, the development environments are the biggest hurdle. Even more than learning HDL.
Do you know of any manufacturers that have a modern development environment?
I'm definitely interested in the Prop 2.
The FPGA's I quoted above are from Lattice, - not many FPGA vendors offer QFN48 package sizes. Most are much larger.
All vendors I've seen, have 'large, slow' systems, that's the nature of the beast.