Page 1 of 1
Missing timeout in SPI synchronous functions
Posted: Fri Mar 04, 2016 11:42 am
by 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
Re: Missing timeout in SPI synchronous functions
Posted: Fri Mar 04, 2016 12:16 pm
by 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
Re: Missing timeout in SPI synchronous functions
Posted: Fri Mar 04, 2016 12:54 pm
by neums
Hi,
that is right.
Re: Missing timeout in SPI synchronous functions
Posted: Mon Mar 28, 2016 6:20 am
by 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.
Re: Missing timeout in SPI synchronous functions
Posted: Thu Mar 31, 2016 4:02 pm
by 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
Re: Missing timeout in SPI synchronous functions
Posted: Thu Mar 31, 2016 4:17 pm
by 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