Very nice introduction to what promisses to be one of the best eLua platforms of 2010 !

All the generic examples of eLua are running fine on the mbed already.

eLua VFD (Vacuum Fluorescent Tube) control has also been sucessfully tested on the mbed board. The control module source code, as well as some example aplications, can be found at the eLuaVFD section of the eLuaExamples repo at Google Code.

Congrats for the great work with the port!

Dado

 

 

Excellent demo. Many thanks for sharing this. I look to many long hours experimenting with the mbed LUA port.

Dave

James, which "flavor" of the GNU tool chain do you use to compile eLua for the LPC1768? WinARM, CodeSourcery, etc.? I have licenses for CodeSourcry Standard and Rowley's suported GNU tool chains. I haven't download the source yet, but assum it is in Makefile form? Just lloking for some advice ot where to start. Also do you prefer to be contact in this form or on the eLua site form (or not at all)?

Thanks,

Dave

Awesome.

I had heard of Lua but never really looked at it.  Followed the instructions above and all worked flawlessly.
I even wrote a few noddy scripts and ran them on my mbed.  I look forward to using lua more in the future.

Thanks for all the effort and keep up the good work
Hugh

 

David Comer wrote:

James, which "flavor" of the GNU tool chain do you use to compile eLua for the LPC1768? WinARM, CodeSourcery, etc.? I have licenses for CodeSourcry Standard and Rowley's suported GNU tool chains. I haven't download the source yet, but assum it is in Makefile form? Just lloking for some advice ot where to start. Also do you prefer to be contact in this form or on the eLua site form (or not at all)?

Thanks,

Dave

