Lua API Question

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

Lua API Question

Hi -

I've implemented smoothing functionality, which seems to work for me  
on the Stellaris platform.  I'm sure there are a few bugs in there,  
and cases I haven't covered, so I'm not quite done with it.  I'm open  
to suggestions if I've done anything particularly ugly or  
problematic :-)   I also plan to move the code around a little so that  
as much as possible is common to all platforms.  I tried to limit  
platform-specific functionality at this go around, so simlar code with  
platform specific driver calls changed should work on all platforms, I  
think.

One thing I haven't implemented yet is the burst sampling function.  I  
haven't done this yet because I haven't decided how I want to return  
the results to Lua.  I was originally thinking that I wanted to return  
some sort of array or table, so that one could do, for example:

res = adc.burst(id, timer_id, freq)

and have res be a table containing the returned samples, however, I  
don't see a method to push such a thing onto the stack used to  
transfer between Lua and C.

I suppose the table could be created first in lua, pass that to  
adc.burst and use the api functions to manipulate the table:

res_table = {}
adc.burst(id,res_table,timer_id,freq)

Of course this option makes returning results in a non-blocking manner  
a little easier since I assume I can have my interrupt stick values  
into the table at a later point.  The main thing I don't like about it  
is that if I accept a table, I don't really know what I'm going to  
get.  Will it be empty? Do I replace key->value pairs or only add them?

I suppose another option could be that I accept not a table, but a  
name for one, and then create that using the API and slot values into  
it.

Any thoughts on what approach would be the most reasonable?

Thanks!

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 644-2322

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090127/d74f6474/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090127/d74f6474/attachment.pgp 

BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Lua API Question

You could probably use this:

=================

lua_createtable

[-0, +1, m]

void lua_createtable (lua_State *L, int narr, int nrec);

Creates a new empty table and pushes it onto the stack. The new table
has space pre-allocated for narr array elements and nrec non-array
elements. This pre-allocation is useful when you know exactly how many
elements the table will have. Otherwise you can use the function
lua_newtable.

=================

Then use lua_rawseti to set the elements in your newly created table.

Best,
Bogdan

On Wed, Jan 28, 2009 at 3:16 AM, James Snyder <jbsnyder at fanplastic.org> wrote:

> Hi -
> I've implemented smoothing functionality, which seems to work for me on the
> Stellaris platform.  I'm sure there are a few bugs in there, and cases I
> haven't covered, so I'm not quite done with it.  I'm open to suggestions if
> I've done anything particularly ugly or problematic :-)   I also plan to
> move the code around a little so that as much as possible is common to all
> platforms.  I tried to limit platform-specific functionality at this go
> around, so simlar code with platform specific driver calls changed should
> work on all platforms, I think.
> One thing I haven't implemented yet is the burst sampling function.  I
> haven't done this yet because I haven't decided how I want to return the
> results to Lua.  I was originally thinking that I wanted to return some sort
> of array or table, so that one could do, for example:
> res = adc.burst(id, timer_id, freq)
> and have res be a table containing the returned samples, however, I don't
> see a method to push such a thing onto the stack used to transfer between
> Lua and C.
> I suppose the table could be created first in lua, pass that to adc.burst
> and use the api functions to manipulate the table:
> res_table = {}
> adc.burst(id,res_table,timer_id,freq)
> Of course this option makes returning results in a non-blocking manner a
> little easier since I assume I can have my interrupt stick values into the
> table at a later point.  The main thing I don't like about it is that if I
> accept a table, I don't really know what I'm going to get.  Will it be
> empty? Do I replace key->value pairs or only add them?
> I suppose another option could be that I accept not a table, but a name for
> one, and then create that using the API and slot values into it.
> Any thoughts on what approach would be the most reasonable?
> Thanks!
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Lua API Question

Ah, I guess somehow I had missed that in the docs, that sounds good.  
I'll work on making that functional over the coming days.

Without burst, what I've seen so far is that the adcscope, which  
simply repeatedly asks that a sample be generated in a blocking way  
gets about 1.8 kHz sampling rate with smoothing enabled and 4 channels  
being sampled from on each loop.  I think this could go higher, but  
it's not terrible for a first go-round.  The ceiling for this platform  
should be around 1 Msample/s.

On Jan 28, 2009, at 2:21 AM, Bogdan Marinescu wrote:

> You could probably use this:
>
> =================
>
> lua_createtable
>
> [-0, +1, m]
>
> void lua_createtable (lua_State *L, int narr, int nrec);
>
> Creates a new empty table and pushes it onto the stack. The new table
> has space pre-allocated for narr array elements and nrec non-array
> elements. This pre-allocation is useful when you know exactly how many
> elements the table will have. Otherwise you can use the function
> lua_newtable.
>
> =================
>
> Then use lua_rawseti to set the elements in your newly created table.
>
> Best,
> Bogdan
>
> On Wed, Jan 28, 2009 at 3:16 AM, James Snyder  
> <jbsnyder at fanplastic.org> wrote:
>> Hi -
>> I've implemented smoothing functionality, which seems to work for  
>> me on the
>> Stellaris platform.  I'm sure there are a few bugs in there, and  
>> cases I
>> haven't covered, so I'm not quite done with it.  I'm open to  
>> suggestions if
>> I've done anything particularly ugly or problematic :-)   I also  
>> plan to
>> move the code around a little so that as much as possible is common  
>> to all
>> platforms.  I tried to limit platform-specific functionality at  
>> this go
>> around, so simlar code with platform specific driver calls changed  
>> should
>> work on all platforms, I think.
>> One thing I haven't implemented yet is the burst sampling  
>> function.  I
>> haven't done this yet because I haven't decided how I want to  
>> return the
>> results to Lua.  I was originally thinking that I wanted to return  
>> some sort
>> of array or table, so that one could do, for example:
>> res = adc.burst(id, timer_id, freq)
>> and have res be a table containing the returned samples, however, I  
>> don't
>> see a method to push such a thing onto the stack used to transfer  
>> between
>> Lua and C.
>> I suppose the table could be created first in lua, pass that to  
>> adc.burst
>> and use the api functions to manipulate the table:
>> res_table = {}
>> adc.burst(id,res_table,timer_id,freq)
>> Of course this option makes returning results in a non-blocking  
>> manner a
>> little easier since I assume I can have my interrupt stick values  
>> into the
>> table at a later point.  The main thing I don't like about it is  
>> that if I
>> accept a table, I don't really know what I'm going to get.  Will it  
>> be
>> empty? Do I replace key->value pairs or only add them?
>> I suppose another option could be that I accept not a table, but a  
>> name for
>> one, and then create that using the API and slot values into it.
>> Any thoughts on what approach would be the most reasonable?
>> Thanks!
>> --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> jbsnyder at fanplastic.org
>> http://fanplastic.org/key.txt
>> ph: (847) 644-2322
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 644-2322

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090128/c39c6395/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090128/c39c6395/attachment.pgp