This is the mail archive of the ecos-discuss@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]

Notification of changes required for CPU support


 
Although we are not ready yet to commit changes, I thought it
would be good if we would give an overview of changes required
to support a new processor/processor board combination under
ecos, and get feedback on what the form of the changes should
be before putting that back to the ecos project.

The lpc2xxx series from NXP (formerly Phillips) has proceeded
through the lpc21xx and lpc22xx series to the current lpc23xx
series. The board we are working with is the MCB2300 available
from Keil. The current support under ecos is the MCB2100 board.

Unfortunately, unlike what the lpc2xxx directory tree under
ecos implies, the lpc23xx series processors aren't in fact
compatible with the lpc21xx and lpc22xx series. The method
of handling interrupts changed. The lpc2xxx series is downward
compatable with the ARM convention of a single IRQ vector at
location $28 in that the vector automatically selected by the
processor is placed in a register, which the instruction at
$28 can move to the PC, thus accomplishing a vectored
interrupt. This is downward compatible with ARM general
conventions, because if the code ignores the automatic vectoring
and simply proceeds to the the IRQ handler code from $28,
the code will function, but simply not benefit from the
automatic vectoring.

The lpc2xxx code in ecos ignores the automatic vectoring, but
uses the lpc2xxx autovectoring hardware to automatically
determine which logical vector (from 0-15) is being serviced.
This is then passed to the IRQ service code when it reaches
the point it needs to find the vector number, so that it can
look it up in the hal_interrupt_data and hal_interrupt_handlers
tables.

Since the lpc2xxx/var code depends on the hardware vectoring
in this way, and also because the number of interrupts servicable
by the CPU increase from 16 to 32, and because of other minor
ways the interrupt handling changes, the lpc2xx/var code must
change for the lpc23xx processors.

Here is a list of the files that required changes:

../hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
../hal/arm/lpc2xxx/var/current/include/var_io.h

This gets us going, but clearly creates a conflict in ecos, 
since the lpc2xxx tree no longer supports all processors in the
series.

I'm open to suggestions about what to do about that before trying
to put it back to ecos. The possibilities are:

1. Break the lpc2xxx tree into lpc21xx_lpc22xx and lpc23xx trees.

2. Have the lpc2xxx code automatically configure per the processor.

Other?

Right now, I am just hacking up the lpc2xxx series to get our stuff
running without regard for lpc21xx and lpc22xx backwards compatibility.

Hey, blame Phillips for creating an incompatibility in their own
series.

Scott Moore
Powerfile Inc.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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