Potential playground for embeddedLua?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential playground for embeddedLua?

Joseph Stewart
Some of you may no doubt have seen the article on OSNews and Slashdot about the ZipIt box ($99 WiFi box with uCLinux). I'm thinking this would be a nifty replacement for my long-gone programmable calculator when running something like Lua? Anyone else have ideas about this?

Check the original linuxdevices article at:
http://www.linuxdevices.com/articles/AT8107883197.html

...and the wiki at (which gives info on how to re-flash the device with "other stuff":
http://www.elinux.org/wiki/ZipIt

Blessings!
-joe

--
If it ain't broke, break it.  How else are you going to figure out how it works?
Reply | Threaded
Open this post in threaded view
|

Re: Potential playground for embeddedLua?

Jolan Luff
On Mon, Jul 18, 2005 at 01:59:00PM -0400, Joseph Stewart wrote:
> Some of you may no doubt have seen the article on OSNews and Slashdot about 
> the ZipIt box ($99 WiFi box with uCLinux). I'm thinking this would be a 
> nifty replacement for my long-gone programmable calculator when running 
> something like Lua? Anyone else have ideas about this?

there doesn't seem to be a lot of hardware to play around with (in terms
of expandability and storage space) which i personally would find very
limiting.  if you want a multifunctional device, you may want to look at
the sharp zaurus c3000/c3100.  it ships with linux as well, but it has a
faster CPU, 64MB of RAM, 4GB hard drive, CF slot, and USB.  the default
environment is pretty limiting (no compiler for one) and thus you have
to rely on third party packagers or cross compiling to get the software
you want.

i decided to install openbsd on mine (http://www.openbsd.org/zaurus.html).
this let me have a fully self-hosting development environment.  no cross
compiling or worrying about who packaged the software.  i can build and
install everything myself.  so it's basically an embedded device but
without the usual problems of having an embedded device ;)

one of my favorite things about using openbsd/zaurus/lua is that the
openbsd ports system handles the path additions and module loading in a
mostly user invisible way:

http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/lua/files/
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/lua/patches/patch-src_lua_lua_c

this makes using lua a much more enjoyable experience.  well, at least
for someone still very new to lua such as myself.

one thing that i'm concerned about is that arm processors don't have any
sort of floating point unit, so floating point operations are emulated
in software which is obviously very slow.  i've seen it mentioned a few
times that changing lua to represent numbers with a different type is
trivial but i haven't heard any caveats which come with doing so.  i'm
especially worried about running the same code with a modified lua
interpreter and a non-modified one and having the output be slightly
different.  does anyone have any experiences to share?

Reply | Threaded
Open this post in threaded view
|

Re: Potential playground for embeddedLua?

Zachary P. Landau-4
> one thing that i'm concerned about is that arm processors don't have any
> sort of floating point unit, so floating point operations are emulated
> in software which is obviously very slow.  i've seen it mentioned a few
> times that changing lua to represent numbers with a different type is
> trivial but i haven't heard any caveats which come with doing so.  i'm
> especially worried about running the same code with a modified lua
> interpreter and a non-modified one and having the output be slightly
> different.  does anyone have any experiences to share?

Jolan,

I've modified Lua socket to use integers for running on a ColdFire. 
To do this, I defined USE_INT and included luser_number.h, as
mentioned in 'config' in the root directory.  This worked well, but
there are a few things to watch out for:

   * Make sure any libraries you compile into Lua also know that you
are using ints instead of doubles.  Otherwise you will get some fun
errors when the two libraries try to communicate
   * You may want to modify some libraries to work better with
integers.  For example, luasocket allows sub-second timeouts by using
floating point numbers.  This won't work anymore, so you'll have to do
something like taking in msecs instead of seconds.

Also, when running Lua on embedded platforms, you may want to lower
MAXVARS and MAXUPVALUES.  Otherwise it is fairly easy to get a stack
overflow.
  
-- 
Zachary P. Landau <[hidden email]>