<p>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
<p>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
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.</p>
<aname="portability"/><h2>Since I'm using the Lua platform modules (uart, spi, pwm, tmr...), can I trust my peripheral code to run the same on all my
platforms?</h2>
<p>Unfortunately, no. While <b>eLua</b> makes it possible to have a common code on different platforms using the <ahref="arch_platform.html">platform interface</a>,
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 <b>eLua</b>, 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). <b>eLua</b> 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):</p>
<ul>
<li><b>timers</b>: from all the platforms on which <b>eLua</b> runs, only the Luminary Cortex CPUs has rock solid 32-bit timers. You can do pretty much
everything you need with them. All the other platforms have 16-bit timers, which imposes some limits on the range of delays you can achieve with them.
Make sure to use tmr.mindelay(id) and tmr.maxdelay(id) to check the actual resolution of your timers, and adapt your code accordingly. To 'compensate'
for this, it's not possible to change the base timer frequency on the Cortex CPUs, but it is possible on most other platforms :) So be sure to also check
the result of tmr.setclock(id)</li>
<li>also, when using timers, remember that if you're using XMODEM and/or the "term" module, one of them (generall TMR0) is used by both of them. So, if
you change the TMR0 base clock in your code, be sure to restore the original setting before returning to the <b>eLua</b> shell.</li>
<li><b>PWM</b>: the Cortex CPUs have 6 PWM channels, but channels 0/1, 2/3 and 4/5 respectively share the same base clock setting. So, when you're
changing the base clock for channel 1, you're also changing the base clock for channel 0; if channel 0 was already running, you won't like
what will happen next. This time no eLua function can save you, you simply need you know your CPU architecture.</li>
<li><b>GPIO</b>: only some platform have internal pullups for the GPIO pins (others might also have pulldowns). However, in this case you're safe, as
<aname="windows"/><h2>All your tutorials give instructions on how to compile eLua under Linux, yet you seem to use a lot of Windows tools. How come?</h2>
<p>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
<p>This is not a bug in <b>eLua</b>, it's a bit more subtle than that. See <ahref="using.html#cross">the cross-compile section</a> for a full discussion
<li><b>precompile your source to bytecode</b>: if you use bytecode instead of source code Lua won't need to compile your source, so you save some RAM.</li>
<li><b>try to avoid using too many strings</b>: strings are immutable in Lua. That means that a statement like <i>s = s .. "\n"</i> (where s is a string)
will create a new string each time it's called. If this happens a lot (for example in a loop), your memory will quickly run out because of all the
strings. If you really need to do frequent string operations, put them in a table and then use
<li><b>control Lua's garbage collection manually</b>: if you're still running out of memory, try calling <i>collectgarbage('collect')</i> from your code,
which will force a garbage collection and thus might free some memory.</li>
<p>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 <b>math</b> module. With LTR enabled, <b>math</b> is a rotable, so you can't change its keys/values. But you can use metatables
