eLua v0.8 released


We are proud to annunce the release of eLua v0.8 (codename “FINALLY! It was about time for a new release” 🙂 ). eLua is an effort to expand the presence of the Lua programming language in the embedded world, especially on microcontroller-based platforms. It is meant to be a complete MCU development environment. It currently runs on a number of ARM variants (including Cortex-M3), AVR32 (and i386 as a proof of concept).

What follows is a list of new features in this release:
  • Added the RFS (Remote File System), a new file system which allows sharing a directory on the PC with the eLua board.
  • Added a serial multiplexer which allows using more virtual serial ports over a single physical UART connection.
  • Added Lua and C interrupt handlers support, see here for more details.
  • Added linenoise support (eLua and Lua shell command line history and navigation, more details here).
  • Added generic I2C support and docs
  • Added hardware flow control and runtime configurable buffers for UARTs.
  • Added support for new boards: mbedATEVK1101Mizar32EK-LM3S1968
  • Added SPI and SD/MMC support for EVK1100 and EVK1101 (AVR32)
  • Added I2C support for STR-E912 (STR912)
  • Added support for require() and autorun from SD/MMC
  • Added external memory support for STR912
  • Added long filename support for SD/MMC
  • Added RTC (real time clock) platform specific support for str9 (see the documentation of the str9.rtc module).
  • Added support for AsciiDoc in the documentation system
  • Tutorials and new projects added to the eLua Wiki
  • Demo files were moved out of the distro to http://wiki.eluaproject.net/Projects
  • Added a media page with eLua related media on the project site


Tagged with: , ,
Posted in Uncategorized

10 Reasons Python Rocks for Research

I just stumbled upon this article on Reddit.  This echos a number of things I may not have mentioned on this blog, but I’ve said it elsewhere in talks and when speaking with friends.  The reasons cited are (of course this is actually more than 10):

  1. Freedom
  2. Readability
  3. Documentation system
  4. High level vs. low level
  5. Standard library
  6. 2rd Party OSS for Science Work
  7. Data Structures
  8. Module system
  9. Project scalability
  10. Calling syntax
  11. Multiple Programming Paradigms
  12. Distribution system

Definitely worth looking over if you’re on the fence about switching away from something like MATLAB. Below I’ll discuss some of these points:


One of the first and foremost advantages of using Python, NumPy, SciPy and related modules is that they’re available for free and under quite liberal licenses (MIT, BSD, etc.. rather than GPL).  This means you’re really free to do with these whatever you want, with very minimal exceptions.


Python syntax, in part by enforcing certain white-space constraints results in very readable code.  As the linked article notes, this is by design.


Python has a fabulous system for documentation which is a language feature and not some strange form of comment that one has to rigidly structure in order for something like Doxygen to scrape out relevant details.  A great example is the Python core documentation.  Docstrings support describing method/function behavior inline in the code in a fairly elegant fashion which immediately becomes available through the documentation system.  Additionally Python docstrings can even incorporate unit tests which double as usage examples.

High level vs low level

Python provides allows you to write easy to read, highly maintainable code, but what about performance?  Python provides a number of approaches for dealing with performance that provide a great tradeoff to allow the developer to write maintainable code and then jump down to lower levels in order to optimize spots where performance might be less than desired.  At the higher levels, using appropriate data structures/types and utilizing functionality that these types provide can make up much of the performance gap with lower level implementations in C or Fortran.  Here I’m simply referring to what MATLAB frequently calls vectorization, if I want to take two matrices of equal shape and multiply them by one another, one could do this with a for loop and operate on these element-by-element in Python, but this will be much slower than desired.  Using the functionality built into modules like NumPy allow you to do this operation by simply multiplying one matrix by the other in a single binary operation.  Python also provides a number of great ways to integrate lower level Fortran or C/C++ code as needed when these types of Python-only efficiency gains are not enough.  In my opinion truly great abstractions acknowledge that they don’t cover every usage case and provide workable methods to break out of the pure abstraction without completely tearing it down.

Standard library

Python is batteries included.  You get a huge variety of high quality modules out of the box without having to search the web for build instructions or precompiled binaries for doing simple things like working with HTTP servers, compressing/decompressing files, parsing JSON, XML, threading/multiprocessing, etc..  NumPy doesn’t come bundled with Python, but you won’t spend huge amounts of time pulling together modules from tons of sources just to get basic functionality that you need.

The other items mentioned in the article are certainly important ones as well, but those above are some of the more important ones for me.

Tagged with: , ,
Posted in Uncategorized

Moved to Posterous

I believe the move over to Posterous from a WordPress install should be done now including handling some previous links that had gotten broken.  I got tired of finding that every time I logged in to make a post or do maintenance, there was yet another update to install.  On the upside, I no longer have to deal with that.  On the downside, Posterous doesn’t provide the ability to fully customize URLs or define redirects, some previous links were broken.  As such, I’ve moved the blog over to blog.fanplastic.org and now have lighttpd/mod_magnet (yay, Lua!) accepting requests to fanplastic.org that should be redirected to appropriate pages on the blog hosted at Posterous.

Tagged with: ,
Posted in Uncategorized

eLua User Labs!

The Embedded Lua project has announced a new sub-site for community members to find and post content about projects they’re working on:”We’re proud to announce the launch of a new community site: eLua User Labs. This Wiki-based site provides a centralized area where users can share project code, documentation and media. This site also contains official code examples, tutorials, FAQs (Frequently Asked Questions) and other goodies maintained by project members. Registered users are able to create new pages or make edits to many of the existing pages. We have prepared some initial content, and now welcome the rest of the eLua community to add, explore and refine.”We’re hoping that this will encourage users who have been working on projects independently to share information about them to help get new users excited, and also to provide a resource to everyone for finding re-usable code for different project types.

Tagged with: , ,
Posted in Uncategorized

eLua 0.6 Released!

It has been a bit of a quiet release so far, but I wanted to mention that eLua 0.6 has just recently been released.Here’s a rundown of the major changes in the release:

  • License changed to MIT
  • Web page and documentation completely redesigned
  • Documentation available offline
  • Added support for AVR32 CPUs
  • Added support for STM32 Cortex-M3 CPUs
  • Added ADC module with support for moving average filters
  • Added support for multiple toolchains
  • Added an ls (or dir) shell command
  • Added new examples: pong, tetrives, spaceship (games), logo (graphics), adcpoll, adcscope (ADC operations)
  • Added the LTR (Lua Tiny RAM) patch
  • ROM FS content can be specified per board now
  • API semantic revisions (old code might not be compatible)

One of the biggest things present in this release that I think makes the project much more accessible to new users is the establishment of good documentation. The project now has documentation for how ports work (including the platform API used to allow peripheral-specific modules to work on various platforms with fairly consistent behavior), how to use the various modules added to the base Lua distribution, and tutorials/how-tos showing methods for everything from getting release binaries onto a device through to how to get a toolchain up and going to do development on the project.There are still a number of components that are yet to be added (or are in SVN, but not in this release) that are necessary for a 1.0 release; however, this is a release that many more people can dig into without needing to read through source code in order to figure out how to use even basic functionality.Now if we only had a perfect device that we could standardize on and get a vendor to sell it pre-loaded with eLua 🙂

Tagged with: ,
Posted in Uncategorized

Should Fortran be taught to Undergraduates?

The following post has some very good thoughts about what languages to teach undergrads:Walking Randomly » Should Fortran be taught to Undergraduates?.Essentially he suggests starting with Python, NumPy & matplotlib which are both excellent and free.  He briefly mentions MATLAB in the post as well, but doesn’t say much about whether or not to use it.  I would suggest that people NOT use it, unless it specifically has some sort of built-in functionality that you need and can’t easily get elsewhere.  It’s a member of a class of tools that while quite easy to get started with and providing decent performance lock you into a closed toolchain which you either have to pay quite a bit of money for or lose the value of the tools you’ve built on top of it.  For basic numerical work, there’s not really much of an argument for needing to have MATLAB.  Python, NumPy & matplotlib are free, quite easy to work with, and expose you to the wonderful world of Python modules, where chances are someone has put together some quality groundwork for you to build upon for numerical work, networking, database, and a lot of other areas which are somewhat beyond the central expertise provided by tools like MATLAB.  Heck, you can even get support for it if you want to: Enthought.

Tagged with: , ,
Posted in Uncategorized

LuaRPC Update Jun 6, 2009

LuaRPC has grown a few additional features again.  We are now able to handle calling functions that are registered on tables and not just in the global environment.  This is crucial to be able to use modules where where functions are registered at something like modulename.function or modulename.subtable.function.  I’ve also stripped out some now unneeded code that did some remote error handling since the functionality it was used for was just adding an extra static buffer.  We also are now set up to be able to register additional commands that can be issued to the remote side beyond function calls.  Initially this will be used to provide methods to serialize data on the remote server and return this data locally, other functionality may follow.I also struck up a conversation on the Lua List about how one might go about treating a remote lua universe as just another table (do function calls, get data, handle metamethods, etc..), and there appear to be a number of problems in the way of doing all of that simply.  I think that the added command extensions will be used to add some sane portions of this functionality, and more complicated-to-implement functionality will be tabled until solutions can be found that aren’t miserably hackish.  If you’re interested in reading the exchange, you can find it here.

Tagged with: ,
Posted in Uncategorized

LuaRPC Update Jun 1, 2009

I’ve got a few more issues to attend to before I’m going to put the LuaRPC code into the eLua trunk.  One thing that I’m thinking about that I’ve not yet come up with a satisfactory solution for is dealing with connection state.  The original code used sockets, and therefore the protocol makes some assumptions that, in most cases, data arrives in order with no errors, unless some exception is thrown.One advantage of all of this is that the code is reasonably simple and is minimal on CPU usage.  However, I think it’s a little too minimal to handle serial communications where a client might hangup or one simply gets a bad read, and there are only the TXD and RXD lines to indicate physical/data link state.  So far what I’ve done is padded out each buffered read & write (one or many bytes) with a header and tail byte (different) so that either the client or server can complain and jump back to waiting for fresh requests on error.  I may consider following HDLC a little more closely in terms of asynchronous framing, but this may be OK for now.It should be easy to layer checksums, addressing, retransmission or other assurances on top of this implementation by simply wrapping the functions that read and write chunks of data.

Tagged with: ,
Posted in Uncategorized

LuaRPC Update

I’ve now both gotten it working on 5.1.4 and have abstracted out the transport layer.  As it stands which “transport” one uses is a compile-time option set by enabling or disabling some defines in config.h, but both serial (using pty to simulate real serial) and socket connections seem to be working at the moment for desktop use.  It’s still somewhat rough around the edges, and I’d like to be able to support multiple transports from a single compilation, but I’ve not decided how I might want to do that yet (multiple modules?  function pointers that allow switching within a single module file?).The existing module uses C-based exceptions to deal with transport-layer errors (take a look at luarpc_rpc.h if you’re interested).  I know we’re not really using exceptions for most of the eLua modules, but I’m wondering whether I should leave that in place, or change that in order to be friendly to porting.  As it is set up, it doesn’t have to derive from errno codes defined by system libraries (not sure whether Newlib provides an errno global), so if custom codes or strings are needed they can be set up.  I think, though, with the current flow, some exceptions will need to be thrown in order to enable connection resets when the client disappears, or if bad data is sent/received.Additionally, argument handling for connection setup that varies between transports is included in the “transport” side of the code, so the API to the transport layer includes a few functions that want a lua_State.  This feels a bit undesirable to me since some of them push stuff onto the stack depending on what args are given to them, and that number has to be passed back up the chain of called functions, since none of the transport layer functions are called directly from Lua.Also, beyond whatever was included in the original code, I’ve not done anything special security-wise to prevent clients from doing nasty things.  That said, if you were letting someone connect to a LuaRPC server, you were already letting them run arbitrary code on your server (unless you disable loadstring), so… :-)I think I’ll have an eLua serial backend going sometime in the near future, and I’ll certainly mention that when it’s ready to be abused.

Tagged with: ,
Posted in Uncategorized

RPC over {TCP/IP, Serial, Full Duplex FIFOs}

I’ve tinkered a bit further with Lua-RPC, but I’ve still not settled on how I’d like to deal with multiple lower level layers over which it can operate.  Inherently, it should be fairly simple because all the modalities mentioned in the title can be treated like files on UNIX/POSIX.  This means that once setup is complete, so long as no errors are encountered, all of these links should essentially look the same.  With error handling included, perhaps this can be somewhat simplified if we can look up error messages depending on which type of link is in use.The main point of interest, I think, is in allowing any one of these link types to be configured for the same library.  Perhaps the best way to handle this is to have a set of different handle creators (one per link layer), and each one of these takes parameters appropriate for configuration of that link, while leaving a handle that can be used by a common set of utility functions that read and write to the file descriptor set up when the handle was created.Currently there is one RPC_open function for opening client-side connections to a server.  If the namespacing were adjusted so that we have an rpc table, and function entries corresponding to different link types, our adjusted set of “open” functions could look like:h_sock = rpc.open_socket(address,port)h_ser = rpc.open_serial(serial_port, baud, etc..)h_fifo = rpc.open_fifo(file_path)I’m not sure if after setting up the file descriptor that when read() or write() are subsequently called that anything special need be done to ensure that those functions are the ones that know how to work with the link type that has been set up.  I would assume that at least for the serial and fifo situations, where an actual “file” exists to be read and written to that this isn’t too much of a problem, but for the socket there’s no file or fake file to represent the open socket.  Does POSIX/UNIX take care of this for you?  I suppose I’ll just have to check 🙂

Tagged with: ,
Posted in Uncategorized