lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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 -----
From: bert
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 -----
From: bert
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-----



Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.