BIST-Research / batbot6

code for batbot6
MIT License
1 stars 0 forks source link

Add addressing ability to the SPI interface #5

Open bepiis opened 1 year ago

bepiis commented 1 year ago

Basically, the current SPI implementation is meant for sending bulk amounts of data eg. When we do a chirp and listen on the sonar system, the microcontroller has two buffers (for left and right microphone respectively) full of data that we would like to send upstream to the Jetson.

We ideally need another SPI instance that only handles short messages between the Jetson and the microcontrollers. For example, we need the Jetson to be able to tell the M4 when to start data emission and acquisition. We cannot easily do this through the same SPI channel because we send a predefined amount of data from the MCU to the Jetson. We don't want to have to shift out a huge buffer (the size of the echo data buffers) from the Jetson to the MCU just to issue a command that would be 1-2 bytes in length.

I would recommend coming back to this task once you have worked with the SPI interface for a bit. For example once the integration with the sonar code is finished.

That however begs the question: How do we tell the MCU to start a run from the Jetson if this hasn't been implemented yet? I would add a GPIO pin on the Jetson that connects to a GPIO pin on the MCU which we can toggle high when we want to start a run, and then another set of GPIO pins (one on Jetson and another on MCU) that the MCU can toggle when it has finished a run and has data that can be transferred. The Jetson can then start a run by setting the first GPIO pin, and then wait for the other GPIO pin to be set (by the MCU) to start the SPI transfer.

kofikofi123 commented 9 months ago

Current progress:

My new current approach is using a circular buffer for variable-size SPI requests. Verified a couple of varying commands. Will test with full command set to confirm.

Next step:

echo_code.txt

kofikofi123 commented 9 months ago

echo_code.txt