ChibiOS Free Embedded RTOS

Any updates on the official support for the slave driver? Would make the chibiOS HAL only excellent for small slave devices.

I created a patch for the SPIv2 and the newest chibos 191. Does that seem right?

Hi,

The current SPI driver will not support officially a slave mode, it is not designed for that.

A separate slave SPI driver will be eventually introduced, so far I have no clear idea of how it should be, there is a lot of variability on possible slave SPI uses.

Giovanni

Would you recommend using plyatovs solution from here: viewtopic.php?f=38&t=3213&start=20#p32291 (earlier in this thread) for a production system? Or is it more wise to create a complete Slave SPI solution without using chibiOS HAL?

Furthermore a driver that has a read/write buffer it transmits/receives on NSS and an interrupt/event for a incoming message probably would be very low level and expandable.

For a slave SPI application, my recommendation is to design a driver specifically for the protocol you need, I have not found yet a generic enough solution or I would have already implemented it in HAL.

The current SPI driver can be adapted (like you did) to implement very simple SPI slave scenarios, like exchanging fixed size buffers, more complex things like "idle frames" are more difficult to implement. See the SPI MMC/SD protocol, that would be very hard to implement without a specific driver.

Giovanni

Understood. Why not expose the the "very simple" scenario by just exposing the slave flag to the config?
As I understand the rest of the code would already allow for simple receive/sends (see example from plyatov).

Can you help me understand how the HAL API would behave in this slave scenario? As far as I understood, calling the Send/Receive/Exchange function "primes" the SPI to fill/empty the receive/transmit buffer when the master sends a signal, how is that triggered? Over the hardware NSS or simply when the clock starts running?

Here is my idea of things:
I'm planning to use the HAL without an RTOS, so I would call the exchange function and set a callback interrupt when a transmission was handled. In the callback I deal with my data, clear the buffer and call the exchange function again for the next transfer. I always know that my transmission is two bytes so I can set that beforehand.

Thanks!

The problem is long term support, I am not going to expose as an official feature a workaround.

Giovanni

For those who don't want to patch anything, you can simply do that:



Tested OK on G431