Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Search WWW Search seattlerobotics.org

'Reaching the Next Step in Motion Control and Sensor-Software Fusion for Mobile Robots.'

Kenneth Maxon



This article presents a follow up to an Article for the encoder newsletter in which the author described the implementation of a quadrature decode system implemented with a single PIC micro-controller. The idea with that particular design was to interface the PIC along with dedicated PWM circuitry to an under powered 8-bit micro-controller to provide a real time servo-feedback mechanism for a Statistical Process Control (SPC) device. Since then several projects have taken the author back into the motion control realm including a new 3-axis feedback project for a CNC milling machine, absolute feedback systems for a large long term robot project and now the latest project a small high speed robot. As previously mentioned these projects have centered around PIC processors and still others around the HCTL-2020 quadrature decoder by HP and finally hand written grey-code to 32 bit counters in custom FPGA's. These systems work quite well, with the drawback that they feed back to under powered 8-bit processors, require large amounts of board space and the current draw on these devices does not lend itself readily to battery operation. A new more powerful implementation of this circuitry is realized with Motorola's MC68332 (Reference #1) processor, which contains all of the necessary components on-chip.

"Why?", you might ask, would someone go to all the trouble to build and implement a 32-bit micro-controller for a small 2-wheeled (or larger) mobile robot? The answer is to, 'reach the next step in motion control and software-sensor fusion.' Simply put to free our robots to be robots. To remove the system processor from motion control tasks such that it can spend its valuable instruction processing time processing data from vision systems, laser range finders, Geiger counters, Sonar modules, etc to accomplish robotics related goals. In other words to remove the robotics platform from the realm of motor control devices and re-insert it into the field of robotics used to plan and accomplish tasks.

Motorola's MC68332 micro-controller brings the full 32 bit processing power of the M68000 family to the embedded world in a feature packed IC. Along with a full M68000 compatible instruction set, Motorola has added a queued serial module (QSM), system integration module (SIM) and a time processing unit (TPU) to the package. The later of these, the TPU, supplies the pure hardware processing power to independently drive most of the functions required of a robot and will be the focus of this article. The independence of the TPU is achieved by implementing a separate micro-coded engine that runs independently of the CPU on the same piece of silicon. The CPU interfaces to the TPU micro-code engine through internal RAM memory locations and a programmable interrupt interface. Although the author found coverage of the TPU lacking, Harman offers a complete look at the CPU32 function with respect to the '332 and a light coverage of the SIM and QSM in his book (Reference #16). The Circuit Cellar Magazine offered a good in depth look at TPU functionality from comparisons to existing processor technology all the way to writing custom micro-code for the TPU task scheduler in a four part series (Reference #17). Motorola also provides in depth coverage of each TPU function, two of which are included later in this article.

This article is intended to demonstrate the specifics of implementing both the multi-channel pulse width modulation (MCPWM) feature of the TPU in conjunction with the fast quadrature decode (FQD) TPU function for automated control of a two (or more) wheeled robot. In a month or two the author will present a separate article focused on the control algorithm used to develop and implement a PID filter feedback function.


There are five basic parts to the implementation of a full servo system. The five parts are the hardware interfaces to the motors and encoders, and the TPU interface to the pulse width modulator and quadrature decode function. The fifth part, which I'll not delve into, past a basic representation, is the feedback algorithm (such as a PID filter) linking the input mechanism and output mechanism together. Instead, of the PID algorithm the author presents the code to get both MCPWM and FQD up and running and leaves the algorithmic solutions to a future article. (Stay tuned for more.)

The five parts of a servo system discussed in the preceding paragraph can be regrouped into three main subsections for the purpose of clarity in discussion. These three subsections are the CONTROLLER, which generates the desired motion profile, the OUTPUT MECHANISM (amplifier/motors, hardware/software) and the INPUT MECHANISM (encoders/tachometer, hardware/software). The modeling of the system, by the controller, and the second order differential equation used to describe these relationships is well beyond the scope of this text, however an extremely light linear relationship will be developed in the control section. The depth and breadth of the topic expand to include coefficients for position and velocity feedback, for mechanical delay (inertia and linkages), electrical delay (PWM & amplifier response time), Second Order Differential Equations, Nodal analysis, and much, much more. Rather than attempt to cover in depth all of these topics the author's intent is to provide a real world hardware/software solution to bootstrap the process. Several texts, however, are cited at the end of this article, which fully address this topic (Reference #3, #4, #5, #6, #7, #8 & #15).

Just as the architecture of a servo control system can be broken down into three basic modules, demonstrated in the preceding paragraphs, so to can the software associated with each of these modules. Referring to (Table 1.1) the reader will note that the author has done just that. Specifically, the software presented here has been segregated into three parts as determined by its functionality. These three parts are chosen to match up with their basic function in the scheme of a servo feedback mechanism. (MCPWM for Output, FQD for Input, & MAIN for Control). Each includes a *.C file containing functioning 'C' source code and the associated *.H header file with definitions and function prototypes.

The reader will most likely observe that the focus of this article repeatedly returns to the functionality provided by the Time Processing Unit (TPU) within the 68332. This is due to the fact that all three subsections of servomotor control directly interact with TPU functionality. The TPU is the processors interface to the output mechanism as well as the interface to the input mechanism. The control subsection while interfacing to both sections of the TPU completes the feedback functionality of the servomechanism.


This article is defined as follows (Table 1.1) with the three primary topics covered Output mechanism, Input mechanism, & Control module each with it's own section of discussion. The References and Notes (Section 7) is devoted to providing internet related links as well as links to published hardcopy to further extend the covered subject to the reader.

Table 1.1:

Section Topics Software
SECTION 1: INTRODUCTION Theory of operation, Article overview  
SECTION 2: THE OUTPUT MECHANISM What is it?, How is it done?, Hardware used, Register usage MCPWM.H & MCPWM.C
SECTION 3: THE INPUT MECHANISM Incremental encoders, Hardware used, register assignment FQD.H & FQD.C
SECTION 4: CONTROL Feedback case A & B, Differential drive, Delat_1-tracking, Delta_2-steering, Real world, Further steps TPU.H, MAIN.H & MAIN.C
SECTION 5: DEVELOPMENT PLATFORM Processor platform hardware: (CRC332)  
SECTION 7: NOTES & REFERENCES Possibly the most important part of the article, this section contains - Links and bibliography information  


The primary output mechanism discussed in this article is that of pulse width modulation (PWM). Although the MC68332's TPU function library includes support for brushless DC motor control with hall effect sensor feedback, as well as two, four and eight channel stepper motor table drive functions, the author has chosen to stay focused on pulse width modulation. This arrow focus provides a clear concise example easy to implement on high-speed mobile robot platforms.


So what is pulse width modulation? Pulse width modulation uses a single bit output (2 in the case of the TPU, more on that later) to generate an analog value proportional to the desired speed of the motor. This is done by establishing a base line period or switching frequency for the signal. Quite often it is common to hear of PWM systems 'switching' at 22KHz. (Note: A frequency of 22KHz is important for many reasons, but an important one that is usually over looked is the fact that it is above the spectral frequency response of the human ear.) Accounting for the 'P' portion of PWM means that the leading edge of a new (P)ulse starts twenty-two thousand times a second. In PWM the 'W' stands for the (W)idth of the signal or pulse. It is commonly referred to as the duty cycle of the signal, meaning how long the pulse stays active. Duty cycle is usually expressed in terms of percentage from 0% - 100%. So a PWM signal running at 22KHz with a duty cycle of 25% will output a leading edge (high going pulse) 22 thousand times a second, and that pulse will stay high for 25% of 22KHz, or eighty-eight thousandths of a second. 22,000 * (1/.025) = 88,000.


The often-asked question is, 'How this train of pulses becomes an analog value to control a motor or other device?' The answer is relatively simple although it has it basis in calculus. (Don't worry, you don't have to have a full grasp of calculus to use this system on a mobile robot) The current traveling through the coil of a DC motor can not be changed instantly. In fact the current takes time to build up or decay in the motor coil. The pulse width modulation, when applied to the motor, has the effect of boosting the current through the coil while on and letting it slowly decay when off. The longer the pulse is on, the higher the current level through the motor coil builds before shutting off again. The specifics of this on/off again cycling are given mathematically in the next paragraph, however all the reader really needs to understand is that this relationship can be modeled by an average depicted graphically in (Figure 2.1) and modeled in (Equation 2.3). The relationship between output duty cycle and motor current is shown in further detail in (Figure 2.3).

The mathematics that describe this energizing and de-energizing current are described by (Equation 2.1 & 2.2) below. These two equations, together, show the time dependant relationship between the voltage applied the Inductance of the motor and the resistance of the circuit to achieve a particular current level. Specifically, (Equation 2.1) shows the current buildup as a function of time for an 'R-L' circuit, while (Equation 2.2) shows the current decay. These two equations, together, describe the characteristic waveform present during DC driving. When the forcing function is modified by the addition of pulse width modulation of the driving function, then the wave form must be analyzed on discrete intervals of signal on/off, such as analysis of a time dependant unit step function, taking into account the partially energized/de-energized status of the inductor (motor). A graphical representation of the output of a PWM when applied to an 'R-L' circuit may be observed in (Figure 2.2) below. To reiterate from the previous paragraph, these models show exacting mathematical relationships. A full understanding of these equations is not required to implement a servo feedback system. For the purposes of implementation the reader need only know the relationship to the average motor current depicted in (Figure 2.1 & 2.3) and modeled mathematically by (Equation 2.3).

Equation 2.1: Equation 2.2:

Table 2.1:

Turn the circuit on often enough to keep the current through the motor from falling below the desired point. Turn the circuit off after a specific amount of time to keep the current through the motor from climbing too high.

Figure 2.1.shows that when this cycle is repeated tens of thousands of times per second. The average effect described by it is that of an average current level. The specifics of this are determined by integrating the on time over a discrete interval and multiplying it by the current decay function for the particular values of L & R in the motor and it's drive circuitry. A simplified model of this can be represented by (Equation 2.3 below). (Reference #10, #11, #12 & #14) at the end of this article offer detailed explanations and extended coverage of the topic.

(Figure 2.2 right) As an experiment one could use an inline sense resistor (No larger than 0.5 ohms and a wattage rating high enough to handle the power, in this case, P = I^2 * R) and an oscilloscope to actually see the building and decaying of the current in the motor.

Equation 2.3:

Figure 2.3


The TPU in the MC68332 contains sixteen I/O pins to interface with the outside world. Additionally, there are sixteen separate TPU functions preprogrammed into the micro-controller. (These functions differ between the '-A', '-G' & '-C' mask sets. The functions discussed in this article, MCPWM & FQD, are only present in the '-G' mask set, Reference #1.) These 16 TPU functions may be assigned to any of the TPU pins in almost any combination/number providing a massive amount of system flexibility. There is also a feature available for the reader to upload custom microcode into on-chip RAM for the users own TPU functions. Motorola provides the TPU microcode compiler for free on their web site (Reference #2) for the adventurous. In this article the author will focus on only the two functions required to implement a servo system and the hardware to support them.

The TPU requires one external hardware support IC to generate true pulse width modulation (MCPWM) from its TPU port pins. This single IC is an 'exclusive or gate' such as that in the 74LS86 IC. In (Figure 2.4) the schematic shows a full PWM implementation. Multi Channel Pulse Width Modulation (MCPWM) as its name implies can Multiple channels (or all of them) with PWM signals of varying duty cycles. In order to accomplish this, the TPU outputs one PWM signal, the Master channel, against which all other channels are compared using an Exclusive-OR function. Each of the other channels, Slaves, are then output out of phase timewise with the master channel. The amount of phase shift of this out of phase relation ship is determined by the duty cycle of the PWM signal. This functionality frees up a large amount of over head from the TPU allowing it to operate with good resolution while still continuing to service other functions at the same time. The need for the master channel is the driving requirement for the external (xor) gate and requires one more TPU IO pin than the number of PWM's needed in the design. This functionality is investigated further in Figures 2.5, 2.6 & 2.7 (below) and it's associated paragraphs.

Figure 2.4:

The schematic above shows an interface to an LM18200D, 3 Amp DC Motor Controller. Also depicted are a simple voltage reference and single rail comparitor used to feed back a single bit alerting the system to over current situations with the motor controller. This is useful information for detecting a stalled motor condition on a mobile robot. I.E. the control system has told the robot to move forward while the robot is firmly planted up against a wall which the robot did not 'see' in this condition the motors can not turn. The stalled motors will trip the current limit feedback bit notifying the processor of the problem so that the processor can work out an alternate solution.

Two additional inputs to the motor control board are the dir and brake input. A careful review of the data sheet for the LMD18200 (LMD18200.PDF below) shows that these are the direction and braking inputs to the chip. These can be driven from any spare processor pins (such as Port 'E' when not used for primary functions) or, as in the case of the 'C' Robot Controller (CRC332) board, designed by a group that included the author, by spare TPU lines programmed for discrete I/O.


A further improvement to the schematic shown above would be to remove the common ground and associated power connection by the addition of opto-isolation components. Make sure that in choosing drive components for opto-isolation to determine the drive currents in the internal led components. Usually, these situations are best served by using an open-collector mechanism below the led in the input side, and an inverting output on the TTL or compatible output side. Many of these systems have open collector outputs as well, which requires the addition of a pull up resistor on both sides, additionally due to the switching effects of as much as 30mA(or more) at frequencies in the 22KHz range, multi-capacitor decoupling is recommended. Remember that the pull up resistor on the input side connects to VCC1 (input) while the pull up resistor on the output side connects to VCC2 (output), a subtle but often over looked distinction.

Figure 2.5 - 2.7 (below) depict the output at three differing levels of duty cycle from the Pulse Width Modulation TPU function. In each figure, three wave forms are present. The top wave form in each figure is the output of the TPU's master channel, while the second is that of the slave channel. Finally, the third wave form depicts a signal tap of the PWM signal after the XOR gate. Close inspection will reveal the phase relationship between master and slave channels and the associated varying duty cycle between each of the three figures.

Figure 2.5, 2.6 & 2.7:


This section describes the software setup required to initialize the TPU and to start it generating a varying duty cycle pulse width modulated output. The code examples provided were compiled with the DOS port of the GCC (Reference #9) compiler, which supports the M68000 family of target processors.

The MC68332 supports five modes of operation. These modes of operation include Normal user, Normal supervisor, exception processing, background debugging and halt. To keep with an underlying premise of clarity and simplicity the code presented in this section and others throughout this article is written to operate in supervisory mode exclusively. This precludes setting up and calling traps to jump between privilege modes which may obscure some of the simplicity and functionality presented here in. Further, exception processing is not supported for the same reasons. This keeps the code operation to a linear model and re-enforces understandability on the part of the reader. Implementation of exception processing to further streamline the flow control of the programs is left as a task to the reader.

The first PDF file listed in this section (TPURM.PDF) contains the Motorola documentation describing the overall use and function registers of the TPU on the MC68332 micro-controller. The second PDF file listed in this section contains the Motorola documentation on configuring the TPU (TPUPN05.PDF) for multi-channel pulse width modulation (MCPWM). A quick review of these two PDF files reveals the more that 100 registers associated with TPU functionality. This extraordinarily large flexibility in configuration comes at the high cost of configuration complexity.




It is the intent of this text to aid the reader in making sense of this jungle of complexity to get a mobile robot up and running quickly. In so doing this article will implement the edge aligned method of multi-channel pulse width modulation. Refer to TPUPN05.PDF (above) for more information on edge or center aligned modes. Although edge aligned mode has some minor drawbacks related to limited duty cycles near 0% and 100% this solution does not require insertion of dead time, and limits the number of TPU channels required, leaving them available for other reader implemented functions. The set up featured in the TPU manual on MCPWM follows in Table 2.2:

For a complete set of technical documentation on the remaining TPU functions as well as the complete manual set for the MC68332 processor, see the Motorola web server. (Reference #2)

Table 2.2

1. Disable all the master and slave MCPWM channels by clearing channel priority bits.
2. Select the MCPWM function on the master and all the slave channels by writing the MCPWM function number to channel function select bits.
3. Initialize PERIOD, IRQ_RATE, PERIOD_COUNT, RISE_TIME_PTR, and FALL_TIME_PTR in master channel parameter RAM.
4. Initialize PERIOD, HIGH_TIME_PTR, RISE_TIME_PTR and FALL_TIME_PTR in the PRAM of all edge-aligned slaves.
5. Select edge-aligned mode on each slave channel by clearing the host sequence bits.
6. Set the interrupt enable bit for the master channel if a periodic CPU interrupt is desired. The interrupt enable bits for all the slave channels should be cleared.
7. Initialize the HIGH_TIME parameter(s) wherever they reside in PRAM.
8. Issue an HSR%11 to the master channel and an HSR%10 to each slave channel.
9. Enable servicing by assigning the same non-zero priority (H, M, or L) to all of the MCPWM channels.

The code fragments below include the 'C' header & code functions to implement the steps above. This code is hard coded to initialize TPU channel 3 as the MCPWM master and channel 4 as the MCPWM slave for the sake of simplicity and to ease the code's readability. Additionally it completely walks over all other functions that may have been running on the TPU at the time it is executed returning them to a, 'fresh out of reset', state. If the reader plans to use this code unaltered in their own application, for experimentation purposes, it is important to call this TPU initialization code before any others. This code was generated in 'C' for use by the 'GCC' compiler set up for a 68300 family target. (Reference #9)

This code is known to be error free as it was built and executed on the authors own 68332 robot controller (more later).

Fragment from "MCPWM.H"

void init_Tpu_pwm(void);	// Function Prototype

#define MASTER_CHAN 2
#define SLAVE_1_CHAN 3
#define MCPWM_FUNC 7

#define MIN_PWM_WIDTH 0x0020
#define MAX_PWM_WIDTH 0x2000
#define PWM_INCREMENT 0x20

struct tpu_Master_mcpwm_ram
	unsigned short int period;
	unsigned char irq_rate;
	unsigned char period_count;
	unsigned short int last_rise_time;
	unsigned short int last_fall_time;
	unsigned short int rise_time_ptr;
	unsigned short int fall_time_ptr;	

struct tpu_Slave_mcpwm_ram
	unsigned short int period;
	unsigned short int high_time;
	unsigned short int undefined;
	unsigned short int high_time_ptr;
	unsigned short int rise_time_ptr;
	unsigned short int fall_time_ptr;

Fragment from "MCPWM.C"

void init_Tpu_pwm(void)
	struct tpu_Def * Tpu;
	struct tpu_Master_mcpwm_ram * mtpu_Ram;
	struct tpu_Slave_mcpwm_ram * stpu_Ram;

	Tpu = (struct tpu_Def *)TPU_BASE;
	mtpu_Ram = (struct tpu_Master_mcpwm_ram *)(TPU_RAM + (MASTER_CHAN << 4));
	stpu_Ram = (struct tpu_Slave_mcpwm_ram *)(TPU_RAM +(SLAVE_1_CHAN << 4));

	Tpu->TPUMCR = 0x00C0;

/* step one set channel priority bits */
	Tpu->CPR0 = (short int) 0;			/* force priority for all channels to 00 = disabled re-enabled before function exit*/
	Tpu->CPR1 = (short int) 0;
/* Step two set channel function selection registers */
	Tpu->CFSR0 = (short int) 0x0000;		/* function 7 is MCPWM all other TPU functions off */
	Tpu->CFSR1 = (short int) 0x0000;
	Tpu->CFSR2 = (short int) 0x0000;
	Tpu->CFSR3 = (short int) ((MCPWM_FUNC << 12) + (MCPWM_FUNC << 8));
/* Step three Initialize master period, irq_rate, period_count, rise_time_ptr and fall_time_ptr */
	mtpu_Ram->period = (short int) MAX_PWM_WIDTH;			/*set half way between min (0x0000) and max (0x4000) */
	mtpu_Ram->irq_rate = (unsigned char) 0x00;		/* no rate defined as we'll poll in this example, no interrupts */
	mtpu_Ram->period_count = (unsigned char) 0xFF;	/* when not used defined to 0xFF as it is incremented by 1 during HSR */
	mtpu_Ram->rise_time_ptr = (unsigned int)((MASTER_CHAN << 4) + RISE_TIME_OFFSET); /*0x0024;*/	/* this is hard coded to point to the last rise time for channel 3*/
	mtpu_Ram->fall_time_ptr = (unsigned int)((MASTER_CHAN << 4) + FALL_TIME_OFFSET); /*0x0026;*/  /* this is hard coded to point to the last fall time for channel 3*/
/* Step four initialize slave period, high_time_ptr, rise_time_ptr, and fall_time_ptr */
	stpu_Ram->period = (short int) MAX_PWM_WIDTH;		/* this must match the period value assigned to the master above */
	stpu_Ram->high_time_ptr = (short int) ((SLAVE_1_CHAN << 4) + HIGH_TIME_OFFSET); /*0x0032;*/	/* hard coded to point to this channels high time value */
	stpu_Ram->rise_time_ptr = (short int) ((MASTER_CHAN << 4) + RISE_TIME_OFFSET); /*0x0024;*/	/* hard coded to point to the master channel last_rise_time param */
	stpu_Ram->fall_time_ptr = (short int) ((MASTER_CHAN << 4) + FALL_TIME_OFFSET); /*0x0026;*/	/* hard coded to point to the master channel last_fall_time param */
/* Step five select edge aligned mode for slave channels */
 	Tpu->HSQR0 = (short int) 0x0000;			/* clear em all for now */
	Tpu->HSQR1 = (short int) 0x0000;			/* clear em all for now */
/* Step six set the interrupt for the master channel if desired The interrupt for all slave channels should be cleared */
	Tpu->CIER = (short int) 0x0000;		/* disable all interupts for now */
/* Step seven initialize high_time parameters */
	stpu_Ram->high_time = (short int) MIN_PWM_WIDTH;	/* defined to give a 50% duty cycle */
/* Step eight issue a HSR %11 to the master channel and an HSR%10 to each slave channel */
	Tpu->HSRR1 = (short int) 0x00B0;
/* Step nine turn on non-zero priorities to TPU channels */
	Tpu->CPR1 = (short int) 0x00A0;		/* assign medium to both master and slave*/
	Tpu->CPR0 = (short int) 0x0000;

A myriad of other implementation options for the MCPWM functions are possible. These choices are not to covered here in so doing, the simplicity that is possible when using these functions will not be lost to obscurity. Configurations of note however are TPU generation of interrupts at specific number of PWM cycles for acceleration profile updating. Exception processing based on interrupt stimulation proves to be an extremely efficient method to implement acceleration profiles, A compact exception processing routine can evaluate the most recent position information and desired points along the velocity profile and adjust the PWM output to correlate the two. More on this under (Section 4: Control). Also center aligned PWM can be useful to keep leading and trailing edges of the high going pulse from triggering at the same time when multiple channels are used with a varying high time. The full set of configuration options is covered in the Motorola TPU-MCPWM application note provided above.



Multi-channel incremental quadrature encoders overcome the direction problem by adding a second channel, displaced from the first, so the resulting pulse trains are 90 degrees out of phase as shown in (Figure 3.1 & 3.2). This technique allows the decoding electronics to determine which channel is leading the other and hence ascertain the direction of rotation, with the added benefit of increased resolution. The incremental nature of the phase-quadrature output signals dictates that any resolution of angular position can only be relative to some specific reference, as opposed to absolute.

The input mechanism used in this application will be a quadrature type encoder in which two channels from a wheel encoder or other linear/angular device sends two signals to the processor 90deg out of phase. Using a simple four-node state machine (Figure 3.1 & 3.2), the processor can tell which way to count, up or down, buy using the changing inputs to tell it which node to travel to next. The FQD function in the MC68332 offers some extra features such as deleting jitter pulse that are not asserted long enough to meet specific set up timing parameters. This system of a four node state machine adds a level of security for which the user can check. If the speed of the incoming pulse train becomes faster than the clocking/response speed of the state machine, the inputs will represent a request to jump to a state that is not adjacent to the current state.

Figure 3.1: The observed phase relationship between Channel A and B pulse trains can be used to determine the direction of rotation with a phase-quadrature encoder, while unique output states - allow for up to a S1..S4 four-fold increase in resolution. The single slot in the outer track generates one index pulse per disk rotation. This index pulse is not required in the implementation presented here-in.

Figure 3.2: In the graphic pick a vertical line centered on an upper channel pulse. Pick any imaginary count. Move along the graphic to the right. If the bottom channel goes high next meaning the encoder has turned counter clockwise, you need to add one to your counter. However, if the top channel goes low, you need to subtract one meaning the encoder has tuned clockwise. Now you are centered in the middle of a pulse on the lower channel. Repeat the steps above for the higher channel. Keep trading off upper channel for lower channel based on whether the vertical line you are currently on is centered on a pulse in the upper channel or the lower channel. (Look at the channel opposite the one you are centered on.)

In Figure 3.3, below, the reader can see each functional piece of the encoder discussed in this article. The photo comes from one of the encoders tested by the author, offering 1000 lines and 4000 CPR (counts per revolution) When this high level of accuracy/lines is required for an application, special care must be taken while aligning the encoder module with respect to the encoder disk. The front edge of the unit must lie precisely perpendicular to a radial line passing through the center of the encoder disk. Any small amount of angular misalignment leads to invalid readings between the 'A' and 'B' channels within the device. For further information on the HEDS-9000 series of optical encoders refer to the Adobe Acrobat file included below. Figure 3.4 below shows another common encoder configuration used in mobile robotics. This sample, also from the authors collection offers 256 lines or 1024 counts per revolution while still retaining a small form factor. Finally, Figure 3.5 shows a close up of a small section of linear encoder used in some of the authors previous work in machine positioning. The strip shown offers 360 lines per inch giving 1440 counts per inch which works out to 0.0006 inches per count. The poor image quality in this photo is due to the high degree of zoom required to capture any detail what-so-ever.

Figure 3.3

Figure 3.4

Figure 3.5

There are many other forms of feedback devices commonly used in conjunction with servo systems. One of the more prevalent of these is the analog tachometer. This device modeled as a generator returns a voltage proportional to the rate of angular velocity. When this angular velocity is worked back into the feedback equation it adds an entirely new level of complexity to the differential equation used to describe the system. In amongst the error terms fed back (see delta_1 & delta_2 in section 4) into the system are velocity from the tachometer which is the first differential of position. The reader can appreciate how this quickly adds complexity. Analog tachometers are worthy of note as they are commonly found in milling machines, CNC lathes and other motion control devices requiring accurate positioning during extremely slow and fast speeds alike. This is not the case on most mobile robots however. Often when more accuracy at slower speeds is required a higher line count encoder is implemented to increase the effective speed of the feedback loop while lowering the incremental change represented by each individual count.

Although not addressed in this article, the Motorola documentation included later in this section (FQD) provides functionality to read time indices to help rule out performance drops due to extremely low speed operation. For further reading, refer to one of the author's previous articles in the Seattle Robotics Society online 'Encoder' newsletter or (Reference #11, #12, #13 & #14) in the reference section at the end of this article.


The MC68332 processor needs no additional hardware to interface to incremental encoders through it's IO pins. Information on the author's 68332 board (C Robot Controller - CRC332) will follow in a later section. Connection to an incremental encoder is show in the photo below (Figure 3.6). In the photo one can observe the four wires used to complete the connection. Two of these wires carry signals Data_A & Data_B, while the other two carry VCC & VSS to power the encoder itself.

Figure 3.6

The encoder chosen for this project is from the HEDS-9000 family by Hewlett Packard. (Photos above - Figures 3.3 & 3.4) The main reasons for this choice are the TTL compatibility and noise rejection (jitter removal) inherent with-in the device itself. Connection to the MC68332 TPU lines consisted of simply running wire between two sets of header pins without the need for any additional components. Refer to the PDF file (HEDS9000.PDF) for a representative encoder module of the HEDS-9000 family from Hewlett Packard:



The PDF file (TPUPN02.PDF) in this section of the article contains the Motorola documentation for configuring the TPU to interface to the fast quadrature decode function (FQD). The interface to the TPU for FQD closely resembles that encountered while configuring the MCPWM function in previous sections. This is because any of these functions can be assigned to any of the channels of the TPU. This sharing requirement forces the different functions to interface through the same on-chip RAM and the same interrupt calling functions. Each TPU function allocates its memory configuration registers to function as required for the particular implementation. The priority of service access level of the micro-code engine and the priority of the interrupt generated for a particular TPU function may vary under software assignment to allow maximum flexibility. Flexibility aside the core TPU function interface remains constant from one function to the next so the code to initialize and start the quadrature decode function operates in much the same way as the initialization and startup code for other TPU functions.


The Motorola FQD document (above) describes the initialization functions by the following sequence of actions listed in Table 3.1. Once the initialization has been initiated by completing all steps 1..7 the CPU must not attempt to read from the FQD function until the HSR values for the channels used have returned to %00.

Table 3.1

1. Disable the channels by clearing the two channel priority bits on each of the FQD channels (not necessary from reset).
2. Select the FQD function on both channels by writing the FQD function number to their function select bits.
3. Initialize CORR_PINSTATE_ADDR and EDGE_TIME_LSB_ADDR in parameter RAM of both channels.
4. Initialize POSITION_COUNT to the desired start value.
5. Select one channel as the primary channel and the other as the secondary channel via HSQ0.
6. Issue an HSR %11 to each channel to initialize the function.
7. Enable servicing by assigning H, M, or L priority to the channel priority bits. Both FQD channels must be assigned the same priority to ensure correct operation.


In the 'C' code snippets provided, the quadrature decode functions have been hard coded to TPU channel 4 & 5. This has been done to simplify the code for the reader, although since this initialization is intended to take place after that for the MCPWM, this code (unlike the MCPWM code snippets presented earlier) is non-destructive to other TPU functions that may have already been started.

Following are code snippets form "FQD.H":

void init_Tpu_enc(void);		/* maintain function prototypes */

#define FQD_FUNCT 6

struct tpu_Primary_fqd_ram		/* this structure for TPU RAM overlay developed directly from Motorola docs */
	unsigned short int edge_time;
	unsigned short int position_count;
	unsigned short int tcr1_value;
	unsigned short int chan_pinstate;
	unsigned short int corr_pinstate_addr;
	unsigned short int edge_time_lsb_addr;

struct tpu_Secondary_fqd_ram		/* this structure for TPU RAM overlay developed directly from Motorola docs */
	unsigned short int unused_1;
	unsigned short int unused_2;
	unsigned short int tcr1_value;
	unsigned short int chan_pinstate;
	unsigned short int corr_pinstate_addr;
	unsigned short int edge_time_lsb_addr;

Following are code snippets from FQD.C":

void init_Tpu_enc(void)
	struct tpu_Def * Tpu;
	struct tpu_Primary_fqd_ram * primary_Tpu_ram;
	struct tpu_Secondary_fqd_ram * secondary_Tpu_ram;

	Tpu = (struct tpu_Def *)TPU_BASE;
	primary_Tpu_ram = (struct tpu_Primary_fqd_ram *)(TPU_RAM + (PRIMARY_CHANEL << 4));
	secondary_Tpu_ram = (struct tpu_Secondary_fqd_ram *)(TPU_RAM +(SECONDARY_CHANEL << 4));

	while((short int)0x0000 != (short int)(Tpu->HSRR1))
/* step one: disable the channel by clearing the two channel priority bits */
	Tpu->CPR1 &= (short int) 0xF0FF;	/* chanel 4 & 5 */
/* step two: select the FQD function on both channels by writing the FQD function number to their function select bits. */
	Tpu->CFSR2 &= (short int) 0xFF00;
	Tpu->CFSR2 |= (short int) ((FQD_FUNCT << 4) + (FQD_FUNCT));
/* step three: initialize corr_pinsate_addr and edge_time_lsb_addr in parameter RAM of both channels.*/
	primary_Tpu_ram->corr_pinstate_addr = (short int)((SECONDARY_CHANEL << 4) + 6);	/* each one points to the other pinstate */
	secondary_Tpu_ram->corr_pinstate_addr = (short int)((PRIMARY_CHANEL << 4) + 6);	/* each one points to the other pinstate */
	primary_Tpu_ram->edge_time_lsb_addr = (short int)((PRIMARY_CHANEL << 4) + 1);	/* both chanels point to the same one */
	secondary_Tpu_ram->edge_time_lsb_addr = (short int)((PRIMARY_CHANEL << 4) + 1);	/* both chanels point to the same one */
/* step four: initializes position_count to the desired start value */
	primary_Tpu_ram->position_count = (short int)0x0800;	/* arbitrary choice for test purposes only */
/* step five: select one channel as the primary channel and the other as the secondary channel vias hsq0 */
	Tpu->HSQR1 |= (short int)0x0400;	/* these are channel specific */
/* step six: select normal mode of operation by ensuring that hsq1 of the primary channel is cleared */
	Tpu->HSQR1 &= (short int)0xFCFF;
/* step seven: Issue an HSR type %11 to each channel to initialize the function */
	Tpu->HSRR1 = (short int)0x0F00;		/* this line is channel specific */
/* step eight: Enable servicing by assigning the H, M, or L priority to the channel priority bits */
	Tpu->CPR1 |= (short int)0x0A00;		/* this line is channel specific */
	while((short int)0x0000 != (short int)(Tpu->HSRR1 & (short int)0x0F00))
		//pause here and do nothing until after the tpu function is serviced.

Once the FQD has been initialized by an HSR %11 to each of the channels involved, the hardware must wait until it reads an HSR value of %00 before reading POSITION for the first time. After that the POSITION variable is available any time for periodic reference without special timing considerations. The reader, to extend the POSITION count well beyond the 16 bits provided by the TPU may implement software techniques stretching the count to 24 bits, 36 bits and beyond.

There are other supported modes for the FQD including 'Fast' mode. In this mode counter transitions are only noted on the rising edge of the primary channel. This mode is entered when the train of incoming edge transitions is above a certain threshold, and exited when it falls below the threshold. There are no lost counts when transitioning between 'normal' and 'fast' mode in the FQD TPU function. As this is an introductory article, this exercise is left to the reader and only required when transitions for multiple encoders surpass 200,000 counts/sec depending on the other functions being processed by the TPU.


The components of the control block are in many cases (and this example as well) contained completely with-in software. There are many ways in which the control or feedback function can be implemented. The two cases (A & B) discussed here vary an extremely large amount in the required knowledge base of the robot designer who will be implementing them:

CONTROL BLOCK - CASE A: The simple linear case where the encoder is read, and the position of the robot is compared against the desired position of the robot. If the robot is behind it's target location for the time slice evaluated, the duty cycle of the PWM is incremented. If the robot is ahead of it's target location for the time slice evaluated, the duty cycle of the PWM is decremented. There are a large number of drawbacks to this system the most notable of which is ringing. (Ringing arises when the PWM is incremented to 'catch-up' and over shoots it's desired target location, followed by an over shoot in slowing down, and characterized by oscillations in the PWM signal.) Oscillations such as those present in a robot's position while attempting to come to a stop at a specific location are characterized by the blue curve in (Figure 4.1 below). Ringing is not limited to the ends of a motion path. A robot may experience control problems even during normal travel. Picture the case where 10ms has elapsed and the servo system sees that the robot is not quite to the position it needs to be. Possibly it has traveled onto carpet where it takes more power from the motors to move at the same speed. While the robot is still traveling at almost a constant velocity, it needs to increase the PWM duty cycle a bit to 'catch-up'. Everything is okay until the robot gets 'caught-up' and needs to slow down, where inertia will carry it past it's target on the position/time curve, or even worse, the robot will travel back onto smooth floor again. The reader can come up with countless scenarios to demonstrate this type of problem. A complete coverage of oscillations, electrical, mechanical and other is presented by Tapley. (Reference #15) One simple work around is to use under powered motors/gear ratios or simply program a cap on the PWM positive pulse width such that the robot is always playing catch up, and can never over shoot. (The overdamped solution)

Figure 4.1:

CONTROL BLOCK - CASE B: The complex case, uses Proportional Integral Derivative (PID) filter feedback. The three terms refer to the way the error function is calculated and fed back into the control function. The first error calculation is in position, where we are versus where we want to be. The second error term is the integral of the error term such that a small error over time adds up. Finally, the third error term fed back into the system is the derivative term, or how fast the error is growing/being corrected. PID filters have their equations based in differential calculus to adjust the PWM so that the robot approaches the desired location along a critically damped path. The desired critically damped path (Figure 4.2) is one in which the robot approaches the end point of it's positional move and slows to a stop directly on top of it's target location. The trick to 'tuning' a PID filter is to have the robot approach and stop directly over it's target at the maximum velocity that can be obtained without over shoot. Although this implementation requires much more coding than that discussed in Case A above, a positive note to the reader follows: PID filters have been researched, torn apart and analyzed from all sides by others who have come before. It is not necessary to have a complete grasp of differential calculus to implement PID filtered feedback on your robot. There are many texts, which address these issues, and even source code samples to get the reader started. (Reference #3, #4, #5, #6, #7, #8 & #15).

Figure 4.2:


In, 'The real world', mobile robots usually have two, three or more driven wheels. In the simple case, two driven wheels with two compliant casters using differential drive the configuration of the control loop can be quite simple. The basic premise follows: Over any discrete time interval both wheels must always travel the same linear distance. The reader should take a moment to reflect on (Figure 4.3) until they understand this fully. Once you do, your half way there. Following this simple rule, without taking into account variations in surface textures, angle of inclination, minute differences in mechanism construction etc, the robot should always track straight. (More later ... The Other Stuff) The preceding premise for the control of a differential drive mobile robot appears at first glance to simple. Remember in technologically complex systems that often the simple things are the most elegant solutions. So what needs to be added to make this a complete system? Completion of this system is as straight forward as the simple premise of it's control. There are two Deltas, discussed next, that correct tracking errors and implement steering.

Figure 4.3

Delta 1: Tracking. accounting for true tracking. After building the '332 processor system, motor amplifiers, encoder and the required source code, there is still a tune up step to be implemented. This tune up step involves the first Delta variable - Delta_1 used to account for differences in the drive mechanism between the left and right drive systems on the robot discussed in the previous paragraph. Even with identical driving chips, motors, encoders, belts, chains, wheels etc... when outputting any given duty cycle through the MCPWM function the two wheels will not spin at exactly the same speed. Since the robot has encoders to provide feedback with a closed loop response system it can simply speed up or slow down the two motors to keep the robot tracking true. This however is not the optimal solution as the robot will 'wiggle' to and fro while accomplishing this task. A direct approach that keeps with the simplicity of the previous paragraph is to use the delta_1 variable and subtract it from the PWM output sent to one of the two motors and add it to the PWM output sent to the other motor in an open loop fashion. This variable, delta_1, is determined experimentally, by powering up the system with a small piece of code that outputs a fixed duty cycle PWM and actually measuring the difference in angular velocity between the two wheels. A couple of educated guesses will quickly iterate to a solution for the delta_1 variable which should be within 2.5% of full scale (100% duty cycle). An easy fixture to test this is to remove the wheels of the robot and attach two strings of equal length stretched across the floor. Then power up the robot with the sample code and watch it reel in the strings. When one string or the other is fully wound quickly cut the power and measure the length left unwound on the other string. This should be done five to ten times and averaged to attain a single reading. The reader now has an implementation plan for a differential drive robot with two feedback paths and the first adjustment variable delta_1 that affects both feedback paths in an open loop fashion allowing the robot to 'track true'.

Delta 2: Steering. Much like the discussion of the delta_1 variable above, the delta_2 variable is used to modify the feedback term going to both motors inversely. Delta_2 is the variable that controls steering. The case investigated here is that of turning while the robot is stationary usually referred to as pure rotation as opposed to rotation during translation. Pure rotation is easily implemented by the following: while the robot is servo-ing, continuously being told to go to location x, the value of delta_2 is incremented. The reader may well ask, 'And how does this make the robot turn?'. To understand this is to understand that the position x the robot is repeatedly being commanded to go to never changes. Simply, the robot is not 'going' anywhere, but the variable delta_2 keeps increasing under software control, causing the feedback path to report a positive error on one side of the robot and a negative error on the other. This is due to the fact that delta_2 is added to one feedback loop and subtracted from the other. So the error keeps growing and the feedback mechanism will compensate by spinning one motor clockwise and the other counter-clockwise to compensate. Again, a simple, but elegant solution.

The Other Stuff: Above we discussed the ideal case with constant surface coefficients and identical mechanisms. Back to realty, as the reader will realize that this is never the case. The phenomena where a finely tuned system slowly looses track of its actual global position in the world due to slippage of wheels etc is referred to as drift. There is no simple or quick fix for drift. The best methods for dealing with drift use sensors to measure the distances to known objects or landmarks and then to correlate this data, using a Kahlman filter, against the robot's 'belief' of its position in the world. This subject will require many additional articles to cover and for now is left to those who have come before. (References #10, #18, #19, #20, #21, #22, #23, #24) This represents a short list of the more applicable reading material from the authors library.

Now we've looked at all three mechanisms (Input, Output & Control) required, from the theory and hardware aspects in order to implement MCPWM and FQD as well as code snippets for both, all we need is the control algorithm and the glue to hold it all together. In this system, the control and glue come in the form of a small program to start everything off and update the system every once in awhile to show some real output.

The following code snipped is from "TPU.H"

#define TPU_BASE 0xFFFFFE00
#define TPU_RAM 0xFFFFFF00

struct tpu_Def
	unsigned short int TPUMCR;				/* The following defines are derived directly from the TPURM provide above */
	unsigned short int TCR;
	unsigned short int DSCR;
	unsigned short int DSSR;
	unsigned short int TICR;
	unsigned short int CIER;
	unsigned short int CFSR0;
	unsigned short int CFSR1;
	unsigned short int CFSR2;
	unsigned short int CFSR3;
	unsigned short int HSQR0;
	unsigned short int HSQR1;
	unsigned short int HSRR0;
	unsigned short int HSRR1;
	unsigned short int CPR0;
	unsigned short int CPR1;
	unsigned short int CISR;
	unsigned short int LR;
	unsigned short int SGLR;
	unsigned short int DCNR;

The following code snippet is from "MAIN.H": comments follow second code snippet

/* global character buffer */
unsigned char char_Buffer[100];

The following code snippet is from "MAIN.C":

#include "crc332.h"
#include "tpu.h"
#include "lcd.h"
#include "mcpwm.h"
#include "fqd.h"
#include "lcd.c"
#include "mcpwm.c"
#include "fqd.c"

int main(void)
	struct tpu_Slave_mcpwm_ram * stpu_Ram;
	struct tpu_Primary_fqd_ram * primary_Tpu_ram;
	long *i;
	char *k;
	unsigned short int *w;
	unsigned short int counter_1;
	unsigned short int pwm_Width;
	unsigned char j;

	pwm_Width = MIN_PWM_WIDTH;
	stpu_Ram = (struct tpu_Slave_mcpwm_ram *)(TPU_RAM +(SLAVE_1_CHAN << 4));
	primary_Tpu_ram = (struct tpu_Primary_fqd_ram *)(TPU_RAM + (PRIMARY_CHANEL << 4));

	i = (long*)0x102000;		/* now fill some memory for a quick test */
	for(j = 0; j<4; j++)
	    (*i) = 0xDEADBEEF;
	lcd_String("CRC 332");
	lcd_String("Init MCPWM.");
	lcd_String("Init FQD...");
	lcd_String("           ");
		for(counter_1 = 0; counter_1 < 100; counter_1++)
		pwm_Width += PWM_INCREMENT;
		stpu_Ram->high_time = pwm_Width;
		if((MAX_PWM_WIDTH - PWM_INCREMENT) < pwm_Width)
			pwm_Width = MIN_PWM_WIDTH;


Realistically, any function the reader chooses to construct can be used for the position function. There are many improvements to be made to this demonstration program. The first simple changes left to the reader is to make the code portable. (Remove the hard coding of values and make all TPU references generic)

From the algorithm stand point, a good first step might be to implement a dead spot around the target position the robot is trying to reach. I.E. if we're still moving (when scaled speed is taken into account (Current_Read - Last_Read etc...) and we're only off by less that ten counts (again scaled by the current speed of travel), let's not update the PWM duty cycle. On the next time through, either you will have gotten farther away than ten counts (scaled by a speed factor) and you will again update the duty cycle, or you will still be close enough for it not to matter.

Another algorithm commonly used employ's a time function that scales the error factor (desired position - robot current position) by the amount of time the error has existed. I.E. the longer we've been in an error condition the harder we need to try to catch up since the previous catch-up scheme was not performing adequately. Rule bases formed by sets of algorithms like the preceding have been shown to react dependably with time, however they do not usually approach the efficiency of completely 'tuned' PID filters when running near top system speeds.

SECTION 5: Processor Platform

At this point, the reader might logically be asking, "how is it possible to build a small robot, using the 68332 processor, to compete in a competition like the micromouse where space is limited?" In answer to this, the author presents Figure 5.1 & 5.2 The board depicted there-in represents the culmination of work conducted as a group project including the author do develop just such a board. This space packed power house measure 3.375" x 3.9" and only draws 149mA when fully populated. A modular design was chosen so that the user needs only populate the components required for the job at hand.

Figure 5.1:

Figure 5.2:

Upon further examination, the user can see the header pins used to implement the MCPWM and FQD, TPU functions in the lower right corner of the picture. These pins are laid out in a fashion to facilitate connection of servo motors, encoders etc... by placing power and ground pins adjacent to them, and offering a jumper selectable voltage source for the power pins so that the processor and servo motors are not sharing the same power from the regulator. A lot of time and effort went into the placement of the parts in order to allow the author to pack-in all of the functionality required. All of the header pins that bring signals to and from the external world are on 0.100" centers to take advantage of commonly available connectors like those from Amp/Waldom (Family 50-57-90XX, where XX is the number of pins) Even in this space constrained package, the board offers a list of power packed features hard to match, as follows: (Table 5.1)

Table 5.1:

BDM: Complete bdm interface built into onboard CPLD logic. (In system Programable) A simple cable to parallel port is all that is required.

Using BDM code may be uploaded into RAM or Flash, memory and registers can be dumped modified and coded may be executed(trace or go).

Power: Input: 7.5VDC - 40VDC drawing 149mA. (This leads to 4+hrs of operation from a 9v battery)

Output: onboard -5v inverter 200mA for LCD contrast and off board Op-amp support.

Speed: Processor: 0 - 25MHz Static.
Memory: Ram: 1Mbyte (The author also designed a 2MByte expansion board for use through the vertical stackthrough port)

Eprom: 512Kbyte (Mounts to bottom of board)

Flash: 256Kbyte (Mounts to bottom of board)

Boot Options: 8 bit buss width / 16 bit buss width. (Jumper Selectable) through the default CPLD programming. (Refer to schematic for Jumper setting)

Also Jumper Selectable are options to boot from Eprom, Flash, or Battery Backed RAM

A to D: 8 channels single ended, header pins grouped with VSS, VDD & VEE for off board OP-AMP support.
Reset: Onboard POR and External PushButton input via header pins.
Battery Backup: Two seperate battery backup ic's with support for lowpower CE lockout. Support for two batteries.

1: bottom of board mount coin cell which supplies up to five years of battery backup for two 512K (Low-Low-Power) ram chips.

2: External input via header pins.

Serial Support: RS-232C compatible signal levels brought out through a DB-9.

Requires an optional driver IC which mounts to bottom of PCB.

Discrete I/O: 24 Bi-Directional I/O's connected to system through CPLD's and brought to header pins. CPLD's have all signals necessary for complex bus interfacing including Data bus & timing signals.
CPLD Support: Onboard CPLD parts are in-system programmable using simple parallel port cable and free synthasis software.
SPI: Four dedicated SPI ports are provided. Two have additional (spare) processor Port-E pins and IRQ lines. These lines support a variety of plug-on prehiperals such as A to D, Parallel interface, Vector 2x compass and much more.
Other Expansion: A vertical stackthrough expansion buss allows for addition of multiple daughter boards, including I/O and 2Mbyte expansion board.
LCD Support: Header pins are provided for standard parallel interface LCD modules. Internal board generation of -5VDC (invertor) can be used for generating contrast voltage. For systems operating above 16MHz (Maximum wait states internally programmable on the bus) an exteranl DSACK generator is built into one of the CPLD's used to drive the Chip Select for the LCD.
Clock Calendar: Battery backed clock calendar with scratchpad RAM.

Hours, Minutes, Seconds, Day, Month, Year.

Documentation The 'C' Robot Controller (CRC332) ships with all Schematics, graphics,'C'-compilers,demo software and CPLD compiler included on CD-ROM.

At this point, it should be obvious, that this board was designed specificly for use with mobile robots. All hardware issues have been addressed from the standpoint of taking this board from the bench to the robot without the need for any additions. (excepting only batteries!) Soon to follow this powerhouse a micro-minature all surface mount compact version will soon follow with a target size of 2" square. This compactness will come at the expense of reduced number of higher density connectors.

One of the most powerful features on this board, aside from that afforded by the 32 bit MC68332 processor, is that provided by the two on board Complex Programmable Logic Devices (CPLDs). As a simple first step towards utalizing the functionality afforded by the CPLD's the reader might move the two required Exclusive-OR gates, discussed above in Section 3 on MCPWM, into the CPLD removing the need for additional IC's.

The author provides a second article specifically dedicated to using these CPLDs. This article can be found in this same issue of the Seattle Robotics Society's online Encoder magazine.


So how does the reader reach, 'The next step in motion control and software-sensor fusion?' A solid first step is to remove most of the control loop and high demand overhead from the processor's instruction processing unit. In this article the author has outlined how to do, exactly that. With all of the features and power packed into the MC68332 micro-controller, take a moment to marvel, as the author did while writing this article, at how little code was required to support all of these hardware functions. Success in hand the reader will realize that the intensive motor control functionality has shifted to hardware allowing the processor to move on to more important processing tasks such as sensing, planning and acting. Looking back over the document I'd like to say, "See, that's all there is to it, it's just that easy!" But, alas, that is not the case, and this article just scratches the surface of the MC68332 processor. A complete MC68332 system is a complex powerhouse that requires a substantial effort to develop, configure, program and interface not to mention the more than 3000 pages of technical documentation from Motorola one must digest. (GULP!) Contact the author at: mailto:(kmaxon@uswest.net)


1. The particular mask set for the chip referenced in this article is the '-G' mask. Such a mask set would be found in the end part number as MC68332GCFC-25. Where the 'G' after the 68332 in the product part number indicates the mask set. The MCPWM function is not present in the '-A' or the '-C' mask set, although one could download the micro-code source and compiler from Motorola and compile their own version which would be loaded into on-chip RAM at run time.

2. The Motorola technical documentation for the CPU32 product line with respect to the MC68322 processor can be found at: MC68332 Technical Documentation The links to technical documentation will lead you to the full manual set for the CPU32, SIM, QSM, TPU, as well as special function references for the TPU functions and user manuals. Just a note for the technically inept, these manual sets are composed of 3000+ pages of highly technical readying.

3. 'Schaum's Outline of Feedback and Control Systems', Allen R. Stubberud, et al / Paperback / Published 1994

4. 'Feedback Systems Design, Volume 1, Principles of control', George A. Biernson / Hardcover / Published 1988

5. 'Introduction to feedback control systems', Pericles Emanuel, Edward Leff (Contributor) / Hardcover / Published 1979

6. 'Modern Control Systems', Richard C. Dorf, Robert H. Bishop / Hardcover / Published 1997

7. 'Introduction to Robotics: Mechanics and Control', John J. Craig / Published May 1989

8. 'REA's Problem Solvers: Automatic Control Systems / Robotics', Research and Education Association, Chief Editor Dr. M Fogiel / Revised 1990.

9. The NT port of the GCC compiler is available through the EFI group: EFI Link All associated documentation, compilers, linker, etc can be found there. A DOS version of the compiler also exists as the author has personally used it, but the site that it was originally obtained from is no longer available on the net.

10. 'Intorduction to Robotics', Phillip John McKerrow / Published 1991

11. 'Mobile Robots Inspiration to Implementation', Joseph L. Jones, Anita M. Flynn / Hardcover / Published 1993

12. 'Motion Control by Microprocessors', Jacob Tal, Galil Motion Control / Published 1985

13. 'An Introduction to Robot Technology', Philippe Coiffet, Michel Chirouze / Hardcover / Published 1982

14. 'Microprocessor Based Robotics - Intelligent Machine Series', Mark J. Robillard / Published 1983

15. 'Eshbach's Handbook of Engineering Fundamentals: Fourth Edition', Byron D. Tapley / Hardcover / Published 1989

16. 'The Motorola Mc68332 Microcontroller : Product Design, Assembly Language Programming, and Interfacing ',Thomas L. Harman / Published 1991.

17. 'The Circuit Cellar Ink The Computer Applications Journal',Steve Ciarcia / Published 1999.

18. 'Designing Autonomous Agents Theory and Practice from Biology to Engineering and Back', MIT, Elsevier / Published 1991.

19. 'Robotics Science', Michael Brady / Hardback / Published .1989

20. 'Artificial Intelligence and Mobile Robots Case Studies of Successful Robot Systems', Kortenkamp, Bonasso, and Murphy / Hardcover / Published 1998.

21. 'The Map-Building and Exploration Strategies of a Simple Sonar-Equipped Mobile Robot', David Lee/ Published 1996.

22. 'Kinematics of Robot Manipulators', J.M. McCarthy / Published 1987.

23. 'Algoritymic Foundations of Robotics', Ken Goldberg, Dan Halperin, Jean-Claude Latombe and Randall Wilson / Hardcover /Published 1995.

24. 'Robot Motion Planning and Control', Michael Brady, John M. Hollerbach, Timothy L. Johnson, Tomas Lozano-Perez, Matthew T. Maxon / Hardcover /Published 1982.

25. 'Build Your Own Robot', Karl Lundt / Published 2000.

26. 'Behavior Based Robotics', Ronald C. Arkin / Published 1988.

27. 'Sensors For Mobile Robots Theroy & Application', H. R. Everett / Hardcover / Published 1995.

28. 'Cambrian Intelligence the Early History of the New AI', Rodney A. Brooks / Published 1999.

29. 'Applied Robotics', Edwin Wise / Published 1999.

Come visit me and share the state of robotics in my corner of the world. Kenneth's Web Page

CRC332 Boards are available... Max's Little Robot Shop

'Drinkin Diet Coke - n - Gettin it done ' - Kenneth