Test UART Serial Algorithm

[daveythacher]

No description provided.

[daveythacher]

Add documentation under LED_Matrix/lib/Serial/serial_uart, LED_Matrix/src/uart and LED_Matrix/include/Serial/serial_uart.

[daveythacher]

Create idle loop to fire bus idle token from device to host every 10uS.

Host must send bus active token to device.
Host must wait for the bus to become active (no more idle loop on device). (Timeout of 100uS.)
If error device discards frame and enters idle loop.
If successful device enters idle loop once completed.

Create idle loop within serial_task

If frame does not get response back within timeout host can attempt to recover the bus back to idle.
If host detects the bus became idle too soon, frame is lost and host will drop it. (UDP)
Frame corruption is allowed in this protocol as it is not believed to be worth the computation. (However DMA may support verification.)

This would supersede the serial_uart_v2.
This works to the same goal of marking frames on the wire just without discrete control signals.

[daveythacher]

I may be interested in replacing the current logic with the previous post's outline. This may also remove the need for the other UART version.

[daveythacher]

May want to add checksum to this. DMA may be able to do this passively.

[daveythacher]

May want to remove the callback since this is now an interface library. There is no need for this anymore.

[daveythacher]

Tested aspects of this.

[daveythacher]

Tested state machine. (idle and start tokens. Packet length.)
Tested CRC logic calculation.
Did not pass valid data through. Did not test CRC rejection.

[daveythacher]

Lets go back to framed comms.

[daveythacher]

Plan is to move the UART protocol to external RP2040. This will allow a simpler protocol between the two RP2040s. I am not sure there is enough performance on a single RP2040. (A RP4050 would probably handle it.)

[daveythacher]

One core is pretty much consumed on convert the RGB values into bitplanes to conserve bandwidth. The bandwidth requirement for a single 16x32 display is 31.5Mbps (0.74Mbps for hardware PWM). This is about 512 pixels, with this core we can support something like 8192 pixels.

Another core is pretty much consumed doing multiplexing at high frequency. (This is better with hardware PWM.)