STM32F103C8 BluePill VGA Project

[feluga]

I was thinking BSRR was good choice because it would be possible to use other ports. Yes, it's 32bit register, what i had in mind to use two buffers of 4*pixels bytes per line, and in interrupt use something like:
-Set DMA to send 1st/2nd buffer (with few flags as "if" statement, and always same execution time +/- few cycles)
-Calculate 2nd/1st buffer as stream of 4bytes (32bits) for BSRR (this is not time critical, since DMA is already sending 1st/2nd buffer in background)
-exit interrupt

Only thing to find out is how much cycles is DMA transfer delayed when triggered every 8 cpu ticks (for 224 pixels resolution).

Time for me to dive into RM0008 Reference manual again and find a way to drive DMA with timer

It sounds like a good plan!

I know that you shall set Timer DIER to update generated DMA, for instance.
Check DMA/Channel linked to that TIMER/Event and set it up to be Memory to Peripheral direction.
Parallel processing with DMA, especially when accessing memory will sufer from bus access arbitration and this may lead to some pixels bigger than others.

But, for sure, it is worth trying!
Let us know about your progress.

[feluga]

Here goes some links that may help on getting DMA+Timer --> GPIO to work:

Some documentation about DMA and paralellism

Check this:
chapter 5 - DMA latency
5.3 Sharing the bus matrix with CPU
AN2548 Application note - Using the STM32F0/F1/F3/Gx/Lx Series DMA controller

Although this AN is not for F103, the general concept will help:
AN4666 Application note - Parallel synchronous transmission using GPIO and DMA



Some links of discussion:
DMA-> GPIO STM32f103
Can STM32F103c8T6 transfer data from memory to GPIO

Not for BluePill, but helps :: STM32E407 Timer->DMA->GPIO

[Bakisha]

Well, i have good news and bad news

Good news is that i was able to make timer 4 channel 1 trigger dma to stream memory to BSRR register (i just altered sketch that i had for streaming memory to SPI), but the bad news is that it not much usefull for VGA timings. Once i found what registers and bits to set, i first set overflow of timer to 72 (1uS) and it was running great, but as i lowered overflow, for values lower then 18 (249,84nS) pulses started to have same width and stayed at around 250nS for any overflow less then 18. My guess it is 32bit DMA read-write + CPU time. Will test some day with 8bit values to some other register (maybe ODR), but for now i'll leave it as-is.
I'll attach some pics from logic analyzer and sketch that used for testing.

[feluga]

Well, i have good news and bad news
.. it was running great, but as i lowered overflow, for values lower then 18 (249,84nS) pulses started to have same width and stayed at around 250nS for any overflow less then 18. My guess it is 32bit DMA read-write + CPU time. Will test some day with 8bit values to some other register (maybe ODR), but for now i'll leave it as-is.
I'll attach some pics from logic analyzer and sketch that used for testing.

Very Nice Bakisha!
I tested also it, but I changed two things to DMA_TIM_BSSR_test001.ino:
1) DMA sets Peripheral size to 8 bits instead of 32 bits
2) DMA CPAR pointing to ((uint32_t)&GPIOA->ODR)

Results:
Minimal overflow with effect is now 7 (97.2 ns), enough for 262 horizontal pixels.
VGA 640x480@60HZ needs 25.42 us for visible scanline.
With overflow on 8 we get 111.11 ns x 224 = 24.89us (a VGA fit with borders - OK)
This is with no parallel processing (in the sketch it runs a delay(), which has no load on CPU or Bus).

It sounds promising!

[Bakisha]

I tested also it, but I changed two things to DMA_TIM_BSSR_test001.ino:
1) DMA sets Peripheral size to 8 bits instead of 32 bits
2) DMA CPAR pointing to ((uint32_t)&GPIOA->ODR)

Results:
Minimal overflow with effect is now 7 (97.2 ns), enough for 262 horizontal pixels.
VGA 640x480@60HZ needs 25.42 us for visible scanline.
With overflow on 8 we get 111.11 ns x 224 = 24.89us (a VGA fit with borders - OK)
This is with no parallel processing (in the sketch it runs a delay(), which has no load on CPU or Bus).

It sounds promising!

Hopefully, 37.177 uS should be enough time to calculate next scanline.
I also tested with 8bit data to ODR, and i still get minimum time of 250nS. Maybe SK32F103c8 clone issue? Well, at least i know a little more then yesterday

Good luck with your library, you are doing good job so far!

[feluga]

Hopefully, 37.177 uS should be enough time to calculate next scanline.
I also tested with 8bit data to ODR, and i still get minimum time of 250nS. Maybe SK32F103c8 clone issue? Well, at least i know a little more then yesterday

