Re: eLua STM32 support and general questions

[lua-2]

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

I'm not at all familiar with Crossworks or the MCBSTM32E, so I don't know what to tell you. In theory, an elf file should work no matter how you upload it to the board. I couldn't find a schematic of the forementioned board, so please check a few things:

- what is the code of the CPU on your board? It must match a CPU famility with 512k flash/64k RAM, check for details here : http://www.st.com/mcu/inchtml-pages-stm32.html
- are you indeed connecting to UART0 ? (check the schematic)
- on your terminal program, is the serial port setup at 115200, 8 data bits, no parity bits, one stop bit?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:25 AM, <[hidden email]> wrote:

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[lua-2]

After playing around with platform_conf.h, I attached wrong version.
#define BUILD_CON_GENERIC is included so it looks like:

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

This looks fine, I don't think the problem is here.
Hmmmm. Come to think of it, I never really uploaded an elf to a board before. Just binary or hex file that I get from the elf after running objcopy on it. I don't know how the elf uploader in Crossworks works. Do you have an option to specify what sections you can upload, or something similar?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:34 AM, <[hidden email]> wrote:

After playing around with platform_conf.h, I attached wrong version.
#define BUILD_CON_GENERIC is included so it looks like:

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[lua-2]

Hi Bogdan,

checking the schematics regarding the really used UART was the hint I needed.
I think it's a good idea to set CON_UART_ID to 1, if it is build for board=STM3210E-EVAL.

Best Regards,
Joerg

Hi,

I'm not at all familiar with Crossworks or the MCBSTM32E, so I don't know what to tell you. In theory, an elf file should work no matter how you upload it to the board. I couldn't find a schematic of the forementioned board, so please check a few things:

- what is the code of the CPU on your board? It must match a CPU famility with 512k flash/64k RAM, check for details here : http://www.st.com/mcu/inchtml-pages-stm32.html
- are you indeed connecting to UART0 ? (check the schematic)
- on your terminal program, is the serial port setup at 115200, 8 data bits, no parity bits, one stop bit?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:25 AM, <[hidden email]> wrote:

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Jul 15, 2009 at 12:36 PM, <[hidden email]> wrote:

Hi Bogdan,

checking the schematics regarding the really used UART was the hint I needed.
I think it's a good idea to set CON_UART_ID to 1, if it is build for board=STM3210E-EVAL.

It's a matter of numbering, really. Although CON_UART_ID is set to 0 in platform_conf.h, the chip itself starts numbering its USART interfaces from 1, so CON_UART_ID 0 actually maps to USART1 in the code. You're probably using USART2 since setting CON_UART_ID to 1 did the trick for you. I don't think this is the case for the STM3210E-EVAL board, though. The corect way to handle this is to add a new board for the stm32 platform (in your case MCBSTM32E) and set CON_UART_ID to 1 only for this board. If you'd like to know how to add a new board to eLua, check this link:

http://elua.berlios.de/beta/en/arch_newport.html

In any case, I'm glad it's working for you now :)

Best,
Bogdan

Hi,

I'm not at all familiar with Crossworks or the MCBSTM32E, so I don't know what to tell you. In theory, an elf file should work no matter how you upload it to the board. I couldn't find a schematic of the forementioned board, so please check a few things:

- what is the code of the CPU on your board? It must match a CPU famility with 512k flash/64k RAM, check for details here : http://www.st.com/mcu/inchtml-pages-stm32.html
- are you indeed connecting to UART0 ? (check the schematic)
- on your terminal program, is the serial port setup at 115200, 8 data bits, no parity bits, one stop bit?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:25 AM, <[hidden email]> wrote:

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[lua-2]

Hi,

I didn't realize that the board from Keil is not the same as the board from ST.

The board does not use the "real" UART. The UART is done via GPIO and ST3232.
Numbering is given by platform.c:
static const u16 usart_gpio_rx_pin[] = { GPIO_Pin_10, GPIO_Pin_3, ... };
static const u16 usart_gpio_tx_pin[] = { GPIO_Pin_9, GPIO_Pin_2, ... };

First scripts ('hello', 'led,' ...) are also working. :-)

Best Regards,
Joerg

On Wed, Jul 15, 2009 at 12:36 PM, <[hidden email]> wrote:

Hi Bogdan,

checking the schematics regarding the really used UART was the hint I needed.
I think it's a good idea to set CON_UART_ID to 1, if it is build for board=STM3210E-EVAL.

It's a matter of numbering, really. Although CON_UART_ID is set to 0 in platform_conf.h, the chip itself starts numbering its USART interfaces from 1, so CON_UART_ID 0 actually maps to USART1 in the code. You're probably using USART2 since setting CON_UART_ID to 1 did the trick for you. I don't think this is the case for the STM3210E-EVAL board, though. The corect way to handle this is to add a new board for the stm32 platform (in your case MCBSTM32E) and set CON_UART_ID to 1 only for this board. If you'd like to know how to add a new board to eLua, check this link:

http://elua.berlios.de/beta/en/arch_newport.html

In any case, I'm glad it's working for you now :)

