◎ STM32F > VGA Output from STM32F4 Discovery board

TODAY656 TOTAL210,921
사이트 이용안내
포럼 동영상강좌 회원가입

BASIC4MCU 후원업체 최신 정보

BASIC4MCU | ◎ STM32F | STM32 | VGA Output from STM32F4 Discovery board

페이지 정보

작성자 키트 작성일2017-09-13 11:27 조회648회 댓글0건


VGA Output from STM32F4 Discovery board
(Last updated 3 Jan 2015)

I love the web!  There are so many cool projects out there, and some, with a tweak or two, get me where I want to go quickly, saving a ton of time and effort.  Case in point: The Artektit page on VGA output using a 36-pin STM32.

The Artekit gang developed a minimalist VGA implementation using one of the boards they sell, with a 72 MHz STM32F103 device on-board.  I say "minimalist" because it uses just the board and a VGA connector, but you get 800x600 monochrome VGA out.  Then they added code for doing simple graphics and text generation, and all VGA timing is done using DMA writes to an SPI channel.  Their design has negligible impact on processor resources, so you could drop their VGA drivers into your project and see almost no hit to throughput.

Because of memory constraints in the chosen device, they only have room for 400x200 pixels.  They implement this by assigning a 10K frame buffer, then writing out the pixels as 200 lines of 50 bytes each.  Each pixel is sent twice and each line is sent three times.  The result satisfies the monitor's timing for 800x600 VGA, but the effective graphics resolution is 400x200.

Enter the STM32F4 Discovery board.  It has plenty of room for a full 800x600 frame buffer and runs far faster than the original '103 device.  All that is needed is to port their code from the '103 device to the STM32F4 processor and modify it to display a full 800x600 monochrome VGA.  VGA output from a $15 board.  With almost no CPU through-put hit.  What's not to like?

The porting effort
I started with a download of the Artekit files from the above link.  I have to say the code is impressive.  The comments told me most of what I needed to know, and the structure was well thought out.

I'm only addressing items I changed or added to the Artekit project.  Some of this won't make sense unless you also read through the Artekit page; you've been warned.

The first task was selecting the I/O pins to use on the S4D board.  Here is what I ended up with:

Vertical sync
VGA pixel data (GREEN)
Horizontal sync

That's it!  Four wires and you're good.

I switched my pixel data output to PB5.  I needed a MOSI signal from SPI1 and my only choices that supported DMA channels were PA8 and PB5, and PA8 was already assigned.

The VGA timing requirements are widely available on the web; one of the best sites is TinyVGA.com, which has pages devoted to many of the VGA resolutions.  The Artekit code uses a 56 Hz refresh rate, and I stuck to that.  From the TinyVGA site, the important 800x600 56 Hz timing info is:

General timing

Screen refresh rate56 Hz
Vertical refresh35.15625 kHz
Pixel freq.36.0 MHz

Horizontal timing (line)

Polarity of horizontal sync pulse is positive.
Scanline partPixelsTime [µs]
Visible area80022.222222222222
Front porch240.66666666666667
Sync pulse722
Back porch1283.5555555555556
Whole line102428.444444444444

Vertical timing (frame)

Polarity of vertical sync pulse is positive.
Frame partLinesTime [ms]
Visible area60017.066666666667
Front porch10.028444444444444
Sync pulse20.056888888888889
Back porch220.62577777777778
Whole frame62517.777777777778

All of the setup for this timing happens in the file video.c.  The code uses two channels of TIM1.  Channel 1 generates the Hsync pulse and channel 2 generates the Hsync plus back porch pulse.  Additionally, TIM1 is set as the master for TIM2.

The code also uses two channels of TIM2.  Channel 2 generates the Vsync pulse and channel 3 generates the Vsync plus back porch pulse.  Because TIM2 is slaved to TIM1, it automatically fires in lock-step with events generated by TIM1, ensuring that horizontal and vertical timing are properly synced.

Pixel data appears on MOSI of SPI1.  SPI1 is fed pixel data via DMA, which is triggered by completion of the Hsync plus back porch event on TIM1.  Each DMA transfer writes one line of pixel data to SPI1; data appears on MOSI with no timing gaps.

When each DMA transfer completes, a small amount of code in the IRQ handler updates the input pointer (M0AR) to point to either the next line of pixel data or, if a full screen transfer just ended, the start of the frame buffer.

The IRQ handlers for DMA, TIM1 and TIM2 contain the only run-time code needed to keep the entire VGA output going; we're talking about 10 lines of code total.  All work to generate timing and move the pixel data is handled automatically by the timers and the DMA subsystem.

The pixel frequency is fixed at 36 MHz, which in turn sets the SPI clock and there are a limited number of prescalers in that clock range.  I set the MCU system clock to 144 MHz, then used a /2 prescaler to get the need pixel clock.

Because the S4D has a much larger RAM pool than the original device, I expanded the frame buffer to hold a full 800x600 monochrome display.  I also made slight modifications to the IRQ handlers to allow for the expanded pixel stream and larger number of horizontal lines.  Because the original Artekit code was so well laid out, these changes were obvious and easy.

I left the Artekit demo code intact.  The demo looks almost exactly as its creators left it, except the text appears in the upper-left corner rather than the center, and the text is quite a bit smaller though perfectly readable.

Here is a picture of the hardware:

Hardwre for 800x600 VGA on STM32F4 Discovery

Yes, I know, it looks pretty nasty.  I'll clean it up on the next hardware revision.

The photo does show one small mod I made to the wiring.  The Artekit writeup talks about using a resistor divider on the GREEN input.  Basically, I connected PB5 to a 120-ohm resistor, with a 47 pf capacitor wired across the resistor.  The other end of the resistor went to the GREEN input on the VGA connector.  Finally, I tied a 270-ohm resistor between the GREEN input and ground.

The Artekit page notes that they have driven a lot of monitors directly from the 3.3V output of their micro, but it seemed to me using the resistor divider would be a better choice.

Here is a picture of the output on a Dell monitor:

Circles from the Artekit demo code

This is part of the Artekit demo program and gives you an idea of the display quality.  You can just make out the original Artekit text near the upper-left corner.

I hit a few snags during this effort, not the least of which was my unfamiliarity with VGA signal generation and use of the STM32 DMA subsystem.

One headache that came back almost immediately was the reason why I haven't done any STM32 code in several months.  The ST Micros Std Peripheral Driver library just sucks.  Whoever thought it was a good idea to wrap a simple register change in a function call needs to develop a few time-critical apps on an ATtiny and see how far that concept gets you.  The only thing I've seen that's worse is Arduino code.

At one point in my development, I needed to push a stream of bytes out the SPI, so I used one of the library's functions to write to the DR register.  The function introduced 250 ns gaps in the data stream.  Really?  A 250 ns penalty for using your library call?  Not gonna happen.  I switched to a direct write to the register using a macro and the gap disappeared.

I see a lot of STM32 code on the web that uses library calls to initialize subsystems, then switches to macros inside functional code.  That's pretty much what I did here.  And I hated doing even that, because I just knew the linker probably brought in 8K or so of bloat from invoking these calls.

I ran into a problem with minor tearing (more like shimmering) of the display, even when the display was not being modified by the code (so this was not a issue with DMA accessing the frame buffer while the mainline code was accessing it).  I traced the problem to general memory accesses not related to the frame buffer.  I was using a spin-loop to generate delays, like this:

void sysDelayMs(u32 dly)
    int32_t                n;
    int32_t                j;

    for (n=0; n
        for (j=0; j<20000; j++)  ;        // rough guess, looking for 1 ms delay

The above code caused the display to distort and tear while the mainline code was waiting for the delay to end.  If I moved the two timing variables into registers, like this:

void sysDelayMs(u32 dly)

    register int32_t                n;
    register int32_t                j;

    for (n=0; n
        for (j=0; j<20000; j++)  ;        // rough guess, looking for 1 ms delay

the display became rock-solid and clean.  I don't know enough about the inner workings of the STM32F4 to know why the earlier code affected the display.  If anyone has an answer, please drop me an email.

I've bundled all of my code into a single zip file.  Like most of my embedded projects, I used Visual Studio 2008 as the IDE and the folder layout reflects that.  In order to set up this code to match your IDE, check through the Makefile (vga_artekit.mak); the comments should help you as you edit the Makefile for your needs.

I'm assuming here that you already have CodeSourcery Lite++ installed on your machine and you also have the ST Micros STM32F4 Discovery support files installed.  In my case, I installed the ST Micros code here: C:\projects\STM32F4-Discovery_FW_V1.1.0\.  Note that I renamed any directories with spaces in their name to remove those spaces.  The spaces cause issues when I build within VS2008.

The code in this release is a working modification to the original Artekit code, but I make no claims that this is bug-free or even high quality.  It works, it shows an excellent display, but I know it needs more time and work from me.  I'm releasing it so others can use it as a starting point for their projects.  As I update this code, I'll try and keep this page updated, as well.

I started this project because I wanted VGA display of text from an embedded microcontroller for the least effort, smallest throughput hit, and lowest cost possible.  Thanks to Artekit and ST Micros, I now have the hardest part of that project done.

There's still plenty to do, of course.  I need to tweak the font file, wrap all of this code into a finished library, create text and graphics APIs for my other projects to use, and probably some other stuff.

But I am much farther along on my project than I could have hoped to be without the headstart given by Artekit.  Thanks, guys, for some excellent code and a terrific project!

Here is the zip file of my project: vga_artekit.zip


댓글 0

조회수 648

등록된 댓글이 없습니다.

◎ STM32FHOME > ◎ STM32F > 전체 목록

◎ STM32F 목록
제목 작성자 작성일 조회
82 STM32 Migration and compatibility guidelines for STM32 microcontro… 키트 17-09-14 775
81 STM32 ST마이크로일렉트로닉스, 모든 STM32 MCU 디바이스에 로우 레이어 API 탑재 이미지 키트 17-09-14 821
80 STM32 STM32 자료실 키트 17-09-14 1029
79 STM32 HAL vs LL 키트 17-09-14 904
78 STM32 STM32F103 응용 - SignalTech 이미지 키트 17-09-14 875
현재글 STM32 VGA Output from STM32F4 Discovery board 이미지 키트 17-09-13 649
76 STM32 STM32-MP3NL/COD - Audio Engine MP3 Codec and Utilities 이미지 키트 17-09-13 871
75 STM32 Arduino for STM32 키트 17-09-13 745
74 STM32 ARDUINO and STM32 이미지 키트 17-09-13 712
73 STM32 stm32circle.com 키트 17-09-13 694
72 STM32 stm32f4-discovery.net 키트 17-09-13 679
71 STM32 STM32 Nucleo community 키트 17-09-13 656
70 STM32 stm32 | Projects & Libraries 이미지 키트 17-09-13 538
69 STM32 Let’s code with STM32 NUCLEO 키트 17-09-13 428
68 STM32 101 Projects tagged with "STM32" 키트 17-09-13 308
게시물 검색

Privacy Policy
MCU BASIC ⓒ 2017