> You have one in the lpc2378 demo. If you want to add libraries, look
> at the Makefile I have in the Files folder here on Yahoo lpc2000. You
> will need to change all the 'arm-elf' strings to 'arm-eabi'
>
> In my Makefile, look at how I spec the LOCATION. Change to suit...
> Change all arm-elf- to arm-eabi-
>
> Look at the ARCHIVE1 and ARCHIVE2 definitions. These specify the path
> to the various libraries. Fix them to match your installation
>
> Look at the LIBRARIES definition. It says that libc and libg are in
> ${LOCATION}/arm-elf/lib (change to arm-eabi). libgcc is in
> ${LOCATION}/lib/gcc/arm-elf/4.0.2 Fix the path to match
> arm-eabi/ This Makefile lists all of the source files (SRCS = ) and object files
> to be created (OBJS = )
>
> 'make all' (or just 'make' as 'all' is the default target because it
> is the FIRST target) checks the dependencies, creates a builddate.h
> file and recursively makes the '${TARGET}.hex' 'sizes' and 'list' targets.
>
> ${TARGET}.hex depends on ${TARGET}.elf which depends on ${LDSCRIPT}
> crt.o and ALL object files ${OBJS} and ${TARGET}.hex simply uses
> objcopy to convert from .elf (.eabi?) to .hex. You probably need to
> think about this since your file is .eabi.
>
> ${TARGET}.elf does all the work of linking the object files and the
> libraries.
>
> The ${OBJS} target compiles each of the .c files whose .o filename is
> listed in ${OBJS}.
>
> The 'depend' target is hairy. It runs through the source files
> looking for dependencies and builds a new Makefile. Notice all the
> dependencies listed below # DO NOT DELETE (Dependencies follow)
>
> Don't delete the first line of the Makefile because it is searched for
> by awk. awk copies from the top of the Makefile through the DO NOT
> DELETE line before it builds all of the dependencies. Then it decides
> whether to keep the new Makefile or scrap it. Keep or scrap is
> important because of the file date. It would be unwise to always keep
> if there are no changes.
>
> Richard

IT WORKS!, i've downloaded "lpc2378_demo1_20070629.zip" from here:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/lpc2378_demo1_20070629.zip

I modified it to blink my leds, and it works fine (devkitARM toolchain)

Now i see serveral NXP files on this example:

- timer.c: Timer C file for NXP LPC23xx/24xx Family Microprocessors
- target.c: Target C file for NXP LPC23xx/24xx Family Microprocessors
- irq.c: Interrupt handler C file for NXP LPC23xx/24xx Family Microprocessors
- fio.c: Fast I/O module file for NXP LPC23xx Family Microprocessors
- uart.c: UART API file for NXP LPC23xx/24xx Family Microprocessors

I'm trying to find any information regarding this files which seem to
be official NXP support files and a good api for several things. Is
there any documentation available on this files? or do i have to read
the code and figure out myself?

I would like to include this (or similar ones) files into my app skeleton.

Thanks in advance.

Regards,
Jorge.

An Engineer's Guide to the LPC2100 Series

>> Have you had a look at FreeRTOS.org. There is an eclipse demo there for the
> lpc23xx devices. It has a Makefile. I used it as a basis for an lpc2368
> board I
> have and it is working fine under linix using I think v4.2 gnuarm compiler
> and
> newlib, which I built myself from following the instructions on gnuarm.org
>

Well, just downloaded and compiled FreeRTOS (ARM7_LPC2368_Eclipse
demo) and it compiles fine, no errors, etc.

The demo doesn't work with my board, of course i've configured IP
address to match my network settings and so on, i think it could be
an LPC revision issue or some other problem related with my board
(http://www.futurlec.com/ARM2368_Controller.shtml). The board comes
with a EasyWeb.hex sample that works fine (i'm able to see the webpage
served from the LPC2368) so i can assume there's no hardware problem,
and no network problems.

Anyway, just for testing, i edited the main.c on FreeRTOS demo and
simply replaced the main function "void main(void)" with the code i
know is working on the LED_BLINK demo from olimex. This is now my main
function code:

(The board comes with 2 leds: One on p3.25 and the other one on p3.26,
and a beeper on p2.8)

int main ( void )
{

long j;
prvSetupHardware(); // Call Hardware init just as FreeRTOS main
function does it.

// Config Pin GPIO = P2[8] Drive Mini Speaker Generate Beep
PINSEL4 &= 0xFFFCFFFF; // Config P2[8] = GPIO Function
FIO2DIR |= 0x00000100; // Config P2[8] = Output

PINSEL7 &= 0xFFC3FFFF; // Config P3[26:25] = GPIO Function
PINMODE7 &= 0xFFC3FFFF; // Enable Pull-Up on P3[26:25]

// set io pins for led P0.21
FIO3DIR |= 0x06000000; // P3.25 OUTPUT, P3.26 OUTPUT

FIO3SET = 0x06000000;

FIO3CLR = 0x06000000;

FIO2DIR |= 0x00000100; // P2.8 OUTPUT

// Blink everything.

while (1)

{

{
FIO2SET = 0x00000100; // P2[8] = "1" (ON Speaker)

FIO3CLR = 0x06000000; // Leds ON

for (j = 0; j < 2000000; j++ );

FIO2CLR = 0x00000100; // P2[8] = "0" (OFF Speaker)

FIO3SET = 0x06000000; // Leds OFF

for (j = 0; j < 2000000; j++ );

}

}

}
This code doesn't works, while on the original example from olimex it
works fine being compiled with the same toolchain. Any ideas? I know
it must be my fault, maybe i should pay attention to hardware init or
something, but i don't know where to start looking. Sorry for keep on
asking dumb questions, but it must be something that i don't see,
maybe with some help i sucess on this.

Thank you everybody for taking time to answer.

Regards ,

Jorge.

On Thu, Sep 18, 2008 at 7:02 PM, rtstofer wrote:
> --- In l..., "Jorge S." wrote:
>
>> Same here, devkitARM works with a blinking led example on my LPC23xx
>> (example downloaded from Olimex).
>>
>> The problem is that this example manually calls the LD and it only
>> works (as i described before) when you
>> don't include any newlib .h file
>
> Actually, if I'm looking at the same project, the makefile calls ld.
> This is the way it will ALWAYS be done. gcc calling ld implicitly is
> used only for very small projects and those are mostly native (platform).
>
>> What i'm crying for ... is a well done LPC2368 app skeleton / Makefile
>> to start working with :)
>
> You have one in the lpc2378 demo. If you want to add libraries, look
> at the Makefile I have in the Files folder here on Yahoo lpc2000. You
> will need to change all the 'arm-elf' strings to 'arm-eabi'
>
> In my Makefile, look at how I spec the LOCATION. Change to suit...
> Change all arm-elf- to arm-eabi-
>
> Look at the ARCHIVE1 and ARCHIVE2 definitions. These specify the path
> to the various libraries. Fix them to match your installation
>
> Look at the LIBRARIES definition. It says that libc and libg are in
> ${LOCATION}/arm-elf/lib (change to arm-eabi). libgcc is in
> ${LOCATION}/lib/gcc/arm-elf/4.0.2 Fix the path to match
> arm-eabi/ This Makefile lists all of the source files (SRCS = ) and object files
> to be created (OBJS = )
>
> 'make all' (or just 'make' as 'all' is the default target because it
> is the FIRST target) checks the dependencies, creates a builddate.h
> file and recursively makes the '${TARGET}.hex' 'sizes' and 'list' targets.
>
> ${TARGET}.hex depends on ${TARGET}.elf which depends on ${LDSCRIPT}
> crt.o and ALL object files ${OBJS} and ${TARGET}.hex simply uses
> objcopy to convert from .elf (.eabi?) to .hex. You probably need to
> think about this since your file is .eabi.
>
> ${TARGET}.elf does all the work of linking the object files and the
> libraries.
>
> The ${OBJS} target compiles each of the .c files whose .o filename is
> listed in ${OBJS}.
>
> The 'depend' target is hairy. It runs through the source files
> looking for dependencies and builds a new Makefile. Notice all the
> dependencies listed below # DO NOT DELETE (Dependencies follow)
>
> Don't delete the first line of the Makefile because it is searched for
> by awk. awk copies from the top of the Makefile through the DO NOT
> DELETE line before it builds all of the dependencies. Then it decides
> whether to keep the new Makefile or scrap it. Keep or scrap is
> important because of the file date. It would be unwise to always keep
> if there are no changes.
>
> Richard
>

Ok, will try it today, thank you.

