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

Hi Uwe,

you wrote "owidriver", but you mean "spibus driver", right?

I thought a little about this idea. Such a function should ideally be
implemented as IOCTL to the driver. Unfortunately the SPI-bus is not a
NUTDEVICE and therefore can not implement IOCTLs.

Personally I think this is a very special function of this special SPI
client device. So it might be a good idea to implement it as a IOCTL of
the SPI node driver?

If not, I personally would suggest to implement a special API call like

int NutSpiBusGetMISOLine(NUTSPINODE * node).

Any further ideas?

Btw: there is another LPC SPI driver beside of
"nut/arch/cm3/dev/nxp/lpc176x_spi.c":

nut/arch/cm3/dev/nxp/lpc17xx_ssp.c

Best regard,

Ole


Am 07.09.2016 um 12:55 schrieb Uwe Bonnes:
> Hello,
> 
> e.g. the LTC24xx delta-sigma converters with spi connection provide a static
> value on MISO to indicate conversion completion. With the present owibus
> driver, I don't see a way to query MISO via the driver. Instead the IO pin
> has to be queried by GPIO commands, requiring the user program  to know the
> MISO line.
> 
> I have a patch, extending the spi bus transfer functionality like:
> 
> /*!
>   * \brief Transfer data on the SPI bus using single buffered interrupt mode.
>   *
>   * A device must have been selected by calling At91SpiSelect().
>   *
> + * With xlen = 0, the status of the MISO line is returned.
> + *
>   * \param node  Specifies the SPI bus node.
>   * \param txbuf Pointer to the transmit buffer. If NULL, undetermined
>   *              byte values are transmitted.
>   * \param rxbuf Pointer to the receive buffer. If NULL, then incoming
>   *              data is discarded.
>   * \param xlen  Number of bytes to transfer.
>   *
> - * \return Always 0.
> + * \return Status of Miso with xlen == 0, 0 else.
>   */
> 
> Use like:
>         rc = (*bus->bus_transfer) (node, NULL, NULL, 0);
> 
> and implemented in following file:
> 
>  nut/arch/avr/dev/spibus0avr.c           |  7 ++++++-
>  nut/arch/cm3/dev/nxp/lpc176x_spi.c      |  7 ++++++-
>  nut/arch/cm3/dev/stm/stm32_spi.c        |  9 ++++++---
>  nut/dev/spibus0gpio.c                   | 13 ++++++++++++-
>  nut/dev/spibus_npl.c                    |  2 ++
>  9 files changed, 42 insertions(+), 6 deletions(-)
> 
> Only a fixme is added for some archs where I don't understand GPIO handling:
>  nut/arch/arm/dev/atmel/spibus0at91.c    |  2 ++
>  nut/arch/arm/dev/atmel/spibus0at91ssc.c |  2 ++
>  nut/arch/arm/dev/atmel/spibus1at91.c    |  2 ++
>  nut/arch/arm/dev/atmel/spibus_at91.c    |  4 ++++
> but not for some other archs.
> 
> Question:
> - Does this approach make sense?
> - Is it right to apply the patch even when for some archs the feature is not
>  implemented?
> 
> Cheers
> 

-- 
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