Lpc2000

Hello, gentlemen,

   I am experiencing something that does not make sense to me. To 
make my debugging easier I wish to use the printf function to send 
formatted output to UARTO. 

   Fine. As far as I can see, I did everything right: I rewrote the 
putchar function so it writes to UART0, and the putchar function 
works OK. 

   However, when I use the printf function, it does not output to 
UART0 (if it outputs to something at all), and I can't understand 
why not.

   Checking the .MAP file, I see the compiler takes the putchar 
function that is in my main.o and the remaining functions that 
printf uses (such as puts, fflush, etc) it takes from libc.a .

   If I DO NOT write my putchar, I see from the .MAP file that the 
compiler takes putchar.o from libc.a -- and then I understand why it 
wouldn't send anything to the UART0. But why doesn't printf send to 
the UART0 if my putchar function tells it to?

Hoping for some enlightening from you gurus,

Fernando

--- In lpc2000@yahoogroups.com, "tiogate" <gate@t...> wrote:
> 
> Hello, gentlemen,
> 
>    I am experiencing something that does not make sense to me. To 
> make my debugging easier I wish to use the printf function to send 
> formatted output to UARTO. 
> 
>    Fine. As far as I can see, I did everything right: I rewrote the 
> putchar function so it writes to UART0, and the putchar function 
> works OK. 
> 
>    However, when I use the printf function, it does not output to 
> UART0 (if it outputs to something at all), and I can't understand 
> why not.
> 
>    Checking the .MAP file, I see the compiler takes the putchar 
> function that is in my main.o and the remaining functions that 
> printf uses (such as puts, fflush, etc) it takes from libc.a .
> 
>    If I DO NOT write my putchar, I see from the .MAP file that the 
> compiler takes putchar.o from libc.a -- and then I understand why 
it 
> wouldn't send anything to the UART0. But why doesn't printf send to 
> the UART0 if my putchar function tells it to?
> 
> Hoping for some enlightening from you gurus,
> 
> Fernando

All depends on what c library you are using, with  newlib you need to 
override _write or _write_r (reentrant version) eg.

int _write_r(void *reent, int fd, char *ptr, size_t len)
{
   // send data via uart
   UART_DataSend( UART0, ptr, len );
   return len;
}

unlike other c libs newlib does not use putchar.
Look in the newlib docs for other system overdides.

Regards
Spen

On 24 Feb 2005 at 15:19, tiogate wrote:

> 
> 
> Hello, gentlemen,
> 
>    I am experiencing something that does not make sense to me. To make
> my debugging easier I wish to use the printf function to send
> formatted output to UARTO. 
> 
>    Fine. As far as I can see, I did everything right: I rewrote the
> putchar function so it writes to UART0, and the putchar function works
> OK. 
> 
>    However, when I use the printf function, it does not output to
> UART0 (if it outputs to something at all), and I can't understand why
> not.
> 
>    Checking the .MAP file, I see the compiler takes the putchar 
> function that is in my main.o and the remaining functions that 
> printf uses (such as puts, fflush, etc) it takes from libc.a .
> 
>    If I DO NOT write my putchar, I see from the .MAP file that the
> compiler takes putchar.o from libc.a -- and then I understand why it
> wouldn't send anything to the UART0. But why doesn't printf send to
> the UART0 if my putchar function tells it to?
> 
> Hoping for some enlightening from you gurus,
> 

If you are using the gcc toolset, then you are probably  using newlib. Hence
you need to port newlib to your specific hardware. Look for "Porting Newlib" and
you should find a fair amount of info. There is such a porting library for the LPC.
You can download it at http://www.aeolusdevelopment.com/Articles/download.html.
There are some issues when using the interrupt uart routines in this package. ( The 
assembler portion is not linked in from the library) 

Regards
  Anton Erasmus-- 
A J Erasmus

--- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
>> 
> All depends on what c library you are using, with  newlib you need 
to 
> override _write or _write_r (reentrant version) eg.
> 
> Spen

I am not sure, but I think I am not using newlib. The hint is: there 
is no reent.h available. The package I installed was GCCARM331 
downloaded from Keil Evaluation 
(http://www.keil.com/demo/evaldl.asp). The Manuals mention "GNUPro 
Tools" and there is not one occurrence of the word "newlib" in them.

Does anybody know what libs are these, and which function(s) I 
should override?

Fernando

On 24 Feb 2005 at 18:52, tiogate wrote:

> 
> 
> --- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
> >> > All depends on what c library you are using, with  newlib you
> need to > override _write or _write_r (reentrant version) eg. > > Spen
> 
> I am not sure, but I think I am not using newlib. The hint is: there
> is no reent.h available. The package I installed was GCCARM331
> downloaded from Keil Evaluation (http://www.keil.com/demo/evaldl.asp).
> The Manuals mention "GNUPro Tools" and there is not one occurrence of
> the word "newlib" in them.
> 
> Does anybody know what libs are these, and which function(s) I 
> should override?
> 
The best is probably to ask Keil. The want you to later buy their full
version, so it is in their interest to help you. If they do not help you
switch to the tools on http://www.gnuarm.com which uses newlib.

Regards
  Anton Erasmus
-- 
A J Erasmus

At 07:03 PM 2/24/05 +0200, Anton Erasmus wrote:
>If you are using the gcc toolset, then you are probably  using newlib. Hence
>you need to port newlib to your specific hardware. Look for "Porting 
>Newlib" and
>you should find a fair amount of info. There is such a porting library for 
>the LPC.
>You can download it at 
>http://www.aeolusdevelopment.com/Articles/download.html.
>There are some issues when using the interrupt uart routines in this 
>package. ( The
>assembler portion is not linked in from the library)

Anton, I'd appreciate it if you could give me some more information on 
this.  Maybe send me a map file of a program illustrating the issue with it 
no linked in.  I'm working on the next release and I'd like to try and 
duplicate and fix this if I can.  There are a couple of contact links on 
the website and they should get through to me.  You can just send a quick 
note and we can exchange address's for more in depth conversation if you wish.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In lpc2000@yahoogroups.com, "tiogate" <gate@t...> wrote:
> 
> --- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
> >> 
> > All depends on what c library you are using, with  newlib you 
need 
> to 
> > override _write or _write_r (reentrant version) eg.
> > 
> > Spen
> 
> I am not sure, but I think I am not using newlib. The hint is: 
there 
> is no reent.h available. The package I installed was GCCARM331 
> downloaded from Keil Evaluation 
> (http://www.keil.com/demo/evaldl.asp). The Manuals mention "GNUPro 
> Tools" and there is not one occurrence of the word "newlib" in them.
> 
> Does anybody know what libs are these, and which function(s) I 
> should override?
> 
> Fernando

Keil gcc uses uclibc, the version you require is:

int write (int file, char * ptr, int len)
{
    return len;
}
All the system functions are just non reentrant versions.

Be careful of uisng uclibc as a clib, even though it is a better lib 
for smaller devices it comes under lgpl rather than gpl. This is only 
really a problem if you are statically linking with the libs.

Regards
Spen

Yes, you are right. I've overridden write() and now printf outputs 
to UART0. Thank you.

Fernando


--- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
> 
> Keil gcc uses uclibc, the version you require is:
> 
> int write (int file, char * ptr, int len)
> {
>     return len;
> }
> All the system functions are just non reentrant versions.
> 
> Be careful of uisng uclibc as a clib, even though it is a better 
lib 
> for smaller devices it comes under lgpl rather than gpl. This is 
only 

> really a problem if you are statically linking with the libs.
> 
> Regards
> Spen

On 24 Feb 2005 at 17:46, Robert Adsett wrote:

> 
> At 07:03 PM 2/24/05 +0200, Anton Erasmus wrote:
> >If you are using the gcc toolset, then you are probably  using
> >newlib. Hence you need to port newlib to your specific hardware. Look
> >for "Porting Newlib" and you should find a fair amount of info. There
> >is such a porting library for the LPC. You can download it at
> >http://www.aeolusdevelopment.com/Articles/download.html. There are
> >some issues when using the interrupt uart routines in this package. (
> >The assembler portion is not linked in from the library)
> 
> Anton, I'd appreciate it if you could give me some more information on
> this.  Maybe send me a map file of a program illustrating the issue
> with it no linked in.  I'm working on the next release and I'd like to
> try and duplicate and fix this if I can.  There are a couple of
> contact links on the website and they should get through to me.  You
> can just send a quick note and we can exchange address's for more in
> depth conversation if you wish.

Murphy strikes again :-(  - I tried the same thing on my home machine as I did
at work, and of course now I do not get the same thing. I have an older version
of cygwin installed at work, but otherwise everything is the same. I have only compiled
the examples at home - direct link as well as linking with the library. I haven't tried 
executing the examples. Example  test10 executes correctly when linking directly with
the library object files, but when linked agains the library (No errors reported), the 
example does not execute correctly. (No serial output). I will try the hex files I compiled 
at home  on monday to see if both version work.

Regards
  Anton Erasmus
-- 
A J Erasmus

At 07:37 PM 2/25/05 +0200, Anton Erasmus wrote:
>Murphy strikes again :-(  - I tried the same thing on my home machine as I did
>at work, and of course now I do not get the same thing. I have an older 
>version
>of cygwin installed at work, but otherwise everything is the same. I have 
>only compiled
>the examples at home - direct link as well as linking with the library. I 
>haven't tried
>executing the examples. Example  test10 executes correctly when linking 
>directly with
>the library object files, but when linked agains the library (No errors 
>reported), the
>example does not execute correctly. (No serial output). I will try the hex 
>files I compiled
>at home  on monday to see if both version work.


I appreciate the effort Anton.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

On 26 Feb 2005 at 23:58, Robert Adsett wrote:

> 
> At 07:37 PM 2/25/05 +0200, Anton Erasmus wrote:
> >Murphy strikes again :-(  - I tried the same thing on my home machine
> >as I did at work, and of course now I do not get the same thing. I
> >have an older version of cygwin installed at work, but otherwise
> >everything is the same. I have only compiled the examples at home -
> >direct link as well as linking with the library. I haven't tried
> >executing the examples. Example  test10 executes correctly when
> >linking directly with the library object files, but when linked
> >agains the library (No errors reported), the example does not execute
> >correctly. (No serial output). I will try the hex files I compiled at
> >home  on monday to see if both version work.
> 
> 
> I appreciate the effort Anton.

I have tested the two versions of the test10 example on my board. The
version directly linked with the object files runs correctly while the version
linked with the generated library does not. Using the -t option on the linker, it
does not appear to be a problem with not linking in all the code. I currently do
not have a JTAG debugger, so it is a bit difficult to see why the version linked
with the library does not work. 
I can e-mail the hex files plus anything else you thing might help if you are interested.

Regards
   Anton Erasmus

-- 
A J Erasmus

At 10:50 PM 2/28/05 +0200, Anton Erasmus wrote:
>On 26 Feb 2005 at 23:58, Robert Adsett wrote:
> > At 07:37 PM 2/25/05 +0200, Anton Erasmus wrote:
> > >Murphy strikes again :-(  - I tried the same thing on my home machine
> > >as I did at work, and of course now I do not get the same thing. I
> > >have an older version of cygwin installed at work, but otherwise
> > >everything is the same. I have only compiled the examples at home -
> > >direct link as well as linking with the library. I haven't tried
> > >executing the examples. Example  test10 executes correctly when
> > >linking directly with the library object files, but when linked
> > >agains the library (No errors reported), the example does not execute
> > >correctly. (No serial output). I will try the hex files I compiled at
> > >home  on monday to see if both version work.
> > I appreciate the effort Anton.
>
>I have tested the two versions of the test10 example on my board. The
>version directly linked with the object files runs correctly while the version
>linked with the generated library does not. Using the -t option on the 
>linker, it
>does not appear to be a problem with not linking in all the code. I 
>currently do
>not have a JTAG debugger, so it is a bit difficult to see why the version 
>linked
>with the library does not work.
>I can e-mail the hex files plus anything else you thing might help if you 
>are interested.

I'd appreciate it if you could send the hex files and corresponding map 
files (-M or --print-map).

Use the information-request link on 
http://www.aeolusdevelopment.com/Articles/Contacts.html to get it to me or 
fill in the form  on the same page and I'll send you back an address (the 
first uses some javascript to reduce the likelihood of harvesting)

Thanks Anton,

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III