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