Lpc2000

Hello all!!

Let me first say I'm pretty new at GNUARM so please be somewhat kind...

Now to my problem.  I was tring to use Robert Adsett's ibutton test
port with my WinARM installation.  Everything seems to go fine then I
get this Linking error.  I have no clue how to fix this, so if someone
could point it out or point me in the right direction it would be great.

I did not make a ibutton library I just included the .c files in my
make file.  I would like to compile the ibutton port into a librar
file but that is another problem :)


Thanks,
Oc.

Linking: test1.elf
arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN  -O0 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=test1.o  -std=gnu99 -MD -MP -MF
.dep/test1.elf.d test1.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ownet.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpcses.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\owerr.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ioutil.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpclnk.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\owtran.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\crcutil.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\rawmem.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbshaee.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbeprom.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbnv.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbappreg.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbnvcrc.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrcrc.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrex.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbsha.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscree.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscr.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee77.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrx77.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee.o
C:\WinARM\arm-elf\include\arch\philips\ibutton\common\pw77.o
build/crt0.o  --output test1.elf -nostartfiles
-Wl,-Map=test1.map,--cref -lm -lc -lnewlib-lpc -lm -Tbuild/LPC210x_ROM.ld
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(makebuf.o):
In function `__smakebuf':makebuf.c:(.text+0x110): undefined reference
to `isatty'
collect2: ld returned 1 exit status
make.exe: *** [test1.elf] Error 1

At 11:17 PM 4/5/2006 +0000, ocnek1 wrote:
>Let me first say I'm pretty new at GNUARM so please be somewhat kind...

We'll try :)

>Now to my problem.  I was tring to use Robert Adsett's ibutton test
>port with my WinARM installation.  Everything seems to go fine then I
>get this Linking error.  I have no clue how to fix this, so if someone
>could point it out or point me in the right direction it would be great.
>
>I did not make a ibutton library I just included the .c files in my
>make file.  I would like to compile the ibutton port into a librar
>file but that is another problem :)
>
>
>Thanks,
>Oc.
>
>Linking: test1.elf
>arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN  -O0 -funsigned-char
>-funsigned-bitfields -fpack-struct -fshort-enums -Wall
>-Wstrict-prototypes -Wa,-adhlns=test1.o  -std=gnu99 -MD -MP -MF
>.dep/test1.elf.d test1.o
>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ownet.o
>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpcses.o

<snip>

>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee.o
>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\pw77.o
>build/crt0.o  --output test1.elf -nostartfiles
>-Wl,-Map=test1.map,--cref -lm -lc -lnewlib-lpc -lm -Tbuild/LPC210x_ROM.ld
>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(makebuf.o):
>In function `__smakebuf':makebuf.c:(.text+0x110): undefined reference
>to `isatty'
>collect2: ld returned 1 exit status
>make.exe: *** [test1.elf] Error 1

Apparently ld can't find isatty. I suspect either a link order problem or 
possibly a lack of room.

Take a look at the map file and see how close you are to running out of 
room.  Unfortunately that library is rather large if you try to include all 
the functionality.

What is in your LPC210x_ROM.ld file?

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
http://www.aeolusdevelopment.com/

Robert Adsett wrote:

>At 11:17 PM 4/5/2006 +0000, ocnek1 wrote:
>  
>
>>Let me first say I'm pretty new at GNUARM so please be somewhat kind...
>>    
>>
>
>We'll try :)
>
>  
>
>>Now to my problem.  I was tring to use Robert Adsett's ibutton test
>>port with my WinARM installation.  Everything seems to go fine then I
>>get this Linking error.  I have no clue how to fix this, so if someone
>>could point it out or point me in the right direction it would be great.
>>
>>I did not make a ibutton library I just included the .c files in my
>>make file.  I would like to compile the ibutton port into a librar
>>file but that is another problem :)
>>
>>
>>Thanks,
>>Oc.
>>
>>Linking: test1.elf
>>arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN  -O0 -funsigned-char
>>-funsigned-bitfields -fpack-struct -fshort-enums -Wall
>>-Wstrict-prototypes -Wa,-adhlns=test1.o  -std=gnu99 -MD -MP -MF
>>.dep/test1.elf.d test1.o
>>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ownet.o
>>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpcses.o
>>    
>>
>
><snip>
>
>  
>
>>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee.o
>>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\pw77.o
>>build/crt0.o  --output test1.elf -nostartfiles
>>-Wl,-Map=test1.map,--cref -lm -lc -lnewlib-lpc -lm -Tbuild/LPC210x_ROM.ld
>>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(makebuf.o):
>>In function `__smakebuf':makebuf.c:(.text+0x110): undefined reference
>>to `isatty'
>>collect2: ld returned 1 exit status
>>make.exe: *** [test1.elf] Error 1
>>    
>>
>
>Apparently ld can't find isatty. I suspect either a link order problem or 
>possibly a lack of room.
>
>  
>
BTDT.  No, it is an extern reference from newlib, but it needs to be 
stubbed out:

