Arduino for STM32

Posted: **Sat Dec 26, 2020 4:26 am**

my thoughts are that it may be worth taking a closer look at
https://github.com/eprive/STM32Lvideo
https://github.com/eprive/STM32Lvideo/wiki
https://www.youtube.com/watch?v=Bg80o8y ... e=youtu.be
based on that description, basically hardware timers and i2s (spi) along with dma are used to drive video out, and the cpu is free to simply update the frame buffer in sram.
this is quite a 'big deal' as it implies all you need to do is to 'draw' your screen in sram, and the hardware timer and i2s with dma takes care of making the composite video. frame buffers use quite a lot of (s)ram (at least w x h / 8), so you may want to get a stm32 with more sram or use external sram/sdram.

of course right here we'd also have the blue pill vga project:
viewtopic.php?f=10&t=347
so you have options

this may make it considerably easier as you could possibly get a board with big chip like stm32f407 or even the board like STM32F429IDISCOVERY, that one has 8MB sdram on board plus a 2.4 inch lcd on board thrown in ! accordingly it is a ili9341 i read somewhere.

some of the spi and hardware timers are used to drive video, the rest of unused io such as spi, uart, i2c, gpio etc can then be purposed for applications.
it could become a 'single chip' solution and much of that implementation become simply software.

Posted: **Sat Dec 26, 2020 2:34 pm**

Of course, I'm aware of the BlueVGA project. It is not suitable because it outputs 640x480, and the display I'm using does recognize 800x600 only : viewtopic.php?f=47&t=815&start=30 ; lots of assembly and very low level coding involved.

The two threads should be merged. I PM'd a moderator. Hope it could be done.

I suggest the discussion goes on on the other thread, or it will be unreadable for anybody searching about SPI, OLED sniffing and video !

(currently doing some essential optimizations)

Posted: **Sun Dec 27, 2020 3:00 am**

Problems are now solved. It's alive and usable !
Thank you guys !

https://youtu.be/R5ec8EIZus8

Posted: **Sun Dec 27, 2020 4:49 am**

Y@@J wrote: Sun Dec 27, 2020 3:00 am Problems are now solved. It's alive and usable !
Thank you guys !

https://youtu.be/R5ec8EIZus8

+1
Cool! Congratulations!
Nice video.

Posted: **Sun Dec 27, 2020 12:00 pm**

Now I can read the links :

@feluga : for this application, timer based parallel data reading was not usable on the Nano, as they are in use for the video signal. Also, no interruption is allowed. It is just polled, waiting for CLK falling edges, everytime the beam is returning to (0,0). No timers, no interrupts. It is by design. On the STM32 side, the parallel signal timings are generated with simple dalyMicroseconds() calls (1µs).

@ stevsetrong : SoftwareSerial is not usable on the Nano for the same reasons, and anyway far too slow : 1KB has to be sent/received within 5ms. I'd like it to be faster : I'm lucky the video stays in sync, as the gramerate slows down to 50-51Hz (should be 60Hz). Now looking how to get sub microsecond delays. Shouldn'd be too difficult (for example loops that incerment a counter, or call asm "NOOP")

@ag123 : I'm using TVOut on the Nano. Worls prfectly ! Far more simpler and cheaper than any external circuit, and does not require any knowledge. Artekit is for Cube, with asm, and no idea how it could be ported to Roger's Core. I attempted and failed ! STM32Lvideo generates PAL, and my monitor (based on Realtek RTD2660) seems not to work with PAL : NTSC only. And looks like Cube generated. Isn't it ? The mixer/buffer amplifier is interesting (had seen it before). But the TVOut signal is perfect without. This being said, it's worth giving it a try with the BJTs I have can by hand. But the Realtek RTD2660 composite input seems not to be picky with impedance matching !
Makes me think of something else : cycling through the 4 inputs on the monitor is tedious (HDMI, VGA, Aux1, Aux2). Could the RasPi output a 1024x600 composite signal and the RTD2660 recognize it ? If yes maybe the video amp could be hacked and used as a switch (Nano/Raspi), with a remote switch... Will try that... Or search for composite switch schematics ; might be tons on them.

The parallel transmission.

On the BluePill side ; the Nano sends a signal asking for data :

Code: Select all

// currently limited to 330kHz because of delayMicroseconds() granularity

#define PULSE_DATA	1
#define PULSE_CLK	1

void ISR_RTS()
{
	for (uint i = 0; i < 1024; i++)
	{
		uint16_t odr = GPIOB->regs->ODR;
		odr &= 0x00FF;						// zero B15-B8, hide B7-B0
		odr |= (bmpTVOut[i] << 8);			// B15-B8 = val
		GPIOB->regs->ODR = odr;				// write bitmap to parallel bus
		delayMicroseconds(PULSE_DATA);
		GPIOB->regs->ODR &= ~(1 << 7);		// CLK = LOW ; PB7
		delayMicroseconds(PULSE_CLK);
		GPIOB->regs->ODR |= (1 << 7);		// CLK = HIGH ; PB7

	}

	delayMicroseconds(PULSE_DATA);
}

On the Nano side :

Code: Select all

// get new bitmap on V Blanking
void onStartVBlanking()
{
	PORTB &= ~(1 << 5); // 13 (B-5) LOW : send Request To Send (RTS)
	uint16_t i = 0;

	while (i < 1024)
	{
		// wait for CLK falling
		while (PINC & (1 << 4)); // A4 = C-4

		// read value
		//						D3-D6 = MSB				A0-A3 = LSB
		//							D-3-6					C-0-3
		*(videoBuffer + i++) = ((PIND & 0b01111000) << 1) | (PINC & 0b00001111);

		// wait for CLK rising
		while (!(PINC & (1 << 4))); // wait for CLK (A4 = C-4)) == HIGH : byte end
	}

	// D13 (B-5) HIGH : RTS HIGH, end of transmiision ; could be used as ACK...
	PORTB |= 1 << 5;
}

Not sure it could be simpler !

[EDIT]
Replacing delayMicroseconds() with series of asm "NOP" in data transfers for timings generate strange effects.
Every delayMicroseconds(1) was relaced with NOPs. An image can be seen, stable, from 24 to 40 NOP. The clock frequency is about 800 to 900kHz, a frame is 1 to 1.5µs. But the image is shifted down, and pixels are no more square. From 40 to 60 NOP, the image is as usual, but scrolls down (unstable).

The sweet spot is between CLK = 300kHz to 400kHz, with a the frame between 2 and 3ms.
If the frame is 5ms or more, it takes too long and the image is unreadable (out of synch).

Don't know what happens on the Nano. Probably related with timers...

NOP are added manually, a for() instruction adding too much time.

Why pushing the CLK as high as possible ? Because it can be done ! And because the Marlin display uses 64 lines only, when TVOut is able to display 96 lines. There is room for 32 more lines, that could be used for some information the STM32 could generate. For example the 3D printer controller enclosure temperature, or the PSU voltage and amperage, or a real time clock, or many other information.

Here's the image when a frame is sent parallel in 1-1.5 µs : shifted down

: DSC_7851.JPG (66.43 KiB) Viewed 6883 times

Posted: **Sun Dec 27, 2020 5:14 pm**

+1 congrats

Posted: **Sun Dec 27, 2020 6:16 pm**

This is not really completed. I used a SPI OLED with *VERY* simple and obvious protocol and data formatting. But it isn't the most common, and it needs a hack : it is not natively supported by Marlin. See here : https://reprap.org/forum/read.php?415,8 ... msg-879480 where I answered to someone on Marlin Git (was out of topic, was feeling that moderators were about to be upset).
Before it is natively usable for everyone, the emulator *MUST* support the ubiquitous "reprap discount full graphic smart controller". Also SPI-like, but with a more complex protocol, also implying some ACK messages in return (seen with the logic analyzer,). Don't understand a word from the datasheet !
This is what does BigTreeTech with its dual mode touch screen : https://www.youtube.com/watch?v=l1Putn10_Ek
This is where the idea came from. They switch between their proprietary (but open source) UI and marlin : wanted to switch between OctoPrint/TouchUI and Marlin. Their communication say their UI is better. No way ! OctoPrint + TouchUI is FAR better. And could run on a 24" touch screen.
Marlin is needed at least because it has a rotary encoder for fine adjustments. It adds pseudo analogic control that tapping a screen cannot replace, even in OctoPrint.

