eLua Preliminary Port

A preliminary port is now available to use eLua on mbed (currently the NXP LPC1768 version).

Check out the eLua website for general information about the project: http://www.eluaproject.net/

Latest Notes:

12/7/2010: ADC is now supported by this port. For code examples check out adcpoll.lua and adcscope.lua (you should be able to "cat" them from the startup prompt to get listings.  Currently pins will be automatically reconfigured for ADC when one starts sampling, and p15 -> p20 pins map to adc channels 0 - 5, so using this device should refer to channels using the 0 - 5 id number.  Also note that clocked sampling only works with timer id 1 (using the timer match trigger).

Port Status

Supported Peripherals:
  • GPIO
  • PWM
  • UART
  • Timers
  • ADC

Other Supported Features:

  • MBED Filesystem (including directory listing using the ls command)

Note: This port is currently a bare metal GCC-based port to the LPC1768, as such it does not use the online compiler, and requires a GCC toolchain to build fresh images.

Getting Started

To to try out eLua on mbed, you can simply grab the image linked below, drag it onto your mbed, and press the button on top to load:
http://fanplastic.org/files/elua_lua_lpc1768.bin
The built-in serial console will automatically start on the mbed's virtual serial port, and you can access it using the PC-side instructions provided in the handbook here: http://mbed.org/handbook/SerialPC
The default console starts up with 115200 baud, 8-bits, no parity, 1 stop bit (8N1).  General usage information can be found here: http://www.eluaproject.net/en_using.html
Quick Pointers:
The linked image will start up at an eLua# prompt (hit the mbed reset button or hit enter if you started your terminal application after starting up the mbed).
One can run the lua programs on the rom filesystem included in the image, and look at the source code as examples:
eLua v0.7  Copyright (C) 2007-2010 www.eluaproject.org
eLua# ls  

/rom
bisect.lua                     646 bytes
hangman.lua                    3378 bytes
hello.lua                      23 bytes
info.lua                       134 bytes
led.lua                        1296 bytes
pwmled.lua                     1007 bytes
dualpwm.lua                    932 bytes
life.lua                       2601 bytes
MBED.lua                       793 bytes

Total on /rom: 10810 bytes

/semi
MBED.HTM                       340 bytes
TESTREAD.LUA                   194 bytes
HELLO.LUA                      23 bytes
ELUA_L~1.BIN                   175640 bytes
TESTTEST.TXT                   33 bytes
TESTFILE.TXT                   333 bytes

Total on /semi: 176563 bytes

Lua# cat /rom/info.lua
print( "I'm running on platform " .. pd.platform() )
print( "The CPU is a " .. pd.cpu() )
print( "The board name is " .. pd.board() )
eLua# lua /rom/info.lua
Press CTRL+Z to exit Lua
I'm running on platform LPC17XX
The CPU is a LPC1768
The board name is MBED
eLua#  

Known issues: dualpwm.lua, which alternately dims and brightens LED1 & 2 using PWM indicates that one can press any key to exit, however it appears to be stuck in the program.  This program will run until you reset the mbed.

eLua on MBED Particulars

We have not yet done an eLua release with the mbed port included, so the site docs do not mention this port or any of its particulars. As such, some of these are noted here.

Addressing Pins

Pins are addressed using an extension for the built-in pio module, through mbed.pio.  The standard mode of addressing pins provided by the pio module correspond to the pins on the LPC1768, instead of the DIP pins of the mbed module.  As such, a platform specific module maps pins as shown on the mbed module and in the docs.  As an example, to turn on and off an LED, one would use the following Lua calls:
pio.pin.setdir( pio.OUTPUT, mbed.pio.LED1 )  -- set LED1 pin to output mode
pio.pin.sethigh( mbed.pio.LED1 ) -- turn on LED1
pio.pin.setlow( mbed.pio.LED1 ) -- turn OFF LED1  

Pin Functions

The standard mbed library abstracts away some of the configuration that one would normally need to do manually, in order to use functions like PWM with a given pin.  Since the eLua API doesn't yet have a convenient model for supporting similar autoconfiguration of pin functions, one must currently refer to the schematic and LPC176x reference manual to know what mode pins must be set in to support what function: http://mbed.org/nxp/lpc1768/technical-reference/
Some examples are provided below to simplify getting started:

PWM Pin Mapping

mbed Pin Peripheral ID Pin Function
LED1 1 2
LED2 2 2
LED3 3 2
LED4 4 2
p21 6 1
p22 5 1
p23 4 1
p24 3 1
p25 2 1
p26 1 1

UART Pin Mapping

mbed Pin peripheral ID pin function
p13 1 (TX) 1
p14 1 (RX) 1
p28 2 (TX) 1
p27 2 (RX) 1


As an example, to set up LED1 for PWM, you would do the following:

-- configure LED1 for function 2, not in open drain mode (3rd param),
-- pin mode zero (4th param)
mbed.pio.configpin(mbed.pio.LED1, 2, 0, 0)

pwm.setup( 1, 50000, 23 ) -- configure peripheral ID 1 to 50 kHz w/ a duty of 23%
pwm.start( 1 ) -- start PWM output

The default function for each pin is 0, so if you need to switch a pin back to general purpose I/O mode, you would need to execute a command similar to:

mbed.pio.configpin(mbed.pio.LED1, 0, 0, 0)

 

One peripheral that does not require pre-configuration of pins is ADC, since the channels don't have multiple locations that can be mapped. eLua's ADC dev 0 -> 5 correspond to pins p15 -> p20 on the mbed and are enbabled using eLua's style of referencing devices, i.e.: adc.sample(2,4) -- collect 4 samples on channel 2.

 

Using the Filesystem

Basic access to the mbed on-board filesystem has been added to the downloadable binary and eLua SVN as of Mar 8, 2010.  Directory listing isn't yet supported, but reading and writing files as well as seeking appears to work as expected.  The path for this filesystem starts at /semi.  Here's a basic usage example (from within Lua, on eLua):
filename = "/semi/testfile.txt"
f = assert(io.open(filename, "a"))
f:write("Looks like filesystem support works!\n")
f:close()

f = assert(io.open(filename, "r"))
print(f:read("*all"))
f:close() 

Note:

If you were to put this on the mbed filesystem as testfs.lua, you could repeatedly run it this way, each time appending the text from the f:write line to the file:

eLua#  lua /semi/testfs.lua
Press CTRL+Z to exit Lua
Looks like filesystem support works!

eLua#  lua /semi/testfs.lua
Press CTRL+Z to exit Lua
Looks like filesystem support works!
Looks like filesystem support works!

eLua#  lua /semi/testfs.lua
Press CTRL+Z to exit Lua
Looks like filesystem support works!
Looks like filesystem support works!
Looks like filesystem support works!

eLua#  lua /semi/tesfs.lua
Press CTRL+Z to exit Lua
Looks like filesystem support works!
Looks like filesystem support works!
Looks like filesystem support works!
Looks like filesystem support works!

For more information on Lua's I/O model, check out the following pages:

Getting Involved

The current sources are available from our Subversion repository:
http://www.eluaproject.net/en_downloads.html#source
The eLua main mailing list is accessible as both a mailing list and a forum (thanks to Nabble).


27 comments

26 Feb 2010 . Edited: 26 Feb 2010

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

 

 

27 Feb 2010

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

Dave

27 Feb 2010

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

27 Feb 2010

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

27 Feb 2010

 

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.

27 Feb 2010
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

27 Feb 2010

 

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.

 

27 Feb 2010

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

28 Feb 2010

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.

28 Feb 2010
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 :-)

03 Mar 2010

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

 

Best,

Fernando Araujo

08 Mar 2010

 

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?

 

13 Mar 2010

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.

15 Mar 2010

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

 

 

 

19 Mar 2010 . Edited: 19 Mar 2010

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

19 Mar 2010

Can you distinguish files from directories with this call?

27 Mar 2010

 

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.

 

31 Jul 2010

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

Thanks,

Hugo

03 Aug 2010

user avatar 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.

08 Aug 2010

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

09 Aug 2010

user avatar 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 :-)

02 Oct 2010 . Edited: 03 Oct 2010

The link to the binary file is broken.

Please provide BIN file

 

                Georges

13 Oct 2010

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

 

 

14 Oct 2010

James,

Do you plan to support I2C and CAN ?

          Best regards

                 Georges

 

 

 

14 Oct 2010

 

user 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 :-)

08 Nov 2010 . Edited: 08 Nov 2010

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 )

 

16 Nov 2012 . Edited: 16 Nov 2012
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 ...

You need to log in to post a comment