At 10:14 PM 1/22/2007 +0200, Anton Erasmus wrote: >On 21 Jan 2007 at 19:51, Robert Adsett wrote:
>
> > At 12:15 AM 1/22/2007 +0100, Eric Pasquier wrote:
> > >Robert,
> > >
> > >I took a look at the link and at Bill Galiff's page.
> > >I checked the newlib for LPC and discovered the existence of a syscall.c
> > >file in WinARM.
> > >I made some changes (no uart yet) and .... it works !
> > >
> > >But I still don't understand why this was working for WinAVR
without
> > >"external" stubs ....
> >
> > Two possibilities
> > - It doesn't use newlib but some other library. Actually I
> > suspect it uses something of it's own but I've never used it so I
don't
> know.
>
>WinAVR uses avr-libc, a library specifically developed for the avr port of
>gcc. IMO it would actually make a very nice library for all the small ARM
MCUs
>if it was ported for the ARM. A fair amount of the code is in assembler
>though,
>so it would be a non-trivial exercise.
I figured it was something like that.
> > - It uses newlib but includes stubs
appropriate to the AVR
> >
> > Newlib is often compiled as a single library with stubs included. The
> > reason for leaving the stubs out would be to allow linking in stubs
> > appropriate to the particular micro being used. With the number of
> variant
> > families available for ARM micros that's more likely to be useful for
ARM
> > than AVR.
>
>The number of variants on the AVRs are also quite large and getting larger
>by the day.
Sure. But I don't think Atmel has shown the, um, enthusiasm the various
ARM licensees have in differentiating the basics. The four architectures
I've looked at somewhat closely (NXP, Atmel, AD and ST) use five different
interrupt architectures and I suspect if I looked closely at TI and Sharp
I'd find two more. And of course they all use different peripherals (not
just different mixes but different devices for the same job).
The stubs that don't have need to perform I/O are pretty portable (_sbrk as
an example) and the ones in newlib-lpc should work pretty well but when you
touch the I/O you need new drivers. The basic structure would still work
though. If anyone wants to adapt that structure they are free to (and I'd
be happy to add any drivers etc.. to the library ;) )
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by Anton Erasmus●January 22, 20072007-01-22
On 21 Jan 2007 at 19:51, Robert Adsett wrote:
> At 12:15 AM 1/22/2007 +0100, Eric Pasquier wrote:
> >Robert,
> >
> >I took a look at the link and at Bill Galiff's page.
> >I checked the newlib for LPC and discovered the existence of a syscall.c
> >file in WinARM.
> >I made some changes (no uart yet) and .... it works !
> >
> >But I still don't understand why this was working for WinAVR without
> >"external" stubs ....
>
> Two possibilities
> - It doesn't use newlib but some other library. Actually I
> suspect it uses something of it's own but I've never used it so I
don't know.
WinAVR uses avr-libc, a library specifically developed for the avr port of
gcc. IMO it would actually make a very nice library for all the small ARM
MCUs
if it was ported for the ARM. A fair amount of the code is in assembler
though,
so it would be a non-trivial exercise.
> - It uses newlib but includes stubs
appropriate to the AVR
>
> Newlib is often compiled as a single library with stubs included. The
> reason for leaving the stubs out would be to allow linking in stubs
> appropriate to the particular micro being used. With the number of variant
> families available for ARM micros that's more likely to be useful for ARM
> than AVR.
The number of variants on the AVRs are also quite large and getting larger by
the day.
Regards
Anton Erasmus
--
A J Erasmus
Reply by Robert Adsett●January 21, 20072007-01-21
At 12:15 AM 1/22/2007 +0100, Eric Pasquier wrote: >Robert,
>
>I took a look at the link and at Bill Galiff's page.
>I checked the newlib for LPC and discovered the existence of a syscall.c
>file in WinARM.
>I made some changes (no uart yet) and .... it works !
>
>But I still don't understand why this was working for WinAVR without
>"external" stubs ....
Two possibilities
- It doesn't use newlib but some other library. Actually I
suspect it uses something of it's own but I've never used it so I
don't know.
- It uses newlib but includes stubs appropriate to the AVR
Newlib is often compiled as a single library with stubs included. The
reason for leaving the stubs out would be to allow linking in stubs
appropriate to the particular micro being used. With the number of variant
families available for ARM micros that's more likely to be useful for ARM
than AVR.
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by Eric Pasquier●January 21, 20072007-01-21
Robert,
I took a look at the link and at Bill Galiff's page.
I checked the newlib for LPC and discovered the existence of a syscall.c
file in WinARM.
I made some changes (no uart yet) and .... it works !
But I still don't understand why this was working for WinAVR without
"external" stubs ....
Thanks for your help,
Eric.
-----Mensagem original-----
De: A... [mailto:A...] Em nome de
Robert Adsett
Enviada em: dimanche 21 janvier 2007 16:49
Para: A...
Assunto: Re: [AT91SAM] sprintf with gcc arm-elf
At 02:10 PM 1/21/2007 +0000, eric_pasquier wrote: >I am porting an AVR ATMega32 application to
AT91SAM7S256, using WinARM
>(but the problem is the same with YAGARTO).
>
>When I try to use the sprintf function, I get lots of unresolved
>references (see below).
>In fact, this function is working well in WinAVR (gcc 3.4.6) and is
>using the following functions :
>Does anybody know why this function in libc.a (or
libg.a) is
>implemented differently ? Am I missing a compiler/linker option ?
Different origins, different implementation strategies. There are many
different ways to implement the standard libraries.
>c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(f reer.o): >In function `_malloc_trim_r':
>mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
The winarm implementation uses newlib and leaves the stubs unresolved
IIRC. For the LPC it uses newlib-lpc to provide the needed stubs. The
stubs are quite simple and I expect the newlib-lpc stubs (other than
peripheral I/O and LPC specific timing and setup functions) would work. It
would be worth taking a look at them as an implementation example, they'd
be easy to adapt if necessary.
velopment.com/Articles/download.html Also take a look
at the resources page for a link to Bill Gatliff's page. He has a good
introduction to the stubs.
>From the Divided by a Common Language File (Edited to
protect the guilty) ME - "I'd like to get Price and delivery for connector Part #
XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by Robert Adsett●January 21, 20072007-01-21
At 02:10 PM 1/21/2007 +0000, eric_pasquier wrote: >I am porting an AVR ATMega32 application to
AT91SAM7S256, using WinARM
>(but the problem is the same with YAGARTO).
>
>When I try to use the sprintf function, I get lots of unresolved
>references (see below).
>In fact, this function is working well in WinAVR (gcc 3.4.6) and is
>using the following functions :
>Does anybody know why this function in libc.a (or
libg.a) is
>implemented differently ? Am I missing a compiler/linker option ?
Different origins, different implementation strategies. There are many
different ways to implement the standard libraries. >c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(freer.o):
>In function `_malloc_trim_r':
>mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
The winarm implementation uses newlib and leaves the stubs unresolved
IIRC. For the LPC it uses newlib-lpc to provide the needed stubs. The
stubs are quite simple and I expect the newlib-lpc stubs (other than
peripheral I/O and LPC specific timing and setup functions) would work. It
would be worth taking a look at them as an implementation example, they'd
be easy to adapt if necessary.
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by eric_pasquier●January 21, 20072007-01-21
I am porting an AVR ATMega32 application to AT91SAM7S256, using WinARM
(but the problem is the same with YAGARTO).
When I try to use the sprintf function, I get lots of unresolved
references (see below).
In fact, this function is working well in WinAVR (gcc 3.4.6) and is
using the following functions :
Does anybody know why this function in libc.a (or libg.a) is
implemented differently ? Am I missing a compiler/linker option ?
Thks,
Eric.
List of unresolved references :
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(freer.o):
In function `_malloc_trim_r':
mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(makebuf.o):
In function `__smakebuf':
makebuf.c:(.text+0x3c): undefined reference to `_fstat_r'
makebuf.c:(.text+0x110): undefined reference to `isatty'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(mallocr.o):
In function `_malloc_r':
mallocr.c:(.text+0x424): undefined reference to `_sbrk_r'
mallocr.c:(.text+0x4cc): undefined reference to `_sbrk_r'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(stdio.o):
In function `__sclose':
stdio.c:(.text+0xc): undefined reference to `_close_r'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(stdio.o):
In function `__sseek':
stdio.c:(.text+0x30): undefined reference to `_lseek_r'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(stdio.o):
In function `__swrite':
stdio.c:(.text+0x84): undefined reference to `_lseek_r'
stdio.c:(.text+0xac): undefined reference to `_write_r'
c:/arm/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(stdio.o):
In function `__sread':
stdio.c:(.text+0xd0): undefined reference to `_read_r'