This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: SPI and 9 bit transfers (on AT91)
- From: Bart Veer <bartv at ecoscentric dot com>
- To: Peter Niebert <peter at niebert dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 27 May 2009 17:57:53 +0100
- Subject: Re: [ECOS] SPI and 9 bit transfers (on AT91)
- References: <26F9EA9E-04C8-4BAF-869F-E7DDB41CC0A2@niebert.com>
>>>>> "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