[En-Nut-Discussion] RFC: spibus: Return status of MISO line with transfer with xlen == 0;
ole.reinhardt at embedded-it.de
Wed Sep 7 18:26:46 CEST 2016
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
Am 07.09.2016 um 12:55 schrieb Uwe Bonnes:
> 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.
> - Does this approach make sense?
> - Is it right to apply the patch even when for some archs the feature is not
Alter Weg 3
More information about the En-Nut-Discussion