VGA Output on an Atmel XMEGA

Displaying a lot of information from an XMEGA on an LCD

Public Chat
Similar projects worth following
A monochrome VGA video generator project with Atmel XMEGA, using DMA and SPI. The DMA is absolutely necessary on a low-speed processor so this project cannot be adapted to the simpler ATmega family.

This is a nearly no-component monochrome VGA output project. It has a relatively low processor demand, too. This is achieved by utilizing peripherals on the microcontroller:
• Timer - for accurate timing,
• DMA - for constant data flow,
• SPI - for serialization of pixel data,
• Event System Matrix - to lower the interrupt usage and for more accurate timing.

Check out the YouTube video and the project files folder!

[created in 2016]

If you know a possible industrial use for this project or if you have any further ideas, let me know.

Driver Interface 

// Driver Initialization

// Setting the color of a pixel
vga_gen_set_pixel(x, y, color);

That’s all. 

It’s simple because it’s intended to be used as a lower layer for graphical libraries. The example uses the µGUI library. 


Crystal oscillator 

It is necessary to run the XMEGA from an external crystal. The internal RC oscillator is not stable enough for VGA - the image would be wavy or noisy or, more often, the monitor will not lock on it at all. 

The value of the crystal is not critical as the on-chip PLL can generate the required frequency. 

The PLL output frequency doesn’t have to be exactly the pixel frequency in the mode definition, just choose the closest possible. Modern monitors are quite forgiving. A few percent deviation won't be a problem.

Functional Diagram

Project Files Download

Google Drive Link for XMEGA VGA

I use a URL shortener because I'm curious about the download count.

View all instructions

Enjoy this project?



KilkennyCat wrote 05/09/2024 at 07:41 point

Nice. Thanks. I'll try to make a port on Risc-V from WCH

  Are you sure? yes | no

Gabriel Cséfalvay wrote 05/09/2024 at 10:35 point

Let me know.

  Are you sure? yes | no

KilkennyCat wrote 05/09/2024 at 10:39 point


  Are you sure? yes | no

Alysson Rowan wrote 05/08/2024 at 16:52 point

Nice little project - it has potential for other things, especially given that cheap, used VGA monitors are suddenly available being replaced with digital interface displays. Most excellent for the hacker / hobby community

What toolchain are you using for this project?
Is there enough processor/memory capacity to get 4, 8 or 16 colour capability?

I can see a number of possible applications for this, not the least of which are:

+ Vectorscope type display

+ Digital oscilloscope display for classroom use

+ Dedicated display for scientific instruments such as spectrometers

+ Navigational display, sonar display etc.
   - switch select between red (night vision), amber (high vis)  and green (daylight) output.

While I haven't looked into the demo software (yet), these would need your API library to include text handling (and font(s)), serial interface and interface for ADCs. 

.... all way beyond my programming ability ( I mostly just do hardware).

  Are you sure? yes | no

Gabriel Cséfalvay wrote 05/08/2024 at 19:14 point


The memory might be enough for more colors but the bitrate certainly will not be at 'only' 32MHz.

I'm working on a version for STM32 processors that are a bit faster. Maybe I can get some HD resolutions working on them. In this version I plan to include a quasi-color feature where the color of each line could be set individually. Or maybe each line could be divided into 2 halves with 2 different colors. In this way the resolution won't suffer and, at the same time, the displayed information would be more comprehensible (eg. red for errors, green for ok, blue for company logo etc.). So stay tuned! :]

I used Atmel Studio for this project - I created it some years ago. 

I included an open-source graphics library in the project. I wouldn't dare to write one myself - too big of a project for a single ADHD person. :) I wrote the VGA signal generator and made it to cooperate with the library. It's really independent on the graphics library you use.

Those are some interesting possibilities you suggested. I guess it could be useful in such low-cost scenarios.

  Are you sure? yes | no

Alysson Rowan wrote 05/08/2024 at 20:18 point

That makes sense. I look forward to seeing the next iteration.

  Are you sure? yes | no

RonW wrote 05/12/2024 at 01:34 point

The XMEGA A1U family has multiple DMA and USART/SPI channels that could be used used in parallel (one each for R, G & B). Of course, an obvious concern with this would be the skew between the channels.

  Are you sure? yes | no

Gabriel Cséfalvay wrote 05/27/2024 at 11:19 point

There are Multiple SPIs, but there is only 1 DMA controller, and only 1 peripheral bus. So the peripheral bus throughput would be the bottleneck in your suggestion. It could work up to a given resolution. The DMA has more channels but they cannot function in parallel - they share the same bus master interface.

However, the the synchronization of the SPIs would be the real issue. At this time the SPI is synchronized by a single byte DMA write triggered thru the event system (no SW involved). This cannot be accomplished with multiple SPIs.

It would be interesting to find a different solution to this issue.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates