|
Hi Bert,
That makes more sense (I couldn't quite figure how someone
would be doing embedded ARM development while trying to avoid C).
How about having your interrupts setting a flag, and having
Lua (run from the main routine) set up with a co-routine that activates on the
flag? Obviously you are not going to get immediate response, but you will
avoid things like race conditions.
As to converting Lua straight to assembly, I doubt if it would
be easy to make a general solution. You might be able to convert a useful
subset of Lua to C (and then let the C compiler do the rest of the work), but I
don't know enough of the implementation of Lua to help.
mvh.,
David
----- Original Message -----
Sent: Sunday, May 21, 2006 11:07 PM
Subject: Re: lua on ARM7
I've been programming C and C++ for a very long time, and I wrote
several LUA extensions already.
I just want to go straight from LUA to assembly, because I can't
expect my users to learn C and they need to extend the functionality of the
embedded platform. David Brown <david@westcontrol.com>
wrote:
If you are doing embedded development, you have to learn C
- there's no way round it. Use C for the low-level stuff and the
time-critical stuff. Lua can make sense for higher level coding,
especially for code that might change often.
Mixing C and Lua is not hard - I suppose that's one of the
main points about using Lua in the first place.
mvh.,
David
----- Original Message -----
Sent: Thursday, May 18, 2006 8:12
PM
Subject: Re: lua on ARM7
Hi Asko, all,
Sorry, I've been out of the office for
a few days and not keeping up with this thread.
Anyway, I'm
definately interested in that SDL_mixer example.. might help clear up some
stuff.
I was thinking of using LUA to process samples from the
ARM's on-board analog-to-digital converter, but it looks like that would
be asking too much.
So my next question is.. how hard is it to
compile LUA to ARM7 assembly :-)
maybe Thumb mode ...
I realize
it would be very complicated, since you would need the garbage collector.
but what if I limit it to compiling a LUA function like this
:
function process(input1,
input2)
return input1 *
input2
end
I guess that wouldn't be too hard?
I'm not sure if there exists a lua scanner/parser in LUA
itself...
what if it gets more complicated:
lut = [0, 0, 0, 0, ... 0]
--- say, 256 values in lut
function process(input)
return lut [
input ]
end
or what about this
:
function process(input)
local t = [math.random(), math.random(),
math.random()]
return input *
t[math.random(3)]
end
I know these functions
don't make a lot of sense but I'm trying to get a general idea of how to
go about this.
I'd like to have some function in LUA that does
something like this
funBinaryCode =
compileARM(function (input1, input2) return input1*input2 end)
---
funBinaryCode now holds a table of bytes which can be cast to a function
pointer on the ARM7 and called
Any comments highly
appreciated.
Bert
Asko Kauppi
<askok@dnainternet.net> wrote:
Ah, yeah.
Your flag thing is a "one entry
queue" but I was expecting Bert not
to want to lose a single
interrupt (and them to be different, like
having some data values
attached, that Lua would care about).
Anyways, already this is
getting speculative, since we don't know
what Bert does. Bert: if
you want an event dispatch queue, I can send
code I've used in
LuaX/SDL_mixer, to catch played music samples at
real time (and show
the graphs by Lua). Don't remember about memory
allocation, but yes,
most likely one alloc per interrupt is needed
there.
-asko
David Given kirjoitti 15.5.2006 kello
20.00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash:
SHA1
>
> Asko Kauppi wrote:
> [...]
>> I
would consider doing an "event dispatch" interrupt handler (in
>> C) that
>> would sit in the other end of a FIFO
queue, the other end being
>> polled
>> by Lua (can
you run one instance, as the main loop?) to take in
>>
"commands".
> [...]
>
> A common technique is to have
the interrupt handler set a bit to say
> 'this interrupt has
happened'. Your userspace code then polls all the
> various bits,
does its work, and then clears them again. Getting the
> logic
right to ensure that all interrupts are properly serviced is
> a
bit
> challenging, and of course you lose any kind of
real-time-ness, but it
> does allow you to avoid having to
allocate memory during your
> interrupt
>
handler.
>
> - --
> +- David Given --McQ-+ "Preacher,
don't the Bible have some pretty
> | dg@cowlark.com | specific
things to say about killing?" "Quite
> | (dg@tao-group.com) |
specific. It is, however, somewhat fuzzier
> on the
> +-
www.cowlark.com --+ subject of kneecaps." --- Firefly, _War
>
Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG
v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
>
>
iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
>
ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP
SIGNATURE-----
New Yahoo! Messenger with Voice. Call
regular phones from your PC and save big.
|