Good luck with your library, you are doing good job so far!

Thanks Bakisha!
I've made it work generating 256 colors using GPIOB PB8 to PB15 plus 8 resistors (2K, 1K, 500R for Red and Green, 520R 390R for Blue).
The result is a colorful screen similar to the one we used to see in the 90's.

Some screenshots of a scrolling demo with "a Mario theme":

Mario1_small.png (94.78 KiB) Viewed 10150 times

Mario2_small.png (94.66 KiB) Viewed 10150 times

Check out the video of the scrolling scene:
https://www.youtube.com/watch?v=D1Ie7qcdRL4

[Bakisha]

Nice! That's some NES level 8bit graphic
DMA stream to ODR or BSSR?
Is resolution stll 224x240?

[feluga]

Nice! That's some NES level 8bit graphic

Yes, that's the initial target. I'm trying to push it to the limit and get something between NES and SNES.

DMA stream to ODR or BSSR?
Is resolution stll 224x240?

No, still direct bitbanging to ODR. DMA suffers from lack of BUS Matrix access priorization mechanisms.
Although DMA can be used, it's not feasible for VGA because the timing and synchronism of pixels are the key for a good image.
Resolution increased to 256 x 240. This particular demo uses 224x208.

[Y@@J]

Hi @feluga
was wondering if your VGA driver could run on a LPC1768/9 (also Cortex M3...)
I've no idea about the instruction set and registers differences between these processors and a STM32F103, and I'm not low level enough to understand the datasheets.
The idea being to add a VGA output to a 3D printer running Marlin on such a MC 'MPC1769). Works this way : double buffering, a memory bitmap being sent to a graphics display. This bitmap could be sent to a VGA display along (or not) with the graphic LCD or OLED or TFT... Uses u8glib.
For now, I can decode a OLED SPI signal and get still images of the display : means VGA is feasible, at least through a BluePill running your lib. But it would be much smarter if VGA feature could be added to Marlin... Marlin was written for Arduino, ported to many other platforms after a HAL was created. Reading the code, some bits are Arduino, some others are written with Cube (NVIC***). Most functions in your library (if not all) are standard C functions. The "offending" parts are the assembly instructions, the registers and the interrupt management (the core functions...). On my side, if it needs any porting, it's a dead end !
In your opinion, could your library be used as sis for a driver in such a software without modification ?

[feluga]

Hello @Y@@J

was wondering if your VGA driver could run on a LPC1768/9 (also Cortex M3...)

The concepts of BlueVGA driver can apply to any capable Microcontroller. Yes, it can be applied to a LPC1768/9.

I've no idea about the instruction set and registers differences between these processors and a STM32F103, and I'm not low level enough to understand the datasheets.

They are different microcontrollers. Their Registers are not he same, CPU frequency is not the same.
Both only use the same Cortex M3, thus ASM shall be the same, but I'd do something different given that LPC1768/9 has more SRAM.

The idea being to add a VGA output to a 3D printer running Marlin on such a MC 'MPC1769). Works this way : double buffering, a memory bitmap being sent to a graphics display. This bitmap could be sent to a VGA display along (or not) with the graphic LCD or OLED or TFT... Uses u8glib.
For now, I can decode a OLED SPI signal and get still images of the display : means VGA is feasible, at least through a BluePill running your lib. But it would be much smarter if VGA feature could be added to Marlin... Marlin was written for Arduino, ported to many other platforms after a HAL was created. Reading the code, some bits are Arduino, some others are written with Cube (NVIC***). Most functions in your library (if not all) are standard C functions. The "offending" parts are the assembly instructions, the registers and the interrupt management (the core functions...). On my side, if it needs any porting, it's a dead end !
In your opinion, could your library be used as sis for a driver in such a software without modification ?

No, it has to be ported, but for sure feasible. It would require time, a lot of reading, some coding and testing - just to make BlueVGA run on the LPC. Anyway, I don't have an LPC1769/8 development board to try it...

Regarding running Marlin and a VGA driver on the same MCU, I'd say that I'm not sure it would work and for sure it is not so easy to integrate.
VGA driver is a real time application that uses Timer IRQs to send images to the VGA monitor, and usually it consumes a lot of CPU cycles, unless DMA is used to send pixels to screen - but it may display incorrectly because of image artifacts due to DMA bus access arbitration. At the same time, a 3D printer controller, such as Marlin, has pretty much of its own timing demands as it also has to control the step motors, the nozzle and bed temperatures, the extruder etc.

It'd require a large effort in my opinion... and a LOT of testing!