I'm personally using a special build of the CodeSourcery chain on a Mac ( http://github.com/jsnyder/arm-eabi-toolchain ). If you're on Windows or Linux, the normal CodeSourcery chain should work.  Or, use the instructions on the eLua site for building a toolchain (ARM ELF, non-EABI) for Cortex-M3 ( http://www.eluaproject.net/en_tc_cortex.html ).

We are suing SCons for our build system, so you will need Python and SCons: http://www.eluaproject.net/en_building.html

As far as appropriate venues, I would say that mbed specific eLua discussion could go on here.  If it's more generic to eLua, or if the mbed specific stuff tends to overgrow the comment system here, I'd suggest the main eLua list.

Side note: depending on which GCC toolchain you use, and version of libraries, there may be some more modifications needed to the linker script to work with every gcc toolchain.  AFAIK, it should work with the versions described in the first part of this reply.

James Snyder wrote:

 onally using a special build of the CodeSourcery chain on a Mac ( http://github.com/jsnyder/arm-eabi-toolchain ). If you're on Windows or Linux, the normal CodeSourcery chain should work.  Or, use the instructions on the eLua site for building a toolchain (ARM ELF, non-EABI) for Cortex-M3 ( http://www.eluaproject.net/en_tc_cortex.html ).

We are suing SCons for our build system, so you will need Python and SCons: http://www.eluaproject.net/en_building.html

As far as appropriate venues, I would say that mbed specific eLua discussion could go on here.  If it's more generic to eLua, or if the mbed specific stuff tends to overgrow the comment system here, I'd suggest the main eLua list.

Side note: depending on which GCC toolchain you use, and version of libraries, there may be some more modifications needed to the linker script to work with every gcc toolchain.  AFAIK, it should work with the versions described in the first part of this reply.

Thanks James.I installed SVN (Tortoise SVN), checked out the latest code, and after poking around a bit last night seem to have my berings. I'll see how far I can get with the compilation. I plan on starting with the "Standard" EABI version of CodeSourcery. I have the option of using the Codesourcery proprietary library or the GNU so it sounds as if the GNU library is probably the way to go with LUA. Have to look into SCons and Pyton next.

Dave

 

David Comer wrote:

Thanks James.I installed SVN (Tortoise SVN), checked out the latest code, and after poking around a bit last night seem to have my berings. I'll see how far I can get with the compilation. I plan on starting with the "Standard" EABI version of CodeSourcery. I have the option of using the Codesourcery proprietary library or the GNU so it sounds as if the GNU library is probably the way to go with LUA. Have to look into SCons and Pyton next.

Dave

We do have a page that has some suggestions for building on Windows here: http://www.eluaproject.net/en_building_win.html

Most of the developers are primarily using Linux or OS X (mostly Linux), but we do try to double-check things on windows with some frequency.

Also of note, for those who are less adventurous with putting together a toolchain: we are working on a web-based tool that will allow you to configure and build eLua with whatever scripts you want on the romfs.

Also, I'm planning on adding the ability to read/write on the built-in filesystem, and I think I know how I'm going to implement this, but I'm not sure how much trouble it might be, since it's done using the JTAG link with semihosting.

 

This. Is. Awesome.

Yes, it is possible to access the mbed filesystem using the raw semihosting calls, so running an actual lua txt file straight from the USB drive will definitely be possible. not only that, it'll make programming as simple as dragging on a binary and writing a .lua file in your favourite editor :)

To talk to the interface you can use semihosting functions; here is a summary of my implementation for reference (you can see the details of the __semihost intrinsic to understand what underlying SWI/BKPT instruction actually invokes the call):

 

// ARM Semihosting Commands
#define SYS_OPEN   (0x1)
#define SYS_CLOSE  (0x2)
#define SYS_WRITE  (0x5)
#define SYS_READ   (0x6)
#define SYS_ISTTY  (0x9)
#define SYS_SEEK   (0xa)
#define SYS_ENSURE (0xb)
#define SYS_FLEN   (0xc)

FILEHANDLE semihost_open(const char* name, int openmode) {
    uint32_t args[3];
    args[0] = (uint32_t)name;
    args[1] = (uint32_t)openmode;
    args[2] = (uint32_t)strlen(name);
    return __semihost(SYS_OPEN, args);
}

int semihost_close(FILEHANDLE fh) {
    return __semihost(SYS_CLOSE, &fh);
}

int semihost_write(FILEHANDLE fh, const unsigned char* buffer, unsigned int length, int mode) {
    uint32_t args[3];
    args[0] = (uint32_t)fh;
    args[1] = (uint32_t)buffer;
    args[2] = (uint32_t)length; 
    return __semihost(SYS_WRITE, args);
} 

int semihost_read(FILEHANDLE fh, unsigned char* buffer, unsigned int length, int mode) {
	uint32_t args[3];
    args[0] = (uint32_t)fh;
    args[1] = (uint32_t)buffer;
    args[2] = (uint32_t)length; 
    return __semihost(SYS_READ, args); 
}

int semihost_istty(FILEHANDLE fh) {
    return __semihost(SYS_ISTTY, &fh);
}

int semihost_seek(FILEHANDLE fh, long position) {
	uint32_t args[2];
    args[0] = (uint32_t)fh;
    args[1] = (uint32_t)position;
    return __semihost(SYS_SEEK, args);
}

int semihost_ensure(FILEHANDLE fh) {
	return __semihost(SYS_ENSURE, &fh);
}

long semihost_flen(FILEHANDLE fh) { 
	return __semihost(SYS_FLEN, &fh);
}

Simon

Lua?? Never heard of it... until now. It looks exciting! I had embedded Tcl on my wishlist - now having eLua option seems to be very good substitute (maybe even more streamlined than Tcl) in the area of dynamic languages on MBED.

I wanted to share my use cases for eLua on MBED:

1. eLua with C/C++ low-level routines. I want to write a "device driver" in C++, but make high-level applications in eLua. Should be straightforward from reading the eLua overview, but I will need to get to customizable build. Using eLua in mbed.org/compiler will be a big win for this use case.

2. eLua + HTTPServer. I want to call eLua from HTTP pages served over TCP/IP, even better pass query to and to serve dynamic pages returned from eLua scripts. It looks like eLua contains uIP, while MBED has a more full lwip implementation. Any roadmap towards lwip in eLua? Maybe it is possible to cross the two on MBED with custom main() implementation and few glue functions?

3. eLua with loadable libs. This will eliminate the need to recompile eLua binary to add new hardware functions.

I have warm feeling that all these can be achieved.

Ilya I wrote:

Lua?? Never heard of it... until now. It looks exciting! I had embedded Tcl on my wishlist - now having eLua option seems to be very good substitute (maybe even more streamlined than Tcl) in the area of dynamic languages on MBED.

Yep, you may want to check out the main lua website: http://www.lua.org/

Additionally, the lua-users wiki may be of interest: http://lua-users.org/

I wanted to share my use cases for eLua on MBED:

1. eLua with C/C++ low-level routines. I want to write a "device driver" in C++, but make high-level applications in eLua. Should be straightforward from reading the eLua overview, but I will need to get to customizable build. Using eLua in mbed.org/compiler will be a big win for this use case.

This is largely what we're aiming for with the project.  We have drivers and more expensive operations available through C routines and use the Lua API (which is quite easy to use, and not too complicated to get started with) to expose the functionality to Lua.

 

As far as building is concerned.  I made a partial port for the mbed compiler, but that's on hold at the moment because of the complexities involved in getting certain things working and because I'm not nearly as familiar with the ARM compiler and toolchain as I am with gcc/newlib.  We'll get it up and running at some point down the road.

The eLua project, itself, will also have a web-based building system for eLua that will allow users to roll their own build configurations and include lua scripts of their own.  I'm guessing there should be something public in the coming weeks.  It isn't designed for rolling in custom C/C++ code that isn't in the main project, but I suppose we could consider something like that for future versions.

2. eLua + HTTPServer. I want to call eLua from HTTP pages served over TCP/IP, even better pass query to and to serve dynamic pages returned from eLua scripts. It looks like eLua contains uIP, while MBED has a more full lwip implementation. Any roadmap towards lwip in eLua? Maybe it is possible to cross the two on MBED with custom main() implementation and few glue functions?

We currently have uIP included due to its lighter footprint (we also try and minimize memory usage as much as possible to provide maximum space for user scripts), but we could consider making it possible to switch between the two as a build option. I'd have to look more into the differences between the lwip and uip implementations to know how easy it might be to swap these.  If you have any use cases that differentiate the two, that would certainly make it more likely to happen.

If we were building with the mbed lib through the mbed online compiler it wouldn't be too hard to either use the mbed API under our net module, or to just create a platform-specific module that uses those functions.

3. eLua with loadable libs. This will eliminate the need to recompile eLua binary to add new hardware functions.

This is a planned feature, but we haven't yet done any sketching out of how it will work yet.  Certainly one can already have loadable Lua-based libraries (raw source or pre-compiled bytecode), but I suspect you're meaning binary C/C++ modules.

I have warm feeling that all these can be achieved.

I agree. Much of what you're interested in is planned. We're also always open to comments or contributions, both of which certainly have their ways of affecting what comes sooner or later on the roadmap :-)

Got mbed working with eLua! I've already worked with eLua in other platforms but mbed is just so fantastic!! =)

 

Best,

Fernando Araujo

 

Simon Ford wrote:

This. Is. Awesome.

Yes, it is possible to access the mbed filesystem using the raw semihosting calls, so running an actual lua txt file straight from the USB drive will definitely be possible. not only that, it'll make programming as simple as dragging on a binary and writing a .lua file in your favourite editor :)

To talk to the interface you can use semihosting functions; here is a summary of my implementation for reference (you can see the details of the __semihost intrinsic to understand what underlying SWI/BKPT instruction actually invokes the call):

Simon

Thanks!  Using that and some of the newlib syscall implementation that allow using this interface, I'm now able to read and write files from eLua!  I haven't tested it extensively yet to make sure seeking is working perfectly, but opening (interface stops offering mass storage over usb), closing (mass storage device comes back on usb), reading and writing seem to work without any problems. I'll post a binary once I've done a quick test on the seek functionality.

2 other questions:

1. It seems like I'm getting 8.3 filenames for reading and writing, with filenames getting capitalized automatically, and truncated if the name is too long.  Is there access to LFN versions of filenames, or is this planned?  If you're using FatFs it does have the capability for supporting longer filenames in recent versions, as well as an option to limit that length if one wants to keep down memory usage.

2. How do I go about getting a directory listing over this interface. From the ARM manual, it looks like there's a SYS_SYSTEM command that would allow for executing things like ls on the host side, although it looks like there might be some reserved semihosting commands on mbed for accomplishing this.  Would it be possible to get some pointers on how this works?

 

Could someone please give me an idea of how large of a program can be run on the mbed elua. I assume it gets loaded into ram and run? Thanks.

David Mayotte wrote:

Could someone please give me an idea of how large of a program can be run on the mbed elua. I assume it gets loaded into ram and run? Thanks.

It's difficult to give an exact answer because it's certainly dependent on the memory usage of the program that will be running.  The program does get loaded into RAM and then run, so currently you'll have the overhead of the bytecode in the VM for sure (programs can be run from raw source or bytecode, and precompiling will certainly save you some SRAM).  If you want some examples of things that currently have no trouble running on devices with similar amounts of memory to the mbed, check out some of the examples in our romfs directory in the repository (not all of these will run on the mbed, some require things like an OLED display):

http://svn.berlios.de/wsvn/elua/trunk/romfs/#_trunk_romfs_

There are a few games in there, many of which require an attached OLED display, but

Our startup overhead is a fair bit lower than a standard Lua implementation because we have a lot of the built-in modules on read-only tables, which can be used from flash. This gets us down to about 5-6kB of objects in the VM at startup: http://www.eluaproject.net/en_arch_ltr.html

We also have an emergency garbage collection patch integrated which allows us to run a GC cycle when object allocation fails: http://www.eluaproject.net/en_elua_egc.html (I believe I've set the mbed port to run gc on alloc failure by default).

I know that's all a bit indirect as far as giving exact quantifications, but our overall goal is to keep memory usage by our modules and external C code as low as possible to provide as much space in the VM for user code.  Lua types have overheads, but they're not too bad.  I believe that the data here on this wiki should be correct for eLua as well: http://www.wowwiki.com/Lua_object_memory_sizes

 

 

 

Hi James,

James Snyder wrote:
It seems like I'm getting 8.3 filenames for reading and writing, with filenames getting capitalized automatically, and truncated if the name is too long.  Is there access to LFN versions of filenames, or is this planned?  If you're using FatFs it does have the capability for supporting longer filenames in recent versions, as well as an option to limit that length if one wants to keep down memory usage.

Yes, the mbed interface only supports 8.3 filenames as I believe you need a license to support LFNs unfortunately. We don't use FatFS; the interface was built using Keil RTX and RL-ARM libraries.

James Snyder wrote:
How do I go about getting a directory listing over this interface.

This is an unofficial interface at the moment (as is everything in this thread for now!), but as you asked nicely:

typedef struct {
    unsigned char  hr;   /* Hours    [0..23]                  */
    unsigned char  min;  /* Minutes  [0..59]                  */
    unsigned char  sec;  /* Seconds  [0..59]                  */
    unsigned char  day;  /* Day      [1..31]                  */
    unsigned char  mon;  /* Month    [1..12]                  */
    unsigned short year; /* Year     [1980..2107]             */
} FTIME;

typedef struct {         /* File Search info record           */
    char  name[32];      /* File name                         */
    long  size;          /* File size in bytes                */
    int   fileID;        /* System File Identification        */
    FTIME create_time;   /* Date & time file was created      */
    FTIME write_time;    /* Date & time of last write         */
} XFINFO;

#define RESERVED_FOR_USER_APPLICATIONS (0x100) /* 0x100 - 0x1ff */
#define USR_XFFIND (RESERVED_FOR_USER_APPLICATIONS + 0)    

static int xffind (const char *pattern, XFINFO *info)
{
    unsigned param[4];

    param[0] = (unsigned long)pattern;
    param[1] = (unsigned long)strlen(pattern);
    param[2] = (unsigned long)info;
    param[3] = (unsigned long)sizeof(XFINFO);
    
    return __semihost(USR_XFFIND, param);
}

Hope that helps.

Simon

Can you distinguish files from directories with this call?

 

Igor Skochinsky wrote:

Can you distinguish files from directories with this call?

I presume not, unless the ids have some special meaning? Or return codes can indicate a directory as opposed to a file?

FYI, it seems to work like the ffind function provided by RL-ARM for searching on a flash filesystem, as described here: http://www.keil.com/support/man/docs/rlarm/rlarm_ffind.htm

Presumably, as in that example, fileID needs to be set to zero, and by passing a pattern of "*" I get back a root directory listing of all the files, but no directories.  I'll post an updated binary that works with eLua's "ls" shell command shortly.

 

FYI your semihosted filesystem code seems to work fine on LPC2368-based mbeds too. Nice work!

Thanks,

Hugo

Hugo Vincent wrote:

FYI your semihosted filesystem code seems to work fine on LPC2368-based mbeds too. Nice work!

Thanks,

Hugo

Thanks for the note!  Are you using eLua on one of the 2368-based mbeds or are you just using the semihosting for another purpose?  I'm just curious since, I think getting eLua going on 2368 wouldn't be too hard since we have a 24xx port, but I haven't tried going through and making the needed modifications.

It's in my FreeRTOS port (@ github.com/hugovincent/mbed-freertos), not in eLua. Sorry, I've never even tried eLua yet.

Hugo Vincent wrote:

It's in my FreeRTOS port (@ github.com/hugovincent/mbed-freertos), not in eLua. Sorry, I've never even tried eLua yet.

I was just curious.  Glad it's working in your freertos port.  I'll have to check that out at some point :-)

The link to the binary file is broken.

Please provide BIN file

 

                Georges

James,

Work great now. Very nice job. Many thanks

Which parameter of Elua do you use ?

Is RPC working ? 

Floating or integer ?

Are all serial ports implemented ? with buffer ?

          Best regards

                  Georges

 

 

James,

Do you plan to support I2C and CAN ?

          Best regards

                 Georges

 

 

 

 

King Georges wrote:

James,

Work great now. Very nice job. Many thanks

Which parameter of Elua do you use ?

Is RPC working ?

Floating or integer ?

Are all serial ports implemented ? with buffer ?

Best regards

Georges

 

 

RPC should be working. The bin provided is for floating point, but I suspect integer works as well even though I haven't tested this specific board (other CortexM3 has been working).  Serial ports should work, although you'll need to do pinconfig for the UARTs yourself (not done automatically).  We're not using the eLua buffering system for the uarts, however this platform does have a UART FIFO and I believe that's enabled.

I2C and CAN are planned.  We're aiming to have more "complete" ports for all our platforms with the next eLua release.  Implementation of these two peripherals shouldn't be too complicated.  I'm not sure I have any I2C hardware around right now, so I may have to persuade Bogdan or someone else to do that before 0.8.  Also, of course, patches are always welcome :-)  Ditto on feedback or bug reports :-)

Hello James

I am very appreciative of your efforts.  If you would like me to send you hardware to experiment on, I will do so.  I would be happy to support the expansion of software lua running on the mbed from NXP.

I have various i2c chips.  One of my favourites is the  AMIS-30624. 
( http://www.onsemi.com/PowerSolutions/product.do?id=AMIS30624C6244G )   I will send you a protoboard with the chip if you are interrested.  If you want a simpler i2c chip, let me know.
I can probably dig up CAN , i2c and SPI modules if you wish.   I have displays as well.  Some of them are color and use i2c.

 

Best

Gus in Denver    ( Joanne Yamaguchi is my partner )

 

Hello altogether, I searching for something like a autostart script, to run at startup or reset of my elua-device? Thank you for your help. Kind Regards ...