interested in stm32 port

classic Classic list List threaded Threaded
16 messages Options
Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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 

Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/e22a4e17/attachment.html 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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 

Dado Sutter Dado Sutter
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/9fbfc833/attachment.html 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/92e2151c/attachment-0001.html 

Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/00ad79ac/attachment.html 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/6185b5d4/attachment-0001.html 

Dado Sutter-2 Dado Sutter-2
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/6a0109f9/attachment.html 

Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/4b863908/attachment-0001.html 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081227/34033b5e/attachment.html 

Mike Panetta Mike Panetta
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/427c3fec/attachment.html 

Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/5bd5a5ec/attachment.html 

Mike Panetta Mike Panetta
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/02692583/attachment-0001.html 

Alex Babkin Alex Babkin
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/ae6dc4d4/attachment.html 

Dado Sutter Dado Sutter
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081230/b6495d05/attachment-0001.html 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

interested in stm32 port

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090102/b199eaf6/attachment.html