| |
> What about the following:
> OCRA -> Start A/D convert, Perform Task Swap
> OCRB -> Update display, sound, motor, etc..
I have been following this thread in my peripheral vision
for a while now. All of the talk is very interesting and
appears to be leading to a general question about how
and why the drivers are the way they are....
As a point of interest, some of you may know that I have
developed a servo driver for the RCX, except you need to
use pbForth to drive it:
<http://www.hempeldesigngroup.com/lego/servos/index.html>
The interesting thing is that I use OCRB to help generate the
servo waveforms.
The OCRA interrupt is used to turn the motor driver chip off to
start the (inverted) servo pulse. I then set OCRB to interrupt some
time later to turn the motor driver back on.
The nice thing is that I use OCRB in single shot mode. I can drive
each of the motor ports independently because I only update each
motor port every 32 msec for about 30 servo pulses per second out of
each driver port.
The source is in my pbForth distribution - I'm really busy in the
next few days, so I can't really help too much here.
I tend to use the ROM routines as much as possible in pbForth. That
way I don't need to rewrite too much code that has already been
written and tested :-)
Hope this doesn't stir the pot too much....
Ralph
|
|
Message is in Reply To:
 | | Re: Interesting BrickOS Timing Results
|
| 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 (...) (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
|
|
|
|