Posted: **Sun Dec 27, 2020 6:20 pm**

+1
Nice job!

As i recall, vertical blanking interval on NTSC is around 2.5mS. Maybe little more with TvOUT library, just by looking the numbers, it should be 2.9mS.
Maybe you are exceeding that time while bluepill/nano wait each other for sync and those 2 microsecond delay.

Just an idea, you could transfer half the buffer (512 bytes) per vertical sync time. You'll have 30 FPS, alternating between drawing upper and lower half part of screen. Maybe use another pin for request to send?

Posted: **Sun Dec 27, 2020 6:29 pm**

@Bakisha Works fine, and it is around 50-60 fps. Timings are as you wrote. Was super lucky delayMicroseconds(1) worked immediately !!! Don't you think so ? I don't know on the LCD side. But what I can say is TVOut goes crazy if data transfer takes too long or too short. Data are transfered within the callback "onStartVBlanking()". Should not be upsetted if it is faster, as this callback is optionnal... Should just have to be shorter than the beam return... Unfortunately, the TVOut developper disappeared from the Internets.

This being said, the project is not really completed. I used a SPI OLED with *VERY* simple and obvious protocol and data formatting. But it isn't the most common, and it needs a hack : it is not natively supported by Marlin. See here : https://reprap.org/forum/read.php?415,8 ... msg-879480 where I answered to someone on Marlin Git (was out of topic, was feeling that moderators were about to be upset).
Before it is natively usable for everyone, the emulator *MUST* support the ubiquitous "reprap discount full graphic smart controller". Also SPI-like, but with a more complex protocol, also implying some ACK messages in return (seen with the logic analyzer,). Don't understand a word from the datasheet !
This is what does BigTreeTech with its dual mode touch screen : https://www.youtube.com/watch?v=l1Putn10_Ek
This is where the idea came from. They switch between their proprietary (but open source) UI and marlin : wanted to switch between OctoPrint/TouchUI and Marlin. Their communication say their UI is better. No way ! OctoPrint + TouchUI is FAR better. And could run on a 24" touch screen.
Marlin is needed at least because it has a rotary encoder for fine adjustments. It adds pseudo analogic control that tapping a screen cannot replace, even in OctoPrint.

Imagine : the user has a 3D printer with Marlin and the reprap discount blah display (90% of the market). Unplug it, plug a cable that goes to a BluePill based RasPi hat, turn it on and just work !

And even better : the data going to the RasPi GPIO, and displayed in a OctoPrint plugin... The RasPi cannot do it alone, as SPI slave mode is not OS supported.

Posted: **Sun Dec 27, 2020 7:32 pm**

@Y@@J
Yeah, i'm impressed with that parallel sending data!
I can't say from TvOUT library why it breaks if onStartVBlanking() is shorter then Vblank. I couldn't figure out from code is that per scanline callback or only when it's in Vblank stage.
I'm not into 3d printer hardware and terminology, so i can't help you much there...

But as said before, nice job so far! And thanks for sharing the code, could be useful someday!

Arduino for STM32

emulating a OLED display on a VGA and/or a LCD monitor

Re: BluePill as I²C slave with Roger's Core

Re: BluePill as I²C slave with Roger's Core

Re: Looking for a suitable SPI slave example/tutorial

Re: Looking for a suitable SPI slave example/tutorial

Re: emulating a OLED display on a VGA and/or a LCD monitor

Re: emulating a OLED display on a VGA and/or a LCD monitor

Re: emulating a OLED display on a VGA and/or a LCD monitor

Re: emulating a OLED display on a VGA and/or a LCD monitor

Re: emulating a OLED display on a VGA and/or a LCD monitor

Re: emulating a OLED display on a VGA and/or a LCD monitor