Create program that talks to the MCU

[jbewing]

On the Raspberry Pi, there needs to be a single program which talks to the MCU over whatever medium that we decide. Originally the plan was to use Bluetooth for this, but we could potentially talk via a wired connection. This program accepts inputs from the PoV API endpoints and handles the data transfer between the RPI and MCU.

[jbewing]

We talked about this in our meeting today, hashing some results out here

Protocol Details for Transmitting a Static Image to the Pi

Message Types

• START
• DATA
• ACK
• STOP

STARTING_TRANSMIT -- (Pi => MCU)

Indicates that the Pi wants to display a new image on the PoV Display. This message contains any possible metadata that we can think of that the MCU needs to display an image.

DATA -- (Pi => MCU)

Contains information about the RBG information for a row of pixels.

ACK -- (MCU => PI)

Sent in response to a STARTING_TRANSMIT, DATA, and STOP messages immediately after the received message is validated. We should probably add a flag to this message indicating whether it's a "negative acknowledgement" i.e. retransmit or an acknowledgement.

STOP -- (Pi => MCU)

Sent to tell the MCU to stop displaying an image.

Retransmissions

If the Pi doesn't receive an ACK for a message in a very small fixed amount of time, then it will just retransmit the same message until it receives an ACK. In the case of this being done over a wired medium, this fixed amount of time will be pretty easy to find via testing.

Error Correction

If we're implementing this over the wire (Pi <=> MCU via Slip Ring), we'll need to implement an error correction scheme for DATA messages as we don't know what the drop rate is going to be. It's not relevant to implement them for the other messages because retransmissions will take care of it (and retransmissions will depend on drop rate). A CRC works best here as it's simple + fast for use with the MCU.

Sample Flows

Sample "Happy Path" Message Exchange

    Pi                                    MCU
_________           START               _________
|       | ============================> |       |
|       |            ACK                |       |
|       | <============================ |       |
|       |            DATA               |       |
|       | ============================> |       |
|       |            ACK                |       |
|       | <============================ |       |
|       |     ... 20 or so times        |       |
|       |   Implicit from PoV Resolution|       |
_________                               _________

Sample Un-Acked Message Exchange

    Pi                                    MCU
_________           START               _________
|       | ============================> |       |
|       |            ACK                |       |
|       |        X <=================== |       |
|       |            START              |       |
|       | ============================> |       |
|       |            ACK                |       |
|       | <============================ |       |
_________                               _________

Sample NACK Message Exchange

    Pi                                    MCU
_________           DATA (row 1)        _________
|       | ============================> |       |
|       |            NACK               |       |
|       | <============================ |       |
|       |            DATA (row 1)       |       |
|       | ============================> |       |
|       |            ACK                |       |
|       | <============================ |       |
_________                               _________

Format

As far as format, binary probably works the best here (for MCU to save on serialization/deserialization). For a data message, a format like:

(2 bits)  
#####################
# Type # CRC # Data #
#####################

would work where CRC + data sizes are undefined for now (CRC depends on size of data generally/how much error we would accept).

As for the other message types, the 2 bit type would be the entire message.

Note: This is stop + wait based so we're losing a ton of the potential bandwidth from our signaling medium, but it makes the protocol control logic much less complex so 💯. We can upgrade if we need to :/

cc @brodigan-e @DarkAce65

[pesamonika]

GitHub is very foreign to me after a couple years of not using this so I don't think I have permission to assign myself this topic or create a label "MP" for it. Thus, the comment will represent the act of assigning myself to contribute to this issue/task.

[brodigan-e]

I added some basic code to the esp32 to configure it as a SPI slave driver so it can receive/send data from the master. Code was copied from here and the reference for the spi slave driver is here. There's a similar page for the spi master driver which gives an idea of what the Raspberry pi would have to do.