Hi,

I am (so far) using mostly J.C. Wren's code to run small applications
on an LPC2148 board. Turns out I don't need USB that much after all,
so I play with LPC2103 now using the FreeRTOS ARM7_LPC2106_GCC
example. I use gcc, so that's all fine.

And then I thought: would it not be nice to have one header file which
include all LPC members (or at least a family like LPC21xx), so that
compiling for LPC2103 and for LPC2148 is as simple as you can say "-D
LPC2148".

I'd expect NXP to have this available, but either that is not the case
or they are hiding it well.

Does that exist?

If not, then I'll start with the complete looking lpc214x.h from J.C.
and use #ifdef's to limit the LPC210x from showing too much definitions.

Harald
Start a New Thread

Hi Harald,

A problem I would worry about is the inevitable issue of errors
in the header files, and how one ensures corrections to them are
automatically applied to the "universal" header.

The way I tacked this problem with PICs (where I only _needed_
small-memory parts, but occasionally only large-memory parts
were in stock) was to have a file "processor.h" which had all
the appropriate switches along the lines of
#ifdef __16F914
#include
#endif
#ifdef __16F917
#include
#endif
(Strictly speaking this was assembly code, so the extension
was .inc not .h but you get the idea).

This way I would always use the appropriate unedited header as
supplied by my vendor, and if ever the vendor made corrections
to those files I did not need to edit anything to use the
corrected file.

Am I being over-cautious or making things over-complicated?
Maybe, but I do see occasional corrections to headers in the
revision history of the lpc IDE I use (Rowley Crossworks).

The other option available with Crossworks is slightly-more-
generic headers like lpc213x.h or lpc21xx.h instead of the
processor-specific lpc2138.h

Just my two-cents worth.
- Danish
--- In l..., Harald Kubota wrote:
>
> Hi,
>
> I am (so far) using mostly J.C. Wren's code to run small applications
> on an LPC2148 board. Turns out I don't need USB that much after all,
> so I play with LPC2103 now using the FreeRTOS ARM7_LPC2106_GCC
> example. I use gcc, so that's all fine.
>
> And then I thought: would it not be nice to have one header file which
> include all LPC members (or at least a family like LPC21xx), so that
> compiling for LPC2103 and for LPC2148 is as simple as you can say "-D
> LPC2148".
>
> I'd expect NXP to have this available, but either that is not the case
> or they are hiding it well.
>
> Does that exist?
>
> If not, then I'll start with the complete looking lpc214x.h from J.C.
> and use #ifdef's to limit the LPC210x from showing too much definitions.
>
> Harald
>

Start a New Thread

--- In l..., Harald Kubota wrote:
>
> And then I thought: would it not be nice to have one header file
which
> include all LPC members (or at least a family like LPC21xx), so that
> compiling for LPC2103 and for LPC2148 is as simple as you can say "-
D
> LPC2148".
>
> I'd expect NXP to have this available, but either that is not the
case
> or they are hiding it well.
>
> Does that exist?
>

Not that I'm aware of.

I came to the same conclusion myself a while ago. Consequently, in
the design of Armaide (the Oberon-07 language ARM Development
System) I have allowed for one generic module containing the common
definitions for LPC2xxx and a separate module only contains the
additional definitions specifically for each LPC variant.

e.g. the generic module contains definitions for PINSEL, IOPIN, FIO,
MAM, PLL, Timer, UART etc.

Modules that only use generic features then only need to reference
LPC2xxx whereas the processor-specific modules usually reference the
generic module and the processor sub-family specific module (e.g.
LPC214x).

I have not used C since the 1990's but from memory I can think of no
technical reason why a similar strategy could not be used in a C
language based development system.

Regards,
Chris Burrows
Armaide: Oberon-07 ARM Development System for Windows
http://www.armaide.com

Start a New Thread