Hi all:
I'm starting with the LPC2368, i own a development board from Futurlec.
As some people told me in this group, i've just downloaded and compiled
lpc2isp v1.60 under Linux, and its working fine,
i just sucessfully uploaded some example .hex files that came with my board.
Now i'm facing the toolchain dilema...
I've downloaeded 2 working toolchains, one from CodeSourcery (Sourcery
G++
Lite 2008q1-126) and another one from gnuarm.org.
Both toolchains are able to produce a working binary from a simple led blink
example source.
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, but issuing a gcc -v on the gnuarm
toolchain shows references to newlib. Anyway, i'm unable to create a
working
Makefile when linking newlib is involved.
My makefiles just work when no standard C lib includes are involved.
Just reading on the newlib docs, i found that manually calling LD isn't
recommened as the library is built with -multi-lib you
need to manually write all the lib paths, so you have to let gcc to link the
source, and here is when i'm totally stuck.
Questions:
- Since my host system is Linux, can somebody point me to a working
toolchain+newlib toolchain or provide any known working makefile
with some toolchain? Or do i have to build my own toolchain as stated here
-> http://www.openhardware.net/Embedded_ARM/Toolchain/?
- I saw some samples where people opens uarts using fopen(), is this a
newlib feature? Or maybe there are some additional
libs i can use to access peripherals "the easy way"?
Thanks in advance.
Regards,
Jorge.
Newbie again: Toolchain / Makefile questions.
Started by ●September 18, 2008
Reply by ●September 18, 20082008-09-18
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.
I tried to use the CodeSourcery's tool chain too and it failed to link
properly.
I guess it's well working for their environment, but for me it did not work.
I never tried the gnuarm chain as the ready-to-use binaries for Linux
were old.
The main ARM CPU I program is an LPC2148, but another one I have (no time
for it yet) is a Cortex M3 one, so I wanted to be able to create Thumb-2
code,
so it had to be a recent gcc.
In the end I compiled everything myself and never looked back.
See
http://harald.studiokubota.com/wordpress/2008/09/12/compiling-jcwrens-lpc2148-demo/
for a short version of what needs to be configured how.
> - I saw some samples where people opens uarts using fopen(), is this a
> newlib feature? Or maybe there are some additional
> libs i can use to access peripherals "the easy way"?
>
Newlib does not know how to open a serial port, how to "print" a character,
so you need to define those yourself. See
http://sourceware.org/newlib/libc.html#SEC195
I'd recommend to have a look at the mentioned LPC2148_Demo as it links
against newlib
and it does things like 'open ("/dev/uart1", O_RDONLY)' in gps.c and
lots of printf() everywhere.
Harald
> 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.
I tried to use the CodeSourcery's tool chain too and it failed to link
properly.
I guess it's well working for their environment, but for me it did not work.
I never tried the gnuarm chain as the ready-to-use binaries for Linux
were old.
The main ARM CPU I program is an LPC2148, but another one I have (no time
for it yet) is a Cortex M3 one, so I wanted to be able to create Thumb-2
code,
so it had to be a recent gcc.
In the end I compiled everything myself and never looked back.
See
http://harald.studiokubota.com/wordpress/2008/09/12/compiling-jcwrens-lpc2148-demo/
for a short version of what needs to be configured how.
> - I saw some samples where people opens uarts using fopen(), is this a
> newlib feature? Or maybe there are some additional
> libs i can use to access peripherals "the easy way"?
>
Newlib does not know how to open a serial port, how to "print" a character,
so you need to define those yourself. See
http://sourceware.org/newlib/libc.html#SEC195
I'd recommend to have a look at the mentioned LPC2148_Demo as it links
against newlib
and it does things like 'open ("/dev/uart1", O_RDONLY)' in gps.c and
lots of printf() everywhere.
Harald
Reply by ●September 18, 20082008-09-18
On Thu, Sep 18, 2008 at 4:13 PM, Harald Kubota 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.
>
> I tried to use the CodeSourcery's tool chain too and it failed to link
> properly.
> I guess it's well working for their environment, but for me it did not work.
>
> I never tried the gnuarm chain as the ready-to-use binaries for Linux
> were old.
> The main ARM CPU I program is an LPC2148, but another one I have (no time
> for it yet) is a Cortex M3 one, so I wanted to be able to create Thumb-2
> code,
> so it had to be a recent gcc.
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?
>
> In the end I compiled everything myself and never looked back.
> See
> http://harald.studiokubota.com/wordpress/2008/09/12/compiling-jcwrens-lpc2148-demo/
> for a short version of what needs to be configured how.
>
> > - I saw some samples where people opens uarts using fopen(), is this a
> > newlib feature? Or maybe there are some additional
> > libs i can use to access peripherals "the easy way"?
> > Newlib does not know how to open a serial port, how to "print" a character,
> so you need to define those yourself. See
> http://sourceware.org/newlib/libc.html#SEC195
Good information. Thanks.
>
> I'd recommend to have a look at the mentioned LPC2148_Demo as it links
> against newlib
> and it does things like 'open ("/dev/uart1", O_RDONLY)' in gps.c and
> lots of printf() everywhere.
For sure i'll take a look. I'm just learning and i would like to read
as much as i can.
>
Thank you for taking the time to help.
>
> 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.
>
> I tried to use the CodeSourcery's tool chain too and it failed to link
> properly.
> I guess it's well working for their environment, but for me it did not work.
>
> I never tried the gnuarm chain as the ready-to-use binaries for Linux
> were old.
> The main ARM CPU I program is an LPC2148, but another one I have (no time
> for it yet) is a Cortex M3 one, so I wanted to be able to create Thumb-2
> code,
> so it had to be a recent gcc.
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?
>
> In the end I compiled everything myself and never looked back.
> See
> http://harald.studiokubota.com/wordpress/2008/09/12/compiling-jcwrens-lpc2148-demo/
> for a short version of what needs to be configured how.
>
> > - I saw some samples where people opens uarts using fopen(), is this a
> > newlib feature? Or maybe there are some additional
> > libs i can use to access peripherals "the easy way"?
> > Newlib does not know how to open a serial port, how to "print" a character,
> so you need to define those yourself. See
> http://sourceware.org/newlib/libc.html#SEC195
Good information. Thanks.
>
> I'd recommend to have a look at the mentioned LPC2148_Demo as it links
> against newlib
> and it does things like 'open ("/dev/uart1", O_RDONLY)' in gps.c and
> lots of printf() everywhere.
For sure i'll take a look. I'm just learning and i would like to read
as much as i can.
>
Thank you for taking the time to help.
Reply by ●September 18, 20082008-09-18
--- In l..., "Jorge S." wrote:
>
> Hi all:
>
> I'm starting with the LPC2368, i own a development board from Futurlec.
>
> As some people told me in this group, i've just downloaded and compiled
> lpc2isp v1.60 under Linux, and its working fine,
> i just sucessfully uploaded some example .hex files that came with
my board.
>
> Now i'm facing the toolchain dilema...
>
> I've downloaeded 2 working toolchains, one from CodeSourcery
(Sourcery G++
> Lite 2008q1-126) and another one from gnuarm.org.
> Both toolchains are able to produce a working binary from a simple
led blink
> example source.
>
> My problem comes when trying to use standard C library functions,
> sprintf,memcpy, etc.
Yup! It's up to YOU to create the code for things like sbrk (for
malloc, used by sprintf) and all of the file functions. The best
example of this in in the LPC2148 demo code from www.jcwren.com/arm
Look in the newlib folder after extraction.
newlib provides stubs for these functions but you need to write the
actual code.
You can avoid the stub functions by just creating your own simplified
IO routines and avoiding string functions. Things like puts(),
putch() can be written specific to the hardware and no library
functions are required. There is some concern about using dynamic
memory allocation on an embedded processor with limited resources.
>
> Just issuing a gcc -v on the CodeSourcery toolchain, i don't see any
> reference to newlib, but issuing a gcc -v on the gnuarm
> toolchain shows references to newlib. Anyway, i'm unable to create a
working
> Makefile when linking newlib is involved.
Some suppliers include their own library. But, get your feet on the
same side of the river. Either use GNUARM or use Codesourcery. You
can't do both.
> My makefiles just work when no standard C lib includes are involved.
>
> Just reading on the newlib docs, i found that manually calling LD isn't
> recommened as the library is built with -multi-lib you
> need to manually write all the lib paths, so you have to let gcc to
link the
> source, and here is when i'm totally stuck.
It isn't multi-lib that causes the problem. It is the number of
options to ld that makes manual linking a nightmare. Usually, ld is
called explicitly in the Makefile, not implicitly via gcc.
>
> Questions:
>
> - Since my host system is Linux, can somebody point me to a working
> toolchain+newlib toolchain or provide any known working makefile
> with some toolchain? Or do i have to build my own toolchain as
stated here
> -> http://www.openhardware.net/Embedded_ARM/Toolchain/?
You will have to build it. You can also use the instructions at
www.gnuarm.org under Support. The [toolchain-prefix] is the location
where you intend to install the toolchain. You can use (as root)
install to /usr/local/arm/ but I install to /home/rstofer/armtools/.
I specify the location of the toolchain in my makefiles, it is not on
the path. Like:
export LOCATION=/home/rstofer/armtools/bin/
export INCLUDES=-I /home/rstofer/armtools/include/
export CC=${LOCATION}arm-elf-gcc
The lpc2148 demo referenced above has a makefile. In fact, it is
about as complex as makefiles get in that it recurses through all
subdirectories invoking other makefiles. If you start out using this
makefile set, just follow the model layout of the demo.
>
> - I saw some samples where people opens uarts using fopen(), is this a
> newlib feature? Or maybe there are some additional
> libs i can use to access peripherals "the easy way"?
Sure, right after you implement syscalls.c as shown in the demo.
There's a demo Makefile in the files section of the forum. I posted
this some time ago and forgot to delete it.
Richard
>
> Hi all:
>
> I'm starting with the LPC2368, i own a development board from Futurlec.
>
> As some people told me in this group, i've just downloaded and compiled
> lpc2isp v1.60 under Linux, and its working fine,
> i just sucessfully uploaded some example .hex files that came with
my board.
>
> Now i'm facing the toolchain dilema...
>
> I've downloaeded 2 working toolchains, one from CodeSourcery
(Sourcery G++
> Lite 2008q1-126) and another one from gnuarm.org.
> Both toolchains are able to produce a working binary from a simple
led blink
> example source.
>
> My problem comes when trying to use standard C library functions,
> sprintf,memcpy, etc.
Yup! It's up to YOU to create the code for things like sbrk (for
malloc, used by sprintf) and all of the file functions. The best
example of this in in the LPC2148 demo code from www.jcwren.com/arm
Look in the newlib folder after extraction.
newlib provides stubs for these functions but you need to write the
actual code.
You can avoid the stub functions by just creating your own simplified
IO routines and avoiding string functions. Things like puts(),
putch() can be written specific to the hardware and no library
functions are required. There is some concern about using dynamic
memory allocation on an embedded processor with limited resources.
>
> Just issuing a gcc -v on the CodeSourcery toolchain, i don't see any
> reference to newlib, but issuing a gcc -v on the gnuarm
> toolchain shows references to newlib. Anyway, i'm unable to create a
working
> Makefile when linking newlib is involved.
Some suppliers include their own library. But, get your feet on the
same side of the river. Either use GNUARM or use Codesourcery. You
can't do both.
> My makefiles just work when no standard C lib includes are involved.
>
> Just reading on the newlib docs, i found that manually calling LD isn't
> recommened as the library is built with -multi-lib you
> need to manually write all the lib paths, so you have to let gcc to
link the
> source, and here is when i'm totally stuck.
It isn't multi-lib that causes the problem. It is the number of
options to ld that makes manual linking a nightmare. Usually, ld is
called explicitly in the Makefile, not implicitly via gcc.
>
> Questions:
>
> - Since my host system is Linux, can somebody point me to a working
> toolchain+newlib toolchain or provide any known working makefile
> with some toolchain? Or do i have to build my own toolchain as
stated here
> -> http://www.openhardware.net/Embedded_ARM/Toolchain/?
You will have to build it. You can also use the instructions at
www.gnuarm.org under Support. The [toolchain-prefix] is the location
where you intend to install the toolchain. You can use (as root)
install to /usr/local/arm/ but I install to /home/rstofer/armtools/.
I specify the location of the toolchain in my makefiles, it is not on
the path. Like:
export LOCATION=/home/rstofer/armtools/bin/
export INCLUDES=-I /home/rstofer/armtools/include/
export CC=${LOCATION}arm-elf-gcc
The lpc2148 demo referenced above has a makefile. In fact, it is
about as complex as makefiles get in that it recurses through all
subdirectories invoking other makefiles. If you start out using this
makefile set, just follow the model layout of the demo.
>
> - I saw some samples where people opens uarts using fopen(), is this a
> newlib feature? Or maybe there are some additional
> libs i can use to access peripherals "the easy way"?
Sure, right after you implement syscalls.c as shown in the demo.
There's a demo Makefile in the files section of the forum. I posted
this some time ago and forgot to delete it.
Richard
Reply by ●September 18, 20082008-09-18
> >
> > 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.
> > 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.
Reply by ●September 18, 20082008-09-18
--- 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
> 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
Reply by ●September 18, 20082008-09-18
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 :)
>> >
>> > 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 :)
Reply by ●September 18, 20082008-09-18
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.
> --- 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.
Reply by ●September 18, 20082008-09-18
--- 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.
>
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
Reply by ●September 18, 20082008-09-18
--- 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
> 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
