[ECOS] SPI and 9 bit transfers (on AT91)

[ECOS] SPI and 9 bit transfers (on AT91)

[Peter Niebert]

SPI transfers can vary depending on the protocol between 8 and 16  
bits. The generic SPI API suggests transfers in multiples of 8bits  
though. How should this be interpreted in cases of protocols with 9 or  
more bits?
I suppose that there is no other way than splitting such transfers to  
two bytes. It could be acceptable to have this transparent in the  
generic SPI API, but the byte order has to be clarified somewhere.

Now I look at the SPI driver for AT91, which currently implements 8bit  
transfers only. The configuration record could be extended by an  
additional field (bits, by default 8). Then the transfer functions  
(polled and dma) have to be adapted. I have no idea how the dma  
controller interpretes the transfers for the case of 9bit or higher,  
but in principle it should interprete these transfers as half words.

It is of course possible to start with an implementation of polled mode.

Any suggestions?

Thanks!



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] SPI and 9 bit transfers (on AT91)

[Bart Veer]

>>>>> "Peter" == Peter Niebert <peter@niebert.com> writes:

    Peter> SPI transfers can vary depending on the protocol between 8
    Peter> and 16 bits. The generic SPI API suggests transfers in
    Peter> multiples of 8bits though. How should this be interpreted
    Peter> in cases of protocols with 9 or more bits? I suppose that
    Peter> there is no other way than splitting such transfers to two
    Peter> bytes. It could be acceptable to have this transparent in
    Peter> the generic SPI API, but the byte order has to be clarified
    Peter> somewhere.

The current SPI already defines semantics for transfers of more than 8
bits. See http://ecos.sourceware.org/docs-latest/ref/spi-api.html,
section "Simple Transfers", and the description of the tx_data
argument. Basically tx_data will be interpreted as an array of shorts
instead of bytes, and only the bottom n bits of each short will be
transferred.

These semantics were appropriate for the ColdFire QSPI device, and the
first eCos SPI driver targetted that device. It also seems like the
simplest semantics from the perspective of application developers. I
do not know how well it maps onto the AT91 hardware.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] SPI and 9 bit transfers (on AT91)

[Peter Niebert]

Just to be sure, this means that the count would be "shorts" rather  
than "bytes" in the case of transfers between 9 and 16 bits?
I will soon be able to post a patched version of the at91_spi driver  
that allows for different bit length transmits.

Cheers and thanks for eCos, again and again.

-- Peter


Le 27 mai 09 à 18:57, Bart Veer a écrit :

>>>>>> "Peter" == Peter Niebert <peter@niebert.com> writes:
>
>    Peter> SPI transfers can vary depending on the protocol between 8
>    Peter> and 16 bits. The generic SPI API suggests transfers in
>    Peter> multiples of 8bits though. How should this be interpreted
>    Peter> in cases of protocols with 9 or more bits? I suppose that
>    Peter> there is no other way than splitting such transfers to two
>    Peter> bytes. It could be acceptable to have this transparent in
>    Peter> the generic SPI API, but the byte order has to be clarified
>    Peter> somewhere.
>
> The current SPI already defines semantics for transfers of more than 8
> bits. See http://ecos.sourceware.org/docs-latest/ref/spi-api.html,
> section "Simple Transfers", and the description of the tx_data
> argument. Basically tx_data will be interpreted as an array of shorts
> instead of bytes, and only the bottom n bits of each short will be
> transferred.
>
> These semantics were appropriate for the ColdFire QSPI device, and the
> first eCos SPI driver targetted that device. It also seems like the
> simplest semantics from the perspective of application developers. I
> do not know how well it maps onto the AT91 hardware.
>
> Bart
>
> -- 
> Bart Veer                                   eCos Configuration  
> Architect
> eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
> Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223  
> 245571
> Registered in England and Wales: Reg No 4422071.


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] SPI and 9 bit transfers (on AT91)

[Bart Veer]

>>>>> "Peter" == Peter Niebert <peter@niebert.com> writes:

    Peter> Just to be sure, this means that the count would be
    Peter> "shorts" rather than "bytes" in the case of transfers
    Peter> between 9 and 16 bits? I will soon be able to post a
    Peter> patched version of the at91_spi driver that allows for
    Peter> different bit length transmits.

    Peter> Cheers and thanks for eCos, again and again.

The count is the number of data items to be transferred. If the count
is 100 and the SPI device is set up for 9-bit transfers, both tx_data
and rx_data should point at arrays of 100 shorts, i.e. 1600 bits. Only
900 bits would actually get transferred over the SPI bus.

Bart
    
-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss