and ROBOTS

worldmags
PWM(), respectively. Examining these methods, you would
notice they each have an infinite loop that would never
finish. Quad continuously monitors and updates the
quadrature state count, and PWM() ensures the PWM
signal is constantly updated.
In traditional interrupt or event-driven programming,
these loops would have to be “interrupted” occasionally to
allow for the rest of the program to execute. Also, since
they would be running together you wouldn’t be able to
put them in two separate loops like we have them now.
Furthermore, due to the interruptions their actions would
not be fully deterministic, meaning that the system may
have signaling jitter and missed pulse counts while other
tasks are being handled by the processor.
In the Propeller chip, these two methods run fully in
parallel in their own cogs eliminating the need for
interrupts. Notice the statements that call CogNew() in the
Start() methods in both figures. This function launches the
associated method (subroutine) into one of the eight cogs.
Once a cog is started, it will continuously do its tasks
independently of other cogs. However, notice how in
Figure 11 the PWM duty level is set. This is the way to
communicate between the cog that is
running the main program and the cog that
carries out the PWM work. We just set a
value within the hub RAM which PWM()
knows about and can read. Upon reading
this value, it will change the duty level of the
PWM signal.
Likewise, the quadrature encoder cog
will continue to interrogate the infrared
hardware and update the state count into a
variable in the hub RAM. The cog running
the main program reads this count when
needed from that variable.
We do not have to worry about
contention handling because the Propeller
chip does that for us by ensuring that each
cog can only read or write to the hub RAM
in a round robin fashion. This guarantees
that no two cogs can simultaneously read
and write to the shared memory.
The round robin contention prevention
works on a long (32 bits) by long basis.
Should you need to ensure exclusive access
to a block of memory over multiple round
robin turns, the Propeller chip also provides
hardware-based semaphores (eight of them,
called locks) which simplify semaphore
programming tremendously. In our programs,
we do not need them since we are only
using longs for the PWM duty and the
quadrature state count.
Putting A Fresh Spin
On Things
The RobotBASIC program was necessary
in the original project because we needed a GUI for the
operator of the system to be able to command it.
Additionally, the simulator aspect was powerful for the
purposes of operator training and for tweaking system
parameters like PID factors. With the Propeller-based
project, you are able to dispense with the PC system (with a
caveat).
With the Propeller chip and a few pre-written powerful
objects and some resistors, you can add a PS/2 mouse and
keyboard, as well as a VGA (or TV) display to the system.
The Propeller can also do floating point math (using an
object) which would enable the implementation of an
accurate PID control algorithm. You can therefore
implement the user interface for the operator, as well as
the PID control using just the Propeller chip.
This is definitely a powerful option, but the graphics
and GUI are not going to be as powerful as you can
achieve on a PC. Also, a PC system can provide additional
processing and other services that can enhance a Propellerbased
project (e.g., the simulator in this project). SV
www.servomagazine.com/index.php?/magazine/article/
december2010_Blankenship
FIGURE 13. PWM
controller program.
SERVO 12.2010 75
worldmags