DPRG List  

DPRG: GARP Operating System

Subject: DPRG: GARP Operating System
From: Jim Brown jbrown at spdmail.spd.dsccc.com
Date: Mon Jun 16 15:40:28 CDT 1997

> GARP motor driver specification
>   serial RS-232 control  9600 N 8 1

Serial settings probably don't matter since they can be configured
at the operating system level for each device attached.
>   full duplex with acknolwedge after any commands
>   one controller which controlls both left and right motors
>   PWM with 32 speeds  maybe 24 forward/ 8 reverse
>   full H bridge  using MOSFETS
>   24v  10A continuous 50A surge
>   active braking
>   seperate enable/disable line for kill switch
>   some simple control language  like L8:R10 to set the
>   left motor to speed 8 and the right to speed 10

The approach that we'd talked about before was instead of enforcing
a protocol, we'd make it device specific.  Enforcing a protocol
to cover every possible situtation and every possible device and with
everyone so opinionated, such a protocol might never get past the
debate stage.  So, instead of forcing those who want to make a
perifreal to follow a protocol spec, we talked about that it would
be the other way around where the perifreal makers would force the
brain writer to follow a protocol spec.  So, the person making the
perifreal would develop their own protocol to talk to their device,
and maybe make a sample program to talk to their device via a system
call.  The brain writer would take that system call or protocol and
sample source and plug it into the brain code.  That way, say someone
first makes a motor controller using relays that just has forward,
backward, turn left, turn right, and stop. That's all they support,
and that's all that's in their own protocol and sample code.  Some else
later on comes up with a mosfet PWM motor motor controller, with all
sorts of cool stuff like breaking and speeds, etc.  They give their
protocol to the brain writer with sample interface code, and it's
plugged in.  This may not be the most ideal way to it, but it
accomplishes a few things:  (1) We don't get into a protocol war,
(2) it's very flexible, (3) it allows for new features that are
unplanned for, (4) perifreal writers don't have to try to circumvent
the protocol for unthoughtof protocol features needed.  The down side
is that:  (1) It may take a little longer to install/implement the
perifreal on the brain side than if there was a standard protocol.
This way of doing it is sort of like having the perifreal device maker
having to make their  device drivers (or protocol) for each of their
devices they want to install on GARP.  The interface functions could
be simple system calls with command line paramters to their interface
program so they could write their interface code in whatever language they
wanted.  For most things the brain program could just do simple
system calls to their interface code.  For other things that
perhaps needs more speed or attention, the code could be inserted
right into the brain program itself or talk to the background 
program via a pipe, semaphore or something.

- ---------------------------------------------------------------------------
Jim Brown                jbrown at spdmail.spd.dsccc.com or jbrown at why.net
                         http://www.dprg.org (Next meeting June 14th)

Work:  972-519-2868      My employer won't claim these opinions.    
Home:  972-495-3821      So I'm giving them away for free.   


More information about the DPRG mailing list