The small screens as found on PJRC and elsewhere are a commodity item with multiple sources, key thing in the low cost is that all the parts mass produced and well understood so the factories can swap out ICs, PCBs and panels from whoever is lowest cost this week (and no single supplier can jack the price).
For larger panels things get more complex but fundamentally there is a problem asking a Teensy to drive a 8*4.5 display and that's number of pixels and data throughput. First you need to store all those pixels an a large RAM system, then you need to get those pixels out and onto some form of bus to the display. The SPI used for the small LCDs already hits it's limits in terms of reasonable frame rates in the 240/320 domain so going to several thousand in each direction isn't going to work.
Thank you for your response GremlinWrangler,
I thought that in the case of the PJRC TFT Touchscreen, the "video RAM" (whatever RAM contains the pixel color data) was embedded in the screen itself, not in the Teensy. I don't think the Teensy has a scratchpad that it needs to blit to the screen every so often (but I may be wrong).
There are simple primitives to turn a pixel on or off, but that's pretty much it (I've seen some advanced functions to "blit" some bytes, but I don't really need them).
In my use case, I don't want to compose an image and then blit it, which is the model that many graphics cards have (back buffers, v-sync, flipping, etc). I just want to do the same thing I'm doing right now with the small touchscreen: draw a pixel here and there, at a not so high rate. There is very little throughput needed from the Teensy to the screen in this very specific use case (which I concede is not that common).
Fundamentally large panels are what HDMI and it's related hardware were built for so getting away from them means re-inventing what it's doing for you.
The tech for what you want to do exists in the form of the smart whiteboards in various flavours (quick google got one claiming six point touch sensing), depending on your project would suggest either using one directly or trying to source the sub elements that fit your needs. None of those are going to have a low price tag though unfortunately, since any large panel display has the reliability problem. If your process can has one in a million pixels fail then most of your 240/320 (76,800) pixel displays will pass quality control. If you are using the same process at the same pixel size (6 per mm) you get to 2 meters by 1.5 meters and 9000*12000 for a total 108 million pixels where you will be throwing most of the production away, even if you accept a couple of dead pixels per panel.
Unfortunately all of these "off the shelf" panels and smart boards have too high a latency, because they are based on a certain FPS model driven through HDMI. Even at 60 fps, the latency added is too much.
108M pixels is a lot to get right in one shot indeed. 1920x1080 (2M pixels) is a reasonable resolution to start off with actually.
I'm happy to source the sub elements, as long as they let me interface at a level that lets me flip pixels quickly, without having to render in a back buffer and transmit via HDMI.
Imagine a "scaled up version" of the PJRC TFT Touchscreen, 1920x1080, 8'x4.5', 4 Megabytes of VRAM to hold the display pixel data @ 16 bpp, and same SPI interface to detect a touch and draw a pixel. Other than the pixel density being different (and obvious physical size difference), the processing should be the same... unless I'm missing something?
The Teensy wouldn't need to drive more pixels/second than it currently does with my 2.8" display (and it works well with it).
Does that make sense?
Thanks again!
