Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 18:53:45 GMT
|
Viewed:
|
3203 times
|
| |
|
|
"Joseph Woolley" <jwoolley@spamblock.insight.rr.com> wrote:
> Mark, I am not sure you will get the results you want, but it is
> certainly possible to recombine the routines that are currently attached
> to OCRA and OCRB; after all, that is how BrickOS was setup originally.
>
> <opinion>I think the current setup works well, since some functions only
> need to be performed every other pass (or less as the case may be).
> Overhead is reduced by checking and executing these functions every
> other msec. The essential functions are executed every msec.</opinion>
My thought was that the OCRA interrupt could be used
as the general 1ms interrupt and the subsystem handler
(which is currently using OCRB) could be called every
other time from the OCRA handler by using a flag
(toggled every 1ms). Actually, if we move the sys_time
handler back to OCRA (instead of the watchdog NMI),
then we could just check if bit 0 of sys_time is zero to
determine if the subsystem handler should be called (plus
this will get sys_time back to being accurate since I haven't
yet found a way to eliminate that last 0.16% error using the
watchdog timer).
Anyways, this would free up OCRB so it could be used to
trigger the A/D conversion for rates >1KHz. The way to
use OCRB is to add a constant to the OCRB register each
interrupt - if the result is >= 500 (which is the OCRA
interval for 1ms) then subract 500 and store that back in
the OCRB register. So, if you wanted a ~3 KHz sample
rate then the constant would be 167.
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.
In the library I've been working on, I actually don't
clear the 16-bit FRC when there's a match on OCRA
or OCRB, I just let it "free run" (hence Free Running
Counter ;o). This makes the check for >= 500
unnecessary. Here's a code snippet that gets executed
in the OCRA interrupt handler:
OCRA_TICK_COUNT = 500 ;1ms
mov @OCRA,r0
add #OCRA_TICK_COUNT & 0xff,r0l
addx #(OCRA_TICK_COUNT >> 8) & 0xff,r0h
mov r0,@OCRA
Using this technique, both OCRA and OCRB can be
used independantly for arbitrary intervals.
Mark
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Interesting BrickOS Timing Results
|
| OCRA and OCRB are output interrupts for the 16 bit timer. They can be programmed to fire at specific points along the timers run. So, technically, they cannot be used independently of each other. If OCRA resets the timer value back to zero, then (...) (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
|
|
|
|
