1
0
mirror of https://github.com/elua/elua.git synced 2025-01-08 20:56:17 +08:00
elua/doc/pt/faq.html
Dado Sutter 80513aaf52 i386 toolchain build tutorial edited to include John Hind fix
SConstruct edited just to leave group/files definitions close to the platform/groups.
Doc content files mirroed to pt, to ease the portuguese version initial migration
2009-02-21 23:02:39 +00:00

209 lines
13 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Language" content="en-us"><title>Product</title>
<link rel="stylesheet" type="text/css" href="../style.css"></head>
<body style="background-color: rgb(255, 255, 255);">
<h3>eLua Frequently Asked Questions</h3><br><p>Welcome to the official eLua FAQ!
It is assumed that you already know <a>what eLua is</a>, so here's a list of questions you might find useful while exploring eLua.</p>
<ul><li><p><a href="faq.html#learnlua">How can I learn Lua? Is it hard?</a><br></p></li><li><p><a href="faq.html#helpelua">How can I help eLua?</a><br></p></li><li><p><a href="faq.html#comercial">Can I use eLua in my commercial, closed source project?</a><br></p></li><li><p><a href="faq.html#fast">Is eLua fast enough?</a><br></p></li><li><p><a href="faq.html#minimuns">What are the minimum requirements for eLua?</a><br></p></li><li><p><a href="faq.html#portability">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?</a><br></p></li><li><p><a href="faq.html#luaversions">What's the deal with floating-point Lua and integer only Lua?</a><br></p></li><li><p><a href="faq.html#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><br></p></li><li><p><a href="faq.html#cygwin">Will you ever post instructions about how to compile toolchains under Cygwin in Windows?</a><br></p></li><li><p><a href="faq.html#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><br></p></li><li><p><a href="faq.html#outofmemory">I get "out of memory" errors when I run my Lua programs, what should I do?</a><br></p></li></ul>
<p><br></p>
<hr>
<p><a name="learnlua"></a>
<strong>Q: How can I learn Lua? Is it hard?</strong></p>
<p>A: 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 <a target="_top" href="http://www.lua.org/">Lua homepage</a>. In the <a target="_top" href="http://www.lua.org/docs.html">documentation page</a>
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 <a target="_top" href="http://lua-users.org/wiki/">Lua wiki</a>. If you need more help, check the <a target="_top" href="http://www.lua.org/community.html">community page</a>. Lua has a very friendly and active community.</p><p></p><br><p><a name="helpelua"></a>
<strong>Q: How can I help eLua?</strong></p>
<p>A: OK, so I lied, this is NOT a frequently asked question :)
However, if you really want to help eLua, keep in mind that we're
looking for developers. eLua has many ambitious goals, so it would be
great to have more people working on it. Take a look at the <a href="status.html#roadmap">roadmap page</a>, and if you see something there that you'd like to implement, don't hesitate to <a href="overview.html#contacts">contact us</a>.
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 <a href="overview.html#contacts">contact us</a>.</p><p></p>
<p><a name="comercial"></a>
<strong>Q: Can I use eLua in my commercial, closed source project?</strong></p>
<p>A: ### This needs to be updated for the BSD license .........</p><p></p>
<p><a name="fast"></a>
<strong>Q: Is eLua fast enough?</strong></p>
<p>A: 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 <a href="examples.html">examples page</a>.
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.</p><p></p>
<p><a name="minimuns"></a>
<strong>Q: What are the minimum requirements for eLua?</strong></p>
<p>A: 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.</p><p></p>
<p><a name="portability"></a>
<strong>Q: 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?</strong></p>
<p>A: Unfortunately, no. While eLua makes it possible to have a common
code on different platforms using the platform interface
(docs/platform_interface.txt), it can't possibly provide the same
functionality on all platforms, since all CPUs are not created equal.
It is very recommended (and many times imperative) to have an
understanding of the peripherals on your particular CPU before you
write 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):</p>
<ul><li>timers: from all the platforms on which eLua 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, 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
shell. You can change this static timer assignment by modifying
src/main.c. It might also be possible to change it dynamically in the
future, although I see little use for this.</li><li>PWM: 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>GPIO: only
some platform have internal pullups for the GPIO pins, while Cortex is
the only platform that also provides pulldowns for its GPIOs. However,
in this case you're safe, as eLua will signal an error if you try to
execute a pullup operatin on a platform that does not support it.</li></ul>
<p>The lesson here is clear: understand your platform first!</p><p></p>
<p><a name="luaversions"></a>
<strong>Q: What's the deal with floating-point Lua and integer only Lua?</strong></p>
<p>A: 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.</p><p></p>
<p><a name="windows"></a>
<strong>Q: All your tutorials give instructions on how to compile eLua
under Linux, yet you seem to use a lot of Windows tools. How come?</strong></p>
<p>A: 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&nbsp;Linux under an Virtual Machine Manager (<a target="_top" href="http://www.virtualbox.org/">VirtualBox</a>) and do&nbsp;everything else under Windows. Dado does everything on Linux and runs Windows under <a href="http://www.vmware.com" target="_top">VMWare</a>. 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 :)</p><p></p>
<p><a name="cygwin"></a>
<strong>Q: Will you ever post instructions about how to compile toolchains under Cygwin in Windows?</strong></p>
<p>A: 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.</p><p></p>
<p><a name="bytecode"></a>
<strong>Q: 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?</strong></p>
<p>A: This is not a bug in eLua, it's a bit more subtle than that. It's
true that ARM and i386 are very similar when it comes to data types:
all the fundamental data types have the same length, and they are both
little endian. So, in theory, if you compile a Lua source file on PC
you should be able to run the compiled bytecode on your eLua board
without any modifications. But there's a problem here: the default
double precision floating point representation is different on ARM and
PC. So, while the two data types have the same endianess and size, they
are represented differently in memory. This means that you can't use
the "regular" luac compiler for this task. However, starting with
version 0.5, you can cross-compile Lua code on PC to run on target.&nbsp;</p><p></p>
<p><a name="outofmemory"></a>
<strong>Q: I get "out of memory" errors when I run my Lua programs, what should I do?</strong></p>
<p>A: There are a number of things you can try to overcome this:</p>
<ul><li>precompile your source to bytecode:&nbsp; If you use bytecode instead of
source code Lua won't need to compile your source, so you save some RAM.</li><li>try
to avoid using too many strings: strings are immutable in Lua. That
means that a statement like s = s .. "\n" (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 <a href="http://www.lua.org/manual/5.1/manual.html#5.5">table.concat</a> to make a string from your table.</li><li>controll Lua's garbage collection&nbsp;manually: if you're still running out of memory, try
calling collectgarbage('collect') from your code, which will force a
garbage collection and thus might free some memory.</li></ul><br><br></body></html>