============ begin isatty.c ==============
#include <unistd.h>

int isatty (int fd)
{
   return 0;
}
============= snip ==================

Just add that function in your sources (or a seperate file in your project).


TomW

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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>
> Robert Adsett wrote:
> 
> >At 11:17 PM 4/5/2006 +0000, ocnek1 wrote:
> >  
> >
> >>Let me first say I'm pretty new at GNUARM so please be somewhat
kind...
> >>    
> >>
> >
> >We'll try :)
> >
> >  
> >
> >>Now to my problem.  I was tring to use Robert Adsett's ibutton test
> >>port with my WinARM installation.  Everything seems to go fine then I
> >>get this Linking error.  I have no clue how to fix this, so if someone
> >>could point it out or point me in the right direction it would be
great.
> >>
> >>I did not make a ibutton library I just included the .c files in my
> >>make file.  I would like to compile the ibutton port into a librar
> >>file but that is another problem :)
> >>
> >>
> >>Thanks,
> >>Oc.
> >>
> >>Linking: test1.elf
> >>arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN  -O0 -funsigned-char
> >>-funsigned-bitfields -fpack-struct -fshort-enums -Wall
> >>-Wstrict-prototypes -Wa,-adhlns=test1.o  -std=gnu99 -MD -MP -MF
> >>.dep/test1.elf.d test1.o
> >>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ownet.o
> >>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpcses.o
> >>    
> >>
> >
> ><snip>
> >
> >  
> >
> >>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee.o
> >>C:\WinARM\arm-elf\include\arch\philips\ibutton\common\pw77.o
> >>build/crt0.o  --output test1.elf -nostartfiles
> >>-Wl,-Map=test1.map,--cref -lm -lc -lnewlib-lpc -lm
-Tbuild/LPC210x_ROM.ld
>
>>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(makebuf.o):
> >>In function `__smakebuf':makebuf.c:(.text+0x110): undefined reference
> >>to `isatty'
> >>collect2: ld returned 1 exit status
> >>make.exe: *** [test1.elf] Error 1
> >>    
> >>
> >
> >Apparently ld can't find isatty. I suspect either a link order
problem or 
> >possibly a lack of room.
> >
> >  
> >
> BTDT.  No, it is an extern reference from newlib, but it needs to be 
> stubbed out:
> 
> ============ begin isatty.c ==============
> #include <unistd.h>
> 
> int isatty (int fd)
> {
>    return 0;
> }
> ============= snip ==================
> 
> Just add that function in your sources (or a seperate file in your
project).
> 
> 
> TomW
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

TomW,

Thank you!  That worked.  It now compiles with no errors!!  Is this an
error with newlib?  If you can explain why this happend that would be
great.  I would like to understand why this problem happend so I will
be prepared the next time it shows up.

Thanks again,

Oc.


P.S.  Here is the size output in case anybody wanted to know:

Size after:
test1.elf  :
section             size         addr
startup               32            0
prog               96200           32
.data               2380   1073741824
.bss                 976   1073744204
.debug_abbrev       9727            0
.debug_info        57540            0
.debug_line        15507            0
.debug_frame        9936            0
.debug_loc         60936            0
.debug_pubnames    11934            0
.debug_aranges       968            0
.debug_str         13472            0
.comment            1998            0
.debug_ranges        744            0
Total             282350

ocnek1 wrote:

