Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 21:37:08 GMT
|
Viewed:
|
3641 times
|
| |
|
|
Mark Riley wrote:
> 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).
If you take the sys_time off the NMI, then the interrupt can be masked
off or blocked by another interrupt handler. Isn't it then possible to
miss interrupts altogether?
>
> 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.
This makes sense to me now.
>
> 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
>
I see. Looks like that is the way to go.
What about the following:
OCRA -> Start A/D convert, Perform Task Swap
OCRB -> Update display, sound, motor, etc..
As Dick Swan pointed out, the frequency of the task swap might be best
linked to the A/D conversion in some way. OCRA could be set to fire at
any interval (selectable at runtime) and the A/D conversion would be
started each time, but the task swapping would only occur once every Nth
pass. This would allow a lot of flexibility, but decrease complexity.
OCRB would be set independently, and doesn't have to be based on a 1
msec interval. Again, another way to tweak overhead and lcd/sound/motor
response time.
Default configuration: OCRA -> 1500. Task swap to occur every 6th time,
A/D started each time. OCRB -> 500. Motors, sound and LCD at same
interval as they are now.
Sensors would be updated at 333hz, Task swap every 18 msecs. Did I get
this correct?
// Joe
<random thoughts>I am surprised at the number of people writing their
own OS or library.</random thoughts>
|
|
Message has 1 Reply:
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 (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
