[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

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

--- Comment #62 from Ilija Kocho <ilijak@siva.com.mk> 2012-10-14 16:23:04 BST ---
(Addendum to comment #61)
> (In reply to comment #58)
> 
> Hi Stefan
> 
> > Hi ecos Maintainers, Jonathan,
> > any progress on the review of our contribution ? It has almost been two months
> > and we heard nothing so far. I was hoping, that active contributions are more
> > appreciated ?!
> 
> In comment #32 and comment #33 Jifl mentiond duplicate files, and they are
> still present in recent attachment #1872 [details] (aka /MPC5xxx HAL packages/ ).
> There are a lot of definitions repeating across /include/ directories of all
> platforms, in files such as: var_regs.h, mpc5*.h, plf_intr.h, etc. These can,
> and should be consolidated in respective files placed in var/current/include
> directory.
> 
> Also some of these files, notably mpc5*.h have copyright banners that are
> incompatible with eCos licence.
> 

Most of these definitions are actually for devices.
The definitions related to peripherals that have I/O device drivers, (for
example FlexCAN) should live in respective driver directories. That will
decouple them from the HAL and aid design of generic drivers. (Just to note, I
also see some redundant definitions such as ESCI.)

As a guide, var_io.h should contain definitions for peripherals that do not
belong to IO subsystem: clocking, interrupt controller, system integration,
clock/power management, etc.

Here also comes DMA, and I FYI there is a generic eDMA library under
packages/hal/misc/freescale/edma. 

Following peripherals combined with diverse Freescale architectures have
generic eCos drivers (that include headers):
   - ESCI
   - FlexCAN (the converted driver)
   - DSPI (uses eDMA)
   - Ethernet
   - UART
   - I2C (Last one in bug 1001397).

> This is my impression, but could the number of platforms be reduced, at least
> for initial port? I have impression that the aim is to cover every chip (which
> is not bad) but could some of these platforms be consolidated? It will make the
> review and maintenance easier.
> 
> Regards
> 
> Ilija

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