On Thu, Sep 18, 2008 at 5:42 PM, ben_fnr wrote:
> --- In l..., "Jorge S." wrote:
>>
>> On Thu, Sep 18, 2008 at 5:03 PM, rtstofer wrote:
>> > --- In l..., "Jorge S." wrote:
>> >
>> >> Uhm, bad news for me. I'm trying now the devkitARM toolchain wich
>> >> seems to be very
>> >> up to date. Any opinions on this one?
>> >>
>> >>
>> >
>> > I just installed the binary distribution of devkitARM and compiled a
>> > little blinking LED program for the LPC2106. It works correctly.
>> >
>> > I had to change the makefile because devkitARM uses eabi format
>> > instead of elf so gcc is known as arm-eabi-gcc instead of arm-elf-gcc.
>> >
>> > I have no idea what advantage/disadvantage there may be in eabi vs elf.
>> >
>> > But the code works.
>> >
>> > I may get around to building the kit from source using the scripts
>> > provided.
>> >
>> > Richard
>> >
>>
>> Same here, devkitARM works with a blinking led example on my LPC23xx
>> (example downloaded from Olimex).
>>
>> The problem is that this example manually calls the LD and it only
>> works (as i described before) when you
>> don't include any newlib .h file
>>
>> I've other example files from the WinARM guys and i can compile
>> several examples without problems, but none is working.
>>
>> What i'm crying for ... is a well done LPC2368 app skeleton / Makefile
>> to start working with :)
>>
>> Thank you again for taking your time answering my very-newbie questions.
>> Have you had a look at FreeRTOS.org. There is an eclipse demo there for the
> lpc23xx devices. It has a Makefile. I used it as a basis for an lpc2368
> board I
> have and it is working fine under linix using I think v4.2 gnuarm compiler
> and
> newlib, which I built myself from following the instructions on gnuarm.org

Just downloading the FreeRTOS demo. Thanks for the info. My devkitARM
is built with newlib, maybe i'm lucky on this and
i wont need to manually build newlib.
>
> Ben

--- In l..., "Jorge S." wrote:

> Same here, devkitARM works with a blinking led example on my LPC23xx
> (example downloaded from Olimex).
>
> The problem is that this example manually calls the LD and it only
> works (as i described before) when you
> don't include any newlib .h file

Actually, if I'm looking at the same project, the makefile calls ld.
This is the way it will ALWAYS be done. gcc calling ld implicitly is
used only for very small projects and those are mostly native (platform).
> What i'm crying for ... is a well done LPC2368 app skeleton / Makefile
> to start working with :)
You have one in the lpc2378 demo. If you want to add libraries, look
at the Makefile I have in the Files folder here on Yahoo lpc2000. You
will need to change all the 'arm-elf' strings to 'arm-eabi'

In my Makefile, look at how I spec the LOCATION. Change to suit...
Change all arm-elf- to arm-eabi-

Look at the ARCHIVE1 and ARCHIVE2 definitions. These specify the path
to the various libraries. Fix them to match your installation

Look at the LIBRARIES definition. It says that libc and libg are in
${LOCATION}/arm-elf/lib (change to arm-eabi). libgcc is in
${LOCATION}/lib/gcc/arm-elf/4.0.2 Fix the path to match
arm-eabi/

This Makefile lists all of the source files (SRCS = ) and object files
to be created (OBJS = )

'make all' (or just 'make' as 'all' is the default target because it
is the FIRST target) checks the dependencies, creates a builddate.h
file and recursively makes the '${TARGET}.hex' 'sizes' and 'list' targets.

${TARGET}.hex depends on ${TARGET}.elf which depends on ${LDSCRIPT}
crt.o and ALL object files ${OBJS} and ${TARGET}.hex simply uses
objcopy to convert from .elf (.eabi?) to .hex. You probably need to
think about this since your file is .eabi.

${TARGET}.elf does all the work of linking the object files and the
libraries.

The ${OBJS} target compiles each of the .c files whose .o filename is
listed in ${OBJS}.

The 'depend' target is hairy. It runs through the source files
looking for dependencies and builds a new Makefile. Notice all the
dependencies listed below # DO NOT DELETE (Dependencies follow)

Don't delete the first line of the Makefile because it is searched for
by awk. awk copies from the top of the Makefile through the DO NOT
DELETE line before it builds all of the dependencies. Then it decides
whether to keep the new Makefile or scrap it. Keep or scrap is
important because of the file date. It would be unwise to always keep
if there are no changes.

Richard

