From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27684 invoked by alias); 22 May 2009 09:55:35 -0000 Received: (qmail 27671 invoked by uid 22791); 22 May 2009 09:55:34 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from 27.mail-out.ovh.net (HELO 27.mail-out.ovh.net) (91.121.30.210) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 22 May 2009 09:55:29 +0000 Received: (qmail 11235 invoked by uid 503); 22 May 2009 10:48:27 -0000 Received: from gw2.ovh.net (HELO mail94.ha.ovh.net) (213.251.189.202) by 27.mail-out.ovh.net with SMTP; 22 May 2009 10:48:27 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 22 May 2009 09:55:16 -0000 Received: from nap13-1-82-66-182-22.fbx.proxad.net (HELO ?192.168.0.10?) (82.66.182.22) by ns0.ovh.net with SMTP; 22 May 2009 09:55:15 -0000 Message-Id: <26F9EA9E-04C8-4BAF-869F-E7DDB41CC0A2@niebert.com> From: Peter Niebert To: ecos-discuss Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 09:55:00 -0000 X-Ovh-Tracer-Id: 8539669320399943332 X-Ovh-Remote: 82.66.182.22 (nap13-1-82-66-182-22.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] SPI and 9 bit transfers (on AT91) X-SW-Source: 2009-05/txt/msg00086.txt.bz2 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