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 6877 times