--- In l..., "Jorge S." wrote:
>
> On Thu, Sep 18, 2008 at 5:03 PM, rtstofer wrote:
> > --- In l..., "Jorge S." wrote:
> >
> >> Uhm, bad news for me. I'm trying now the devkitARM toolchain wich
> >> seems to be very
> >> up to date. Any opinions on this one?
> >>
> >>
> >
> > I just installed the binary distribution of devkitARM and compiled a
> > little blinking LED program for the LPC2106. It works correctly.
> >
> > I had to change the makefile because devkitARM uses eabi format
> > instead of elf so gcc is known as arm-eabi-gcc instead of arm-elf-gcc.
> >
> > I have no idea what advantage/disadvantage there may be in eabi vs elf.
> >
> > But the code works.
> >
> > I may get around to building the kit from source using the scripts
> > provided.
> >
> > Richard
> > Same here, devkitARM works with a blinking led example on my LPC23xx
> (example downloaded from Olimex).
>
> The problem is that this example manually calls the LD and it only
> works (as i described before) when you
> don't include any newlib .h file
>
> I've other example files from the WinARM guys and i can compile
> several examples without problems, but none is working.
>
> What i'm crying for ... is a well done LPC2368 app skeleton / Makefile
> to start working with :)
>
> Thank you again for taking your time answering my very-newbie questions.
>

Have you had a look at FreeRTOS.org. There is an eclipse demo there for the
lpc23xx devices. It has a Makefile. I used it as a basis for an lpc2368 board I
have and it is working fine under linix using I think v4.2 gnuarm compiler and
newlib, which I built myself from following the instructions on gnuarm.org

Ben

On Thu, Sep 18, 2008 at 5:03 PM, rtstofer wrote:
> --- In l..., "Jorge S." wrote:
>
>> Uhm, bad news for me. I'm trying now the devkitARM toolchain wich
>> seems to be very
>> up to date. Any opinions on this one?
>>
>> I just installed the binary distribution of devkitARM and compiled a
> little blinking LED program for the LPC2106. It works correctly.
>
> I had to change the makefile because devkitARM uses eabi format
> instead of elf so gcc is known as arm-eabi-gcc instead of arm-elf-gcc.
>
> I have no idea what advantage/disadvantage there may be in eabi vs elf.
>
> But the code works.
>
> I may get around to building the kit from source using the scripts
> provided.
>
> Richard
>

Same here, devkitARM works with a blinking led example on my LPC23xx
(example downloaded from Olimex).

The problem is that this example manually calls the LD and it only
works (as i described before) when you
don't include any newlib .h file

I've other example files from the WinARM guys and i can compile
several examples without problems, but none is working.

What i'm crying for ... is a well done LPC2368 app skeleton / Makefile
to start working with :)

Thank you again for taking your time answering my very-newbie questions.

On Thu, Sep 18, 2008 at 4:46 PM, FreeRTOS.org Info wrote:
>> >
>> > Jorge S. wrote:
>> > > My problem comes when trying to use standard C library functions,
>> > > sprintf,memcpy, etc.
>> > >
>> > > Just issuing a gcc -v on the CodeSourcery toolchain, i
>> don't see any
>> > > reference to newlib,
>> > Been there recently, done that.
>
> Is this a personal project? If so, have you considered using CrossWorks?
> They support Linux and have *very* reasonable personal licensing terms.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org

Well, at this moment, it is a personal project. Just learning +
evaluating LPC23xx devices.

But i would like to release an open-hardware/software project near in
the future, so i would like to provide
a working toolchain for people who wants to use my hardware.

Any toughts?

Thanks for helping :)

--- In l..., "Jorge S." wrote:

> Uhm, bad news for me. I'm trying now the devkitARM toolchain wich
> seems to be very
> up to date. Any opinions on this one?

I just installed the binary distribution of devkitARM and compiled a
little blinking LED program for the LPC2106. It works correctly.

I had to change the makefile because devkitARM uses eabi format
instead of elf so gcc is known as arm-eabi-gcc instead of arm-elf-gcc.

I have no idea what advantage/disadvantage there may be in eabi vs elf.

But the code works.

I may get around to building the kit from source using the scripts
provided.

Richard

> >
> > Jorge S. wrote:
> > > My problem comes when trying to use standard C library functions,
> > > sprintf,memcpy, etc.
> > >
> > > Just issuing a gcc -v on the CodeSourcery toolchain, i
> don't see any
> > > reference to newlib,
> > Been there recently, done that.

Is this a personal project? If so, have you considered using CrossWorks?
They support Linux and have *very* reasonable personal licensing terms.

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.