Am 12.03.2016 um 08:21 schrieb Mark Brown: > On Mon, Feb 22, 2016 at 12:42:59PM +0100, Oleksij Rempel wrote: >> Am 22.02.2016 um 12:09 schrieb Mark Brown: > >>> Oh, so this isn't SPI_READY? > >> Not 100%. >> According to TI documentation, transfer initiated by master looks like: >> 1. Master: SPIx_CS (on) >> 2. Slave: SPIx_READY (on) >> 3. Master: Date transfer >> 4. Slave: SPIx_READY (off) >> 5. Master: SPIx_CS (off) > >> Bosch version of 5-wire transfer initiated by master: >> 1. Master: SPIx_CS (on) >> 2. Slave: SPIx_REQUEST (on) >> 3. Master: Date transfer >> 4. Master: SPIx_CS (off) <----- different order. >> 5. Slave: SPIx_REQUEST (on) <----- > > I can't tell the difference between these two cases. In the first case > the device gets busy after the data is transferred, in the second case > it never changes the request line but really there's no meaningful > difference I can see. > There is no difference from device point of view, the difference is only on Master side. The TI SPI Master can be stopped by Slave in the middle of transfer, and if the data transfer was actually done, then Master will dessert CS line. This is why i'm trying to make a difference between slaves which will only confirm start of transfer but will never try to stop it, and Slaves which will do it. Because if device can use Ready line to hold or stop data transfer, then this support can be implemented only by limited number of SPI Master controllers (for example, currently only by: spi-davinci and spi-gpio). In case of Bosch implementation, the slave should actually confirm change of CS. -- Regards, Oleksij
Attachment:
signature.asc
Description: OpenPGP digital signature
