Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 22:24:38 GMT
|
Viewed:
|
3733 times
|
| |
|
|
"Mark Riley" <markril@hotmail.com> wrote:
> 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.
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 job
just fine in a seperate task. I think this LCD code is the what's
pushing the general 1ms interrupt to periodicly take a full 150 us.
But, I think I'm digressing here, so...
Mark
P.S. Ralph, speaking for myself, I find all this quite enjoyable
and it doesn't bother me a bit to reinvent the wheel. As long as
it's fun (and educational), that's what Lego is all about. ;-)
|
|
Message is in Reply To:
 | | Re: Interesting BrickOS Timing Results
|
| (...) 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 (...) (22 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
|
|
|
|
