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 <[email protected]> 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