>
>Thank you!  That worked.  It now compiles with no errors!!  Is this an
>error with newlib?  If you can explain why this happend that would be
>great.  I would like to understand why this problem happend so I will
>be prepared the next time it shows up.
>
>  
>
Not an error.  AFAICT, needs certain functions linked into it when 
compiled as having stubs: --disable-newlib-supplied-syscalls.  By 
disabling syscalls, you will have to provide the missing functionality 
with your own code.  Probably the most common of these are the file 
stream functions: open_r.c, lseek_r.c, write_r.c, sbrk_r.c, ...

In your case, and mine, we used some library calls (functions) which 
caused newlib to see if the target stream is a TTY (console device).  I 
am not sure, but a console device may cook the data in its' driver 
code.  By telling newlib via isatty.c that it is not a console, we would 
get raw data (uncooked)?  I didn't follow the code to see why the 
isatty() call was needed.

Anyhow, you will run into more of this as you go along.  Look into the 
newlib sources at: <newlib_sources>/newlib/libc/reent/ for most of these 
needed stubs.  HINT: you will see what params will be passed to your 
functions via these "stubs".


Regards,

TomW



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

At 02:35 PM 4/6/2006 -0400, Tom Walsh wrote:
>ocnek1 wrote:
> >Thank you!  That worked.  It now compiles with no errors!!  Is this an
> >error with newlib?  If you can explain why this happend that would be
> >great.  I would like to understand why this problem happend so I will
> >be prepared the next time it shows up.
>Not an error.  AFAICT, needs certain functions linked into it when
>compiled as having stubs: --disable-newlib-supplied-syscalls.  By
>disabling syscalls, you will have to provide the missing functionality
>with your own code.  Probably the most common of these are the file
>stream functions: open_r.c, lseek_r.c, write_r.c, sbrk_r.c, ...

Definitely the most common.  I have run into the isatty error before but at 
the same time my program ran out of memory.  Solving the memory problem 
solved the isatty but apparently by accident.  I'll add that to the stub 
functions I have.

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
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, "ocnek1" <markoskyj@...> wrote:
>
> Hello all!!
> 
> Let me first say I'm pretty new at GNUARM so please be somewhat kind...
> 
> Now to my problem.  I was tring to use Robert Adsett's ibutton test
> port with my WinARM installation.  Everything seems to go fine then I
> get this Linking error.  I have no clue how to fix this, so if someone
> could point it out or point me in the right direction it would be great.
> 
> I did not make a ibutton library I just included the .c files in my
> make file.  I would like to compile the ibutton port into a librar
> file but that is another problem :)
> 
> 
> Thanks,
> Oc.
> 
> Linking: test1.elf
> arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN  -O0 -funsigned-char
> -funsigned-bitfields -fpack-struct -fshort-enums -Wall
> -Wstrict-prototypes -Wa,-adhlns=test1.o  -std=gnu99 -MD -MP -MF
> .dep/test1.elf.d test1.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ownet.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpcses.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\owerr.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\ioutil.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\lpclnk.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\owtran.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\crcutil.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\rawmem.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbshaee.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbeprom.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbnv.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbappreg.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbnvcrc.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrcrc.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrex.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbsha.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscree.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscr.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee77.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbscrx77.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\mbee.o
> C:\WinARM\arm-elf\include\arch\philips\ibutton\common\pw77.o
> build/crt0.o  --output test1.elf -nostartfiles
> -Wl,-Map=test1.map,--cref -lm -lc -lnewlib-lpc -lm
-Tbuild/LPC210x_ROM.ld
>
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(makebuf.o):
> In function `__smakebuf':makebuf.c:(.text+0x110): undefined reference
> to `isatty'
> collect2: ld returned 1 exit status
> make.exe: *** [test1.elf] Error 1
>

Thanks guys for the help!!  Now I'm having another problem and I think
it is just my new-B-ness to these tools in general.

The program now compiles fine but when it hits the first ioctl(x ,x
,x) call it goes off into la la land.  I've put some simple IO tests
(Turn LED on) and the program works fine till the function call.  By
the way, I'm using an Olimex LPC2138-MT dev board.

I did go through the newlib-lpc files and updated the header file to
support the LPC2138.  That seemed to work fine.  I even made a lil IO
blink function and added it to the newlib-lpc.a library just to see if
I was compiling the library fine.  The function works when i call it
from main() so is it naive to say that my re-compiled verion of the
library is ok?  

Thanks,
Oc.

At 12:42 AM 4/8/2006 +0000, ocnek1 wrote:
>Thanks guys for the help!!  Now I'm having another problem and I think
>it is just my new-B-ness to these tools in general.

Could be you, could also be a bug in newlib-lpc or the documentation.


>The program now compiles fine but when it hits the first ioctl(x ,x
>,x) call it goes off into la la land.  I've put some simple IO tests
>(Turn LED on) and the program works fine till the function call.  By
>the way, I'm using an Olimex LPC2138-MT dev board.

Can you give a few more details?  A snippet of sample code?

>I did go through the newlib-lpc files and updated the header file to
>support the LPC2138.  That seemed to work fine.  I even made a lil IO
>blink function and added it to the newlib-lpc.a library just to see if
>I was compiling the library fine.  The function works when i call it
>from main() so is it naive to say that my re-compiled verion of the
>library is ok?

Sounds like you should have a pretty small example to show the problem.  If 
that's the case it should be straightforward to figure out where the 
problem is.

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
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> At 12:42 AM 4/8/2006 +0000, ocnek1 wrote:
> >Thanks guys for the help!!  Now I'm having another problem and I think
> >it is just my new-B-ness to these tools in general.
> 
> Could be you, could also be a bug in newlib-lpc or the documentation.
> 
> 
> >The program now compiles fine but when it hits the first ioctl(x ,x
> >,x) call it goes off into la la land.  I've put some simple IO tests
> >(Turn LED on) and the program works fine till the function call.  By
> >the way, I'm using an Olimex LPC2138-MT dev board.
> 
> Can you give a few more details?  A snippet of sample code?
> 
> >I did go through the newlib-lpc files and updated the header file to
> >support the LPC2138.  That seemed to work fine.  I even made a lil IO
> >blink function and added it to the newlib-lpc.a library just to see if
> >I was compiling the library fine.  The function works when i call it
> >from main() so is it naive to say that my re-compiled verion of the
> >library is ok?
> 
> Sounds like you should have a pretty small example to show the
problem.  If 
> that's the case it should be straightforward to figure out where the 
> problem is.
> 
> 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
> http://www.aeolusdevelopment.com/
>


Hi Robert,

Thanks for the help.

The codes is actually your TEST1.c program from the ibutton download.
 Thats why I'm pretty sure it is my problem...  Do you still have the
makefile from when you compiled the test1.c? (there is a hex file but
no make)

From there I think I can figure out what might be happening.

Thanks again,

J.

At 06:25 PM 4/8/06 +0000, ocnek1 wrote:
>Hi Robert,
>
>Thanks for the help.
>
>The codes is actually your TEST1.c program from the ibutton download.
>  Thats why I'm pretty sure it is my problem...  Do you still have the
>makefile from when you compiled the test1.c? (there is a hex file but
>no make)

There is a makefile but I doubt it would be of much use, it's pretty 
localized to the setup I use.  If this next little bit doesn't get you 
going I'll send it along though.

I think I have an idea as to what's going on.  A question

         Are you using a recent release of newlib-lpc?

I think you are from other questions you asked.  If so GCC should be giving 
you complaints about prototype mismatches if you have been using test1.c 
without modifications.

Also what crystal speed have you been using?

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
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> At 06:25 PM 4/8/06 +0000, ocnek1 wrote:
> >Hi Robert,
> >
> >Thanks for the help.
> >
> >The codes is actually your TEST1.c program from the ibutton download.
> >  Thats why I'm pretty sure it is my problem...  Do you still have the
> >makefile from when you compiled the test1.c? (there is a hex file but
> >no make)
> 
> There is a makefile but I doubt it would be of much use, it's pretty 
> localized to the setup I use.  If this next little bit doesn't get you 
> going I'll send it along though.
> 
> I think I have an idea as to what's going on.  A question
> 
>          Are you using a recent release of newlib-lpc?
> 
> I think you are from other questions you asked.  If so GCC should be
giving 
> you complaints about prototype mismatches if you have been using
test1.c 
> without modifications.
> 
> Also what crystal speed have you been using?
> 
> 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
> http://www.aeolusdevelopment.com/
>

Yes I'm using the new (5a) newlib-lpc and I am getting the prototype
warnings.  The dev board has a 14.746Mhz crystal on it.

I must say that I am having fun with this though.  Learning about
makefiles/ linker scripts and build libraries is actually quite
interesting.

Maybe you could answer this question:  Building Libraries...When
building a library file for the ownet do I need to include the
newlib-lpc.c and .h files with all the ownet files when building the
library?  If not how do I ownet.a to link with newlib-lpc.a ?  Is this
in the linker script / make file?  

Thanks for the help Robert...sorry to be a pain asking these dumb
quesitons.

J.

At 06:46 PM 4/9/2006 +0000, ocnek1 wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >
> > At 06:25 PM 4/8/06 +0000, ocnek1 wrote:
> > >Hi Robert,
> > >
> > >Thanks for the help.
> > >
> > >The codes is actually your TEST1.c program from the ibutton download.
> > >  Thats why I'm pretty sure it is my problem...  Do you still have the
> > >makefile from when you compiled the test1.c? (there is a hex file but
> > >no make)
> >
> > There is a makefile but I doubt it would be of much use, it's pretty
> > localized to the setup I use.  If this next little bit doesn't get you
> > going I'll send it along though.
> >
> > I think I have an idea as to what's going on.  A question
> >
> >          Are you using a recent release of newlib-lpc?
> >
> > I think you are from other questions you asked.  If so GCC should be 
> giving
> > you complaints about prototype mismatches if you have been using test1.c
> > without modifications.
> >
> > Also what crystal speed have you been using?
>
>Yes I'm using the new (5a) newlib-lpc and I am getting the prototype
>warnings.  The dev board has a 14.746Mhz crystal on it.

OK, two things you will need to modify.  I can illustrate this with a 
single line from test1.c

  (void)SetNativeSpeed(_impure_ptr, 10000uL);    /*lint !e920 void cast*/

The first issue is the use of _impure_ptr.  The initial versions used it 
but it was dropped early on so all the calls that use it should be 
modified.  You can check the documentation for confirmation of the 
arguments needed.  The one wire support hasn't been touched in some time so 
it is using the older form.  It is only the test drivers that should be 
affected though.  Changing the function calls using _impure_ptr should get 
rid of your prototype mismatch complaints.  I'll add a note to the download 
to indicate that this is a problem until I get a chance to fix this.

The second item is specific to this call.  The second argument (first when 
you remove _impure_ptr) is the speed of your crystal in kHz.  It is used by 
newlib-lpc and the one-wire to determine internal timing for the baud rate 
and timing.  It is also used when setting up the cpu clock speed so you can 
get all sorts of interesting problems if that is wrong.

So the line now becomes

  (void)SetNativeSpeed(14746uL); /*lint !e920 void cast*/

>I must say that I am having fun with this though.  Learning about
>makefiles/ linker scripts and build libraries is actually quite
>interesting.

Good, it's a lot easier when it's fun.

>Maybe you could answer this question:  Building Libraries...When
>building a library file for the ownet do I need to include the
>newlib-lpc.c and .h files with all the ownet files when building the
>library?  If not how do I ownet.a to link with newlib-lpc.a ?  Is this
>in the linker script / make file?

No they can be separate.  Just be aware that since ld is by default a 
single pass linker the one wire library must precede the newlib-lpc 
library.  And yes this is set up with the link script or on the link line 
in the makefile (just list the onewire library archive at the end of the 
object files).

>Thanks for the help Robert...sorry to be a pain asking these dumb
>quesitons.

You're entirely welcome.  Generally I learn as much trying to help others 
understand something as I do first understanding it myself.

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
http://www.aeolusdevelopment.com/

Ok...everything was going ok then I got this error...hehe.  I think
I'm finding every problem that someone can encounter here.

Linking: rs232_stdio.elf
arm-elf-gcc  -mcpu=arm7tdmi  -I. -g -DROM_RUN  -O0 -Wall
-Wstrict-prototypes -Wcast-align -Wcast-qual -Wimplicit 
-Wmissing-prototypes  -Wnested-externs -Wpointer-arith -Wswitch 
-Wredundant-decls -Wreturn-type -Wshadow -Wstrict-prototypes -Wunused
-Wa,-adhlns=build/crt0.o  -std=gnu99  -MD -MP -MF
.dep/rs232_stdio.elf.d build/crt0.o    rs232_stdio.o  --output
rs232_stdio.elf -nostartfiles -Wl,-Map=rs232_stdio.map,--cref  -lc
-lgcc  -lnewlib-lpc -lm -lownet-lpc -Tbuild/LPC2106-ROM.ld
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libnewlib-lpc.a(sys_time.o):
In function `counts_to_us':sys_time.c:(.text+0x30): undefined
reference to `__udivdi3'
collect2: ld returned 1 exit status
make.exe: *** [rs232_stdio.elf] Error 1

