[Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon@bugs.ecos.sourceware.org]

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 <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergei.gavrikov@gmail.com

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 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.