From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23265 invoked by alias); 27 Nov 2007 16:44:58 -0000 Received: (qmail 23251 invoked by uid 22791); 27 Nov 2007 16:44:56 -0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_40,DK_POLICY_SIGNSOME X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Nov 2007 16:44:49 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id lARGikn27230; Tue, 27 Nov 2007 16:44:46 GMT Received: from [192.168.7.9] (unknown [87.127.20.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 8F9463FF6; Tue, 27 Nov 2007 16:44:44 +0000 (GMT) Message-ID: <474C497A.8060005@jifvik.org> Date: Tue, 27 Nov 2007 16:44:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Andrew Lunn Cc: Tom Deconinck , eCos Devel Subject: Re: [ECOS] TWI/I?C driver for AT91 References: <20071122182743.GA11305@lunn.ch> In-Reply-To: <20071122182743.GA11305@lunn.ch> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2007-11/txt/msg00004.txt.bz2 Andrew Lunn wrote: > On Thu, Nov 22, 2007 at 05:42:11PM +0100, Tom Deconinck wrote: >> Hello, >> >> Does anyone know if there exists a driver for the AT91 TWI peripheral? >> It's Atmels implementation of I?C and it's used on the AT91SAM7S >> family (and derivatives). >> I would create a driver that fits in the eCos I?C driver (master >> only), but I wanted to check to make sure nothing alike already >> exists. > > I've been involved in a none eCos project which used an AT91SAM7S and > the TWI port. This turned out to be more difficult than expected. If > you don't feed it data fast enough it stops the transfer mid message > with an abort of something. Also, there is no DMA for this device. So > you need to make sure your other interrupt handlers are fast or you > run into problems. Hmm, I've done an AT91 TWI implementation for eCosPro, and didn't have abort problems. But then there are caveats on its use as it isn't a brilliant fit with the I2C API - in particular there's no way to send NACKs without a STOP, and (I might be misremembering here - it's been a while) I think possibly no way to do a STOP not in conjunction with a transfer. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine