public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Peter Niebert <peter@niebert.com>
To: Bart Veer <bartv@ecoscentric.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] SPI and 9 bit transfers (on AT91)
Date: Wed, 27 May 2009 17:35:00 -0000	[thread overview]
Message-ID: <06FBFDFF-BA5D-4DDE-967B-49F7725EAEB0@niebert.com> (raw)
In-Reply-To: <pnljoiiium.fsf@delenn.bartv.net>

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

  reply	other threads:[~2009-05-27 17:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22  9:55 Peter Niebert
2009-05-27 16:58 ` Bart Veer
2009-05-27 17:35   ` Peter Niebert [this message]
2009-05-28 10:32     ` Bart Veer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06FBFDFF-BA5D-4DDE-967B-49F7725EAEB0@niebert.com \
    --to=peter@niebert.com \
    --cc=bartv@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).