From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26637 invoked by alias); 17 Jan 2011 12:59:21 -0000 Received: (qmail 26611 invoked by uid 22791); 17 Jan 2011 12:59:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 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; Mon, 17 Jan 2011 12:59:13 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 95C892F7800D for ; Mon, 17 Jan 2011 12:59:10 +0000 (GMT) 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 PD6jQVfw6WBk; Mon, 17 Jan 2011 12:59:09 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sergei.gavrikov@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 17 Jan 2011 12:59:00 -0000 Message-Id: <20110117125909.05C4B2F78004@mail.ecoscentric.com> 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: 2011-01/txt/msg00028.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114 Sergei Gavrikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sergei.gavrikov@gmail.com --- Comment #6 from Sergei Gavrikov 2011-01-17 12:59:05 GMT --- Hi, First, Ilija, thank you for your contribution. [RFC to reviewers] As NXP does "copy and paste" own "PrimeCell" registers from a design to design (what is generally speaking is good for programmers) we can observe the same interference the device drivers in a code each other (e.g. lpc2xxx, lpc24xx and now lpc17xx). New Ilija's port for lpc17xx is a good example such an interference and how the hackers would deal with "PrimeCell" registers to reuse the code. Now, if you untar attachment 1184 please, look around % egrep -R '_LPC(24XX|2XXX)' lpc17xx/ I wonder get comments about such fragments, for example, from lpc17xx var_io.h: #define CYGARC_HAL_LPC24XX_REG_UART0_BASE \ CYGHWR_HAL_LPC17XX_REG_UART0_BASE #define CYGARC_HAL_LPC2XXX_REG_RTC_BASE CYGHWR_HAL_LPC17XX_REG_RTC_BASE etc. So, the above definitions let us to utilize some generic LPC2XXX, LPC24XX drivers (see bug 1001115). Pros: code reuse, code reuse, code reuse. Cons: code interference, "difficult" to understand HAL, the bloches of "foreigners" in the target definition (see attachment 1078). What do you think, can we be happy with such an interference? What will be happen if anyone will change some of the lpc2xxx, lpc24xx device drivers, and vice versa (someone will adopt its code for lpc17xx)? Well, this can be managed by a forest from the ifdefs, but may be we can just duplicate the Uwe's drivers code and put such lpc17xx drivers under devs/{eth,serial,wallclock}/cortextm/lpc17xx? Well, I see new "Cons" in my proposal: code duplication, code duplication, code duplication :-) Maybe someone found a better solution? And maybe my fears are baseless at all? Then forget it, please. Thanks. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.