Re: RFC: spibus: Return status of MISO line with transfer with xlen == 0;

Hi Uwe,

Am 07.09.2016 um 19:54 schrieb Uwe Bonnes:
>     Ole> Personally I think this is a very special function of this special
>     Ole> SPI client device. So it might be a good idea to implement it as a
>     Ole> IOCTL of the SPI node driver?
> 
> A short web search for "SPI POLL MISO brings up:
> "The cc1200 requires the cpu wait until the MISO goes low after dropping CS
> before talking with the chip"
>
> and for the EM9301:
> [...]
> So there is a class of SPI devices needing that poll.

Hm ok, interesting. I never was in contact with such a device before.
I'm wondering a little, as typically the SPI peripherals in the CPU does
not support polling of the MISO line. So if I understand your approach
correctly you will need to change the GPIO Pin configuration into GPIO
mode to read in the MISO level, than change it back to SPI and transfer
the data.

With some luck, the peripheral might support reading the input value
even in SPI mode. In this case you won't need to switch the AF before..

>     Ole> If not, I personally would suggest to implement a special API call
>     Ole> like
> 
>     Ole> int NutSpiBusGetMISOLine(NUTSPINODE * node).
> 
> Polling is much more like a zero length transfer than an IoCtl. And
> introducing an IoCtl function to the spibus driver will need more changes
> and more ram for the driver function table.
> Why do you prefer changing the Api interface versus changing an Api return
> value?

If only a few drivers implement this API change, then you might get a
malfunction, when connecting your device to a spibus driver that does
not support this change.

But if a driver would not implement the API, then you would get an
error, when calling the API, so you exactly know, that your device is
incompatible with the used spibus driver.

To be honest, I don't have a really good solution. I understand the pro
and cons of both versions, but both are not ideal.

Have you just checked, how other systems handle this case?

> The return value of the poll could also be written to dout of the transfer,
> not changing the API at all. Would that be more acceptable?
> 
>     Ole> Any further ideas?
> 
>     Ole> Btw: there is another LPC SPI driver beside of
>     Ole> "nut/arch/cm3/dev/nxp/lpc176x_spi.c":
> 
>     Ole> nut/arch/cm3/dev/nxp/lpc17xx_ssp.c
> 
> Will care for that driver too...

Great, thanks.

Best regards,

Ole

-- 
Embedded-IT
Alter Weg 3
57223 Kreuztal
http://www.embedded-it.de

Tel.: +49-177-7420433
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion