2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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



>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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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
>>
>>
>
>>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

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..."
----------------------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Tom Walsh 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
> >>
> >>
> >
> >
> >
> >
> >
> >>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 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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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/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..."
----------------------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "ocnek1" 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.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Robert Adsett 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.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Robert Adsett 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.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 06:46 PM 4/9/2006 +0000, ocnek1 wrote:
>--- In l...@yahoogroups.com, Robert Adsett 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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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 :)



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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



>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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )