Menu

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).

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

Freedom

Readability

Documentation system

High level vs. low level

Standard library

2rd Party OSS for Science Work

Data Structures

Module system

Project scalability

Calling syntax

Multiple Programming Paradigms

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:

Freedom

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.

Readability

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

Documentation

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.

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.

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.

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 🙂

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.

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.