ADC module on STR912
Locked
 
|
Mauricio Henrique Bomfim |
ADC module on STR912
|
Hi,
I've just built the the eLua trunk for a STR912 and I'm trying to use the ADC module. Follows, my code: adc.setblocking(0, 0) -- no blocking on any channels adc.setsmoothing(0, 4) -- set smoothing from adcsmoothing table adc.setclock(0, 4, 0) The error I get: stdin:1: timer 0 not valid with adc 0 stack traceback: [C]: in function 'setclock' stdin:1: in main chunk [C]: ? I've tried all combinations of timers IDs and ADC IDs, but none has worked. Am I doing something wrong? Thanks, Mauricio _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Oct 18, 2010 at 10:09 PM, Mauricio Henrique Bomfim
<[hidden email]> wrote: > Hi, > > I've just built the the eLua trunk for a STR912 and I'm trying to > use the ADC module. Follows, my code: > > adc.setblocking(0, 0) -- no blocking on any channels > adc.setsmoothing(0, 4) -- set smoothing from adcsmoothing table > adc.setclock(0, 4, 0) > > The error I get: > > stdin:1: timer 0 not valid with adc 0 > stack traceback: > [C]: in function 'setclock' > stdin:1: in main chunk > [C]: ? > > I've tried all combinations of timers IDs and ADC IDs, but none has worked. > > Am I doing something wrong? I can see this in src/platform/str9/platform.c: int platform_adc_check_timer_id( unsigned id, unsigned timer_id ) { return 0; // This platform does not support direct timer triggering } Apparently there is no support for ADC triggering using a timer in STR9. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hello List,
On Mon, Oct 18, 2010 at 17:36, Bogdan Marinescu <[hidden email]> wrote:
Right. And this was done (by James Snyder) because some versions of the MCU chip do not generate the int on timer events. Apparently the newer ones do but he had to do it for stability purposes. Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, manually on the Lua ISR now available in eLua. Best, Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> Right.
> And this was done (by James Snyder) because some versions of the MCU chip do > not generate the int on timer events. Apparently the newer ones do but he > had to do it for stability purposes. Ah, are you talking about the STR912FW44 versus the STR912FAW44? If so, you can probably use the timer feature (which I assume is available in the A version) safely, as the old (non-A version) was obsoleted by ST quite a while ago. I'm not even sure one can purchase non-A chips anymore, at least not from a large distributor. I know that one of your STR-E912 boards uses the non-A version, but that's a dinosaur already :) > Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, > manually on the Lua ISR now available in eLua. If so, he needs support for timer interrupts. Mauricio, please let me know if this is the case. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
The STR-E912 has the FW part, not the FAW part. So, for an FAW, with
some minor modification we could add support for using the timers. Really, even without timer triggering, we could use a timer interrupt to do this sort of thing for us, but we don't do that on other platforms so I didn't want to suck up another timer in this manner. For now, one could use the eLua interrupt support, however I have in no way tested this :-) I'm planning to add to eLua interrupts to support C-side handlers for this sort of thing (that wouldn't need to wait on the interpreter), but I haven't yet done any implementation planning or experimentation. -jsnyder On Mon, Oct 18, 2010 at 3:21 PM, Bogdan Marinescu <[hidden email]> wrote: >> Right. >> And this was done (by James Snyder) because some versions of the MCU chip do >> not generate the int on timer events. Apparently the newer ones do but he >> had to do it for stability purposes. > > Ah, are you talking about the STR912FW44 versus the STR912FAW44? If > so, you can probably use the timer feature (which I assume is > available in the A version) safely, as the old (non-A version) was > obsoleted by ST quite a while ago. I'm not even sure one can purchase > non-A chips anymore, at least not from a large distributor. I know > that one of your STR-E912 boards uses the non-A version, but that's a > dinosaur already :) > >> Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, >> manually on the Lua ISR now available in eLua. > > If so, he needs support for timer interrupts. Mauricio, please let me > know if this is the case. > > Best, > Bogdan > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Oct 18, 2010 at 11:41 PM, James Snyder <[hidden email]> wrote:
> The STR-E912 has the FW part, not the FAW part. So, for an FAW, with > some minor modification we could add support for using the timers. They have two of them actually, one with the FW and the other one with the FAW. > Really, even without timer triggering, we could use a timer interrupt > to do this sort of thing for us, but we don't do that on other > platforms so I didn't want to suck up another timer in this manner. I can implement a timer interrupt in Lua, but this will probably take a while. > For now, one could use the eLua interrupt support, however I have in > no way tested this :-) I'm planning to add to eLua interrupts to > support C-side handlers for this sort of thing (that wouldn't need to > wait on the interpreter), but I haven't yet done any implementation > planning or experimentation. Completely agreed on the C-side handlers. Let's talk about this if you start planning, there are quite a few things to consider with all this interrupt support story. Best, Bogdan > > -jsnyder > > On Mon, Oct 18, 2010 at 3:21 PM, Bogdan Marinescu > <[hidden email]> wrote: >>> Right. >>> And this was done (by James Snyder) because some versions of the MCU chip do >>> not generate the int on timer events. Apparently the newer ones do but he >>> had to do it for stability purposes. >> >> Ah, are you talking about the STR912FW44 versus the STR912FAW44? If >> so, you can probably use the timer feature (which I assume is >> available in the A version) safely, as the old (non-A version) was >> obsoleted by ST quite a while ago. I'm not even sure one can purchase >> non-A chips anymore, at least not from a large distributor. I know >> that one of your STR-E912 boards uses the non-A version, but that's a >> dinosaur already :) >> >>> Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, >>> manually on the Lua ISR now available in eLua. >> >> If so, he needs support for timer interrupts. Mauricio, please let me >> know if this is the case. >> >> Best, >> Bogdan >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > _______________________________________________ > 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 |
|
|
On Mon, Oct 18, 2010 at 3:47 PM, Bogdan Marinescu
<[hidden email]> wrote: > On Mon, Oct 18, 2010 at 11:41 PM, James Snyder <[hidden email]> wrote: >> The STR-E912 has the FW part, not the FAW part. So, for an FAW, with >> some minor modification we could add support for using the timers. > > They have two of them actually, one with the FW and the other one with the FAW. I'm not sure I understand what you're saying here. I do understand that there are two revisions of ST parts for this, but I don't think there's an STR-E912 w/ an FAW part, unless I'm missing something: http://www.olimex.com/dev/str-e912.html It would certainly be natural for them to replace the FW part with an FAW, especially if there's an equivalent FAW w/ the same footprint and pin configuration. > >> Really, even without timer triggering, we could use a timer interrupt >> to do this sort of thing for us, but we don't do that on other >> platforms so I didn't want to suck up another timer in this manner. > > I can implement a timer interrupt in Lua, but this will probably take a while. With the eLua interrupt support? Wouldn't this just be a matter of adding another interrupt slot for a timer in addition to the ones you've done before and having a handler that behaves similarly to the other existing handlers? Or are you thinking of something more elaborate? > >> For now, one could use the eLua interrupt support, however I have in >> no way tested this :-) I'm planning to add to eLua interrupts to >> support C-side handlers for this sort of thing (that wouldn't need to >> wait on the interpreter), but I haven't yet done any implementation >> planning or experimentation. > > Completely agreed on the C-side handlers. Let's talk about this if you > start planning, there are quite a few things to consider with all this > interrupt support story. Indeed. I have to look at the implementation before making a detailed plan, but my thought is that the C side should have some way of checking if a registered handler is a Lua handler or a C handler, and that if there's a C-side handler, instead of enqueuing the need to call a Lua function, it just calls the C handler. Perhaps there could also be some mechanism for it to tell Lua that a C-side hander was called, but I suspect that might not be needed. I don't mind if, for the moment, we don't even provide a Lua-side way to set such handlers (though Lua should be able to set/replace C side handlers with Lua ones if it wants). I just feel that if we're adding an interrupt system to eLua it'd be better to plug into it and write some generalized code that would allow any platform with timer interrupts and ADC to suddenly be able to use this type of timer-driven conversion with only having written software-initiated conversions. This will also give us a somewhat crude (latency-wise) way to trigger ADC conversions on digital input interrupts or any other interrupt which our system knows about. If users had need specific platforms could implement the functionality using hardware triggers as needed. I rather like having the generic versions be available, since doing platform specific implementations for every platform of this sort of thing would require quite a bit of work and might only be useful to a small number of individuals. > > Best, > Bogdan > >> >> -jsnyder >> >> On Mon, Oct 18, 2010 at 3:21 PM, Bogdan Marinescu >> <[hidden email]> wrote: >>>> Right. >>>> And this was done (by James Snyder) because some versions of the MCU chip do >>>> not generate the int on timer events. Apparently the newer ones do but he >>>> had to do it for stability purposes. >>> >>> Ah, are you talking about the STR912FW44 versus the STR912FAW44? If >>> so, you can probably use the timer feature (which I assume is >>> available in the A version) safely, as the old (non-A version) was >>> obsoleted by ST quite a while ago. I'm not even sure one can purchase >>> non-A chips anymore, at least not from a large distributor. I know >>> that one of your STR-E912 boards uses the non-A version, but that's a >>> dinosaur already :) >>> >>>> Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, >>>> manually on the Lua ISR now available in eLua. >>> >>> If so, he needs support for timer interrupts. Mauricio, please let me >>> know if this is the case. >>> >>> Best, >>> Bogdan >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> [hidden email] >> PGP: http://fanplastic.org/key.txt >> Phone: (847) 448-0386 >> _______________________________________________ >> 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 > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> I'm not sure I understand what you're saying here. I do understand
> that there are two revisions of ST parts for this, but I don't think > there's an STR-E912 w/ an FAW part, unless I'm missing something: > http://www.olimex.com/dev/str-e912.html You're not really missing anything,but the guys at Olimex are missing some information on their web page. In this particular case, for example, I bought the two boards myself :), and so I know for a fact that one of them comes with the FAW. Kind of a lottery when you order them though. > It would certainly be natural for them to replace the FW part with an > FAW, especially if there's an equivalent FAW w/ the same footprint and > pin configuration. They have the exact same footprint and pin configuration. The story behind the FAW as I know it is that the FW had so many sillicon bugs and limitations that they completely forgot about it and launched the FAW instead. Other than that, there are no functional differences between them. > With the eLua interrupt support? Wouldn't this just be a matter of > adding another interrupt slot for a timer in addition to the ones > you've done before and having a handler that behaves similarly to the > other existing handlers? Or are you thinking of something more > elaborate? There are always virtual timers ... :) Which screams for a more generic mechanism. And at this point, the current limitations of the interrupt support make it awkward to deal with situations like this. This is why I mentioned some while ago that I want to change the interrupt architecture "a bit". For now though I can just implement a simple timer overflow interrupt as a temporary hack and be done with it. > Indeed. I have to look at the implementation before making a detailed > plan, but my thought is that the C side should have some way of > checking if a registered handler is a Lua handler or a C handler, and > that if there's a C-side handler, instead of enqueuing the need to > call a Lua function, it just calls the C handler. Perhaps there could > also be some mechanism for it to tell Lua that a C-side hander was > called, but I suspect that might not be needed. I was thinking that they could be both. The interrupt handler would first call the C handler (if enabled), then the Lua handler (if enabled). A timer interrupt (for example) can benefit from an approach like this. > I don't mind if, for the moment, we don't even provide a Lua-side way > to set such handlers (though Lua should be able to set/replace C side > handlers with Lua ones if it wants). I'd keep them separated: Lua sets Lua handlers, C sets C handlers. Easier to manage from this perspective. > I just feel that if we're adding > an interrupt system to eLua it'd be better to plug into it and write > some generalized code that would allow any platform with timer > interrupts and ADC to suddenly be able to use this type of > timer-driven conversion with only having written software-initiated > conversions. Precisely one of the main reasons I want to modify the interrupt support in eLua. > This will also give us a somewhat crude (latency-wise) way to trigger > ADC conversions on digital input interrupts or any other interrupt > which our system knows about. If users had need specific platforms > could implement the functionality using hardware triggers as needed. > I rather like having the generic versions be available, since doing > platform specific implementations for every platform of this sort of > thing would require quite a bit of work and might only be useful to a > small number of individuals. 100% agreed. Best, Bogdan >>> On Mon, Oct 18, 2010 at 3:21 PM, Bogdan Marinescu >>> <[hidden email]> wrote: >>>>> Right. >>>>> And this was done (by James Snyder) because some versions of the MCU chip do >>>>> not generate the int on timer events. Apparently the newer ones do but he >>>>> had to do it for stability purposes. >>>> >>>> Ah, are you talking about the STR912FW44 versus the STR912FAW44? If >>>> so, you can probably use the timer feature (which I assume is >>>> available in the A version) safely, as the old (non-A version) was >>>> obsoleted by ST quite a while ago. I'm not even sure one can purchase >>>> non-A chips anymore, at least not from a large distributor. I know >>>> that one of your STR-E912 boards uses the non-A version, but that's a >>>> dinosaur already :) >>>> >>>>> Mauricio, I'm afraid you'll have to handle the conversion-on-timer you want, >>>>> manually on the Lua ISR now available in eLua. >>>> >>>> If so, he needs support for timer interrupts. Mauricio, please let me >>>> know if this is the case. >>>> >>>> Best, >>>> Bogdan >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>> >>> >>> >>> -- >>> James Snyder >>> Biomedical Engineering >>> Northwestern University >>> [hidden email] >>> PGP: http://fanplastic.org/key.txt >>> Phone: (847) 448-0386 >>> _______________________________________________ >>> 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 >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > _______________________________________________ > 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 |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |