Welcome to the official eLua FAQ! It is assumed that you already know what eLua, so here's a list of questions (and their answers) that you might find useful.
Lua is a minimalistic language (yet very powerful) which is quite easy to learn. Once you understand the basic concepts you'll find yourself writing Lua programs in notime. The main resource is the Lua homepage. In the documentation page you'll find the reference manual and the first version of the excellent "Programming in Lua" book. I recommend purchasing the second version of this book, since it's likely that this is all you'll ever need to learn Lua. Another very good resource is the Lua wiki. If you need more help, check the community page. Lua has a very friendly and active community.
eLua has many ambitious goals, so it would be great to have more people working on it. Take a look at the roadmap page, and if you see something there that you'd like to work on, don't hesitate to contact us. Also, if you'd like to make a donation to the project (money, or maybe a development board) rest assured that wwe won't say no :) It also helps a lot if you test eLua on your own board and you find a bug or an incomplete feature. Or if you just thought about a cool feature that you'd like to see in eLua. If so, feel free to contact us.
Starting with version 0.6, eLua distributed under a MIT license, so you can use it in your close source projects. Prior to this it was distributed under GPL, which restricted its usage to open source applications only. Be careful though, eLua includes some 3rd party libraries, each with its own licensing terms that might be more restrictive than MIT. See the eLua license for details.
This pretty much depends on what you expect. If you expect your Lua code to run as fast as your compiled C code, this won't happen, simply because C is a compiled language, while Lua is an interpreted language. That said, you'll be happy to know that Lua is one of the fastest interpreted languages out there. If you really need both high speed and Lua, you can write your speed critical code sections in C and export them as a Lua module. This way you get the best of both worlds. We don't have any official benchmarks about Lua speed on embedded devices, but you might want to check the TV-B-Gone example on the ##examples page.TV-B-Gone is a "software remote control" application coded directly in eLua. If you're familiar with the remote control protocols, you'll know that this kind of application is quite "real time", and delays in the order of milliseconds or even less can make your software remote control fail. Yet this sample runs without problems on a 50MHz Cortex (Thumb2) CPU. This should give you a fairly intuitive view on the speed of eLua.
It's hard to give a precise answer to this. As a general rule for a 32-bit CPU, we recommend at least 256k of Flash (program memory) and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definetely fit in 128k of Flash, and depending on your type of application, 32k of RAM might prove just fine. It largely depends on your needs.
Unfortunately, no. While eLua makes it possible to have a common code on different platforms using the ##platform interface, it can't possibly provide the same functionality on all platforms, since all MCUs are not created equal. It is very recommended (and many times imperative) to have an understanding of the peripherals on your particular MPU before you start writing your code. This, of course, is not particular to eLua, but it's especially important since the platform interface might give the impression that it offers an uniform functionality over all platforms, when in fact the only thing in common is often just the interface itself (that is, the methods and variables you can access in a given module). eLua tries to help here by giving you an error when you try to access a physical resource that is not available (for example a timer, a PWM channel, or a PIO pin/port), but it doesn't try to cover all the possible platform-related issues, since this would increase the code size and complexity too much. These are some caveats that come to mind (note that these are only a few examples, the complete list is much longer):
The lesson here is clear: understand your platform first!
Lua is build around a number type. Every number in Lua will have this type. By default, this number type is a double. This means that even if your program only does integer operations, they will still be treated as doubles. On embedded platforms this is a problem, since the floating point operations are generally emulated in software, thus they are very slow. This is why eLua gives you "integer only Lua": a Lua with the default number type changed to long. The advantages are increased speed and smaller code size (since we can force Newlib to "cut" the floating point code from printf/scanf and friends, which has quite a strong impact on the code size) and increased speed. The downside is that you'll loose the ability to do any floating point operations (although a separate module that will partially overcome this limitation will be provided in the future).
It's true that we do all the eLua development under Linux, since we find Linux an environment much more suited for development. At the same time it's true that most of the tools that come with my development boards run under Windows. So we choose to use the best of both world: Bogdan runs Linux under a VirtualBox emulator, and does verything else under Windows. Dado does everything on Linux and runs Windows under VMWare. Both options are nice if you master your environment. To make everything even more flexible, Bogdan keeps his VirtualBox Ubuntu image on an external WD passport disk that he can carry with him wherever he goes, so he can work on eLua whenever he has a bit of spare time :)
Bogdan: If I ever have way too much spare time on my hands, yes. Otherwise, no. There are many reasons for this. As I already mentioned, I favour Linux over Windows when it comes to developing applications. Also, I noticed that the GNU based toolchains are noticeable slower on Cygwin than on Linux, so experimenting with them can prove frustrating. Also, compiling under Linux and Cygwin should be quite similar,so try starting from my Linux based tutorials, they might work as well on Cygwin.
This is not a bug in eLua, it's a bit more subtle than that. See the cross-compile section for a full discussion about this problem and its fix.
There are a number of things you can try to overcome this:
You don't really have to disable LTR to get write access to your rotables, you can use some simple Lua "tricks" instead. Let's suppose that you need write access to the math module. With LTR enabled, math is a rotable, so you can't change its keys/values. But you can use metatables to overcome this limitation:
local oldmath = math
math = { __index = oldmath }
setmetatable( math, math )
This way you can use math in "write mode" now (since it is a regular table), but you can still access the keys from the original math rotable. Of course, if you need write access to all your modules (or to most of them) it makes more sense to disable LTR instead, but from our observations this doesn't happen in practice.