From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15653 invoked by alias); 29 May 2010 10:24:04 -0000 Received: (qmail 15640 invoked by uid 22791); 29 May 2010 10:24:03 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mail-ww0-f49.google.com (HELO mail-ww0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 29 May 2010 10:23:57 +0000 Received: by wwc33 with SMTP id 33so1494040wwc.36 for ; Sat, 29 May 2010 03:23:54 -0700 (PDT) Received: by 10.227.127.84 with SMTP id f20mr1421957wbs.172.1275128632296; Sat, 29 May 2010 03:23:52 -0700 (PDT) Received: from [93.85.204.169] ([93.85.204.169]) by mx.google.com with ESMTPS id l23sm23601761wbb.14.2010.05.29.03.23.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 03:23:50 -0700 (PDT) Date: Sat, 29 May 2010 10:24:00 -0000 From: Sergei Gavrikov To: eCos Patches cc: Christophe Coutand , John Dallaway Subject: RE: AT91 ADC support In-Reply-To: Message-ID: References: <4BFE76A4.1010702@dallaway.org.uk> <4BFE860D.3060702@dallaway.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2010-05/txt/msg00054.txt.bz2 On Fri, 28 May 2010, Sergei Gavrikov wrote: > On Thu, 27 May 2010, Christophe Coutand wrote: >> Hi Sergei, >> >> I have attached an updated var_io.h that includes ADC support for the >> AT91M55800A. I took the opportunity to define the number of channels >> per ADC in this file. It can be overwritten per platform basis since >> AT91SAM7L64 for instance has 4 channels only. > > Hi Christophe, > > Thanks for your time. I will take a look this morning. [snip] >> The definition of AT91_MAX_ADC_CHAN must be removed from >> devs/adc/arm/at91/current/src/adc_at91.c. I have not joined any patch >> for it since I will hopefully submit a new driver that support both >> ADCs. Hi Christophe, John Excuse, that took a bit more time for testing. So, with the latest sent stuff, it's possible to build ADC driver and ADC tests for the next AT91 targets at91sam7sek: SUCCESS at91sam7xek: SUCCESS sam7ex256: SUCCESS eb55: SUCCESS phycore: SUCCESS I'm personally do not see any pit stops which would block a check-in the latest version of the driver. Christophe, thank you for your time and contribution. John? Sergei >> -----Original Message----- >> From: Sergei Gavrikov [mailto:sergei.gavrikov@gmail.com] >> Sent: 27. mai 2010 18:38 >> To: Christophe Coutand >> Cc: John Dallaway; eCos Patches >> Subject: RE: AT91 ADC support >> >> On Thu, 27 May 2010, Christophe Coutand wrote: >>> Hi John, >>> >>> It's pretty easy to add the required definition for the AT91M55800A >>> targets. The only thing I see now is that this device contains 2 ADCs >>> which I have not considered before. I guess there are several ways out >>> of this: >>> >>> 1- Update the actual AT91 ADC driver to make full use of the >>> AT91M55800A targets. I guess should be done by loading a second ADC >>> instance (one for each ADC. I have not been through all the thinking >>> here...). >>> >>> 2- or limit the AT91 driver to use only ADC0 of the AT91M55800A target >>> for the time being. >>> >>> 3- or exclude AT91M55800A targets for the time being. >>> >>> IMO #1 is best but I cannot give any time frame for completing it. >> >> Hi Christophe, John >> >> I would prefer #1, if you want I can add that in AT91/ADC CDL/sources. >> One thing: I won't be able to test it on real hardware (only build >> process can be tested me). >> >> John, what do you think: Can we add the second ADC instance without a >> testing? >> >>> One additional weakness of the driver is that it is made for up to 8 >>> channels. It is defined nowhere what the targeted CPU can actually >>> handle, this is left to the user when configuring eCos. I believe this >>> is pretty fine since the user must anyway know which signal he wants >> to >>> sample but you might disagree on that one. >> >> I know only one target which would use all 8 channels :-) That's eCos >> i386/Linux synthetic target. >> >> Thanks for collaboration. >> >> Sergei >> >>> Regards, >>> Christophe