interested in stm32 port
Locked
|
Hi there
I am an stm32 platform enthusiast and would love to make an easily script-able platform out of it. eLua seems to fit the bill except that i really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am using have) would be enough (even if barely) to be able to run lua scripts, even pre-compiled if needed, off an SD card. I had followed the toolchain building tutorial and built those successfully. But it seems to me that scons for the stm32 target uses arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's toolchain was used for this target. I have tried to build the elua for the stm32f103ze target and it breaks on the following step: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc -ffunction-sections -fdata-sections -fno-strict-aliasing -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o src/newlib/stubs.o src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: error: previous declaration of '_gettimeofday_r' was here scons: *** [src/newlib/stubs.o] Error 1 scons: building terminated because of errors. from the way it looks, something is wrong with newlib. Are there any suggestions as to how i go about fixing it? Is this happening because libnew wasn't compiled in a specific way that elua prescribes? would it be possible to just stick to the toolchain built as per instructions on elua site? or CS's toolchain is really necessary for stm32? btw, i am normally using CS's toolchain (binaries) for all my stm32 projects Thanks Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081226/d2043bc4/attachment.html |
|
|
OK i've made some progress (for those curious or stuck, like myself)
the size results look discouraging for my 128kb flash'ed chips: the binaries are 269kb for lualong and 308kb for lua targets (i used the way to use objcopy to generate binaries from the stm32 example conf.py). And that's with all the newest source, about 50k larger using arm-none-eabi- binary toolchain off of CS's site. is there still a chance to shove it into 128kb/20k chip? EDIT: i've tried excluding the options like terminal and romfs and got the size down to 233k for lualong some things to fix: (not complaining but pointing out potential improvements ;-) ) 1. this piece of code in src/newlib/stubs.c #if ELUA_PLATFORM == AVR32 int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone *tzp ) #else int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) #endif on my system, this #if check doesn't work properly and ends up going through the first branch (i.e as if it's for AVR32 target) while i am using the stm32 target. this was causing my initial problem (my last post), and commenting out all of the above lines except for the second branch (i.e int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it build. 2. scons -c doesn't work, but scons -c <all the required parameters for build> works. I think just scons -c should work and clean everything up 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into a separate variable as opposed to hardcoding it in the platform py file Cheers Alex On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: > Hi there > > I am an stm32 platform enthusiast and would love to make an easily > script-able platform out of it. eLua seems to fit the bill except that i > really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am > using have) would be enough (even if barely) to be able to run lua scripts, > even pre-compiled if needed, off an SD card. > > I had followed the toolchain building tutorial and built those > successfully. But it seems to me that scons for the stm32 target uses > arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's > toolchain was used for this target. > I have tried to build the elua for the stm32f103ze target and it breaks on > the following step: > > > arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os > -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules > -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc > -ffunction-sections -fdata-sections -fno-strict-aliasing > -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 > -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o > src/newlib/stubs.o > src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' > /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: > error: previous declaration of '_gettimeofday_r' was here > scons: *** [src/newlib/stubs.o] Error 1 > scons: building terminated because of errors. > > > from the way it looks, something is wrong with newlib. Are there any > suggestions as to how i go about fixing it? Is this happening because libnew > wasn't compiled in a specific way that elua prescribes? > > would it be possible to just stick to the toolchain built as per > instructions on elua site? or CS's toolchain is really necessary for stm32? > > btw, i am normally using CS's toolchain (binaries) for all my stm32 > projects > > Thanks > Alex > > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/e22a4e17/attachment.html |
|
|
In reply to this post by Alex Babkin
Hi,
I am an stm32 platform enthusiast and would love to make an easily > script-able platform out of it. eLua seems to fit the bill except that i > really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am > using have) would be enough (even if barely) to be able to run lua scripts, > even pre-compiled if needed, off an SD card. 20kb of RAM is a pretty unsafe bet for eLua at this point, so you might be disappointed after you finally manage to compile and burn it. Just a fair warning :) > I had followed the toolchain building tutorial and built those > successfully. But it seems to me that scons for the stm32 target uses > arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's > toolchain was used for this target. I didn't work on this port, but if its conf.py file reffers to arm-none-eabi-gcc, you're probably right about CodeSourcery. arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os > -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules > -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc > -ffunction-sections -fdata-sections -fno-strict-aliasing > -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 > -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o > src/newlib/stubs.o > src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' > /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: > error: previous declaration of '_gettimeofday_r' was here > scons: *** [src/newlib/stubs.o] Error 1 > scons: building terminated because of errors. Happaned to me too. Check your toolchain's include/reent.h file, and also these lines from src/newlib/stubs.c: #*include* *<sys/time.h>* #*if* ELUA_PLATFORM == AVR32 *int* *_gettimeofday_r*( *struct* _reent *r, *struct* timeval *tp, *struct* timezone *tzp ) #*else* *int* *_gettimeofday_r*( *struct* _reent *r, *struct* timeval *tv, *void* *tz ) #*endif* { r->_errno = ENOSYS; *return* -1; } It seems that _gettimeofday_r has different declarations for different targets, so you might want to modify the above to fit your include/reent.h (it doesn't really matter, as the implementation is empty anyway). would it be possible to just stick to the toolchain built as per > instructions on elua site? or CS's toolchain is really necessary for stm32? You could definitely try to stick to the instructions on eLua's site, but more than one people told me that CS's toolchain is probably better for Cortex, so I'd go with that for now. Best, Bogdan -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/942dfe3a/attachment.html |
|
|
In reply to this post by Alex Babkin
Hello Alex, welcome to eLua !!! :)
On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: > 1. > > this piece of code in src/newlib/stubs.c > > #if ELUA_PLATFORM == AVR32 > int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone > *tzp ) > #else > int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) > #endif > > on my system, this #if check doesn't work properly and ends up going > through the first branch (i.e as if it's for AVR32 target) while i am using > the stm32 target. > this was causing my initial problem (my last post), and commenting out all > of the above lines except for the second branch (i.e int _gettimeofday_r( > struct _reent *r, struct timeval *tv, void *tz )) made it build. May be an SConstruct little bug. We'll take a look. 2. scons -c doesn't work, but scons -c <all the required parameters for > build> works. I think just scons -c should work and clean everything up This looked strange to me at first too. But it is actually usefull, when you are working with more than on target at the same time, as the option only clears the selectioned target. On the other hand, most users generally work with a single target at a time and for them help comes from up-arrow or ctr-r sco tab up-arrow for now. Tks for pointing it. We'll keep an eye on other opinions too. > 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into a > separate variable as opposed to hardcoding it in the platform py file Looks good if different toolchains will really be used for the same target. Do we expect it too happen or there will be a clearly "better" choice that deserves to be hardcoded ? Mike is the one that was working on the STM32 port. We (me and Bogdan) don't have STM32 kits :( But this is definetely a nice platform to have eLua on, although I agree that you will probably need some more mem :( My guess is that 32Kb ram will be pretty usable, with some magic that Bogdan has been working on lately :) (read-only tables in flash, light functions, new clib, .......) Cheers > Alex Best Dado > > > > > On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: > >> Hi there >> >> I am an stm32 platform enthusiast and would love to make an easily >> script-able platform out of it. eLua seems to fit the bill except that i >> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >> using have) would be enough (even if barely) to be able to run lua scripts, >> even pre-compiled if needed, off an SD card. >> >> I had followed the toolchain building tutorial and built those >> successfully. But it seems to me that scons for the stm32 target uses >> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >> toolchain was used for this target. >> I have tried to build the elua for the stm32f103ze target and it breaks on >> the following step: >> >> >> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >> -ffunction-sections -fdata-sections -fno-strict-aliasing >> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >> src/newlib/stubs.o >> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >> error: previous declaration of '_gettimeofday_r' was here >> scons: *** [src/newlib/stubs.o] Error 1 >> scons: building terminated because of errors. >> >> >> from the way it looks, something is wrong with newlib. Are there any >> suggestions as to how i go about fixing it? Is this happening because libnew >> wasn't compiled in a specific way that elua prescribes? >> >> would it be possible to just stick to the toolchain built as per >> instructions on elua site? or CS's toolchain is really necessary for stm32? >> >> btw, i am normally using CS's toolchain (binaries) for all my stm32 >> projects >> >> Thanks >> Alex >> >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/9fbfc833/attachment.html |
|
|
>
> On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: > >> 1. >> >> this piece of code in src/newlib/stubs.c >> >> #if ELUA_PLATFORM == AVR32 >> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone >> *tzp ) >> #else >> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >> #endif >> >> on my system, this #if check doesn't work properly and ends up going >> through the first branch (i.e as if it's for AVR32 target) while i am using >> the stm32 target. >> this was causing my initial problem (my last post), and commenting out all >> of the above lines except for the second branch (i.e int _gettimeofday_r( >> struct _reent *r, struct timeval *tv, void *tz )) made it build. > > > May be an SConstruct little bug. We'll take a look. > No SConstruct bugs there, just an error of mine (obviously #if ELUA_PLATFORM==AVR32 is not a valid C preprocessor expression). Fixed on trunk. > 2. scons -c doesn't work, but scons -c <all the required parameters for > build> works. I think just scons -c should work and clean everything up > > This looked strange to me at first too. But it is actually usefull, when > you are working with more than on target at the same time, as the option > only clears the selectioned target. > Exactly. This is not a bugof scons, it's a feature :) > > 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into a >> separate variable as opposed to hardcoding it in the platform py file > > > Looks good if different toolchains will really be used for the same target. > Do we expect it too happen or there will be a clearly "better" choice that > deserves to be hardcoded ? > Once again I agree. For a given target I think it's perfectly OK to hardcode the compiler prefix, as long as you'll most likely use a single toolchain to compile it (unless you're doing some sort of benchmarking between different toolchain, in which case it should be easy to modify conf.py with a new command line option that will give you the option to choose the right toolchain). > My guess is that 32Kb ram will be pretty usable, with some magic that > Bogdan has been working on lately :) (read-only tables in flash, light > functions, new clib, .......) > He was talking about 20Kb of RAM, which is not that usable, sadly. Even with my patch (when it will be available) I see some problems with 20K of RAM. Best, Bogdan > > > >> >> >> >> >> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >> >>> Hi there >>> >>> I am an stm32 platform enthusiast and would love to make an easily >>> script-able platform out of it. eLua seems to fit the bill except that i >>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>> using have) would be enough (even if barely) to be able to run lua scripts, >>> even pre-compiled if needed, off an SD card. >>> >>> I had followed the toolchain building tutorial and built those >>> successfully. But it seems to me that scons for the stm32 target uses >>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>> toolchain was used for this target. >>> I have tried to build the elua for the stm32f103ze target and it breaks >>> on the following step: >>> >>> >>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>> src/newlib/stubs.o >>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>> error: previous declaration of '_gettimeofday_r' was here >>> scons: *** [src/newlib/stubs.o] Error 1 >>> scons: building terminated because of errors. >>> >>> >>> from the way it looks, something is wrong with newlib. Are there any >>> suggestions as to how i go about fixing it? Is this happening because libnew >>> wasn't compiled in a specific way that elua prescribes? >>> >>> would it be possible to just stick to the toolchain built as per >>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>> >>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>> projects >>> >>> Thanks >>> Alex >>> >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/92e2151c/attachment-0001.html |
|
|
In reply to this post by Dado Sutter
Thanks for replies guys
i really grew to like the stm32 platform and the following chip looks perfect fro elua (512k flash / 64kb ram) http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND in regards to having a development kit, i've realised that with some decent soldering skills, a SMD breakout board, protoboard, few components and wirewrap it's quite easy (fun and more rewarding than just buying one) to make your own development board for these chips. in regards to #1, it just looks weird to me using == operator in #if, never seen this done before. #2, i think "scons -c" should clean all targets, while if a target is specified, it should clean only this target. #3 i just went by the fact that Mike used arm-none-eabi for stm32 port. Even if arm-elf is used in majority of cases, i think it's still cleaner to factor it out in some variable just IMHO Alex On Sat, Dec 27, 2008 at 10:09 AM, Dado Sutter <dadosutter at gmail.com> wrote: > Hello Alex, welcome to eLua !!! :) > > > On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: > >> 1. >> >> this piece of code in src/newlib/stubs.c >> >> #if ELUA_PLATFORM == AVR32 >> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone >> *tzp ) >> #else >> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >> #endif >> >> on my system, this #if check doesn't work properly and ends up going >> through the first branch (i.e as if it's for AVR32 target) while i am using >> the stm32 target. >> this was causing my initial problem (my last post), and commenting out all >> of the above lines except for the second branch (i.e int _gettimeofday_r( >> struct _reent *r, struct timeval *tv, void *tz )) made it build. > > > May be an SConstruct little bug. We'll take a look. > > 2. scons -c doesn't work, but scons -c <all the required parameters for >> build> works. I think just scons -c should work and clean everything up > > > This looked strange to me at first too. But it is actually usefull, when > you are working with more than on target at the same time, as the option > only clears the selectioned target. > On the other hand, most users generally work with a single target at a time > and for them help comes from up-arrow or ctr-r sco tab up-arrow for now. > Tks for pointing it. We'll keep an eye on other opinions too. > > >> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into >> a separate variable as opposed to hardcoding it in the platform py file > > > Looks good if different toolchains will really be used for the same target. > Do we expect it too happen or there will be a clearly "better" choice that > deserves to be hardcoded ? > > Mike is the one that was working on the STM32 port. We (me and Bogdan) > don't have STM32 kits :( > But this is definetely a nice platform to have eLua on, although I agree > that you will probably need some more mem :( > My guess is that 32Kb ram will be pretty usable, with some magic that > Bogdan has been working on lately :) (read-only tables in flash, light > functions, new clib, .......) > > Cheers >> Alex > > > Best > Dado > > > > >> >> >> >> >> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >> >>> Hi there >>> >>> I am an stm32 platform enthusiast and would love to make an easily >>> script-able platform out of it. eLua seems to fit the bill except that i >>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>> using have) would be enough (even if barely) to be able to run lua scripts, >>> even pre-compiled if needed, off an SD card. >>> >>> I had followed the toolchain building tutorial and built those >>> successfully. But it seems to me that scons for the stm32 target uses >>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>> toolchain was used for this target. >>> I have tried to build the elua for the stm32f103ze target and it breaks >>> on the following step: >>> >>> >>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>> src/newlib/stubs.o >>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>> error: previous declaration of '_gettimeofday_r' was here >>> scons: *** [src/newlib/stubs.o] Error 1 >>> scons: building terminated because of errors. >>> >>> >>> from the way it looks, something is wrong with newlib. Are there any >>> suggestions as to how i go about fixing it? Is this happening because libnew >>> wasn't compiled in a specific way that elua prescribes? >>> >>> would it be possible to just stick to the toolchain built as per >>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>> >>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>> projects >>> >>> Thanks >>> Alex >>> >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/00ad79ac/attachment.html |
|
|
> i really grew to like the stm32 platform and the following chip looks
> perfect fro elua (512k flash / 64kb ram) > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND That one IS perfect for eLua. If you add some external memory, it becomes more than perfect for eLua :) in regards to having a development kit, i've realised that with some decent > soldering skills, a SMD breakout board, protoboard, few components and > wirewrap it's quite easy (fun and more rewarding than just buying one) to > make your own development board for these chips. That's true, except in some places (like Romania) it's quite hard to find SMD breakout boards. > in regards to #1, it just looks weird to me using == operator in #if, never > seen this done before. It's more than weird, it's wrong :) My bad. > #2, i think "scons -c" should clean all targets, while if a target is > specified, it should clean only this target. Then if you do "scons -c" by mistake, you'd clean all your targets. It doesn't matter much for eLua, but for larger projects this can be a real problem (and I'm talking from experience now). Maybe this is why "scons -c" doesn't clean all targets. > #3 i just went by the fact that Mike used arm-none-eabi for stm32 port. > Even if arm-elf is used in majority of cases, i think it's still cleaner to > factor it out in some variable I disagree with you here. It might be more clear for someone with a lot of experience with toolchains, but for anybody else adding a "toolchin=arm-elf" to the command line will just add confusion without any real benefit, since it's not likely that you'll use more than one toolchain to build a given target. Best, Bogdan On Sat, Dec 27, 2008 at 10:09 AM, Dado Sutter <dadosutter at gmail.com> wrote: > >> Hello Alex, welcome to eLua !!! :) >> >> >> On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: >> >>> 1. >>> >>> this piece of code in src/newlib/stubs.c >>> >>> #if ELUA_PLATFORM == AVR32 >>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>> timezone *tzp ) >>> #else >>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>> #endif >>> >>> on my system, this #if check doesn't work properly and ends up going >>> through the first branch (i.e as if it's for AVR32 target) while i am using >>> the stm32 target. >>> this was causing my initial problem (my last post), and commenting out >>> all of the above lines except for the second branch (i.e int >>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>> build. >> >> >> May be an SConstruct little bug. We'll take a look. >> >> 2. scons -c doesn't work, but scons -c <all the required parameters for >>> build> works. I think just scons -c should work and clean everything up >> >> >> This looked strange to me at first too. But it is actually usefull, when >> you are working with more than on target at the same time, as the option >> only clears the selectioned target. >> On the other hand, most users generally work with a single target at a >> time and for them help comes from up-arrow or ctr-r sco tab up-arrow for >> now. >> Tks for pointing it. We'll keep an eye on other opinions too. >> >> >>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into >>> a separate variable as opposed to hardcoding it in the platform py file >> >> >> Looks good if different toolchains will really be used for the same >> target. Do we expect it too happen or there will be a clearly "better" >> choice that deserves to be hardcoded ? >> >> Mike is the one that was working on the STM32 port. We (me and Bogdan) >> don't have STM32 kits :( >> But this is definetely a nice platform to have eLua on, although I agree >> that you will probably need some more mem :( >> My guess is that 32Kb ram will be pretty usable, with some magic that >> Bogdan has been working on lately :) (read-only tables in flash, light >> functions, new clib, .......) >> >> Cheers >>> Alex >> >> >> Best >> Dado >> >> >> >> >>> >>> >>> >>> >>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> Hi there >>>> >>>> I am an stm32 platform enthusiast and would love to make an easily >>>> script-able platform out of it. eLua seems to fit the bill except that i >>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>> even pre-compiled if needed, off an SD card. >>>> >>>> I had followed the toolchain building tutorial and built those >>>> successfully. But it seems to me that scons for the stm32 target uses >>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>> toolchain was used for this target. >>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>> on the following step: >>>> >>>> >>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>> src/newlib/stubs.o >>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>> error: previous declaration of '_gettimeofday_r' was here >>>> scons: *** [src/newlib/stubs.o] Error 1 >>>> scons: building terminated because of errors. >>>> >>>> >>>> from the way it looks, something is wrong with newlib. Are there any >>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>> wasn't compiled in a specific way that elua prescribes? >>>> >>>> would it be possible to just stick to the toolchain built as per >>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>> >>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>> projects >>>> >>>> Thanks >>>> Alex >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/6185b5d4/attachment-0001.html |
|
|
In reply to this post by Alex Babkin
Hi again,
On Sat, Dec 27, 2008 at 13:58, Alex Babkin <ababkin at gmail.com> wrote: > Thanks for replies guys My pleasure :) > i really grew to like the stm32 platform and the following chip looks > perfect fro elua (512k flash / 64kb ram) > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND Great !! Specially now that we have Mike and Alex supporting the STM32 !!! :) And it still has more room in external memory !! > > <http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND>in > regards to having a development kit, i've realised that with some decent > soldering skills, a SMD breakout board, protoboard, few components and > wirewrap it's quite easy (fun and more rewarding than just buying one) to > make your own development board for these chips. No doubt ! If you have easy access to these breakout boards and even to the MCUs :( :( Downhere "in the jungle" we can hardly find any of those :( :( To buy parts for single-board projects is an adventure in itself :( :( and we end up prefering to loose great part of the fun to get a ready built and tested kit :( :( in regards to #1, it just looks weird to me using == operator in #if, never > seen this done before. Bogdan has just commit it fixed to trunk. #ifdef AVR32 .......... > #2, i think "scons -c" should clean all targets, while if a target is > specified, it should clean only this target. Well, this is a scons behavior, not our script's. There must be a good reason for it, like do not allow you to clear dev targets where you don't have access or something. You can always write a simple script sconsclear, that triggers all the platform -c options but before we have 20+ eLua ports I don't think it is really necessary :) #3 i just went by the fact that Mike used arm-none-eabi for stm32 port. Even > if arm-elf is used in majority of cases, i think it's still cleaner to > factor it out in some variable I don't have a final opinion here, as I don't have the feeling if two diferent toolkits will be in current use for the same platform. I don't think so, at least for 99% of the users, so my vote is to keep it simple (where it is or, at the most, in a scons script variable) for now. just IMHO Thanks a lot !!!!!!!!! > Alex Best Dado > > > On Sat, Dec 27, 2008 at 10:09 AM, Dado Sutter <dadosutter at gmail.com>wrote: > >> Hello Alex, welcome to eLua !!! :) >> >> >> On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: >> >>> 1. >>> >>> this piece of code in src/newlib/stubs.c >>> >>> #if ELUA_PLATFORM == AVR32 >>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>> timezone *tzp ) >>> #else >>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>> #endif >>> >>> on my system, this #if check doesn't work properly and ends up going >>> through the first branch (i.e as if it's for AVR32 target) while i am using >>> the stm32 target. >>> this was causing my initial problem (my last post), and commenting out >>> all of the above lines except for the second branch (i.e int >>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>> build. >> >> >> May be an SConstruct little bug. We'll take a look. >> >> 2. scons -c doesn't work, but scons -c <all the required parameters for >>> build> works. I think just scons -c should work and clean everything up >> >> >> This looked strange to me at first too. But it is actually usefull, when >> you are working with more than on target at the same time, as the option >> only clears the selectioned target. >> On the other hand, most users generally work with a single target at a >> time and for them help comes from up-arrow or ctr-r sco tab up-arrow for >> now. >> Tks for pointing it. We'll keep an eye on other opinions too. >> >> >>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into >>> a separate variable as opposed to hardcoding it in the platform py file >> >> >> Looks good if different toolchains will really be used for the same >> target. Do we expect it too happen or there will be a clearly "better" >> choice that deserves to be hardcoded ? >> >> Mike is the one that was working on the STM32 port. We (me and Bogdan) >> don't have STM32 kits :( >> But this is definetely a nice platform to have eLua on, although I agree >> that you will probably need some more mem :( >> My guess is that 32Kb ram will be pretty usable, with some magic that >> Bogdan has been working on lately :) (read-only tables in flash, light >> functions, new clib, .......) >> >> Cheers >>> Alex >> >> >> Best >> Dado >> >> >> >> >>> >>> >>> >>> >>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> Hi there >>>> >>>> I am an stm32 platform enthusiast and would love to make an easily >>>> script-able platform out of it. eLua seems to fit the bill except that i >>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>> even pre-compiled if needed, off an SD card. >>>> >>>> I had followed the toolchain building tutorial and built those >>>> successfully. But it seems to me that scons for the stm32 target uses >>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>> toolchain was used for this target. >>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>> on the following step: >>>> >>>> >>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>> src/newlib/stubs.o >>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>> error: previous declaration of '_gettimeofday_r' was here >>>> scons: *** [src/newlib/stubs.o] Error 1 >>>> scons: building terminated because of errors. >>>> >>>> >>>> from the way it looks, something is wrong with newlib. Are there any >>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>> wasn't compiled in a specific way that elua prescribes? >>>> >>>> would it be possible to just stick to the toolchain built as per >>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>> >>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>> projects >>>> >>>> Thanks >>>> Alex >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/6a0109f9/attachment.html |
|
|
In reply to this post by BogdanM
Hi Bogdan
this place is a blessing for a SMD diy'er (super cheap breakouts) http://futurlec.com/SMD_Adapters.shtml i am pretty sure the'd ship to Romania (they ship from Thailand AFAIK) Alex On Sat, Dec 27, 2008 at 11:18 AM, Bogdan Marinescu < bogdan.marinescu at gmail.com> wrote: > > i really grew to like the stm32 platform and the following chip looks >> perfect fro elua (512k flash / 64kb ram) >> >> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND > > > That one IS perfect for eLua. If you add some external memory, it becomes > more than perfect for eLua :) > > in regards to having a development kit, i've realised that with some decent >> soldering skills, a SMD breakout board, protoboard, few components and >> wirewrap it's quite easy (fun and more rewarding than just buying one) to >> make your own development board for these chips. > > > That's true, except in some places (like Romania) it's quite hard to find > SMD breakout boards. > > >> in regards to #1, it just looks weird to me using == operator in #if, >> never seen this done before. > > > It's more than weird, it's wrong :) My bad. > > >> #2, i think "scons -c" should clean all targets, while if a target is >> specified, it should clean only this target. > > > Then if you do "scons -c" by mistake, you'd clean all your targets. It > doesn't matter much for eLua, but for larger projects this can be a real > problem (and I'm talking from experience now). Maybe this is why "scons -c" > doesn't clean all targets. > > >> #3 i just went by the fact that Mike used arm-none-eabi for stm32 port. >> Even if arm-elf is used in majority of cases, i think it's still cleaner to >> factor it out in some variable > > > I disagree with you here. It might be more clear for someone with a lot of > experience with toolchains, but for anybody else adding a "toolchin=arm-elf" > to the command line will just add confusion without any real benefit, since > it's not likely that you'll use more than one toolchain to build a given > target. > > Best, > Bogdan > > > On Sat, Dec 27, 2008 at 10:09 AM, Dado Sutter <dadosutter at gmail.com>wrote: >> >>> Hello Alex, welcome to eLua !!! :) >>> >>> >>> On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> 1. >>>> >>>> this piece of code in src/newlib/stubs.c >>>> >>>> #if ELUA_PLATFORM == AVR32 >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>>> timezone *tzp ) >>>> #else >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>>> #endif >>>> >>>> on my system, this #if check doesn't work properly and ends up going >>>> through the first branch (i.e as if it's for AVR32 target) while i am using >>>> the stm32 target. >>>> this was causing my initial problem (my last post), and commenting out >>>> all of the above lines except for the second branch (i.e int >>>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>>> build. >>> >>> >>> May be an SConstruct little bug. We'll take a look. >>> >>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>>> build> works. I think just scons -c should work and clean everything up >>> >>> >>> This looked strange to me at first too. But it is actually usefull, when >>> you are working with more than on target at the same time, as the option >>> only clears the selectioned target. >>> On the other hand, most users generally work with a single target at a >>> time and for them help comes from up-arrow or ctr-r sco tab up-arrow for >>> now. >>> Tks for pointing it. We'll keep an eye on other opinions too. >>> >>> >>>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) >>>> into a separate variable as opposed to hardcoding it in the platform py file >>> >>> >>> Looks good if different toolchains will really be used for the same >>> target. Do we expect it too happen or there will be a clearly "better" >>> choice that deserves to be hardcoded ? >>> >>> Mike is the one that was working on the STM32 port. We (me and Bogdan) >>> don't have STM32 kits :( >>> But this is definetely a nice platform to have eLua on, although I agree >>> that you will probably need some more mem :( >>> My guess is that 32Kb ram will be pretty usable, with some magic that >>> Bogdan has been working on lately :) (read-only tables in flash, light >>> functions, new clib, .......) >>> >>> Cheers >>>> Alex >>> >>> >>> Best >>> Dado >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com>wrote: >>>> >>>>> Hi there >>>>> >>>>> I am an stm32 platform enthusiast and would love to make an easily >>>>> script-able platform out of it. eLua seems to fit the bill except that i >>>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>>> even pre-compiled if needed, off an SD card. >>>>> >>>>> I had followed the toolchain building tutorial and built those >>>>> successfully. But it seems to me that scons for the stm32 target uses >>>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>>> toolchain was used for this target. >>>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>>> on the following step: >>>>> >>>>> >>>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>>> src/newlib/stubs.o >>>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>>> error: previous declaration of '_gettimeofday_r' was here >>>>> scons: *** [src/newlib/stubs.o] Error 1 >>>>> scons: building terminated because of errors. >>>>> >>>>> >>>>> from the way it looks, something is wrong with newlib. Are there any >>>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>>> wasn't compiled in a specific way that elua prescribes? >>>>> >>>>> would it be possible to just stick to the toolchain built as per >>>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>>> >>>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>>> projects >>>>> >>>>> Thanks >>>>> Alex >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Elua-dev mailing list >>>> Elua-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/4b863908/attachment-0001.html |
|
|
Thanks! Their shipping rates seem to be pretty "humane" too :), so I'll
probably use them sometime in the future. Best, Bogdan On Sat, Dec 27, 2008 at 6:46 PM, Alex Babkin <ababkin at gmail.com> wrote: > Hi Bogdan > > this place is a blessing for a SMD diy'er (super cheap breakouts) > http://futurlec.com/SMD_Adapters.shtml > > i am pretty sure the'd ship to Romania (they ship from Thailand AFAIK) > > Alex > > > > On Sat, Dec 27, 2008 at 11:18 AM, Bogdan Marinescu < > bogdan.marinescu at gmail.com> wrote: > >> >> i really grew to like the stm32 platform and the following chip looks >>> perfect fro elua (512k flash / 64kb ram) >>> >>> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-6444-ND >> >> >> That one IS perfect for eLua. If you add some external memory, it becomes >> more than perfect for eLua :) >> >> in regards to having a development kit, i've realised that with some >>> decent soldering skills, a SMD breakout board, protoboard, few components >>> and wirewrap it's quite easy (fun and more rewarding than just buying one) >>> to make your own development board for these chips. >> >> >> That's true, except in some places (like Romania) it's quite hard to find >> SMD breakout boards. >> >> >>> in regards to #1, it just looks weird to me using == operator in #if, >>> never seen this done before. >> >> >> It's more than weird, it's wrong :) My bad. >> >> >>> #2, i think "scons -c" should clean all targets, while if a target is >>> specified, it should clean only this target. >> >> >> Then if you do "scons -c" by mistake, you'd clean all your targets. It >> doesn't matter much for eLua, but for larger projects this can be a real >> problem (and I'm talking from experience now). Maybe this is why "scons -c" >> doesn't clean all targets. >> >> >>> #3 i just went by the fact that Mike used arm-none-eabi for stm32 port. >>> Even if arm-elf is used in majority of cases, i think it's still cleaner to >>> factor it out in some variable >> >> >> I disagree with you here. It might be more clear for someone with a lot of >> experience with toolchains, but for anybody else adding a "toolchin=arm-elf" >> to the command line will just add confusion without any real benefit, since >> it's not likely that you'll use more than one toolchain to build a given >> target. >> >> Best, >> Bogdan >> >> >> On Sat, Dec 27, 2008 at 10:09 AM, Dado Sutter <dadosutter at gmail.com>wrote: >>> >>>> Hello Alex, welcome to eLua !!! :) >>>> >>>> >>>> On Sat, Dec 27, 2008 at 04:03, Alex Babkin <ababkin at gmail.com> wrote: >>>> >>>>> 1. >>>>> >>>>> this piece of code in src/newlib/stubs.c >>>>> >>>>> #if ELUA_PLATFORM == AVR32 >>>>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>>>> timezone *tzp ) >>>>> #else >>>>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>>>> #endif >>>>> >>>>> on my system, this #if check doesn't work properly and ends up going >>>>> through the first branch (i.e as if it's for AVR32 target) while i am using >>>>> the stm32 target. >>>>> this was causing my initial problem (my last post), and commenting out >>>>> all of the above lines except for the second branch (i.e int >>>>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>>>> build. >>>> >>>> >>>> May be an SConstruct little bug. We'll take a look. >>>> >>>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>>>> build> works. I think just scons -c should work and clean everything up >>>> >>>> >>>> This looked strange to me at first too. But it is actually usefull, when >>>> you are working with more than on target at the same time, as the option >>>> only clears the selectioned target. >>>> On the other hand, most users generally work with a single target at a >>>> time and for them help comes from up-arrow or ctr-r sco tab up-arrow for >>>> now. >>>> Tks for pointing it. We'll keep an eye on other opinions too. >>>> >>>> >>>>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) >>>>> into a separate variable as opposed to hardcoding it in the platform py file >>>> >>>> >>>> Looks good if different toolchains will really be used for the same >>>> target. Do we expect it too happen or there will be a clearly "better" >>>> choice that deserves to be hardcoded ? >>>> >>>> Mike is the one that was working on the STM32 port. We (me and Bogdan) >>>> don't have STM32 kits :( >>>> But this is definetely a nice platform to have eLua on, although I agree >>>> that you will probably need some more mem :( >>>> My guess is that 32Kb ram will be pretty usable, with some magic that >>>> Bogdan has been working on lately :) (read-only tables in flash, light >>>> functions, new clib, .......) >>>> >>>> Cheers >>>>> Alex >>>> >>>> >>>> Best >>>> Dado >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com>wrote: >>>>> >>>>>> Hi there >>>>>> >>>>>> I am an stm32 platform enthusiast and would love to make an easily >>>>>> script-able platform out of it. eLua seems to fit the bill except that i >>>>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>>>> even pre-compiled if needed, off an SD card. >>>>>> >>>>>> I had followed the toolchain building tutorial and built those >>>>>> successfully. But it seems to me that scons for the stm32 target uses >>>>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>>>> toolchain was used for this target. >>>>>> I have tried to build the elua for the stm32f103ze target and it >>>>>> breaks on the following step: >>>>>> >>>>>> >>>>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>>>> src/newlib/stubs.o >>>>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>>>> error: previous declaration of '_gettimeofday_r' was here >>>>>> scons: *** [src/newlib/stubs.o] Error 1 >>>>>> scons: building terminated because of errors. >>>>>> >>>>>> >>>>>> from the way it looks, something is wrong with newlib. Are there any >>>>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>>>> wasn't compiled in a specific way that elua prescribes? >>>>>> >>>>>> would it be possible to just stick to the toolchain built as per >>>>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>>>> >>>>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>>>> projects >>>>>> >>>>>> Thanks >>>>>> Alex >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Elua-dev mailing list >>>>> Elua-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Elua-dev mailing list >>>> Elua-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/34033b5e/attachment.html |
|
|
In reply to this post by Alex Babkin
You could remove the LCD module, that might trim some down I think.
After reading this whole conversation, I am still not convinced of any benefits of factoring out the toolchain prefix. I had thought about it myself at one point for *all* the platforms, but decided against that one too. Generally a single platform will always use the same compiler, especially given a tested and proven compiler-platform combination, so again, I do not clearly see the advantage. Maybe I need some enlightenment? :) Mike On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: > OK i've made some progress (for those curious or stuck, like myself) > > the size results look discouraging for my 128kb flash'ed chips: > > the binaries are 269kb for lualong and 308kb for lua targets (i used the > way to use objcopy to generate binaries from the stm32 example conf.py). And > that's with all the newest source, about 50k larger using arm-none-eabi- > binary toolchain off of CS's site. > > is there still a chance to shove it into 128kb/20k chip? > > EDIT: i've tried excluding the options like terminal and romfs and got the > size down to 233k for lualong > > some things to fix: (not complaining but pointing out potential > improvements ;-) ) > 1. > > this piece of code in src/newlib/stubs.c > > #if ELUA_PLATFORM == AVR32 > int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone > *tzp ) > #else > int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) > #endif > > on my system, this #if check doesn't work properly and ends up going > through the first branch (i.e as if it's for AVR32 target) while i am using > the stm32 target. > this was causing my initial problem (my last post), and commenting out all > of the above lines except for the second branch (i.e int _gettimeofday_r( > struct _reent *r, struct timeval *tv, void *tz )) made it build. > > 2. scons -c doesn't work, but scons -c <all the required parameters for > build> works. I think just scons -c should work and clean everything up > > 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into a > separate variable as opposed to hardcoding it in the platform py file > > Cheers > Alex > > > > > On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: > >> Hi there >> >> I am an stm32 platform enthusiast and would love to make an easily >> script-able platform out of it. eLua seems to fit the bill except that i >> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >> using have) would be enough (even if barely) to be able to run lua scripts, >> even pre-compiled if needed, off an SD card. >> >> I had followed the toolchain building tutorial and built those >> successfully. But it seems to me that scons for the stm32 target uses >> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >> toolchain was used for this target. >> I have tried to build the elua for the stm32f103ze target and it breaks on >> the following step: >> >> >> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >> -ffunction-sections -fdata-sections -fno-strict-aliasing >> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >> src/newlib/stubs.o >> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >> error: previous declaration of '_gettimeofday_r' was here >> scons: *** [src/newlib/stubs.o] Error 1 >> scons: building terminated because of errors. >> >> >> from the way it looks, something is wrong with newlib. Are there any >> suggestions as to how i go about fixing it? Is this happening because libnew >> wasn't compiled in a specific way that elua prescribes? >> >> would it be possible to just stick to the toolchain built as per >> instructions on elua site? or CS's toolchain is really necessary for stm32? >> >> btw, i am normally using CS's toolchain (binaries) for all my stm32 >> projects >> >> Thanks >> Alex >> >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/427c3fec/attachment.html |
|
|
Hi Mike
Thanks for chiming in. Yea factoring out stuff - i was just throwing knee-jerk ideas around. Just because i wanted to try both toolchains on the stm32 port and was yukked out that i had to make same edit several times. Mike, i saw your post on codesourcery's forum about .fini section error. I found it as i was researching same error. Not sure if you're aware of the stm32 forum (on ST website) but that forum is pretty good and people like Lanchon are extremely helpful. Using his framework with modified linker scripts and such i've gotten infrastructure to work that supports printf/sprintf/fprintf (and similarly *scanf's) where fio functions use ChaN's tiny fat filesystem written for stm32. Alex On Tue, Dec 30, 2008 at 3:55 PM, Mike Panetta <panetta.mike at gmail.com>wrote: > You could remove the LCD module, that might trim some down I think. > > After reading this whole conversation, I am still not convinced of any > benefits of factoring out the toolchain prefix. I had thought about it > myself at one point for *all* the platforms, but decided against that one > too. Generally a single platform will always use the same compiler, > especially given a tested and proven compiler-platform combination, so > again, I do not clearly see the advantage. Maybe I need some enlightenment? > :) > > Mike > > On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: > >> OK i've made some progress (for those curious or stuck, like myself) >> >> the size results look discouraging for my 128kb flash'ed chips: >> >> the binaries are 269kb for lualong and 308kb for lua targets (i used the >> way to use objcopy to generate binaries from the stm32 example conf.py). And >> that's with all the newest source, about 50k larger using arm-none-eabi- >> binary toolchain off of CS's site. >> >> is there still a chance to shove it into 128kb/20k chip? >> >> EDIT: i've tried excluding the options like terminal and romfs and got the >> size down to 233k for lualong >> >> some things to fix: (not complaining but pointing out potential >> improvements ;-) ) >> 1. >> >> this piece of code in src/newlib/stubs.c >> >> #if ELUA_PLATFORM == AVR32 >> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct timezone >> *tzp ) >> #else >> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >> #endif >> >> on my system, this #if check doesn't work properly and ends up going >> through the first branch (i.e as if it's for AVR32 target) while i am using >> the stm32 target. >> this was causing my initial problem (my last post), and commenting out all >> of the above lines except for the second branch (i.e int _gettimeofday_r( >> struct _reent *r, struct timeval *tv, void *tz )) made it build. >> >> 2. scons -c doesn't work, but scons -c <all the required parameters for >> build> works. I think just scons -c should work and clean everything up >> >> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into >> a separate variable as opposed to hardcoding it in the platform py file >> >> Cheers >> Alex >> >> >> >> >> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >> >>> Hi there >>> >>> I am an stm32 platform enthusiast and would love to make an easily >>> script-able platform out of it. eLua seems to fit the bill except that i >>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>> using have) would be enough (even if barely) to be able to run lua scripts, >>> even pre-compiled if needed, off an SD card. >>> >>> I had followed the toolchain building tutorial and built those >>> successfully. But it seems to me that scons for the stm32 target uses >>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>> toolchain was used for this target. >>> I have tried to build the elua for the stm32f103ze target and it breaks >>> on the following step: >>> >>> >>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>> src/newlib/stubs.o >>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>> error: previous declaration of '_gettimeofday_r' was here >>> scons: *** [src/newlib/stubs.o] Error 1 >>> scons: building terminated because of errors. >>> >>> >>> from the way it looks, something is wrong with newlib. Are there any >>> suggestions as to how i go about fixing it? Is this happening because libnew >>> wasn't compiled in a specific way that elua prescribes? >>> >>> would it be possible to just stick to the toolchain built as per >>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>> >>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>> projects >>> >>> Thanks >>> Alex >>> >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/5bd5a5ec/attachment.html |
|
|
Now that sounds like fun. :) Does it integrate with newlib at all?
The main issue I had with the .fini junk is apparently there is more then one way to interface to newlib, and its a mess... I did eventually fix it by defining/overriding the correct function. I wonder if there would be a use for a libgloss port or a generic stubs lib for newlib and stm32? Mike On Tue, Dec 30, 2008 at 4:13 PM, Alex Babkin <ababkin at gmail.com> wrote: > Hi Mike > > Thanks for chiming in. > Yea factoring out stuff - i was just throwing knee-jerk ideas around. Just > because i wanted to try both toolchains on the stm32 port and was yukked out > that i had to make same edit several times. > > Mike, i saw your post on codesourcery's forum about .fini section error. I > found it as i was researching same error. > Not sure if you're aware of the stm32 forum (on ST website) but that forum > is pretty good and people like Lanchon are extremely helpful. > Using his framework with modified linker scripts and such i've gotten > infrastructure to work that supports printf/sprintf/fprintf (and similarly > *scanf's) where fio functions use ChaN's tiny fat filesystem written for > stm32. > > Alex > > > On Tue, Dec 30, 2008 at 3:55 PM, Mike Panetta <panetta.mike at gmail.com>wrote: > >> You could remove the LCD module, that might trim some down I think. >> >> After reading this whole conversation, I am still not convinced of any >> benefits of factoring out the toolchain prefix. I had thought about it >> myself at one point for *all* the platforms, but decided against that one >> too. Generally a single platform will always use the same compiler, >> especially given a tested and proven compiler-platform combination, so >> again, I do not clearly see the advantage. Maybe I need some enlightenment? >> :) >> >> Mike >> >> On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: >> >>> OK i've made some progress (for those curious or stuck, like myself) >>> >>> the size results look discouraging for my 128kb flash'ed chips: >>> >>> the binaries are 269kb for lualong and 308kb for lua targets (i used the >>> way to use objcopy to generate binaries from the stm32 example conf.py). And >>> that's with all the newest source, about 50k larger using arm-none-eabi- >>> binary toolchain off of CS's site. >>> >>> is there still a chance to shove it into 128kb/20k chip? >>> >>> EDIT: i've tried excluding the options like terminal and romfs and got >>> the size down to 233k for lualong >>> >>> some things to fix: (not complaining but pointing out potential >>> improvements ;-) ) >>> 1. >>> >>> this piece of code in src/newlib/stubs.c >>> >>> #if ELUA_PLATFORM == AVR32 >>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>> timezone *tzp ) >>> #else >>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>> #endif >>> >>> on my system, this #if check doesn't work properly and ends up going >>> through the first branch (i.e as if it's for AVR32 target) while i am using >>> the stm32 target. >>> this was causing my initial problem (my last post), and commenting out >>> all of the above lines except for the second branch (i.e int >>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>> build. >>> >>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>> build> works. I think just scons -c should work and clean everything up >>> >>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) into >>> a separate variable as opposed to hardcoding it in the platform py file >>> >>> Cheers >>> Alex >>> >>> >>> >>> >>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> Hi there >>>> >>>> I am an stm32 platform enthusiast and would love to make an easily >>>> script-able platform out of it. eLua seems to fit the bill except that i >>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>> even pre-compiled if needed, off an SD card. >>>> >>>> I had followed the toolchain building tutorial and built those >>>> successfully. But it seems to me that scons for the stm32 target uses >>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>> toolchain was used for this target. >>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>> on the following step: >>>> >>>> >>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>> src/newlib/stubs.o >>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>> error: previous declaration of '_gettimeofday_r' was here >>>> scons: *** [src/newlib/stubs.o] Error 1 >>>> scons: building terminated because of errors. >>>> >>>> >>>> from the way it looks, something is wrong with newlib. Are there any >>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>> wasn't compiled in a specific way that elua prescribes? >>>> >>>> would it be possible to just stick to the toolchain built as per >>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>> >>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>> projects >>>> >>>> Thanks >>>> Alex >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/02692583/attachment-0001.html |
|
|
Yes, Lanchon grafted the CS's implementation of newlib into his gcc
framework for stm32. See my recent post there on putting an effort forward towards coming up with reliable and easy to use framework that integrates *printf/*scanf and such (newlib) It is quite frustrating dealing with all these various linker scripts, makefile options - i just wanna write a darn program ;-). I mean the original (minimal) ld script in one of the first lanchon's gcc project framework is not so bad (i am a noob at level as low as linking) but his CS3 implementation (including newlib, etc) is a beast to comprehend, all these sections... So yea, it'd be nice to figure out, fix and standardize all that stuff so gcc/stm32 beginners wouldn't be hitting all these walls. This will make stm32 community grow. Alex On Tue, Dec 30, 2008 at 4:19 PM, Mike Panetta <panetta.mike at gmail.com>wrote: > Now that sounds like fun. :) Does it integrate with newlib at all? > > The main issue I had with the .fini junk is apparently there is more then > one way to interface to newlib, and its a mess... I did eventually fix it > by defining/overriding the correct function. I wonder if there would be a > use for a libgloss port or a generic stubs lib for newlib and stm32? > > Mike > > > On Tue, Dec 30, 2008 at 4:13 PM, Alex Babkin <ababkin at gmail.com> wrote: > >> Hi Mike >> >> Thanks for chiming in. >> Yea factoring out stuff - i was just throwing knee-jerk ideas around. Just >> because i wanted to try both toolchains on the stm32 port and was yukked out >> that i had to make same edit several times. >> >> Mike, i saw your post on codesourcery's forum about .fini section error. I >> found it as i was researching same error. >> Not sure if you're aware of the stm32 forum (on ST website) but that forum >> is pretty good and people like Lanchon are extremely helpful. >> Using his framework with modified linker scripts and such i've gotten >> infrastructure to work that supports printf/sprintf/fprintf (and similarly >> *scanf's) where fio functions use ChaN's tiny fat filesystem written for >> stm32. >> >> Alex >> >> >> On Tue, Dec 30, 2008 at 3:55 PM, Mike Panetta <panetta.mike at gmail.com>wrote: >> >>> You could remove the LCD module, that might trim some down I think. >>> >>> After reading this whole conversation, I am still not convinced of any >>> benefits of factoring out the toolchain prefix. I had thought about it >>> myself at one point for *all* the platforms, but decided against that one >>> too. Generally a single platform will always use the same compiler, >>> especially given a tested and proven compiler-platform combination, so >>> again, I do not clearly see the advantage. Maybe I need some enlightenment? >>> :) >>> >>> Mike >>> >>> On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> OK i've made some progress (for those curious or stuck, like myself) >>>> >>>> the size results look discouraging for my 128kb flash'ed chips: >>>> >>>> the binaries are 269kb for lualong and 308kb for lua targets (i used the >>>> way to use objcopy to generate binaries from the stm32 example conf.py). And >>>> that's with all the newest source, about 50k larger using arm-none-eabi- >>>> binary toolchain off of CS's site. >>>> >>>> is there still a chance to shove it into 128kb/20k chip? >>>> >>>> EDIT: i've tried excluding the options like terminal and romfs and got >>>> the size down to 233k for lualong >>>> >>>> some things to fix: (not complaining but pointing out potential >>>> improvements ;-) ) >>>> 1. >>>> >>>> this piece of code in src/newlib/stubs.c >>>> >>>> #if ELUA_PLATFORM == AVR32 >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>>> timezone *tzp ) >>>> #else >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>>> #endif >>>> >>>> on my system, this #if check doesn't work properly and ends up going >>>> through the first branch (i.e as if it's for AVR32 target) while i am using >>>> the stm32 target. >>>> this was causing my initial problem (my last post), and commenting out >>>> all of the above lines except for the second branch (i.e int >>>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>>> build. >>>> >>>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>>> build> works. I think just scons -c should work and clean everything up >>>> >>>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) >>>> into a separate variable as opposed to hardcoding it in the platform py file >>>> >>>> Cheers >>>> Alex >>>> >>>> >>>> >>>> >>>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com>wrote: >>>> >>>>> Hi there >>>>> >>>>> I am an stm32 platform enthusiast and would love to make an easily >>>>> script-able platform out of it. eLua seems to fit the bill except that i >>>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>>> even pre-compiled if needed, off an SD card. >>>>> >>>>> I had followed the toolchain building tutorial and built those >>>>> successfully. But it seems to me that scons for the stm32 target uses >>>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>>> toolchain was used for this target. >>>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>>> on the following step: >>>>> >>>>> >>>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>>> src/newlib/stubs.o >>>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>>> error: previous declaration of '_gettimeofday_r' was here >>>>> scons: *** [src/newlib/stubs.o] Error 1 >>>>> scons: building terminated because of errors. >>>>> >>>>> >>>>> from the way it looks, something is wrong with newlib. Are there any >>>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>>> wasn't compiled in a specific way that elua prescribes? >>>>> >>>>> would it be possible to just stick to the toolchain built as per >>>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>>> >>>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>>> projects >>>>> >>>>> Thanks >>>>> Alex >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Elua-dev mailing list >>>> Elua-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/ae6dc4d4/attachment.html |
|
|
Hello List,
Alex and Mike, thank you for having this discussion here. STM32 is a great platform for eLua and it seems that, with you help, we will soon have an "official" toolchain for it. Best Dado On Tue, Dec 30, 2008 at 19:43, Alex Babkin <ababkin at gmail.com> wrote: > Yes, Lanchon grafted the CS's implementation of newlib into his gcc > framework for stm32. See my recent post there on putting an effort forward > towards coming up with reliable and easy to use framework that integrates > *printf/*scanf and such (newlib) > > It is quite frustrating dealing with all these various linker scripts, > makefile options - i just wanna write a darn program ;-). I mean the > original (minimal) ld script in one of the first lanchon's gcc project > framework is not so bad (i am a noob at level as low as linking) but his CS3 > implementation (including newlib, etc) is a beast to comprehend, all these > sections... > > So yea, it'd be nice to figure out, fix and standardize all that stuff so > gcc/stm32 beginners wouldn't be hitting all these walls. This will make > stm32 community grow. > > Alex > > > On Tue, Dec 30, 2008 at 4:19 PM, Mike Panetta <panetta.mike at gmail.com>wrote: > >> Now that sounds like fun. :) Does it integrate with newlib at all? >> >> The main issue I had with the .fini junk is apparently there is more then >> one way to interface to newlib, and its a mess... I did eventually fix it >> by defining/overriding the correct function. I wonder if there would be a >> use for a libgloss port or a generic stubs lib for newlib and stm32? >> >> Mike >> >> >> On Tue, Dec 30, 2008 at 4:13 PM, Alex Babkin <ababkin at gmail.com> wrote: >> >>> Hi Mike >>> >>> Thanks for chiming in. >>> Yea factoring out stuff - i was just throwing knee-jerk ideas around. >>> Just because i wanted to try both toolchains on the stm32 port and was >>> yukked out that i had to make same edit several times. >>> >>> Mike, i saw your post on codesourcery's forum about .fini section error. >>> I found it as i was researching same error. >>> Not sure if you're aware of the stm32 forum (on ST website) but that >>> forum is pretty good and people like Lanchon are extremely helpful. >>> Using his framework with modified linker scripts and such i've gotten >>> infrastructure to work that supports printf/sprintf/fprintf (and similarly >>> *scanf's) where fio functions use ChaN's tiny fat filesystem written for >>> stm32. >>> >>> Alex >>> >>> >>> On Tue, Dec 30, 2008 at 3:55 PM, Mike Panetta <panetta.mike at gmail.com>wrote: >>> >>>> You could remove the LCD module, that might trim some down I think. >>>> >>>> After reading this whole conversation, I am still not convinced of any >>>> benefits of factoring out the toolchain prefix. I had thought about it >>>> myself at one point for *all* the platforms, but decided against that one >>>> too. Generally a single platform will always use the same compiler, >>>> especially given a tested and proven compiler-platform combination, so >>>> again, I do not clearly see the advantage. Maybe I need some enlightenment? >>>> :) >>>> >>>> Mike >>>> >>>> On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: >>>> >>>>> OK i've made some progress (for those curious or stuck, like myself) >>>>> >>>>> the size results look discouraging for my 128kb flash'ed chips: >>>>> >>>>> the binaries are 269kb for lualong and 308kb for lua targets (i used >>>>> the way to use objcopy to generate binaries from the stm32 example conf.py). >>>>> And that's with all the newest source, about 50k larger using arm-none-eabi- >>>>> binary toolchain off of CS's site. >>>>> >>>>> is there still a chance to shove it into 128kb/20k chip? >>>>> >>>>> EDIT: i've tried excluding the options like terminal and romfs and got >>>>> the size down to 233k for lualong >>>>> >>>>> some things to fix: (not complaining but pointing out potential >>>>> improvements ;-) ) >>>>> 1. >>>>> >>>>> this piece of code in src/newlib/stubs.c >>>>> >>>>> #if ELUA_PLATFORM == AVR32 >>>>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>>>> timezone *tzp ) >>>>> #else >>>>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>>>> #endif >>>>> >>>>> on my system, this #if check doesn't work properly and ends up going >>>>> through the first branch (i.e as if it's for AVR32 target) while i am using >>>>> the stm32 target. >>>>> this was causing my initial problem (my last post), and commenting out >>>>> all of the above lines except for the second branch (i.e int >>>>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>>>> build. >>>>> >>>>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>>>> build> works. I think just scons -c should work and clean everything up >>>>> >>>>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) >>>>> into a separate variable as opposed to hardcoding it in the platform py file >>>>> >>>>> Cheers >>>>> Alex >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com>wrote: >>>>> >>>>>> Hi there >>>>>> >>>>>> I am an stm32 platform enthusiast and would love to make an easily >>>>>> script-able platform out of it. eLua seems to fit the bill except that i >>>>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>>>> even pre-compiled if needed, off an SD card. >>>>>> >>>>>> I had followed the toolchain building tutorial and built those >>>>>> successfully. But it seems to me that scons for the stm32 target uses >>>>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>>>> toolchain was used for this target. >>>>>> I have tried to build the elua for the stm32f103ze target and it >>>>>> breaks on the following step: >>>>>> >>>>>> >>>>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>>>> src/newlib/stubs.o >>>>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>>>> error: previous declaration of '_gettimeofday_r' was here >>>>>> scons: *** [src/newlib/stubs.o] Error 1 >>>>>> scons: building terminated because of errors. >>>>>> >>>>>> >>>>>> from the way it looks, something is wrong with newlib. Are there any >>>>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>>>> wasn't compiled in a specific way that elua prescribes? >>>>>> >>>>>> would it be possible to just stick to the toolchain built as per >>>>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>>>> >>>>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>>>> projects >>>>>> >>>>>> Thanks >>>>>> Alex >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Elua-dev mailing list >>>>> Elua-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Elua-dev mailing list >>>> Elua-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/b6495d05/attachment-0001.html |
|
|
In reply to this post by Mike Panetta
On Tue, Dec 30, 2008 at 11:19 PM, Mike Panetta <panetta.mike at gmail.com>wrote:
> Now that sounds like fun. :) Does it integrate with newlib at all? > > The main issue I had with the .fini junk is apparently there is more then > one way to interface to newlib, and its a mess... I did eventually fix it > by defining/overriding the correct function. I wonder if there would be a > use for a libgloss port or a generic stubs lib for newlib and stm32? I don't know of any libgloss for stm32, but FYI, the way I'm going with this is to give eLua its very own libc. It will be derived from Minix's libc, and will be kept as small as possible, without sacrifing functionality. I already started working on this on a separate branch, but it will be quite a while until I manage to complete it. Best, Bogdan > On Tue, Dec 30, 2008 at 4:13 PM, Alex Babkin <ababkin at gmail.com> wrote: > >> Hi Mike >> >> Thanks for chiming in. >> Yea factoring out stuff - i was just throwing knee-jerk ideas around. Just >> because i wanted to try both toolchains on the stm32 port and was yukked out >> that i had to make same edit several times. >> >> Mike, i saw your post on codesourcery's forum about .fini section error. I >> found it as i was researching same error. >> Not sure if you're aware of the stm32 forum (on ST website) but that forum >> is pretty good and people like Lanchon are extremely helpful. >> Using his framework with modified linker scripts and such i've gotten >> infrastructure to work that supports printf/sprintf/fprintf (and similarly >> *scanf's) where fio functions use ChaN's tiny fat filesystem written for >> stm32. >> >> Alex >> >> >> On Tue, Dec 30, 2008 at 3:55 PM, Mike Panetta <panetta.mike at gmail.com>wrote: >> >>> You could remove the LCD module, that might trim some down I think. >>> >>> After reading this whole conversation, I am still not convinced of any >>> benefits of factoring out the toolchain prefix. I had thought about it >>> myself at one point for *all* the platforms, but decided against that one >>> too. Generally a single platform will always use the same compiler, >>> especially given a tested and proven compiler-platform combination, so >>> again, I do not clearly see the advantage. Maybe I need some enlightenment? >>> :) >>> >>> Mike >>> >>> On Sat, Dec 27, 2008 at 1:03 AM, Alex Babkin <ababkin at gmail.com> wrote: >>> >>>> OK i've made some progress (for those curious or stuck, like myself) >>>> >>>> the size results look discouraging for my 128kb flash'ed chips: >>>> >>>> the binaries are 269kb for lualong and 308kb for lua targets (i used the >>>> way to use objcopy to generate binaries from the stm32 example conf.py). And >>>> that's with all the newest source, about 50k larger using arm-none-eabi- >>>> binary toolchain off of CS's site. >>>> >>>> is there still a chance to shove it into 128kb/20k chip? >>>> >>>> EDIT: i've tried excluding the options like terminal and romfs and got >>>> the size down to 233k for lualong >>>> >>>> some things to fix: (not complaining but pointing out potential >>>> improvements ;-) ) >>>> 1. >>>> >>>> this piece of code in src/newlib/stubs.c >>>> >>>> #if ELUA_PLATFORM == AVR32 >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tp, struct >>>> timezone *tzp ) >>>> #else >>>> int _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz ) >>>> #endif >>>> >>>> on my system, this #if check doesn't work properly and ends up going >>>> through the first branch (i.e as if it's for AVR32 target) while i am using >>>> the stm32 target. >>>> this was causing my initial problem (my last post), and commenting out >>>> all of the above lines except for the second branch (i.e int >>>> _gettimeofday_r( struct _reent *r, struct timeval *tv, void *tz )) made it >>>> build. >>>> >>>> 2. scons -c doesn't work, but scons -c <all the required parameters for >>>> build> works. I think just scons -c should work and clean everything up >>>> >>>> 3. factor out the toolchain prefix (like arm-elf- or arm-none-eabi-) >>>> into a separate variable as opposed to hardcoding it in the platform py file >>>> >>>> Cheers >>>> Alex >>>> >>>> >>>> >>>> >>>> On Fri, Dec 26, 2008 at 11:39 PM, Alex Babkin <ababkin at gmail.com>wrote: >>>> >>>>> Hi there >>>>> >>>>> I am an stm32 platform enthusiast and would love to make an easily >>>>> script-able platform out of it. eLua seems to fit the bill except that i >>>>> really hope that 128kb of flash and 20kb of ram (that the stm32 chips i am >>>>> using have) would be enough (even if barely) to be able to run lua scripts, >>>>> even pre-compiled if needed, off an SD card. >>>>> >>>>> I had followed the toolchain building tutorial and built those >>>>> successfully. But it seems to me that scons for the stm32 target uses >>>>> arm-none-eabi prefix for toolchain. I suspect that the CodeSourcery's >>>>> toolchain was used for this target. >>>>> I have tried to build the elua for the stm32f103ze target and it breaks >>>>> on the following step: >>>>> >>>>> >>>>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mlittle-endian -Os >>>>> -fomit-frame-pointer -Iinc -Iinc/newlib -Isrc/lua -Isrc/modules >>>>> -Isrc/platform/stm32 -Isrc/uip -Isrc/platform/stm32/FWLib/library/inc >>>>> -ffunction-sections -fdata-sections -fno-strict-aliasing >>>>> -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 >>>>> -D__BUFSIZ__=128 -DLUA_NUMBER_INTEGRAL -Dgcc -Wall -c src/newlib/stubs.c -o >>>>> src/newlib/stubs.o >>>>> src/newlib/stubs.c:311: error: conflicting types for '_gettimeofday_r' >>>>> /usr/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/include/reent.h:84: >>>>> error: previous declaration of '_gettimeofday_r' was here >>>>> scons: *** [src/newlib/stubs.o] Error 1 >>>>> scons: building terminated because of errors. >>>>> >>>>> >>>>> from the way it looks, something is wrong with newlib. Are there any >>>>> suggestions as to how i go about fixing it? Is this happening because libnew >>>>> wasn't compiled in a specific way that elua prescribes? >>>>> >>>>> would it be possible to just stick to the toolchain built as per >>>>> instructions on elua site? or CS's toolchain is really necessary for stm32? >>>>> >>>>> btw, i am normally using CS's toolchain (binaries) for all my stm32 >>>>> projects >>>>> >>>>> Thanks >>>>> Alex >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Elua-dev mailing list >>>> Elua-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090102/b199eaf6/attachment.html |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |