Lpc2000

miruffer wrote:

>Hi,
>
>thank you for your answer. I look at your scripts and have seen that
>you use the flag --disable-newlib-supplied-syscalls. I have rebuilt my
>GNU Toolchain. 
>When the linker links my project, there are the errors shown below.
>
>  
>

Absolutely correct.  You've done it the right way.  Now, if you want to 
know what can be done with those missing routines, also get a copy of 
the RDCF2 filesystem source (also from my site).  *You* provide those 
functions: write_r, open_r, etc..


>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(writer.o):
>In function `_write_r':
>../../../../../newlib-1.13.0/newlib/libc/reent/writer.c:58: undefined
>reference to `_write'
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(closer.o):
>In function `_close_r':
>../../../../../newlib-1.13.0/newlib/libc/reent/closer.c:53: undefined
>reference to `_close'
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(fstatr.o):
>In function `_fstat_r':
>../../../../../newlib-1.13.0/newlib/libc/reent/fstatr.c:62: undefined
>reference to `_fstat'
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(lseekr.o):
>In function `_lseek_r':
>../../../../../newlib-1.13.0/newlib/libc/reent/lseekr.c:58: undefined
>reference to `_lseek'
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(readr.o):
>In function `_read_r':
>../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined
>reference to `_read'
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libstdc++.a(eh_personality.o):
>
>
>
>All the functions he can't find, are exsisting in my own libary the
>linker had opend before. I can't understand that.
>
>
>  
>
When you compile newlib, without the stubs, it assumes that it will be 
dealing with an operating system which would provide a call entry 
structure to perform device I/O.   Since you are not using an operating 
system, such as Linux, you have to provide that last bit of code to 
bridge between the library (abstraction) and your hardware (reality).

The newlib, nor any library, is intended to provide a "final solution".  
They cannot, hardware varies from environ to environ.  It is up to you, 
ultimately, to see that the "operating system" provide a means to move 
the data stream coming out of the library over to the hardware.  With 
something like Linux, we do this be means of the various hardware driver 
code and the SysCalls.  When you don't have an operating system, the 
same requirement still exists to physically connect the data stream from 
the library to the hardware.

This is what the RDCF2 code is about.  It illustrates how to do device 
(hardware) interfacing to newlib, so that you can use filestreams such 
as: fopen(), fread(), fwrite(), fgetc(), etc..  I only provided code to 
interface to an SD drive.  The application that I'm building does not 
require, nor tolerate, file streams to the serial port(s).  Having said 
that, you can add a device "UARTx" to the device table, then add another 
file identical in structure to that of 'mmc_module.c'.  Take a look at 
that file, at the bottom is the DEVICE_TABLE_ENTRY struct which provides 
the entry points to get work done.  This is the "final link" between 
newlib and the hardware.  The write_r, read_r, open_r code I provide is 
the mechanism to handle multiple data streams and to direct those 
streams to the various hardware.

I had taken a general purpose approach to implementing the stub code.  
There are two key elements of the interfacing process: adding a new 
device to the DeviceTable array, adding a new module which contains the 
implementation of the device entry.  The code in between, all those 
ending in "*_r.c" do not need to be altered.

1. devices.c contains the device table.
2. sysdefs.h contains the device IDs.
3. mmc_module.c illustrates the implementation of the device.

You simply add your new module code and make an entry into the device table.

I see that this may be confusing to a first time user of libraries on 
embedded systems.  All embedded system libraries function in essentially 
the same manner.  Ultimately, there has to be "bridging code" written by 
the end-user to provide a link between the hardware and the library.

While you could get deep inside the guts of newlib and hack your way 
into getting the write() function to give you an output you desire, I 
would advise against it.


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------