Now this is the function count_to_us()..
static unsigned int counts_to_us( unsigned int counts)
{
 unsigned int us;

	/*  Convert the counts to microseconds taking the actual clock 	*/
	/* rate into account.  Note that as long as 			*/
	/* CLOCK_SPEED/(timing_scale_factor * COUNTS_PER_US) is less	*/
	/* than 1 this cannot overflow a long.  With nominal CLOCK_SPEED*/
	/* at 10000000 this will be true as long as the actual clock	*/
	/* speed is > 1000000.						*/
 us = (unsigned int)((counts * (unsigned long long)CLOCK_SPEED) /
(timing_scale_factor * COUNTS_PER_US));

 return us;
}

Is the problem trying to do the long long math???

J.  Stuck again :)

Now I'm also getting this erro... :( arg!

c:\winarm\bin\..\lib\gcc\arm-elf\4.1.0\..\..\..\..\arm-elf\bin\ld.exe:
ERROR: c:/winarm/bin/../lib/gcc/arm-elf/4.1.0\libgcc.a(_udivsi3.o)
uses hardware FP, whereas rs232_stdio.elf uses software FP

At 12:39 AM 4/10/2006 +0000, ocnek1 wrote:
>Ok...everything was going ok then I got this error...hehe.  I think
>I'm finding every problem that someone can encounter here.
>
>Linking: rs232_stdio.elf
>arm-elf-gcc  -mcpu=arm7tdmi  -I. -g -DROM_RUN  -O0 -Wall
>-Wstrict-prototypes -Wcast-align -Wcast-qual -Wimplicit
>-Wmissing-prototypes  -Wnested-externs -Wpointer-arith -Wswitch
>-Wredundant-decls -Wreturn-type -Wshadow -Wstrict-prototypes -Wunused
>-Wa,-adhlns=build/crt0.o  -std=gnu99  -MD -MP -MF
>.dep/rs232_stdio.elf.d build/crt0.o    rs232_stdio.o  --output
>rs232_stdio.elf -nostartfiles -Wl,-Map=rs232_stdio.map,--cref  -lc
>-lgcc  -lnewlib-lpc -lm -lownet-lpc -Tbuild/LPC2106-ROM.ld
>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libnewlib-lpc.a(sys_time.o):
>In function `counts_to_us':sys_time.c:(.text+0x30): undefined
>reference to `__udivdi3'
>collect2: ld returned 1 exit status
>make.exe: *** [rs232_stdio.elf] Error 1

<snip>

>Is the problem trying to do the long long math???

Sort of,
The problem is it can't find __udivdi3 because it has already linked in the 
library containing it before it finds out that newlib-lpc needs it.  It's a 
consequence of ld being a single pass linker.  Therefore the library 
containing the basic c primitives should be the last on the link line. -lc 
should probably be last -lm before it, -lnewlib-lpc before it and -lgcc 
before it (it's possible -lgcc will need to be both before and after 
-lnewlib-lpc) -lownet-lpc should be first in the list.

Getting the order right can sometimes be a little troublesome.

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
http://www.aeolusdevelopment.com/

At 12:48 AM 4/10/2006 +0000, ocnek1 wrote:
>Now I'm also getting this erro... :( arg!
>
>c:\winarm\bin\..\lib\gcc\arm-elf\4.1.0\..\..\..\..\arm-elf\bin\ld.exe:
>ERROR: c:/winarm/bin/../lib/gcc/arm-elf/4.1.0\libgcc.a(_udivsi3.o)
>uses hardware FP, whereas rs232_stdio.elf uses software FP

You are having a time of aren't you? :(

Others have run into this (You might see if there is something in the list 
archives) and there was a workaround mentioned but I can't help you much 
more than that on it.

The root cause is even though __udivsi3.o does not use floating point the 
object file is tagged as using HW floating point and since rs232_stdio is 
tagged as using SW floating point ....

Time for someone else to chime in to explain further and correct any miss 
explanations I've foisted upon you.

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
http://www.aeolusdevelopment.com/