Best,
Bogdan

Hi,

I'm not at all familiar with Crossworks or the MCBSTM32E, so I don't know what to tell you. In theory, an elf file should work no matter how you upload it to the board. I couldn't find a schematic of the forementioned board, so please check a few things:

- what is the code of the CPU on your board? It must match a CPU famility with 512k flash/64k RAM, check for details here : http://www.st.com/mcu/inchtml-pages-stm32.html
- are you indeed connecting to UART0 ? (check the schematic)
- on your terminal program, is the serial port setup at 115200, 8 data bits, no parity bits, one stop bit?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:25 AM, <[hidden email]> wrote:

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Jul 15, 2009 at 2:39 PM, <[hidden email]> wrote:

Hi,

I didn't realize that the board from Keil is not the same as the board from ST.

Frankly, the only thing I know about the board from Keil is its name :) 

The board does not use the "real" UART. The UART is done via GPIO and ST3232.
Numbering is given by platform.c:
static const u16 usart_gpio_rx_pin[] = { GPIO_Pin_10, GPIO_Pin_3, ... };
static const u16 usart_gpio_tx_pin[] = { GPIO_Pin_9, GPIO_Pin_2, ... };

Actually, the board uses real UART (or so I assume, it would be very strange not to do so), what's listed in platform.c is just the I/O assignment of the UART pins (which is dynamic in the case of the STM32, which means that you can assign the RX/TX line of USART1 (for example) to a number of different pins, not just GPIO_Pin_10/GPIO_Pin_9). Consult the datasheet for more details. Of course, if you change the USART I/O assignment you'd also need to change your PCB :)
 

First scripts ('hello', 'led,' ...) are also working. :-)

Getting there quickly, I see :) Keep up the good work!

Best,
Bogdan
 

On Wed, Jul 15, 2009 at 12:36 PM, <[hidden email]> wrote:

Hi Bogdan,

checking the schematics regarding the really used UART was the hint I needed.
I think it's a good idea to set CON_UART_ID to 1, if it is build for board=STM3210E-EVAL.

It's a matter of numbering, really. Although CON_UART_ID is set to 0 in platform_conf.h, the chip itself starts numbering its USART interfaces from 1, so CON_UART_ID 0 actually maps to USART1 in the code. You're probably using USART2 since setting CON_UART_ID to 1 did the trick for you. I don't think this is the case for the STM3210E-EVAL board, though. The corect way to handle this is to add a new board for the stm32 platform (in your case MCBSTM32E) and set CON_UART_ID to 1 only for this board. If you'd like to know how to add a new board to eLua, check this link:

http://elua.berlios.de/beta/en/arch_newport.html

In any case, I'm glad it's working for you now :)

Best,
Bogdan

Hi,

I'm not at all familiar with Crossworks or the MCBSTM32E, so I don't know what to tell you. In theory, an elf file should work no matter how you upload it to the board. I couldn't find a schematic of the forementioned board, so please check a few things:

- what is the code of the CPU on your board? It must match a CPU famility with 512k flash/64k RAM, check for details here : http://www.st.com/mcu/inchtml-pages-stm32.html
- are you indeed connecting to UART0 ? (check the schematic)
- on your terminal program, is the serial port setup at 115200, 8 data bits, no parity bits, one stop bit?

Best,
Bogdan

On Wed, Jul 15, 2009 at 10:25 AM, <[hidden email]> wrote:

Hi,

in the meantime I got an Eval-Board (MCBSTM32E). I've downloaded the elf-file to the board with Crossworks environment (JTAG<->USB CrossConnect). I guess it works, but I'm not 100% sure on that.
Now I expected something happens at serial interface after rebooting the device.
But nothing happens. Do you have any idea? As I'm not familiar with this board, it might be the case that I've done stupid beginner's mistake(s).

My platform_conf.h:

// ******************************************************
// Define here what components you want for this platform

#define BUILD_XMODEM
#define BUILD_SHELL
#define BUILD_ROMFS
#define BUILD_TERM
//#define BUILD_UIP
//#define BUILD_DHCPC
//#define BUILD_DNS
//#define BUILD_CON_GENERIC
#define BUILD_ADC
//#define BUILD_CON_TCP

// **************************************************
// UART/Timer IDs configuration data (used in main.c)

#define CON_UART_ID           0
#define CON_UART_SPEED        115200
#define CON_TIMER_ID          0
#define TERM_LINES            25
#define TERM_COLS             80

The only jumper on board, which is set is J3 - to enable the speaker.

Best Regards,
Joerg

Hi Bogdan,

you're right there was something wrong in one (or more) of the previous steps.
After performing them all once again, everything works fine.
I've just created an elua_lua_stm32f103ze.elf :-)

Unfortunatelly I've no Eval-Board on my desk, to test.

Best Regards,
Joerg

You're right, I misunderstood you, sorry about that. Still, the problem is the same: the last step of the GCC build is using "gcc" instead of "arm-elf-gcc", which means that it can't find arm-elf-gcc. Are you sure it is in your $PATH? Are you sure that all the "make install"s up to this point completed succesfully? If so, I don't really know what the problem is. The same advice holds here though: try with a precompiled toolchain if this doesn't work. CodeSourcery has versions for both Windows and Linux.

Best,
Bogdan

On Fri, May 29, 2009 at 12:21 PM, <[hidden email]> wrote:

Hi Bogdan,

thanks for your fast answer and sorry for german output.
I set LANG=C and did the same step again.

I guess you missunderstood me. The output was created in Linux environment.
After everything works fine on Linux I will try it again with Windows.

So, here's the english output:

 make CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb" LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all

make[1]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Entering directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'

if [ x"" != x ]; then \
      gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   ../../libiberty/regex.c -o pic/regex.o; \
    else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

cc1: error: unrecognized command line option "-mthumb"
../../libiberty/regex.c:1: error: bad value (cortex-m3) for -mtune= switch
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Error 2

Hi,

I don't speak German at all, so I don't really understand what that error means, but something got screwed up in your gcc's "configure" step, since it's trying to use regular "gcc" instead of "arm-elf-gcc" as it should. I don't know the cause of this error, unfortunately, as I never tried to compile the toolchain on Windows.
May I suggest downloading a precompiled toolchain (like CodeSourcery's freeware ARM toolchain) and working with that? eLua has support for using this toolchain, details here:

http://elua.berlios.de/beta/en/building.html

Best,
Bogdan

On Fri, May 29, 2009 at 11:57 AM, <[hidden email]> wrote:

Hi,

I have tried to build eLau in my Windows Crossworks environment.
After some trouble I tried to use the "standard" way described in your doc.

The last step ("Step4: full GCC") leads into the following error message:

jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$ make
CFLAGS="-mcpu=cortex-m3 -mthumb" CXXFLAGS="-mcpu=cortex-m3 -mthumb"
LIBCXXFLAGS="-mcpu=cortex-m3 -mthumb" all
make[1]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make[2]: Betrete Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o pic/regex.o;
\
else true; fi
gcc -c -DHAVE_CONFIG_H -mcpu=cortex-m3 -mthumb -I.
-I../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic ../../libiberty/regex.c -o regex.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1: Fehler: nicht erkannte Kommandozeilenoption »-mthumb«
../../libiberty/regex.c:1: Fehler: Falscher Wert (cortex-m3) für
Schalter -mtune=
make[2]: *** [regex.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build/libiberty'
make[1]: *** [all-libiberty] Fehler 2
make[1]: Verlasse Verzeichnis
'/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build'
make: *** [all] Fehler 2
jars@jars-desktop:/mnt/hgfs/shared/ARM_toolchain/gcc-4.3.3/build$

It sounds like there's a problem with parameter -mcpu and -mthumb.

I use the same version as your doc describes.
binutils-2.19.50
gcc-4.3.3
newlib-1.17.0

Any idea?

Best Regards
Joerg

Hi, First idea was to write a small script language on my own, but after some research, I decided to try Lua - even if it is much more powerful than my needs. I tried to get Lua 5.1.4 running, but it was not that easy as I thought. Main problem was the need for a filesystem, which is not avaialble. It should be possible to make Lua run without a file system, although I didn't try this myself (you can try searching for this on the Lua list). It's true though that you should modify the code, or at least provide a "dummy" buffered I/O library tailored to your needs. eLua seems to solve my problem, and even more I got a filesystem, terminal mode, and more. I haven't checked eLua until now, because I'm not sure if this is the right direction. I get more than I need, which have to be paid with ROM. eLua is highly configurable, in most cases you can specify what you want to be built into your image and what you don't. eLua without terminal mode, for example, is as easy as not defining BUILD_TERM in your platform's platform_conf.h file. Other components are equally easy to remove.   Do you think Lua | eLua is the right thing to put a small script language to a limited device? eLua is quite OK for this configuration, as it was built with this kind of requirements in mind. You might also try some variant of Forth (which is a completely different language though) or PyMite (http://pymite.python-hosting.com/).  Lua is also probably good enough for you, as long as you can figure your filesystem dependency problem. Compared to Lua though, eLua is optimized for usage on small devices, including (important) memory allocation tunings and a patch called LTR (Lua Tiny RAM) that can have an important impact on your RAM usage.   Do I have to use eLua (which is under GPL/BSD license)? Or should it be even possible to use "plain" Lua (which offers more flexible MIT license)? eLua is MIT at this point, although this isn't specified in the license file. We are planning to make the official announcement to MIT starting with the next release, but you can use the code as you want even now. If you need it, I'll change the LICENSE file right away.   As I wrote, I neither need a FS, GUI nor a terminal mode. Lua scripts are written to the device with a proprietary mechanism. Maximum length of Lua script is ~250 lines. At the end each LOC is stored in one separate string. The upcoming documentation for 0.6, although not 100% complete, contains a lot of information about eLua in general and about how to configure its components at compile time it in particular. It also contains information about the LTR patch and other important parts of eLua. I'll upload it to a temporary location today when I have some time and then come back to the list with the link, maybe this will be help. Best, Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev