This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2011-01-18 11:04:25 GMT ---
(In reply to comment #6)

> [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 [details]).
> 
> 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.

My personal opinion is to favour code re-use in this case. The changes required
to these drivers to support LPC17xx are small. There are already a number of
eCos packages which have an inappropriate name or location in the repository
for historical reasons.

For each affected package, we could optionally change the CDL "display" and
"description" strings and the zeroth package "alias" string in ecos.db
(displayed by configtool) to make them more generic. We should not change any
CDL macro names or the API.

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]