VGA library for Teensy 4.0 and 4.1(finally!)

Jean-Marc

Well-known member
I am happy to share this new project!

https://github.com/Jean-MarcHarvengt/VGA_t4

Probably not yet at the level of uVGA but it was at least a good opportunity for me to learn about QTIMER and FlexIO from all the experiments shared on the forum (thanks to KurtE, Manitou, easone and Paul of course!)

For the moment it supports 352x240 and 512x240 in 8bits RRRGGGBB.
It can be extended to 480 pixels vertically without any problem and I think 12bits would even be possible (see code, feel free to try but it would require another resistor ladder!)

QTIMER3 (timer3) is used for generating the H-SYNC (and the line interrupt)
I use FlexIO1 and FlexIO2 to obtain 2x4bits in parallel on the IO pins.
2 DMA channels are used to generate the PIXELS from the 8bits buffer, started from the line interrupt (feeding the 2 FlexIO shift registers at the pixel clock)
 
Awesome! Any videos of it working that you can share?

I was curious so I looked at your FlexIO setup. I'm sure you're aware about this line configuring the bit width:

Code:
parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(4);  // 4-bit parallel shift width

A value from 4 to 7 actually configures FlexIO to be in 8 bit shift mode, instead of 4. So each FlexIO actually outputs the entire 8 bits at once, only the lower 4 or higher 4 are discarded because they're not connected to external pins. That's a pretty smart way to do it since you don't need to reformat any of the data before transferring it!
 
I will try to port one of the MCUME emulator to the driver this week and share a video ;-)
I have to make a setup with a T4.1 or at least a T4.0 with the SD card to be able to run something. I also ordered a SPDIF amplifier as I cannot use MQSL output anymore for sound.

I have been looking at your LED driver for a while to be honest.
I started from your code (as you can recognize the structure) which I found very convenient!

I find the documentation of NXP very cryptic. I read it 10 times and still don't get it right.
I had a lot of trial and error (also playing with the PWITH parameter). Especially with FlexIO1 I needed the highest nibble so I finally used a SHIFTBUF variant registers (e.g. SHIFTBUFNBS) to get it.
Not sure if it is the best way to do it.

One problem I noticed is that the 2 DMA copies in parallel are like slightly shifted so the colors are a bit smeared. At least I think it is the issue?
 
One problem I noticed is that the 2 DMA copies in parallel are like slightly shifted so the colors are a bit smeared. At least I think it is the issue?

That makes sense. If you trigger two separate DMA transfers, even if they are linked, the DMA engine takes some extra overhead to handle them one after the other (and can also be interrupted by higher priority transfers). It may be possible to get a speedup if you are able to do both transfers with a single DMA loop that sends data to multiple destination addresses... There's an example of this kind of DMA transfer in Paul's OctoWS2811 code. However, you may need to change the way the source buffer is organized to make this work or have your data specifically formatted.
 
I had a look at the example but I opted for another solution.
I modified the second color nibble DMA copy to allow non 32bits aligned source address and allow shifting the line by few pixels. It compensates the delay between the 2 copies. It works at least for 352x240 resolution.
I agree that the DMA priority might be an issue but on my monitor, the picture is rather stable now (not sure on other VGA monitors)
I also added support for double height resolutions (352x480 and 512x480)
I updated the code on the GIT.
I have the Atari 5200 emulator running on VGA now.
I will post the video tomorrow.
- Sketches have to be compiled at 600MHz to avoid interferences
- I also noticed that the white color looks a bit pink. May be because the blue is on 2 bits only and my resistances have to be adjusted.
At least some progress...;-)
 
The pinkish colors issue has been resolved!
It was only occurring with the emulators because the key library was configuring some pins used for the RGB output as input again after the VGA library initialization.
So no change needed in the VGA library for that, it was a side effect...
One problem less...
 
Back
Top