Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 17:45:27 GMT
|
Viewed:
|
3467 times
|
| |
|
|
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 OCRB will never fire. In
the current configuration OCRA fires, but doesn't modify the timers
value; OCRB then fires, resets the timer value to zero and passes
control to the code for OCRA. This way the OCRA routine gets executed
twice per timer cycle; the OCRB routine gets executed once per timer
cycle. At what point OCRA and OCRB fire is configurable; as well as how
fast the timer counts; there is certainly no reason why these HAVE to be
setup on msec boundaries, but that seems to be a conveniently round
number for us humans 8-) Maybe this should be program configurable at
run time, so the program can effect OS overhead, similar to the ability
to effect how often the A/D conversion is initiated.
When I was first looking at the timers available on the H8, I was often
confused by Timer A (8 bit), Timer B (8 bit) and the OCRA/OCRB for the
16 bit timer. However, it all makes sense now (after many hours of
reading/rereading)
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>
// Joe
Gunther Lemm wrote:
> In lugnet.robotics.rcx.legos, Mark Riley writes:
>
>
> > Looking at the code in sys_time.c, it seems possible
> > that the OCRB interrupt could be consolidated with the
> > OCRA interrupt, freeing the OCRB interrupt to be
> > used for sample rates > 1 KHz.
>
>
> Timer B is usually unused but has a lower priority than Timer A. If you do a
> lot of stuff in the timer A routine, this will block timer B interrupts
> (especially if timer B generates more interrupts than timer A).
> The mean thing is that those ROM routines seem to be hardcoded on timer A. So
> you can't just put the whole system on timer B and speed up timer A. Maybe
> there's someone who knows exactly how timer A is connected to the routines in
> ROM and if speeding up timer A just influences on the sound output.
>
> Gunther
|
|
Message has 1 Reply:
 | | Re: Interesting BrickOS Timing Results
|
| (...) 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, (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Interesting BrickOS Timing Results
|
| (...) Timer B is usually unused but has a lower priority than Timer A. If you do a lot of stuff in the timer A routine, this will block timer B interrupts (especially if timer B generates more interrupts than timer A). The mean thing is that those (...) (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
|
|
|
|
