Electronics > Projects, Designs, and Technical Stuff
Need to build On-screen display for VGA
Psi:
DMA of SPI bus running as fast as it can is the way to go if you want to make a MCU solution.
If you have 3 SPI buses you can even do RGB and get some colours.
This is the method used by ATMega's and STM32's to do an OSD over the top of composite video cameras for drones/RC planes.
VGA is similar except It's faster, the V/H sync is already broken out and colour is separated instead of a single B&W signal with a colour burst.
The trick is to code it in the right way so you have zero timing jitter.
If you use an interrupt it you will get jitter because instructions have different length. So whatever instruction is currently executing when the interrupt occurs has to finish and this timing changes depending on what the instruction was.
Yansi:
I am yet to see a comparatively cheap MCU, that can run SPI clocks at 100MHz, with the serdes circuitry around.
1080p TMDS is not analog PAL. Forget the software hackery bullshit.
Psi:
In almost all cases you dont need to run the SPI at pixel clock frequency.
Most of the time you just want to draw some large lines/text and so your needed pixel size is much bigger than the native pixels size.
(I shouldn't really call them pixels. 1920x1080 is lines of 1920 divisions or 1920TVL)
Obviously you still need to fire the DMA for every line though. But that's triggered from the Sync.
As long as the MCU can keep up with the SYNC you could draw pixels on the display in 10x10 grid with quite a slow spi clock.
Its all about timing from the start of SYNC to the SPI output data
If your MCU has enough ram you can have all the SPI data in ram for the entire frame, that way you're not rushing to move anything around between DMA ops.
Then you can update pixels in ram as slow as needed for the MCU to keep up. Obviously you'd want to double buffer it.
Yansi:
Fair point! However how will you keep the MCU clock (the SPI clock) in sync with the HDMI video stream?
You need to cross between two clock domains. If you think your both clocks (MCU and HDMI) are perfect, then no, they aren't and we are back to what I have said: Jitter. You will get garbage data sampled at the imprecisely timed video data transitions. Any vertical edges in the OSD will become jittery.
Keep in mind HDMI is a synchronous clock driven protocol, unlike PAL, where there is no requirement to the pixel clock be in sync with anything. The timing just needs to be without jitter - analog video has no pixels to begin with.
Psi:
When doing composite video it doesn't seem to matter to keep STM32 CPU clock and video pclock in sync.
I guess the jitter is too small to see.
But yes, i think at 1920x1080 you might run into at least some jitter issues due to the clocks drifting in and out of sync.
Maybe a 260mhz STM32F4-7 would be fast enough to be too small to see.
If you really wanted to you could PLL to the sync pulses and generate a fast clock to run the MCU from that.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version