Missing timeout in SPI synchronous functions Topic is solved

[neums]

Hi,
since the spiReceive and the spiSend function are synchronous/blocking functions might it not be sencefully to have a timeout like in this i2c driver (i2cMasterTransmitTimeout and i2cMasterReceiveTimeout)?
When you want to receive something from an on board chip and it does not response the application hangs isn't it?

Thanks

[Giovanni]

Hi,

Does it even make sense? SPI master does not wait for the peripheral, the peripheral has to handle data synchronously with the clock generated by the SPI master.

It could make sense for a SPI slave driver.

Giovanni

[neums]

Hi,
that is right.

[alexblack]

Hi.
But in some cases, especially on STM, it might be. Also it can catch some hardware errors. I think timeouts must be as option.

[neums]

Hi,
i have this problem again now. I have an external flash ROM connected to SPI. Then everything works fine. But if this SPI chip is not connected correctly then i fall into an endless osalThreadSuspend (i do not use the kernel so i use the os-less osal). For this cases a timeout might be good or not? Instead of a timeout there is also an error return possible due to the fact that SPI has no timeouts because of its clock driven synchonization.

I have this problem when is call spiSend.

Thanks

[Giovanni]

It is strange, from the driver point of view the external device is irrelevant, spiSend() should complete regardless the connections. It is possible that wrong connections trigger some kind of hardware problem that disturbs DMAs or SPI itself. Alternatively there could be a bug in the OS-less OSAL but that would not be triggered by connections.

About the API, timeouts are not a good idea because that would make SPI latency much worse, it is a driver where latency matters.

If you need a safety guard then you have to start an asynchronous function and a virtual timer atomically, on the SPI callback stop the timer. If you get the timer callback then an error occurred. A GPT timer can be used in the same way if you don't use RT.

The error is of the "impossible" kind so handling should involve stopping the SPI driver IMHO, it should be handled as a critical error.

Example:

Code: Select all

chSysLock();
spiStartSendI();
chVTSetI();
chSysUnlock();

The above method is usable with all driver with asynchronous API.

Giovanni