Hi,
I am fighting with gcc (version 2008q1 from Codesourcery), the startup
code from boot.s, the linker file for LPC2148, FreeRTOS v5.03 and the
probably excellent lpc2148 demo (v1.20) from jcwren. 'Probably'
because
I cannot compile/link it. And that's what I try to fix.
The good news: the ARM7_LPC2106_GCC demo compiles just fine. I don't
know if it runs (likely after modification of flash/ram address and
size) though.
Trying to compile the (by far much more complex) lpc2148 demo yields:
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/sysdefs.h:39:8:
warning: missing terminating " character
I assume older gcc was not so picky about that one. Easy to fix.
After removing all the modules which cause gcc to throw up an internal
error like this:
uartISR.c: In function 'uartISR1':
uartISR.c:166: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6613
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[1]: *** [uartISR.o] Error 1
the linker lets me know that:
/opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/bin/ld:
error: no memory region specified for loadable section `.ARM.exidx'
collect2: ld returned 1 exit status
make[1]: *** [lpc2148.elf] Error 1
make: *** [all] Error 2
Not knowing what that means and where this comes from (I assume from
gcc, but ARM7_LPC2106_GCC works without defining this stuff), when I
look at /opt/codesourcery/arm-none-eabi/lib/generic.ld and extract the
missing section
/* .ARM.exidx is sorted, so has to go in its own output section. */
__exidx_start = .;
.ARM.exidx :
{
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} >ram
and put it into the lpc2148-rom.ld to get that section into the linker
file, then all hell breaks loose when trying to link:
main.o: In function `main':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
reference to `vSensorsTask'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
reference to `vGPSTask'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
reference to `vMonitorTask'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
In function `rtcInit':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:161:
undefined reference to `rtcISRInit'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
In function `rtcSleep':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:19:
undefined reference to `rtcISR'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(uart.o):
In function `uartInit':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:66:
undefined reference to `uartISRCreateQueues'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:129:
undefined reference to `uartISRCreateQueues'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
undefined reference to `uartISR1'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
undefined reference to `uartISR0'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
In function `f_sync':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1117:
undefined reference to `get_fattime'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
In function `f_mkdir':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1510:
undefined reference to `get_fattime'
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
In function `f_open':
/home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:894:
undefined reference to `get_fattime'
/opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o):
In function `_isatty_r':
isattyr.c:(.text+0x18): undefined reference to `_isatty'
collect2: ld returned 1 exit status
make[1]: *** [lpc2148.elf] Error 1
I have to admit that I am not really knowing what I am doing here. The
linker file with 3 sections (text/data/bss) looks reasonable to me, but
exidx is new to me.
The question I have now is:
What is the cause for the linking problems? gcc-4.2.3? arm-none-eabi
instead of arm-elf? newlib? boot.s?
Harald
gcc, boot.s, lpc2148-ram.ld and lpc2148 demo
Started by ●September 10, 2008
Reply by ●September 10, 20082008-09-10
Harald,
Unfortunately, I can't provide a lot of help here. I develop under a Linux
environment. I am, however, using GCC 4.2.4 with no problems, other than
the issue of fixing the missing quote in the header file.
I' loaded CodeSourcery at some point to play with a Luminary Micros part,
and quite frankly, I can't stand it. I much prefer a command line (even
under Cygwin) and my favorite editor.
That being said, there are several people who have reported compiling the
demo software with success under Windows using WinArm. You might take a
seach through the old posts here, I believe they may have posted the
results.
If you can get CodeSourcery out of the equation, I may be able to provide
you with addition help.
--jc
On Wed, Sep 10, 2008 at 7:30 AM, Harald Kubota wrote:
> Hi,
>
> I am fighting with gcc (version 2008q1 from Codesourcery), the startup
> code from boot.s, the linker file for LPC2148, FreeRTOS v5.03 and the
> probably excellent lpc2148 demo (v1.20) from jcwren. 'Probably' because
> I cannot compile/link it. And that's what I try to fix.
>
> The good news: the ARM7_LPC2106_GCC demo compiles just fine. I don't
> know if it runs (likely after modification of flash/ram address and
> size) though.
>
> Trying to compile the (by far much more complex) lpc2148 demo yields:
>
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/sysdefs.h:39:8:
> warning: missing terminating " character
> I assume older gcc was not so picky about that one. Easy to fix.
>
> After removing all the modules which cause gcc to throw up an internal
> error like this:
>
> uartISR.c: In function 'uartISR1':
> uartISR.c:166: internal compiler error: in expand_expr_addr_expr_1, at
> expr.c:6613
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> make[1]: *** [uartISR.o] Error 1
>
> the linker lets me know that:
>
> /opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/bin/ld:
>
> error: no memory region specified for loadable section `.ARM.exidx'
> collect2: ld returned 1 exit status
> make[1]: *** [lpc2148.elf] Error 1
> make: *** [all] Error 2
>
> Not knowing what that means and where this comes from (I assume from
> gcc, but ARM7_LPC2106_GCC works without defining this stuff), when I
> look at /opt/codesourcery/arm-none-eabi/lib/generic.ld and extract the
> missing section
>
> /* .ARM.exidx is sorted, so has to go in its own output section. */
> __exidx_start = .;
> .ARM.exidx :
> {
> *(.ARM.exidx* .gnu.linkonce.armexidx.*)
> } >ram
>
> and put it into the lpc2148-rom.ld to get that section into the linker
> file, then all hell breaks loose when trying to link:
>
> main.o: In function `main':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vSensorsTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vGPSTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vMonitorTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
>
> In function `rtcInit':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:161:
> undefined reference to `rtcISRInit'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
>
> In function `rtcSleep':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:19:
> undefined reference to `rtcISR'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(uart.o):
>
> In function `uartInit':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:66:
> undefined reference to `uartISRCreateQueues'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:129:
> undefined reference to `uartISRCreateQueues'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
> undefined reference to `uartISR1'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
> undefined reference to `uartISR0'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_sync':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1117:
> undefined reference to `get_fattime'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_mkdir':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1510:
> undefined reference to `get_fattime'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_open':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:894:
> undefined reference to `get_fattime'
> /opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o):
>
> In function `_isatty_r':
> isattyr.c:(.text+0x18): undefined reference to `_isatty'
> collect2: ld returned 1 exit status
> make[1]: *** [lpc2148.elf] Error 1
>
> I have to admit that I am not really knowing what I am doing here. The
> linker file with 3 sections (text/data/bss) looks reasonable to me, but
> exidx is new to me.
>
> The question I have now is:
> What is the cause for the linking problems? gcc-4.2.3? arm-none-eabi
> instead of arm-elf? newlib? boot.s?
>
> Harald
>
>
>
Unfortunately, I can't provide a lot of help here. I develop under a Linux
environment. I am, however, using GCC 4.2.4 with no problems, other than
the issue of fixing the missing quote in the header file.
I' loaded CodeSourcery at some point to play with a Luminary Micros part,
and quite frankly, I can't stand it. I much prefer a command line (even
under Cygwin) and my favorite editor.
That being said, there are several people who have reported compiling the
demo software with success under Windows using WinArm. You might take a
seach through the old posts here, I believe they may have posted the
results.
If you can get CodeSourcery out of the equation, I may be able to provide
you with addition help.
--jc
On Wed, Sep 10, 2008 at 7:30 AM, Harald Kubota wrote:
> Hi,
>
> I am fighting with gcc (version 2008q1 from Codesourcery), the startup
> code from boot.s, the linker file for LPC2148, FreeRTOS v5.03 and the
> probably excellent lpc2148 demo (v1.20) from jcwren. 'Probably' because
> I cannot compile/link it. And that's what I try to fix.
>
> The good news: the ARM7_LPC2106_GCC demo compiles just fine. I don't
> know if it runs (likely after modification of flash/ram address and
> size) though.
>
> Trying to compile the (by far much more complex) lpc2148 demo yields:
>
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/sysdefs.h:39:8:
> warning: missing terminating " character
> I assume older gcc was not so picky about that one. Easy to fix.
>
> After removing all the modules which cause gcc to throw up an internal
> error like this:
>
> uartISR.c: In function 'uartISR1':
> uartISR.c:166: internal compiler error: in expand_expr_addr_expr_1, at
> expr.c:6613
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> make[1]: *** [uartISR.o] Error 1
>
> the linker lets me know that:
>
> /opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/bin/ld:
>
> error: no memory region specified for loadable section `.ARM.exidx'
> collect2: ld returned 1 exit status
> make[1]: *** [lpc2148.elf] Error 1
> make: *** [all] Error 2
>
> Not knowing what that means and where this comes from (I assume from
> gcc, but ARM7_LPC2106_GCC works without defining this stuff), when I
> look at /opt/codesourcery/arm-none-eabi/lib/generic.ld and extract the
> missing section
>
> /* .ARM.exidx is sorted, so has to go in its own output section. */
> __exidx_start = .;
> .ARM.exidx :
> {
> *(.ARM.exidx* .gnu.linkonce.armexidx.*)
> } >ram
>
> and put it into the lpc2148-rom.ld to get that section into the linker
> file, then all hell breaks loose when trying to link:
>
> main.o: In function `main':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vSensorsTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vGPSTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/main.c:87: undefined
> reference to `vMonitorTask'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
>
> In function `rtcInit':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:161:
> undefined reference to `rtcISRInit'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(rtc.o):
>
> In function `rtcSleep':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/rtc/rtc.c:19:
> undefined reference to `rtcISR'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(uart.o):
>
> In function `uartInit':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:66:
> undefined reference to `uartISRCreateQueues'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:129:
> undefined reference to `uartISRCreateQueues'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
> undefined reference to `uartISR1'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/uart/uart.c:120:
> undefined reference to `uartISR0'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_sync':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1117:
> undefined reference to `get_fattime'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_mkdir':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:1510:
> undefined reference to `get_fattime'
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/common/common.a(ff.o):
> In function `f_open':
> /home/harald/uController/FreeRTOS/Demo/LPC2148_Demo/fatfs/ff.c:894:
> undefined reference to `get_fattime'
> /opt/codesourcery/lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o):
>
> In function `_isatty_r':
> isattyr.c:(.text+0x18): undefined reference to `_isatty'
> collect2: ld returned 1 exit status
> make[1]: *** [lpc2148.elf] Error 1
>
> I have to admit that I am not really knowing what I am doing here. The
> linker file with 3 sections (text/data/bss) looks reasonable to me, but
> exidx is new to me.
>
> The question I have now is:
> What is the cause for the linking problems? gcc-4.2.3? arm-none-eabi
> instead of arm-elf? newlib? boot.s?
>
> Harald
>
>
>
Reply by ●September 11, 20082008-09-11
Hi,
I forgot to mention: I use the CodeSourcery's Lite package which is the
standard gcc cross compilers.
I tried Rowley's crossworks IDE and Eclipse. Maybe I am too old, but I
cnanot get used to those.
For now, I'll cross compile gcc myself and see whether that fixes the
link problems.
Harald
I forgot to mention: I use the CodeSourcery's Lite package which is the
standard gcc cross compilers.
I tried Rowley's crossworks IDE and Eclipse. Maybe I am too old, but I
cnanot get used to those.
For now, I'll cross compile gcc myself and see whether that fixes the
link problems.
Harald
Reply by ●September 11, 20082008-09-11
Hi,
J.C. Wren wrote:
> If you can get CodeSourcery out of the equation, I may be able to
> provide you with addition help.
Compiling my own cross compile suite from scratch was not that difficult.
And once I figured out that when configuring newlib I need to
"--disable-newlib-supplied-syscalls", the rest was straightforward. Please
put this comment on building newlib into the next version of the demo
files to save
some people from pulling out their hairs...
When linking I got this one:
/opt/cross/lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libg.a(lib_a-isattyr.o):
In function `_isatty_r':
../../../../../newlib/src/newlib/libc/reent/isattyr.c:58: undefined
reference to `_isatty'
collect2: ld returned 1 exit status
Checking syscalls.c in newlib/ in the LPC2148 Demo files show lots of
definitions starting with an
underscore. Except isatty which is missing the underscore.
Was that on purpose? 'Cause I 'fixed' that and now I can compile the
example code and link it.
I still don't know if the code works or not. but I'll try that once I'm
back from camping.
Thanks,
Harald
J.C. Wren wrote:
> If you can get CodeSourcery out of the equation, I may be able to
> provide you with addition help.
Compiling my own cross compile suite from scratch was not that difficult.
And once I figured out that when configuring newlib I need to
"--disable-newlib-supplied-syscalls", the rest was straightforward. Please
put this comment on building newlib into the next version of the demo
files to save
some people from pulling out their hairs...
When linking I got this one:
/opt/cross/lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libg.a(lib_a-isattyr.o):
In function `_isatty_r':
../../../../../newlib/src/newlib/libc/reent/isattyr.c:58: undefined
reference to `_isatty'
collect2: ld returned 1 exit status
Checking syscalls.c in newlib/ in the LPC2148 Demo files show lots of
definitions starting with an
underscore. Except isatty which is missing the underscore.
Was that on purpose? 'Cause I 'fixed' that and now I can compile the
example code and link it.
I still don't know if the code works or not. but I'll try that once I'm
back from camping.
Thanks,
Harald
Reply by ●September 11, 20082008-09-11
I didn't have to use --disable-newlib-supplied-syscalls on my install.
When
I originally wrote this stuff, I think I grabbed the syscalls.c from the
newlib source tree, and carved it up to work with fatfs and what not. If
you'll notice in that, it's 'isatty' and not 'isatty'. Changing it to
'_isatty' in my syscalls.c results in it trying to link against the newlib
provided version, which causes many warnings about duplicating defined
functions. Basically, as long as the syscalls.c in the demo package
satisifies all the linking needs of the code and libraries, it won't ever
try to look in the newlib libraries for it.
In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
function (the reentrant version). Did you pull yours out of CVS? I found a
reference at http://sourceware.org/ml/newlib-cvs/2008-q1/msg00001.html to it
being added, but that's not mainstream yet, as far as I know. The date on
the .tar.gz file is 2007-12-19, which predates the addition of isatty_r.
The naming of 'isatty' is deliberate. It's the same name they used in the
syscalls.c that shipped in the 1.16.0 files. I noticed that also, and was
curious about it. I see in the CVS branch that it was renamed between
version 1.14, 2007/07/06 16:56:30 and version 1.15, 2008/01/03 22:33:37.
--jc
On Thu, Sep 11, 2008 at 12:00 PM, Harald Kubota wrote:
> Hi,
> J.C. Wren wrote:
>
> > If you can get CodeSourcery out of the equation, I may be able to
> > provide you with addition help.
>
> Compiling my own cross compile suite from scratch was not that difficult.
> And once I figured out that when configuring newlib I need to
> "--disable-newlib-supplied-syscalls", the rest was straightforward. Please
> put this comment on building newlib into the next version of the demo
> files to save
> some people from pulling out their hairs...
>
> When linking I got this one:
>
> /opt/cross/lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libg.a(lib_a-isattyr.o):
>
> In function `_isatty_r':
> ../../../../../newlib/src/newlib/libc/reent/isattyr.c:58: undefined
> reference to `_isatty'
> collect2: ld returned 1 exit status
>
> Checking syscalls.c in newlib/ in the LPC2148 Demo files show lots of
> definitions starting with an
> underscore. Except isatty which is missing the underscore.
>
> Was that on purpose? 'Cause I 'fixed' that and now I can compile the
> example code and link it.
>
> I still don't know if the code works or not. but I'll try that once I'm
> back from camping.
>
> Thanks,
> Harald
>
>
>
I originally wrote this stuff, I think I grabbed the syscalls.c from the
newlib source tree, and carved it up to work with fatfs and what not. If
you'll notice in that, it's 'isatty' and not 'isatty'. Changing it to
'_isatty' in my syscalls.c results in it trying to link against the newlib
provided version, which causes many warnings about duplicating defined
functions. Basically, as long as the syscalls.c in the demo package
satisifies all the linking needs of the code and libraries, it won't ever
try to look in the newlib libraries for it.
In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
function (the reentrant version). Did you pull yours out of CVS? I found a
reference at http://sourceware.org/ml/newlib-cvs/2008-q1/msg00001.html to it
being added, but that's not mainstream yet, as far as I know. The date on
the .tar.gz file is 2007-12-19, which predates the addition of isatty_r.
The naming of 'isatty' is deliberate. It's the same name they used in the
syscalls.c that shipped in the 1.16.0 files. I noticed that also, and was
curious about it. I see in the CVS branch that it was renamed between
version 1.14, 2007/07/06 16:56:30 and version 1.15, 2008/01/03 22:33:37.
--jc
On Thu, Sep 11, 2008 at 12:00 PM, Harald Kubota wrote:
> Hi,
> J.C. Wren wrote:
>
> > If you can get CodeSourcery out of the equation, I may be able to
> > provide you with addition help.
>
> Compiling my own cross compile suite from scratch was not that difficult.
> And once I figured out that when configuring newlib I need to
> "--disable-newlib-supplied-syscalls", the rest was straightforward. Please
> put this comment on building newlib into the next version of the demo
> files to save
> some people from pulling out their hairs...
>
> When linking I got this one:
>
> /opt/cross/lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libg.a(lib_a-isattyr.o):
>
> In function `_isatty_r':
> ../../../../../newlib/src/newlib/libc/reent/isattyr.c:58: undefined
> reference to `_isatty'
> collect2: ld returned 1 exit status
>
> Checking syscalls.c in newlib/ in the LPC2148 Demo files show lots of
> definitions starting with an
> underscore. Except isatty which is missing the underscore.
>
> Was that on purpose? 'Cause I 'fixed' that and now I can compile the
> example code and link it.
>
> I still don't know if the code works or not. but I'll try that once I'm
> back from camping.
>
> Thanks,
> Harald
>
>
>
Reply by ●September 11, 20082008-09-11
Hi,
J.C. Wren wrote:
> I didn't have to use --disable-newlib-supplied-syscalls on my install. When
> I originally wrote this stuff,[...]
> In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
> function (the reentrant version). Did you pull yours out of CVS?
newlib seems to have changed sufficiently since your demo v1.20 was
created...
Thanks for analyzing those small differences. And yes, I used cvs to get
the latest
newlib.
I'm now finally at a stage where I can try some real code and run on the
lpc2148 I have :-)
Thanks for your help on this,
Harald
J.C. Wren wrote:
> I didn't have to use --disable-newlib-supplied-syscalls on my install. When
> I originally wrote this stuff,[...]
> In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
> function (the reentrant version). Did you pull yours out of CVS?
newlib seems to have changed sufficiently since your demo v1.20 was
created...
Thanks for analyzing those small differences. And yes, I used cvs to get
the latest
newlib.
I'm now finally at a stage where I can try some real code and run on the
lpc2148 I have :-)
Thanks for your help on this,
Harald
Reply by ●September 11, 20082008-09-11
Glad it's working for you.
I dunno. Maybe newlib has changed since the 1.16.0 release (the latest
formal release), but the demo code was developed under 1.16.0
--jc
On Thu, Sep 11, 2008 at 6:03 PM, Harald Kubota wrote:
> Hi,
>
> J.C. Wren wrote:
> > I didn't have to use --disable-newlib-supplied-syscalls on my install.
> When
> > I originally wrote this stuff,[...]
> > In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
> > function (the reentrant version). Did you pull yours out of CVS?
>
> newlib seems to have changed sufficiently since your demo v1.20 was
> created...
> Thanks for analyzing those small differences. And yes, I used cvs to get
> the latest
> newlib.
>
> I'm now finally at a stage where I can try some real code and run on the
> lpc2148 I have :-)
>
> Thanks for your help on this,
> Harald
>
>
>
I dunno. Maybe newlib has changed since the 1.16.0 release (the latest
formal release), but the demo code was developed under 1.16.0
--jc
On Thu, Sep 11, 2008 at 6:03 PM, Harald Kubota wrote:
> Hi,
>
> J.C. Wren wrote:
> > I didn't have to use --disable-newlib-supplied-syscalls on my install.
> When
> > I originally wrote this stuff,[...]
> > In the newlib-1.16.0.tar.gz source files, I'm not seeing the isatty_r
> > function (the reentrant version). Did you pull yours out of CVS?
>
> newlib seems to have changed sufficiently since your demo v1.20 was
> created...
> Thanks for analyzing those small differences. And yes, I used cvs to get
> the latest
> newlib.
>
> I'm now finally at a stage where I can try some real code and run on the
> lpc2148 I have :-)
>
> Thanks for your help on this,
> Harald
>
>
>
Reply by ●September 13, 20082008-09-13
Hi,
J.C. Wren wrote:
> I dunno. Maybe newlib has changed since the 1.16.0 release (the latest
> formal release), but the demo code was developed under 1.16.0
>
Yeah, I can confirm all compiles well when using newlib-1.16.0. I
wrongly assumed that
"newer version are surely compatible". Neither FreeRTOS nor newlib is
though...
When moving in the embedded world I shall seriously question my assumption.
Thanks,
Harald
J.C. Wren wrote:
> I dunno. Maybe newlib has changed since the 1.16.0 release (the latest
> formal release), but the demo code was developed under 1.16.0
>
Yeah, I can confirm all compiles well when using newlib-1.16.0. I
wrongly assumed that
"newer version are surely compatible". Neither FreeRTOS nor newlib is
though...
When moving in the embedded world I shall seriously question my assumption.
Thanks,
Harald
Reply by ●September 14, 20082008-09-14
Harald Kubota wrote:
> I'm now finally at a stage where I can try some real code and run on the
> lpc2148 I have :-)
>
>
After all the little problems I had and the help I received from jc,
I am glad to be able to write that I can finally run code on the
LPC2148_USB board
(see http://www.futurlec.com/ARM2148_USB_Development_Board.shtml)
when LEDs are connected to P0[10] and P0[14], which seems to be where they
are on the Olimes 2148 development board.
Other parts were a self compiled gcc-4.3.2, binutils-2.17, newlib-1.60
and lpc2isp-1.60,
and of course the lpc2148_demo-1.20.
Now the fun part starts...
Harald
> I'm now finally at a stage where I can try some real code and run on the
> lpc2148 I have :-)
>
>
After all the little problems I had and the help I received from jc,
I am glad to be able to write that I can finally run code on the
LPC2148_USB board
(see http://www.futurlec.com/ARM2148_USB_Development_Board.shtml)
when LEDs are connected to P0[10] and P0[14], which seems to be where they
are on the Olimes 2148 development board.
Other parts were a self compiled gcc-4.3.2, binutils-2.17, newlib-1.60
and lpc2isp-1.60,
and of course the lpc2148_demo-1.20.
Now the fun part starts...
Harald
Reply by ●September 14, 20082008-09-14
