<li><ahref="#portability">Since I'm using the <b>eLua</b> generic platform modules (uart, spi, pwm, tmr...), can I trust my peripheral code to run the same on all my platforms?</a></li>
<li><ahref="#luaversions">What's the deal with floating-point Lua and
integer-only Lua?</a></li>
<li><ahref="#wincomp">Is it possible to compile eLua under Windows?</a></li>
<li><ahref="#windows">All your tutorials give instructions on how to compile eLua under Linux, yet you seem to use a lot of Windows tools. How come?</a></li>
<li><ahref="#bytecode">I know that Lua can be compiled to bytecode, so I compiled one of the eLua examples with luac and tried to run it on my eLua board, but it didn't work. Is this a bug in eLua?</a></li>
<li><ahref="#rotables">I enabled the LTR patch, but now all my module tables (math, io, string, spi and so on) are read only. Do I have to disable LTR if I want write access to these modules?</a></li>
<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
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 <ahref="examples.html">examples page</a>. TV-B-Gone is a "software remote control" application coded directly in <b>eLua</b>.
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-M3 in Thumb2 mode CPU. This should
give you a fairly intuitive view on the speed of <b>eLua</b>. Of course,
the project benefits from the incredible speed and performance of Lua.</p>
<aname="portability"/><h2>Since I'm using the eLua generic platform modules (uart, spi, pwm, tmr...), can I trust my peripheral code to run the same on all my
<p>Unfortunately, no. While <b>eLua</b> brings an unprecedent level of
source code portability to the embedded world and 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
<li><b>Timers</b>: some CPUs, like the Luminary Cortex CPUs, have rock solid 32-bit timers. You can do pretty much
everything you need with them. Most platforms have only 16-bit timers though, which imposes some limits on the range of delays you can achieve with them.
Make sure to use <a
href="en_refman_gen_tmr.html#tmr.getmindelay">tmr.getmindelay(id)</a> and <a
href="en_refman_gen_tmr.html#tmr.getmindelay">tmr.getmaxdelay(id)</a> 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
<aname="luaversions"/><h2>What's the deal with floating-point Lua and integer-only Lua?</h2>
<p>Lua is built 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
floating-point doubles. On embedded platforms this can be a problem, since the floating point
operations are generally emulated in software and this can be slow. This is why <b>eLua</b> gives you
the choice of "integer only Lua": a Lua with the default
number type changed to long integer. The advantages are increased speed and smaller code size (since we can force Newlib to "cut" the floating point code from
<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
<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>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>
<li><b>use the emergency garbage collector (EGC)</b>: starting with version 0.7, <b>eLua</b> integrates Robert Jakabosky's excellent Emergency Garbage Collector
(EGC) patch. It can help a lot with low memory problems. See <ahref="elua_egc.html">here</a> for details on how to use the EGC patch in <b>eLua</b>.</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
