I read on another forums thread that the RPC SPI for the OpenMV Cam RT1062 is not yet available. Has the micropython machine library adapted now to allow for slaving?
I am unable to use UART for my project (arduino to OpenMV communication) since opening more than two UART ports (which we already have to communicate across multiple different microcontrollers) causes all UART ports to fail (for some reason that we could not solve).
We are using the Teensy 4.1 microcontroller as the master and the OpenMV RT1062 as the slave.
The PCBs that are in charge of the connections has already been printed and we do not have time to reprint them, I did not realize the RPC library has not yet been adapted before we produced them. Is there anything we can do anymore?
Right now no. MicroPython has no support for SPI slave mode. If you are willing, though, you could try to patch the code. The MCU can do SPI slave mode. Otherwise, you may wish to reverse the rolls. The electrical wiring should be the same.
If I reverse the roles, does RPC SPI support master mode for the RT1062? Does it no longer try and import from pyb?
Also: after reading the contents of the arduino RPC library, I don’t see an option for rpc_spi_slave, even though rpc_spi_master exists. How would I go about slaving my Teensy 4.1?
I also noticed that in the rpc_slave there is no option to transfer information from the camera to the Teensy. The point of our connection was to transfer information from the camera to the Teensy 4.1, so I don’t think this would work.
So, the RPC library doesn’t support yet machine.SPI for the master role. This isn’t because it can’t but just because it hasn’t been updated to do so yet.
However, as mentioned, Arduino doesn’t have a SPI slave class so it’s not implemented in the the Arduino library.
…
Yeah… you are free to edit the library and add machine support. It’s actually very simple to do so given the way it’s coded. The class that does the SPI transmit/receive just has two methods that have to be implemented. PutBytes() and GetBytes().
Or, you can do your own custom SPI comms. I don’t recommend this though. It would be faster for you to patch our code.
Right now we are focused on a bug project involving refactoring TensorFlow support so you can run any model. If you want to make a bug tracker on our GitHub I may be able to spend some time on this in the future and fix it.
I can give the patch a shot, but without the slave class in the arduino library there really is no alternative other than to slave my teensy and just use machine.SPI on the camera as the master.
I’m not well versed in C++ enough to make any changes to the arduino library, unfortunately.
I’ve created a bug tracker on the GitHub, so we should probably move this entire conversation onto there.