How to get precisely times samples?
Locked
12
12
 
|
Martin Guy |
How to get precisely times samples?
|
Hi
I'm trying to fix the ADC module on AVR32, and am having some difficulty understanding what I need to do to get precisely-timed samples. For example, the seismographs here on Mount Etna sample at the rate of 27.27Hz, for which a small solar-powered data collecting station would be perfect, but I don't see how to do this yet. I see "adc.setclock()" and "adc.getsamples()", but on AVR32 adc.setclock() is not implemented and adc.getsamples() always returns nil, which leaves me with getsample(), which works, and tmr.delay(), but that would only give an approximate rate of 27.something, depending on CPU speed, the garbage collector and so on. Do adc.settimer() and adc.getsamples() work on other platforms? If so, which platforms, so I can try to make the AVR32 implementation work the same way? Thanks M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
It just so happens my current job is in the seismic industry. I can
go on at length about how to get precisely timed samples from an ADC, but I won't be able to tell you how to do it from elua. Contact me offline if you like. !!Dean On Jul 12, 2011, at 19:17 , Martin Guy wrote: > Hi > I'm trying to fix the ADC module on AVR32, and am having some > difficulty understanding what I need to do to get precisely-timed > samples. > For example, the seismographs here on Mount Etna sample at the rate of > 27.27Hz, for which a small solar-powered data collecting station would > be perfect, but I don't see how to do this yet. > > I see "adc.setclock()" and "adc.getsamples()", but on AVR32 > adc.setclock() is not implemented and adc.getsamples() always returns > nil, which leaves me with getsample(), which works, and tmr.delay(), > but that would only give an approximate rate of 27.something, > depending on CPU speed, the garbage collector and so on. > > Do adc.settimer() and adc.getsamples() work on other platforms? If > so, which platforms, so I can try to make the AVR32 implementation > work the same way? > > Thanks > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: How to get precisely times samples?
|
|
On Tue, Jul 12, 2011 at 20:40, Dean Hall <[hidden email]> wrote: It just so happens my current job is in the seismic industry. I can go on at length about how to get precisely timed samples from an ADC, but I won't be able to tell you how to do it from elua. Contact me offline if you like. Please keep this (interesting !) discussion here on the list as much as you can, specially if it will continue to be related to eLua.
Thanks Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Tue, Jul 12, 2011 at 7:17 PM, Martin Guy <[hidden email]> wrote:
> Hi > I'm trying to fix the ADC module on AVR32, and am having some > difficulty understanding what I need to do to get precisely-timed > samples. > For example, the seismographs here on Mount Etna sample at the rate of > 27.27Hz, for which a small solar-powered data collecting station would > be perfect, but I don't see how to do this yet. > > I see "adc.setclock()" and "adc.getsamples()", but on AVR32 > adc.setclock() is not implemented and adc.getsamples() always returns > nil, which leaves me with getsample(), which works, and tmr.delay(), > but that would only give an approximate rate of 27.something, > depending on CPU speed, the garbage collector and so on. > > Do adc.settimer() and adc.getsamples() work on other platforms? If > so, which platforms, so I can try to make the AVR32 implementation > work the same way? getsamples should be working regardless, I'll take a look at that. settimer isn't enabled because when I initially added ADC support for AVR32, I believe I found that for UC3A0 parts that timer triggers couldn't be used for ADC (and instead one would have to set up timer interrupts to initiate ADC conversions). It does work on other platforms that have hardware timer trigger support. Now that I'm looking around at the documentation I can't seem to find what parts actually support triggered conversions and what don't. The UC3A manual says this about timer triggers: "Timer Counters may or may not be used as hardware triggers depending on user requirements. Thus, some or all of the timer counters may be non-connected." Then when looking at the register field descriptions for the trigger selection (TRGSEL: Trigger Selection), it has a list of internal triggers which are all labelled like this: "Internal Trigger 0, depending of chip integration Internal Trigger 1, depending of chip integration Internal Trigger 2, depending of chip integration ... " This is all in doc 32058 dated april 4/2011. If there's some documentation somewhere indicating what parts have this functionality and how its configured, it should be fairly straightforward to add hardware triggered ADC support. If not, we can use timer interrupts which I've been intending to add support for, but haven't gotten around to yet. > > Thanks > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
On 13 July 2011 04:17, James Snyder <[hidden email]> wrote:
> On Tue, Jul 12, 2011 at 7:17 PM, Martin Guy <[hidden email]> wrote: > settimer isn't enabled because when I initially added ADC support for > AVR32, I believe I found that for UC3A0 parts that timer triggers > couldn't be used for ADC (and instead one would have to set up timer > interrupts to initiate ADC conversions). It does work on other > platforms that have hardware timer trigger support. Now that I'm > looking around at the documentation I can't seem to find what parts > actually support triggered conversions and what don't. The UC3A manual > says this about timer triggers: > "Timer Counters may or may not be used as hardware triggers depending > on user requirements. Thus, some or all of the timer counters may be > non-connected." > > Then when looking at the register field descriptions for the trigger > selection (TRGSEL: Trigger Selection), it has a list of internal > triggers which are all labelled like this: > "Internal Trigger 0, depending of chip integration > Internal Trigger 1, depending of chip integration > Internal Trigger 2, depending of chip integration > This is all in doc 32058 dated april 4/2011. That's the one. It also says (in the same chapter) "The hardware trigger can be one of the TIOA outputs of the Timer Counter channels" of which there are three, although the TRGSEL can select one of six such inputs, "Internal trigger 0-5" Mystery. > If there's some documentation somewhere indicating what parts have > this functionality and how its configured, it should be fairly > straightforward to add hardware triggered ADC support. I've put a query on the avrfreaks forum http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 > If not, we can > use timer interrupts which I've been intending to add support for, but > haven't gotten around to yet. That sounds like the best solution, which would work on all platforms, including those without hardware trigger support. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Jul 13, 2011 at 9:50 AM, Martin Guy <[hidden email]> wrote:
> On 13 July 2011 04:17, James Snyder <[hidden email]> wrote: >> On Tue, Jul 12, 2011 at 7:17 PM, Martin Guy <[hidden email]> wrote: >> settimer isn't enabled because when I initially added ADC support for >> AVR32, I believe I found that for UC3A0 parts that timer triggers >> couldn't be used for ADC (and instead one would have to set up timer >> interrupts to initiate ADC conversions). It does work on other >> platforms that have hardware timer trigger support. Now that I'm >> looking around at the documentation I can't seem to find what parts >> actually support triggered conversions and what don't. The UC3A manual >> says this about timer triggers: >> "Timer Counters may or may not be used as hardware triggers depending >> on user requirements. Thus, some or all of the timer counters may be >> non-connected." >> >> Then when looking at the register field descriptions for the trigger >> selection (TRGSEL: Trigger Selection), it has a list of internal >> triggers which are all labelled like this: >> "Internal Trigger 0, depending of chip integration >> Internal Trigger 1, depending of chip integration >> Internal Trigger 2, depending of chip integration > >> This is all in doc 32058 dated april 4/2011. > > That's the one. It also says (in the same chapter) > "The hardware trigger can be one of the TIOA outputs of the Timer > Counter channels" Yeah, I saw that as well. Then there's also this in "1. Description" "The PWM modules provides seven independent channels with many configuration options including polarity, edge alignment and waveform non overlap control. One PWM channel can trigger ADC conversions for more accurate close loop control implementations." > of which there are three, although the TRGSEL can select one of six > such inputs, "Internal trigger 0-5" > Mystery. Yep, that's how I feel :-) I'm glad I'm not the only one who is a bit confused by this. > >> If there's some documentation somewhere indicating what parts have >> this functionality and how its configured, it should be fairly >> straightforward to add hardware triggered ADC support. > > I've put a query on the avrfreaks forum > http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 Thanks. I'll keep an eye on that. I don't know many people at Atmel, but I suppose I could also ask someone I've communicated with a few times around toolchain stuff. > >> If not, we can >> use timer interrupts which I've been intending to add support for, but >> haven't gotten around to yet. > > That sounds like the best solution, which would work on all platforms, > including those without hardware trigger support. It's also needed at least on older revisions of the STR9 platform, plus a number of other platforms have restrictions on timer usage for ADC triggering. I feel like the best way to do this might be to use the built-in interrupt support and have C-side handlers. This way we could make more of the code platform independent, though it requires that individual platforms that consume this functionality would have timer interrupts supported in eLua's interrupt system. There might be some downsides to using interrupts in terms of latency or effective clock jitter depending on whether latencies are constant but it's better than no timer trigger support and should just be documented when used for a given platform. I have a few other things pending in my queue but I'm happy to help with this as time allows. If there is some way to use periodic triggers in hardware with the AVR32 chips on the Mizar & EVK1100 I can put that together or help with it as well once theres some indication of what supports it and how to do it :-) > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: How to get precisely times samples?
|
|
On Wed, Jul 13, 2011 at 18:58, James Snyder <[hidden email]> wrote:
Yes and I'm afraid that the eLua INT system will be a bit slow for fast triggered ADC conversions. The API would have to be enhanced with some get-the-final-conversion-set instructions or something. There might be some downsides to using interrupts in terms of latency Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
In reply to this post by jbsnyder
On 14 July 2011 00:58, James Snyder <[hidden email]> wrote:
> On Wed, Jul 13, 2011 at 9:50 AM, Martin Guy <[hidden email]> wrote: >> I've put a query on the avrfreaks forum >> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 > > Thanks. I'll keep an eye on that. I don't know many people at Atmel, > but I suppose I could also ask someone I've communicated with a few > times around toolchain stuff. You saw the reply? Maybe UC3A is the same... >>> If not, we can >>> use timer interrupts which I've been intending to add support for, but >>> haven't gotten around to yet. >> >> That sounds like the best solution, which would work on all platforms, >> including those without hardware trigger support. > > There might be some downsides to using interrupts in terms of latency > or effective clock jitter depending on whether latencies are constant > but it's better than no timer trigger support and should just be > documented when used for a given platform. True. I hadn't thought of that. For something like audio, timing jitter would introduce extra noise. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Jul 13, 2011 at 7:53 PM, Martin Guy <[hidden email]> wrote:
> On 14 July 2011 00:58, James Snyder <[hidden email]> wrote: >> On Wed, Jul 13, 2011 at 9:50 AM, Martin Guy <[hidden email]> wrote: >>> I've put a query on the avrfreaks forum >>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 >> >> Thanks. I'll keep an eye on that. I don't know many people at Atmel, >> but I suppose I could also ask someone I've communicated with a few >> times around toolchain stuff. > > You saw the reply? Maybe UC3A is the same... Yep, caught it after you sent this message. Strangely that topic isn't loading for me anymore? Not sure if this is a database glitch or otherwise. I could certainly give it a try, however I'd like some documentation that clearly indicates which devices this should be attempted on vs not. > >>>> If not, we can >>>> use timer interrupts which I've been intending to add support for, but >>>> haven't gotten around to yet. >>> >>> That sounds like the best solution, which would work on all platforms, >>> including those without hardware trigger support. >> >> There might be some downsides to using interrupts in terms of latency >> or effective clock jitter depending on whether latencies are constant >> but it's better than no timer trigger support and should just be >> documented when used for a given platform. > > True. I hadn't thought of that. For something like audio, timing > jitter would introduce extra noise. I haven't investigated the various platforms. Cortex-M3 is supposed to be a pretty large improvement over previous ARM designs, but I have no idea what it's like on AVR32. It does appear that there is a priority system, which should be useful for situations like this. One positive thing is that for things like timer interrupts, the volume of code executed should be fairly small since it basically comes down to verifying the interrupt source and initiating a software conversion. I think it's a good backup to have, but wherever possible I'd like to use hardware support if it exists. One other thing that has occurred to me is that the AVR32 manuals mention using PWM to trigger interrupts, and I think I understood that external interrupts may be supported even if the timer ones are not. I'm wondering that another possibility might be to "sacrifice" a pin to have its state toggled through PWM or otherwise and have that trigger ADC conversions? I think I'll ping the individual I've communicated with before at Atmel and see if even if he might not know off-hand if he could forward the request to the appropriate individual(s) and maybe get that manual/datasheet fixed at the same time. Given that it's missing that section, I wonder if that's a typo in a recent version and that information was in older versions of the same? Best. -jsnyder > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
On 18 July 2011 02:39, James Snyder <[hidden email]> wrote:
> On Wed, Jul 13, 2011 at 7:53 PM, Martin Guy <[hidden email]> wrote: >>>> I've put a query on the avrfreaks forum >>>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 > Yep, caught it after you sent this message. Strangely that topic > isn't loading for me anymore? Not sure if this is a database glitch > or otherwise. "Could not obtain topic information" Hum. It seems like avrfreaks (a division of Atmel) have a web manager just as good as eluaproject's... > I'm wondering that another possibility might be to "sacrifice" a pin > to have its state toggled through PWM or otherwise and have that > trigger ADC conversions? Why? It looks. from what I remember of their site, that it can be done with regular timer interrupts. The 6 channels were either timer0 timer1 timer2 pwm0 pwm1 pwm2 or timer0 pwm0 timer1 pwm1 timer2 pwm2 I forget which. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: How to get precisely times samples?
|
|
On Sun, Jul 17, 2011 at 23:28, Martin Guy <[hidden email]> wrote:
.... or maybe they don't have one as we don't, are as busy as we all are, with as few resources and help as we are, having to work with so many other projects to keep their dream-project alive and also still have to deal with this type of comments. It doesn't seem to be the case of such a large division of such a large and well established company though. It is more likely to be related to some other things that reality sometimes surprises us withl; very unlikely-to-happen accidents.
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
In reply to this post by Martin Guy
On 18 July 2011 05:28, Martin Guy <[hidden email]> wrote:
> On 18 July 2011 02:39, James Snyder <[hidden email]> wrote: >> On Wed, Jul 13, 2011 at 7:53 PM, Martin Guy <[hidden email]> wrote: >>>>> I've put a query on the avrfreaks forum >>>>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 >> Yep, caught it after you sent this message. Strangely that topic >> isn't loading for me anymore? Not sure if this is a database glitch >> or otherwise. > > "Could not obtain topic information" Ok, it's back up. Here's a copy of the reply, which I remembered wrongly... --------- digitalDan, Posted: Jul 13, 2011 - 11:56 PM Interesting. It seems Atmel omitted a vital section from the UC3A datasheet. The UC3B data sheet has an additional section in the ADC chapter titled "Module Configuration" which contains the following table: Feature ADC Number of Channels 8 Internal Trigger 0 TIOA Ouput A of the Timer Counter Channel 0 Internal Trigger 1 TIOB Ouput B of the Timer Counter Channel 0 Internal Trigger 2 TIOA Ouput A of the Timer Counter Channel 1 Internal Trigger 3 TIOB Ouput B of the Timer Counter Channel 1 Internal Trigger 4 TIOA Ouput A of the Timer Counter Channel 2 Internal Trigger 5 TIOB Ouput B of the Timer Counter Channel 2 I have no idea if the UC3As are the same as UC3Bs in this regard. You should contact Atmel and see what they have to say about it. --------- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
In reply to this post by Martin Guy
On 13 July 2011 02:17, Martin Guy <[hidden email]> wrote:
> For example, the seismographs here on Mount Etna sample at the rate of > 27.27Hz, for which a small solar-powered data collecting station would > be perfect, but I don't see how to do this yet. Ah, it can't be expressed in eLua because free-running ADC frequencies are currently integers at the C platform interface. Changing it to lua_Number and making the associated changes in each platform implementation would make this possible, but unfortunately six of the adc functions, including adc.setclock(), all go through platform_adc_op() which forces the parameters and return values of six different functions to be of the same type, u32, whereas in reality they are of different types: GET_MAXVAL takes nothing and returns an ADC conversion value SET_SMOOTHING takes a power-of-two filter length and returns nothing SET_BLOCKING takes a boolean and returns nothing IS_DONE takes nothing and returns a boolean SET_TIMER takes a timer ID and returns nothing SET_CLOCK takes a frequency in Hz and returns a frequency in Hz. The six module functions, adc_getmaxval() and so on, each do their own thing for their parameters, then call platform_asdc_op() with a different constant "operation" parameter, then platform_adc_op just examines the "operation" parameter and does six different, unrelated things. I can't see an advantage to uniting these six functions at the C platform interface and attach a patch to make them six separate functions, which also makes the documentation simpler and clearer. It should also be very slightly faster and saves 26 bytes of code :) If this seems like a good idea to other people, can someone review these changes and check that they work on a platform with a full ADC implementation? I also noticed that the SET_FREERUNNING primitive is undocumented and is never called from anywhere, although a lot of platform code checks the value of s->freerunning (which I guess is always 0). Is this a work in progress awaiting completion? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
elua-separate-adc-ops.patch (18K) |
|
In reply to this post by Martin Guy
On Mon, Jul 18, 2011 at 8:52 AM, Martin Guy <[hidden email]> wrote:
> On 18 July 2011 05:28, Martin Guy <[hidden email]> wrote: >> On 18 July 2011 02:39, James Snyder <[hidden email]> wrote: >>> On Wed, Jul 13, 2011 at 7:53 PM, Martin Guy <[hidden email]> wrote: >>>>>> I've put a query on the avrfreaks forum >>>>>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=848231 >>> Yep, caught it after you sent this message. Strangely that topic >>> isn't loading for me anymore? Not sure if this is a database glitch >>> or otherwise. >> >> "Could not obtain topic information" > > Ok, it's back up. Here's a copy of the reply, which I remembered wrongly... > --------- > digitalDan, Posted: Jul 13, 2011 - 11:56 PM > > Interesting. It seems Atmel omitted a vital section from the UC3A > datasheet. The UC3B data sheet has an additional section in the ADC > chapter titled "Module Configuration" which contains the following > table: > > Feature ADC > Number of Channels 8 > Internal Trigger 0 TIOA Ouput A of the Timer Counter Channel 0 > Internal Trigger 1 TIOB Ouput B of the Timer Counter Channel 0 > Internal Trigger 2 TIOA Ouput A of the Timer Counter Channel 1 > Internal Trigger 3 TIOB Ouput B of the Timer Counter Channel 1 > Internal Trigger 4 TIOA Ouput A of the Timer Counter Channel 2 > Internal Trigger 5 TIOB Ouput B of the Timer Counter Channel 2 > > I have no idea if the UC3As are the same as UC3Bs in this regard. You > should contact Atmel and see what they have to say about it. > --------- That's what I thought I had recalled. I've emailed Atmel about it, so hopefully that can get us a more definitive answer. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
In reply to this post by Dado Sutter
On 18 July 2011 08:51, Dado Sutter <[hidden email]> wrote:
> .... or maybe they don't have one as we don't, are as busy as we all are, Sorry, yes, that was a pointless and offensive remark on my part. I'm not sure why I seem to have this strange need to sneer at other people's work, but I am working on it. Please forgive me M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Mon, Jul 18, 2011 at 12:45 PM, Martin Guy <[hidden email]> wrote:
> On 13 July 2011 02:17, Martin Guy <[hidden email]> wrote: >> For example, the seismographs here on Mount Etna sample at the rate of >> 27.27Hz, for which a small solar-powered data collecting station would >> be perfect, but I don't see how to do this yet. > > Ah, it can't be expressed in eLua because free-running ADC frequencies > are currently integers at the C platform interface. So, are you suggesting changing it so that it could be expressed in floating point or fixed point units as well? > > Changing it to lua_Number One thing we should keep in mind is making sure that such a change should work for both integer and floating point versions of eLua. Also, so far we don't pass any lua types or floating point types through the platform interface. This also brings up the issue of non-integer PWM percentages... > and making the associated changes in each > platform implementation would make this possible, but unfortunately > six of the adc functions, including adc.setclock(), all go through > platform_adc_op() which forces the parameters and return values of six > different functions to be of the same type, u32, whereas in reality > they are of different types: > GET_MAXVAL takes nothing and returns an ADC conversion value > SET_SMOOTHING takes a power-of-two filter length and returns nothing > SET_BLOCKING takes a boolean and returns nothing > IS_DONE takes nothing and returns a boolean > SET_TIMER takes a timer ID and returns nothing > SET_CLOCK takes a frequency in Hz and returns a frequency in Hz. > > The six module functions, adc_getmaxval() and so on, each do their own > thing for their parameters, then call platform_asdc_op() with a > different constant "operation" parameter, then platform_adc_op just > examines the "operation" parameter and does six different, unrelated > things. > > I can't see an advantage to uniting these six functions at the C > platform interface and attach a patch to make them six separate > functions, which also makes the documentation simpler and clearer. It > should also be very slightly faster and saves 26 bytes of code :) > > If this seems like a good idea to other people, can someone review > these changes and check that they work on a platform with a full ADC > implementation? On this front, probably fair enough. When I wrote the platform interface I was following the other platform interfaces which used the _op function, which is similar to a lot of POSIX functionality. I can try applying this on one or two platforms and see if it works for me. > > I also noticed that the SET_FREERUNNING primitive is undocumented and > is never called from anywhere, although a lot of platform code checks > the value of s->freerunning (which I guess is always 0). Is this a > work in progress awaiting completion? It was something that I implemented, but there wasn't popular support for. Essentially, if I recall, what it would do would be constantly write into the ring buffer and expire values even if they hadn't been picked up so that you would always get fresh data. Right now I don't recall whether it simply requires setting the option to make it work or if it's broken. I think it likely still works, there's just not way to turn it on and off at the moment. If nobody wants it, I guess we can remove it. > > M > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
On 18 July 2011 20:13, James Snyder <[hidden email]> wrote:
> On Mon, Jul 18, 2011 at 12:45 PM, Martin Guy <[hidden email]> wrote: >> On 13 July 2011 02:17, Martin Guy <[hidden email]> wrote: >>> For example, the seismographs here on Mount Etna sample at the rate of >>> 27.27Hz, for which a small solar-powered data collecting station would >>> be perfect, but I don't see how to do this yet. >> >> Ah, it can't be expressed in eLua because free-running ADC frequencies >> are currently integers at the C platform interface. > > So, are you suggesting changing it so that it could be expressed in > floating point or fixed point units as well? Yes, but making sure that when LUA_NUMBER_INTEGRAL, everything is integral. If Lua is compiled with its usual floating point numbers, the FP support will be in the executable anyway. This should make no difference to the Lua interface, it would just mean that the decimal places in frequencies survive down to where they need to be used, when they can. >> Changing it to lua_Number > > One thing we should keep in mind is making sure that such a change > should work for both integer and floating point versions of eLua. > Also, so far we don't pass any lua types or floating point types > through the platform interface. > > This also brings up the issue of non-integer PWM percentages... True, It would be a solution to that too... at least, when compiling floating-point Lua. > On this front, probably fair enough. When I wrote the platform > interface I was following the other platform interfaces which used the > _op function, which is similar to a lot of POSIX functionality. Right. A similar mechanism is used in PWM, TIMER and PIO. In the case of PIO, the handling of port/pin selection and processing of the variable arguments to specify pins is done in one place for six eLua functions . PWM doesn't gain anything from it, and TIMER only saves 3 lines of code. But the downside is that it denies the compiler some opportunities for code optimization. > I can try applying this on one or two platforms and see if it works for me. Thanks. Don't apply that patch to trunk though as the documentation part was not correct. I think the code is OK except for one wart, which is that, as a result of the split, it ends up with two functions, one called platform_adc_set_clock() and the other called platform_adc_setclock(), which do the same thing (the one just calls the other). setclock() is the platform-specific one implemented in 6 places, while set_clock is the new C program interface name derived from PLATFORM_ADC_OP_SET_CLOCK. As setclock is the only one of the platform_adc_*() function where two words are united, I guess we can rename platform_adc_setclock() to platform_adc_set_clock() everywhere. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: How to get precisely times samples?
|
|
In reply to this post by Martin Guy
On Mon, Jul 18, 2011 at 13:52, Martin Guy <[hidden email]> wrote:
My sincere thanks and apologies for my unnecessary over-reactions too Martin. You've been doing a great work from the start and I don't want do disturb this in any way.
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Mon, Jul 18, 2011 at 2:02 PM, Martin Guy <[hidden email]> wrote:
> On 18 July 2011 20:13, James Snyder <[hidden email]> wrote: >> On Mon, Jul 18, 2011 at 12:45 PM, Martin Guy <[hidden email]> wrote: >>> On 13 July 2011 02:17, Martin Guy <[hidden email]> wrote: >>>> For example, the seismographs here on Mount Etna sample at the rate of >>>> 27.27Hz, for which a small solar-powered data collecting station would >>>> be perfect, but I don't see how to do this yet. >>> >>> Ah, it can't be expressed in eLua because free-running ADC frequencies >>> are currently integers at the C platform interface. >> >> So, are you suggesting changing it so that it could be expressed in >> floating point or fixed point units as well? > > Yes, but making sure that when LUA_NUMBER_INTEGRAL, everything is integral. > If Lua is compiled with its usual floating point numbers, the FP > support will be in the executable anyway. > This should make no difference to the Lua interface, it would just > mean that the decimal places in frequencies survive down to where they > need to be used, when they can. Indeed. My only point here is that so far we've intentionally kept types that are defined by Lua out of the platform layer so that they don't depend on Lua itself, and that we also only have integer types. This doesn't preclude enabling some sort of union or "number" type from Lua that passes through this layer than can have varying type, but it changes an existing policy. There are two ways I can think of that could remain exclusively integer: 1) Passing optional divisors. For PWM, at one point, I suggested that we could allow finer resolution duty cyles by allowing other fractions than per cent such as /1000 (per mil) or 10000 (per basis point). Clock frequencies could have this as well, either fixed or arbitrary divisors passed as a parameter. 2) Something similar to POSIX's timer API which allows specification of a low and higher resolution component. i.e.: integer Hz + integer µHz or nHz. This came up a while ago, and wasn't for setting clock frequencies, more for timer intervals, but one could use it for clock frequencies as well. So that you would define that you wanted 27 Hz + 270000 µHz or something similar Just a few thoughts. In some ways the gymnastics necessary for the user, interface implementer, and backend implementer start making the floating point version sound appealing :-) > >>> Changing it to lua_Number >> >> One thing we should keep in mind is making sure that such a change >> should work for both integer and floating point versions of eLua. >> Also, so far we don't pass any lua types or floating point types >> through the platform interface. >> >> This also brings up the issue of non-integer PWM percentages... > > True, It would be a solution to that too... at least, when compiling > floating-point Lua. > >> On this front, probably fair enough. When I wrote the platform >> interface I was following the other platform interfaces which used the >> _op function, which is similar to a lot of POSIX functionality. > > Right. A similar mechanism is used in PWM, TIMER and PIO. > In the case of PIO, the handling of port/pin selection and processing > of the variable arguments to specify pins is done in one place for six > eLua functions . PWM doesn't gain anything from it, and TIMER only > saves 3 lines of code. But the downside is that it denies the compiler > some opportunities for code optimization. It's certainly making some decisions for the compiler. I'm not sure whether in the end it comes out as much of a benefit in terms of code space or stack usage. It might be a bit of a wash, but one never knows :-) I was persuaded by your noting how how often the 32 bit passed/returned parameters are used. You're right that it might give it a chance to inline things that it otherwise wouldn't which could save some stack and instructions. > >> I can try applying this on one or two platforms and see if it works for me. > > Thanks. Don't apply that patch to trunk though as the documentation > part was not correct. I think the code is OK except for one wart, > which is that, as a result of the split, it ends up with two > functions, one called platform_adc_set_clock() and the other called > platform_adc_setclock(), which do the same thing (the one just calls > the other). setclock() is the platform-specific one implemented in 6 > places, while set_clock is the new C program interface name derived > from PLATFORM_ADC_OP_SET_CLOCK. As setclock is the only one of the > platform_adc_*() function where two words are united, I guess we can > rename platform_adc_setclock() to platform_adc_set_clock() everywhere. Noted. > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: How to get precisely times samples?
|
|
We seem to be talking about four separate questions here:
- turning the _op primitives into separate functions - allowing more precise low sampling frequencies, like Etna's seismographs at 27.27Hz, for ADC (and I guess PWM). - getting higher precision for duty cycles - use of floating point in order: - turning the _op primitives into separate functions The _op primitives seem to be imitating the ioctl() system call. However, the ioctl system call, with hundreds of "operations" and a single pointer parameter, was designed to collect hundreds of different device-specific functions without having to have hundreds of new system calls, and to allow the addition of new operations for new hardware devices without having to change the system call interface each time. In some Unix platforms the number of system calls is limited by the hardware/instruction set, so they were forced to put hundreds of different functions through a single hole. eLua doesn't have that limitation, since functions are cheap and not limited in number. Having one C function per operation also makes the documentation clearer, since each operation has its own paragraph instead of trying to document 6 different things mixed together. I assume there's no objection to turning these into separate functions where possible. - allowing more precise low sampling frequencies like Etna's seismographs at 27.27Hz, for ADC (and I guess PWM). I agree with not making floating point mandatory because one of eLua's design objectives is to run on embedded platforms where code size can be critical, and the floating point emulator adds 50K to the code size. On 19 July 2011 01:35, James Snyder <[hidden email]> wrote: > Indeed. My only point here is that so far we've intentionally kept > types that are defined by Lua out of the platform layer so that they > don't depend on Lua itself. Is that so that the C platform layer can be more easily re-used, say as the platform-driver layer for a different language, or in custom applications? > There are two ways I can think of that could remain exclusively integer: > 1) Passing optional divisors. For PWM, at one point, I suggested that > we could allow finer resolution duty cyles by allowing other fractions > than per cent such as /1000 (per mil) or 10000 (per basis point). > Clock frequencies could have this as well, either fixed or arbitrary > divisors passed as a parameter. I sort of like this idea - using an optional extra parameter in Lua which by default would be 100 (for percent) for duty cycles. The PWM setup function is currently: frequency = pwm.setup(id, frequency, duty_cycle) and, as far as duty cycle goes, this is OK, since it is the last parameter, but it does nothing for frequencies unless we add two optional parameters as divisors with default values of 100 and 1. Or 1 and 100. > 2) Something similar to POSIX's timer API POSIX is not a manual of good interface design. It was born as an attempt to unite the different ways that manufacturers had extended the original Unix kernel interfaces. All the new stuff since then comes from design-by-committee, which usually produces awful interfaces. Google POSIX timer API. > which allows specification > of a low and higher resolution component. i.e.: integer Hz + integer > µHz or nHz. This came up a while ago, and wasn't for setting clock > frequencies, more for timer intervals, but one could use it for clock > frequencies as well. So that you would define that you wanted 27 Hz + > 270000 µHz or something similar > Just a few thoughts. In some ways the gymnastics necessary for the > user, interface implementer, and backend implementer start making the > floating point version sound appealing :-) Not if floating point becomes necessary, since that goes against the "embedded" objective of eLua. I only suggested that for when FP is already enabled in Lua. If it isn't, the user has no way to express a floating point value from Lua anyway, or to receive an FP value back. What's the lesser of these evils: - no way to express low frequencies with precision, limited PWM duty cycle resolution (current situation) - higher precision in the FP version of Lua, lower precision in the integer one, for duty cycles and low frequencies - interfaces in Lua and C that express floating point values as some combination of integers M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |