Teensy 4.1 and display

T

theboot900

Active member
I am using a Teensey 4.1 and a 7 inch 800 x 480 SSD1963 display with a 16 bit parallel bus.

I have always wanted to get full screen refreshes happening with a buffer on a display with proper syncing and the theory is the Teensey 4.1 could be fast enough. No more of this only drawing changes, and undrawing text etc.

I've written a driver to connect to the display (Thanks to MCUFriend for some of the connection macros - RIP David Prentice) Ive set the refresh rate at 60hz by increasing the vertical non blanking period. (13 milliseconds for display period - 3.6 milliseconds for vertical blanking period.

I've connected a wire to the Tearing Effect pin on the SSD1963 and had to change the SDD1963 data recieve direction to match the display vertical sync direction.

Unfortunately the Teensey doesnt have enough memory for a 16 bit 384000 pixel buffer with the display in 16 bit mode. After trying to split the buffer between Ram1 and Ram2 i was having problems using inline functions in Ram2. I couldnt declare an array using DMAMEM in a header file. Then was having trouble getting a pointer to DMAMEM from my DisplayDriver.cpp class to my Display.h file

I also realised using memset only changes every byte in an array. It's no good for 2 byte data types. I use this to clear the buffer after every frame. So ive currently changed to a U_int8 bit 384000 byte array in MEM1. Then i use a 256 colour look up table for each pixel. So technically i have 65k colours available, just stuck in a 256 colour pallet

So we run as follows:
-Clear the buffer (Using memset) //200 microseconds
-Program update and draw to the buffer //Drawing random text, rectangles and circles to the buffer is under a few milliseconds
-Wait for vertical blank signal
-Send the buffer to the display //3.2 milliseconds with no pixel colour changes. 4 to 5 milliseconds with average pixel colour changes

I've wrote and heavily optomised my drawing code to the buffer for text and graphics primitives. Where possible i use memset for fast set vertical lines. I think ive also got sending the buffer to the display as tight as possible. The SSD1963 has an autoincrement feature. Data is strobed until the data pins need a change due to the pixel colour change.

The only downside is this way im stuck with a 256 colour pallete. This will make adding colour gradients difficult.

Would an 8mb PSRam chip be fast enough to use as a full 16bit buffer? Can i use Memcopy on the PSRam chip on QSPI without the data having to come back through the qspi bus. If so i could have the buffer on the PSram chip, as well as a cleared backing array that simply copies into the buffer array after every frame.
 
Last edited:
Speed of PSRAM ? - Is there a T_4.1 at hand for testing?

If so a memset of the buffer to zero could be timed
then time setting some number of bytes across the buffer with values
Then timing the read the buffer to output pins

It seems some TFT display work was buffered to PSRAM for use { @KurtE or @mjs513 ? )- using DMA? That gave usably fast updates IIRC.

Recent posting and perhaps PR for enabling QSPI PSRAM read ahead was done that helped sequential access - not sure if that made it into TD 1.59 beta 3?
 
theboot900 said:
I am using a Teensey 4.1 and a 7 inch 800 x 480 SSD1963 display with a 16 bit parallel bus.
Would an 8mb PSRam chip be fast enough to use as a full 16bit buffer?.
Click to expand...

I do exactly this for another 800x480*2 parallel display. My benchmarks show that whilst using PSRAM for the buffer, the T4.1 can push 25+ full frames per second. This is with the PSRAM at 133mhz & cache enabled.
 
It depends exactly how you're doing the buffering.
If you copy the full frame to be rendered into PSRAM during vsync, that will probably work fine. But if you try to write to PSRAM during rendering, there won't be enough bandwidth and you'll get glitches.
 
I've ordered an 8mb psram chip and will give it a go.

I do like the idea of smooth 60hz though.

Is direct memory access able to output to a 16 bit parallel line?
 
Not on a Teensy 4.1, no.

Only option you really have is a custom Teensy 4.x pcb and exposing all FLEXIO2/eLCDIF pins
If you’re doing that you might as well go for a dumb lcd display and drive it RGB directly from LCD controller
But you won’t get 60Hz full screen refresh rate buffering in PSRAM for that resolution, maybe with SDRAM, but you’ll need to integrate that yourself both hardware and software wise
 
I would actually go for an 8 bit parallel bus with DMA on a Teensy MicroMod and drive the SSD like that.
Single writes for command and dual write for pixel data
You can run the bus at 30Mhz and get roughly 39Hz refresh rate @ 480*800*2byte color.
If the SSD will support a higher clock rate, you MIGHT be able to get closer to 60Hz
 
So i connected all the 16 bit parallel lines on the first 16 pins on GPIO6. 6.16 to 6.31 in order.

Get very fast register changes now. If i set every pixel on the back buffer to different colours to force a new colour on the parallel lines for every pixel it went down from 22 milliseconds to output to 6 milliseconds to output the whole buffer. Realistically you would never have to do 384000 pixel register changes per frame.

Only problem is i dont have any I2C lines available now. Changing the order of the GPIO6 register to use Pins 0 and 1 to free up pins 18 and 19 for I2C slowed it right down again.

I can speed it up about 400 more microseconds doing a direct register rather than using GPIO6_DR_SET, however then i would loose another 4 pins.
 
Have you considered using Rezo's excellent FlexTFT library here. This is an 8 or 16bit parallel driver using FlexIo. Pins are predefined but it will leave you with a spare i2C port.
 
So im thinking of using 3 x fast 8 bit line driver buffer chips CD74AC244E

Combine 8 parallel lines into each of them. The 24 bit output goes into the parallel lines on the tft. I've got another display on order with all 24 bit parallel lines on the pinout

This way I can use 24 bit mode and also buffer the 3 rgb values so I won't need to constantly cycle each pixel for each update when the pixel colour doesn't change. It's going to take a little longer to set each pixel change but ill see what speed I can get it up to.

I really want to see if it's possible to design a circuit with 2 fast parallel sram modules for a front and back buffer. Then using a fast counter chip and a clock somehow automatically output the front buffer to the display from one of the sram modules on teh vsync trigger, while the backbuffer gets updated from the MC

I shouldn't need address lines on the output, as the ssd1963 auto increments. However will need address lines for the input, as well as switch the inputs and outputs between the 2 sram modules. And also somehow need to autotrigger the commands to set a new pixel. I think the complexity might get to high
 
theboot900 said:
So im thinking of using 3 x fast 8 bit line driver buffer chips CD74AC244E

Combine 8 parallel lines into each of them. The 24 bit output goes into the parallel lines on the tft. I've got another display on order with all 24 bit parallel lines on the pinout

This way I can use 24 bit mode and also buffer the 3 rgb values so I won't need to constantly cycle each pixel for each update when the pixel colour doesn't change. It's going to take a little longer to set each pixel change but ill see what speed I can get it up to.
Click to expand...

Maybe I'm missing something but 74x244s aren't going to buffer like that... they don't latch their input values, they only let you tri-state the outputs. You will still only be able to send 8 bits maximum at any point in time.
Possibly what you want is a 74x573, so each buffer can keep outputting its set channel value while you set the other channels?
 
You must log in or register to reply here.
Back
Top