From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26676 invoked by alias); 27 Nov 2008 17:15:22 -0000 Received: (qmail 26665 invoked by uid 22791); 27 Nov 2008 17:15:20 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Nov 2008 17:14:26 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 774AB21800D; Thu, 27 Nov 2008 17:14:23 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haVhYlJnABZT; Thu, 27 Nov 2008 17:14:22 +0000 (GMT) Message-ID: <492ED567.2080900@eCosCentric.com> Date: Thu, 27 Nov 2008 17:15:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Sergei Gavrikov CC: eCos patches list Subject: Re: Support for LPC2XXX IAP interface References: <20081127125253.GA20616@sg-ubuntu.local> In-Reply-To: <20081127125253.GA20616@sg-ubuntu.local> X-Enigmail-Version: 0.94.4.0 OpenPGP: id=A5FB74E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-11/txt/msg00118.txt.bz2 Sergei Gavrikov wrote: > > I saw no such a support in other HALs. And I decided to put it under the > lpc2xxx/var tree. > > RFC: Is it a good place for the interface in lpc2xxx/var? Seems fine. > +//========================================================================== > + > +#include > +#include > + > +#include > + > +extern int diag_printf (char *, ...); include diag.h > +externC void > +#ifdef CYGPKG_KERNEL > +cyg_user_start (void) > +#else > +cyg_start (void) > +#endif > +{ Why ifdef kernel? > +cyg_uint32 > +lpc_iap_call (cyg_uint32 cmd, cyg_uint32 par0, cyg_uint32 par1, > + cyg_uint32 par2, cyg_uint32 par3, cyg_uint32 *ret); This would be better named something like hal_lpc2xxx_iap_call. > +// 1) WARNING: lpc on-chip flash memory is not accessible during erase and > +// write operations. When the user application code starts executing the > +// interrupt vectors from the user flash area are active. The user should > +// either disable interrupts, or ensure that user interrupt vectors are active > +// in RAM and that the interrupt handlers reside in RAM, before making a flash > +// erase/write IAP call. The IAP code does not use or disable interrupts. You say the user, but below, you do disable interrupts. It sounds like this could be a CDL option, which defaults to what you do i.e. disabling interrupts (for safety). After all, the flash programming would severely hamper real-time operation so many people would want to avoid it.. Otherwise fine. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine