If you need to drive a big screen for a project, it’s fair to say your first thought isn’t going to be to use the ATtiny85. With just 512 bytes of RAM and 8 kilobytes of flash memory, the 8-bit micro seems a little cramped to drive, say, a 10″ screen. Yet that’s exactly what [ToSStudio] is doing with TinyTFT_LT7683: 1024 x 600 pixels of TFT goodness, over I2C no less.
The name kind of gives away the secret: it won’t work on just any TFT display. It’s using properties of the LT7683 display driver, though if you don’t have one of those, the RA8875 is also compatible. Those drivers can take more than just a pixel stream– a good thing, since you’d be hard pressed to get that many pixels streaming from an ATtiny. These are character/graphic display drivers, which means you can get them to draw both characters and graphics on the screen if you speak the lingo.
It’s still not blazing fast; the documentation suggests “static or moderately dynamic UIs” as the suggested use case, and a clock is of the pre-programmed examples. From that, we can surmise that you can get 1 FPS or better with this code. You’re limited both by the simple micro-controller and the bandwidth of the I2C bus, but within those limits this seems like a very powerful technique.
This isn’t the first ATtiny graphics library to blow our minds, but if you really want an impressive graphics demo from the little micro that could, you really need to race the beam.
Thanks to [Thomas Scherer] for the tip!
That’s a pretty decent amount of flash, RAM is a bit limited but not overly limit.
Not a limit, especially since the LT768x driver chip embeds a whooping 128Mb of RAM.
Even if using 24bpp, 1024*600 pixels would use only 14Mb of it. Means you can have several buffers of the whole graphic RAM and there will be still much left.
With clever coding, the MCU could use – maybe it does, i haven´t looked at the code – unused RAM as a – slow – RAM disk of a kind, there is enough flash to allow that. And of course sprites.
Using a ATTiny 85 SSOP would allow using SPI at much faster speed while still having few pins to to anything useful-
How do you get to 14Mb for a screen? 10246003 = 1.843.200 bytes or ~1.8Mb instead of 14Mb. I think you forgot to divide 24bpp by 8 to get Bytes/Pixel :-)
Bwah. 1024 * 600 * 3 (without spaces around the * ) got mangled to 10246003. Sorry!
Quite cool, but a bit underwhelming since its “just” an SPI display greatly reducing the actual complexity. I really wonder what the maximum full refresh rate it tho. I kinda miss a few details or a video i would be very interested in.
(And before i get yelled at again “hurr durr dont criticize make it better”, i made a TWI to 64×64 HUB75 matrix driver using a AVR_DA with double buffer and sprites)
It is “just” a display that has a huge framebuffer as well as advanced functions like chromakey, shape filling etc… i haven´t dig through the whole datasheet but i expect more than just this.
Clearly something intended for (cheap) automotive, lifting most of the work from the controller.
Some display controllers (Fujitsu and others) already have ARM cores, 2.5D/3D functions, blitting, separate buffered layers, alpha blending, video capture and scaling … all oriented toward automotive.
Thinking big picture, random access display protocols should be the future everywhere, imo. Seems like there have been a couple generations of digital display technology trying to overcome our analog history, but i think almost all of the common ones we use are still based on synchronous sequential scanning. The downside is variable latency (depending on what you’re sharing the bus with) but i really think something like a USB 3.0 (or 4.0) interface sending packets of asynchronous VRAM updates is the future. Multiple monitors on one cable, audio/video/control in the same channel, bidirectional, potentially 2-wire operation, all sorts of advantages if you can assume that basically a 5ghz dma manager is a cheap enough feature to add to your ASIC.
But in embedded work it’s a real no-brainer. The hd44780 seems long in the tooth today but its ability to do asynchronous commands was what made it so usable from small computers.