Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 22:04:46 GMT
|
Viewed:
|
3277 times
|
| |
|
|
"Gunther Lemm" <lemm@lepomux.org> wrote:
> > Yes, the OCRA interrupt will cause the sample flow
> > to stutter a little bit (because the OCRB interrupt won't
> > be acknowledged until the OCRA handler finishes), but
> > if this is a concern, it could be avoided if you use sample
> > rates that are a multiple of the general 1ms general
> > interrupt (like 4 KHz) and sychronizing appropriately.
>
> Nice idea, but wouldn't that result in at least one of four cycles beeing
> blocked by OCRA? or is our system interrupt finished within less than
250msec?
Not blocked entirely, but delayed. That's what I meant by
"stutter". I've measured the general interrupt handler to take
anywhere from 70-150us. So, the higher the sample rate the
more significant the disruption. Anything faster than ~6 KHz
and samples will start being missed, though. Faster than
~3 KHz would require a little extra coding to avoid the
situation where a set of 4 samples is being converted and
the interrupt fires again to trigger the conversion of the
next 4 samples.
One way around the stuttering is to synchronize the A/D
conversion with the 1ms timer interrupt. If you wanted to
sample at 4 KHz, for example, you would start the A/D
conversion at the beginning of the 1 ms interrupt, then start
the next 3 conversions at 250 us intervals using the OCRB
timer to trigger them. Heck, you wouldn't even need the
OCRB timer if you just run the OCRA timer at a 250 us
interval, doing one conversion each interrupt and doing the
system stuff every 4th (or 8th) interrupt. However, this
technique would require using the sample-all-4-channels
mode of the A/D converter. So, increased sample rate at
the expense of sample resolution.
Perhaps a prioritized interrupt scheme would work. I recall
seeing a post in this group where, as a student project, such
a scheme was implemented. You would reenable IRQs
right after the general 1ms interrupt fired to allow the A/D
conversion ISR to interrupt the 1ms ISR (if you follow
me ;o). This would require all interrupt handlers to be
aware of such a scheme, though. Might be feasible without
too much effort. I'll have to look into it - seems interesting.
Mark
|
|
Message has 1 Reply:
 | | Re: Interesting BrickOS Timing Results
|
| (...) I forgot to mention... This is *almost* the same as moving some of the subsystem code into a seperate high priority task. For example, LCD refresh code is executed in the 1ms timer ISR. It really doesn't need to be in the ISR. It can do it's (...) (21 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Interesting BrickOS Timing Results
|
| Hi Marc, (...) Nice idea, but wouldn't that result in at least one of four cycles beeing blocked by OCRA? or is our system interrupt finished within less than 250msec? (...) Right, that was what I did for my Lepomux patch - works fine. Gunther (21 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
19 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
