I need to implement a SPI slave capability that works in the following way:
1) You set up your SPI port as a slave, with the polarity and phase of your configuration, and with a slave select pin
2) You provide an outbound buffer to be pulled from. This will be the MISO bytes that are shifted out the next time the master executes a transfer
3) You register a callback that gets called once there is a transfer
--callback is called after chip-deselect of the spi transfer--
4) The callback gets the byte buffer that came in the MOSI line on the transfer. The length _n_ of this buffer also tells you that the first _n_ bytes of the outbound buffer were sent to the master during the transfer
5) The callback submits its next "send these bytes next" buffer and is done
Does this type of interface make sense? If I wanted to do this, how would I go about starting? Would I need to basically implement my own "fork" of the SPI driver and change the parts I need, or is there a clean way to just modify the slave performance to do what I need?
asynchronous buffered SPI Slave interface
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: asynchronous buffered SPI Slave interface
I think that would be a very useful enhancement to the pyb library.
MicroPython development uses a "fork and pull" model. So you create your own fork of the project and clone it to your PC. You create and checkout a branch and set to work on ports/stm32/spi.c. When you have working code, you push it to your GitHub repository and create a pull request. This process is discussed in detail here. It's also worth studying the code conventions.
Your interface description sounds reasonable to me, but if you want to get developer comments an option is to raise an RFC on GitHub.
MicroPython development uses a "fork and pull" model. So you create your own fork of the project and clone it to your PC. You create and checkout a branch and set to work on ports/stm32/spi.c. When you have working code, you push it to your GitHub repository and create a pull request. This process is discussed in detail here. It's also worth studying the code conventions.
Your interface description sounds reasonable to me, but if you want to get developer comments an option is to raise an RFC on GitHub.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: asynchronous buffered SPI Slave interface
>set to work on ports/stm32/spi.c
STM32 is my board, so that suits me fine, but I can't help but asking, what do I do to make sure my contributions are also useful for the wider micropython audience?
STM32 is my board, so that suits me fine, but I can't help but asking, what do I do to make sure my contributions are also useful for the wider micropython audience?
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: asynchronous buffered SPI Slave interface
The pyb module supports SPI slave mode but is STM-specific. The alternative is to modify the machine module which is multi-platform. However this doesn't support slave mode, so you'd need to engineer that from scratch.
I have my doubts about modifying machine because some of the supported platforms (ESP8266, ESP32) have high interrupt latencies. I suspect that a cross-platform nonblocking SPI slave capable of supporting a reasonable throughput would be a major challenge.
There are a lot of users of STM processors and a nonblocking slave mode for those chips would be very useful.
I have my doubts about modifying machine because some of the supported platforms (ESP8266, ESP32) have high interrupt latencies. I suspect that a cross-platform nonblocking SPI slave capable of supporting a reasonable throughput would be a major challenge.
There are a lot of users of STM processors and a nonblocking slave mode for those chips would be very useful.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: asynchronous buffered SPI Slave interface
That makes sense. I will make my changes to the pyb module. Thanks for your guidance!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: asynchronous buffered SPI Slave interface
Good luck! In my view this would be a great enhancement to the firmware so I hope you'll submit a PR when you've got it working.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: asynchronous buffered SPI Slave interface
Hi,kbrafford wrote: ↑Thu Feb 22, 2018 12:59 amI need to implement a SPI slave capability that works in the following way:
1) You set up your SPI port as a slave, with the polarity and phase of your configuration, and with a slave select pin
2) You provide an outbound buffer to be pulled from. This will be the MISO bytes that are shifted out the next time the master executes a transfer
3) You register a callback that gets called once there is a transfer
--callback is called after chip-deselect of the spi transfer--
4) The callback gets the byte buffer that came in the MOSI line on the transfer. The length _n_ of this buffer also tells you that the first _n_ bytes of the outbound buffer were sent to the master during the transfer
5) The callback submits its next "send these bytes next" buffer and is done
Does this type of interface make sense? If I wanted to do this, how would I go about starting? Would I need to basically implement my own "fork" of the SPI driver and change the parts I need, or is there a clean way to just modify the slave performance to do what I need?
Do you have the SPI.c code example for those changes? I'm looking into do the same in my side