Controlling Stepper Motors Using the Power IO Wildcard
C library functions and MOSFET drivers for a four-phase six-wire unipolar permanent-magnet stepper motor

This document describes how to control stepper motors using a QCard or PDQ Board with one or two Power IO Wildcards. Each Power IO Wildcard can control one or two six-wire four-phase unipolar stepper motors, for a maximum of four steppers that can be interfaced to each controller. Pre-coded library routines simplify high level control of up to four unipolar motors. You may use NEMA 11, NEMA 17, NEMA 23 or NEMA 34 stepper motors.

The Mosaic stepper motor is a four-phase, unipolar stepping motor. It is a standard size, 200-steps-per-revolution, NEMA 17 (1.7 in. square footprint, 5 mm shaft diameter), 12 V motor. This motor, like most stepper motors is a permanent-magnet rotor motor. Stepper motors usually have two independent windings, with or without center taps. Those without center taps require bipolar drive, while the center-tapped windings like the Mosaic Stepper are used with unipolar drive. The Mosaic stepper is typical of common high-resolution motors – a full revolution requires 200 steps, while each step turns the shaft only 1.8°. This motor is commonly used in household appliances, medical equipment, stage lighting devices, and in various industrial control applications.

See Stepper Motor Specifications for the motor's full physical and electrical specifications, and mounting instructions.

The motor has six wires, connected to two split windings as is common for unipolar stepper motors:

In use, the center taps of the windings are typically wired to the positive supply, and the two ends of each winding are alternately grounded through a drive circuit to reverse the direction of the field provided by that winding. The Motor Wiring Diagram also illustrates the order of the stator poles in the motor: A, B, A’, B’. This is the order in which they must be energized to cause the motor to step in a specified direction (clockwise or counterclockwise). The following Figure shows the pin connections to the Power I/O Wildcard.

The following table shows the wiring connections for two motors, labeled motor_0 and motor_1. Motor_0 is interfaced using the Power IO Wildcard outputs Out0, Out1, Out2, and Out3. Motor_1 is interfaced using the Power IO Wildcard outputs Out4, Out5, Out6, and Out7.

One output of the Power I/O Wildcard is connected to each of the four phases of the motor, a +12V supply is connected to both center taps of the motor and to the V+Field pin of the Wildcard, and the 12V supplies ground return is connected to any of the output field ground pins on the Wildcard. The following Figure shows the internal drive circuitry of the Power I/O Wildcard, showing four of the eight outputs. Each output is controlled by a power MOSFET whose gate bias is derived from the field supply which must be 4V or greater to provide sufficient gate voltage. Each MOSFET open-drain output is protected with a flyback diode to the V+Field supply and an internal drain-source reverse diode.

The Power I/O Wildcard is rated for field voltages to 50V allowing a stepper motor to be driven with supply voltages up to 50 volts. The Mosaic stepper motor is rated for 12V continuous operation assuming that one phase at a time is energized. It can be run at significantly greater voltages if the duty cycle is correspondingly reduced. The Field supply should be wired to the V+Field pin on the Wildcard’s Field Header. This connection is necessary to enable the Wildcard’s internal diode clamps. These diodes prevent the voltage on the output pins from spiking to above the supply voltage when an output is turned off. If the supply is not connected to the V+Field pin, switching current OFF in inductive loads would cause a voltage spike great enough to cause the output transistors to break down.

The stepper motor will run from lower voltages too, but a minimum 4V supply is needed to provide gate bias voltage for the Wildcard’s MOSFET transistors.

Stepper motor current is limited by winding resistance; each phase draws a maximum of 400 mA from a 12 V supply. This current consumption is well within the 2 A continuous rating of the Power I/O Wildcard’s outputs. If the motor is run in high-torque or half-stepping modes as described below it will draw more current from the 12V supply than its continuous power rating can support. Consequently, its must only be run intermittently in those modes to prevent overheating, or turned off between uses.

When current is applied to one winding of the motor, the rotor (under no load) snaps into alignment with the stator poles corresponding to the energized winding. It will hold that position against an applied mechanical load, at least until the load exceeds the holding torque of the motor. At that point the rotor would slip, and try to catch at the next equilibrium point corresponding to the energized winding, four steps away. Consequently, when they slip stepper motors don’t slip by one step, but by multiples of 4 steps, to one of the equilibrium positions. For any pattern of winding actuation a 200 step-per-revolution motor has 50 equilibrium positions.

To rotate this motor continuously, we apply power to the four phases (or windings) in sequence. We will assume positive logic, where a logic 1 means turning ON the current through a motor winding. This is the way the Power I/O Wildcard works, with a logic 1 turning ON an open-drain output, forcing the output to a low voltage and sinking current.

The following control sequence will step the motor counterclockwise one full step at a time:

Each row represents the state of actuation of the four windings, and successive rows indicate successive times. Note that there are four steps to a full waveform on each winding, with the fifth step repeating the first. The output byte represents the hexadecimal data byte that is sent to the Power I/O Wildcard. Only the lower nibble (four bits) are used. Two motors, corresponding to two axes of motion, could be controlled by a single Power I/O Wildcard by using the upper nibble for a second motor. Full stepping with only one phase energized at a time is also called wave stepping.

While not implemented in the software driver provided here, there is a way to get greater torque from a stepper motor, at the price of greater current. Energizing two adjacent phases provides greater torque. When two adjacent poles are turned ON together the rotor turns to just half-way between the two poles, with both poles exerting force. Twice the current is required, and the forces sum to provide a torque 1.4 times greater than that provided by energizing only one phase at a time. The following sequence provides high-torque full stepping:

Note that the two halves of each winding are never energized at the same time, but both windings are energized simultaneously. Both full-stepping sequences position the rotor one step at a time. The first full-stepping sequence only powers one winding at a time; thus, it uses less power than the high torque sequence.

Interleaving the full stepping sequence with the high-torque full stepping sequence provides for half-stepping. A first winding is energized, aligning the rotor with a particular pole. Then that pole and an adjacent pole are both energized aligning the rotor halfway between them. Then the second pole is energized alone, aligning the rotor with it, and so on. Half stepping provides 400 steps per revolution and smoother motion than full stepping. The following table provides an 8-step half-stepping sequence:

Steppers move more smoothly and are more resistant to resonance effects when half-stepping. Shaft oscillation occurs when the rotor snaps to the next winding during full stepping. The shaft first overshoots, then undershoots, continuing a decaying oscillation. If the load on the shaft happens to have a harmonic period that matches the rotor's oscillation, a resonance develops between the motor and the load. This can destroy the stepper's ability to rotate at certain rates. These resonance effects are much less pronounced when half-stepping.

An extrapolation of half-stepping is called microstepping, in which you can more precisely position the motor's rotor between adjacent indents.

The software driver provided here allows you to control the stepper motor using full- or half-stepping, not microstepping, but you can read more about microstepping if you like.

About microstepping

The maximum stepper motor speed is limited by the inductance of the windings. As the computer switches current to the windings ON and OFF, the rate of current change is limited by the winding inductance. When the winding is switched ON the current increases at an initial rate given by dI/dt = V/L and is eventually limited by the winding resistance. At high speeds there isn’t enough time for the current to attain its maximum. When the source of the current is switched OFF, the current is diverted through the flyback protection diodes and internal MOSFET diodes and decreases only slowly, at a rate determined by the small voltage across the diodes, effectively braking the motor. The result of these effects is ever lowering torque as the motor spins faster.

There are several ways to increase top speed. A zener diode may be used in series with the flyback diodes to increase the flyback voltage across the winding, allowing the current to decay more rapidly, while still protecting the switching transistors.

Once the Power I/O Wildcard is connected to a controller, the address of the Wildcard module must be set using jumper shunts across J1 and J2.

The Module Select Jumpers, labeled J1 and J2, select a 2-bit code that sets a unique address on the module port of the controller. Each module port accommodates up to 4 modules. Module Port 0 provides access to modules 0-3 while Module Port 1 provides access to modules 4-7. Two modules on the same port cannot have the same address (jumper settings). Table 5 shows the possible jumper settings and the corresponding addresses.

A pre-compiled library (called a "kernel extension" on the QCard platform) defines functions that simplify the driving of stepper motors from the Power I/O Wildcard. Each Power IO Wildcard can drive one or two steppers, and up to four steppers can be controlled simultaneously using two Power IO Wildcards.

A demo program is provided in source code form to demonstrate the initialization and use of the motors. Demos are provided for C and Forth languages, and for the QCard and PDQ Board platforms. While the demo code can be configured to control up to four motor, the default code runs a single stepper motor connected to the Power IO Wildcard as shown in the wiring diagram above.

Stepper motors work best when they are ramped in small speed increments from the specified starting speed to the end speed. The stepper motor control software automates the process of generating ramps based on accelerations, decelerations, and default starting and ending speeds that are specified in the demo program. These parameters can be customized to meet the needs of your application.

The stepper motor driver is based on an interrupt routine that fires once per millisecond. The interrupt service routine is defined in the demo code and can be modified to fit the needs of the application. It invokes the Call_Step_Manager function which accesses the ramp data structures that specify the speed profile for each motor. Up to four motors with indices 0, 1, 2, 3 can be controlled simultaneously. On the QCard operating four motors at full speed (1000 steps or half steps per second) requires half of the processor’s capacity, while on the PDQ Board four motors at full speed require only 8% of the CPU time. The load on the CPU is discussed in more detail in the comments at the top of the demo source code file.

The code in the demo program invokes the library software functions that write to the ramp data structures. The interrupt service routine reads the contents of the ramp data structures and controls the motors in real time.

To full step a standard unipolar stepper motor, a sequence of 4 step patterns is applied in a specified order as described above. The frequency at which the patterns are applied is the stepping frequency. In other words, one step is taken each time a new pattern is written to the motor port. Advancing through the 4 patterns in one direction produces clockwise motor rotation, and advancing through the patterns in the opposite direction produces counter-clockwise motor rotation.

To half-step the same motor, a distinct sequence of 8 step patterns is applied in a specified order. Now each time a new pattern is written to the motor port, the motor moves through half the angle it would if it were full stepping.

You can configure any stepper motor for half stepping or full stepping when runtime initialization occurs as illustrated in the Init_Steppers function in the demo. Half stepping is recommended, as it provides smoother performance and more torque. The cost is that the maximum attainable speed as expressed in revolutions per second is lower by a factor of two compared to full stepping. Thus, if the software is capable of writing a new step pattern to a motor 1000 times per second, then a motor configured for full stepping will take a maximum of 1000 steps per second, while a motor configured for half stepping will take a maximum of 1000 half steps per second. If these two motors are identical, the first will turn at twice the speed of the second. It turns out that the default motors supplied by Mosaic cannot reliably step at 1000 full steps per second, but they can reliably step at 1000 half-steps per second (corresponding to 500 full steps per second). Thus there are no downsides to half stepping.

Because half stepping provides the benefits of smoother operation and lower torque, the demo program uses half stepping by default; this can be changed by editing the source code.

All speeds, accelerations, decelerations and step counts are expressed in units of full steps or half-steps, depending on how the stepper motor has been initialized. The Init_Steppers function at the bottom of the demo source code file corrects for this effect by applying a 2× correction factor to the speeds and accelerations saved in the status array if half stepping is specified. But the user must still be aware when specifying the number of steps or half steps, or when calling functions that take a speed as a parameter. The following table summarizes the units for some important parameters:

The stepper motor driver software is provided as a pre-coded modular runtime library, known as a kernel extension library because it enhances the on-board kernel's capabilities. The library functions are accessible from C and Forth.

Instructions for PDQ Board Platform

Instructions for QCard Platform

COLD

COLD

The C demo is located in your installation directory. It is also provided here for reference.

Instructions for the PDQ Board

#include <mosaic/allqed.h>
#include <steppers.h>

Instructions for QED/Q-line

#include "library.c"

#include "library.h"

The Forth demo is located in your installation directory. It is also provided here for reference.

Instructions for the PDQ Board or PDQ Screen

C:\MosaicPlus\forth\demos\Steppers\stepper_demo_includer_PDQ.4th

Demo_Stepper

Instructions for the QCard, QScreen or Handheld Controllers

C:\Mosaic\Wildcard Drivers\ ....4th  

WHICH.MAP 0=
IFTRUE 4 PAGE.TO.RAM  \ if in standard.map...
       5 PAGE.TO.RAM
       6 PAGE.TO.RAM
      DOWNLOAD.MAP
ENDIFTRUE

4 PAGE.TO.FLASH
5 PAGE.TO.FLASH
6 PAGE.TO.FLASH
STANDARD.MAP
SAVE

The Stepper Motor Control Function Glossary contains the following functions:

Near the start of the demo source code file is the definition of the MAX_STEPPERS constant. The maximum allowed value is 4. For maximum efficiency, set MAX_STEPPERS equal to the number of stepper motors that you are controlling (but never more than 4). Motors are referred to by their indices 0, 1, 2 and 3.

On the QCard there is a trade-off between the number of motors being controlled and the maximum stepping speed, limited by the available processing power of the 68HC11. Given that each interrupt-driven step requires 120 µsec per motor, while all 4 motors are stepping at their maximum speeds (1000 steps or half-steps per second in this application), the 68HC11 processor is busy about 50% of the time managing the motion via the low-level interrupt-driven utilities. Thus most applications would either use fewer motors or would raise the value of the MSEC_PER_TICK constant to decrease the maximum attainable speed of each motor. The PDQ Board has a more powerful processor, so using four motors at 1000 full- or half-steps per second consumes only 8% of the PDQ Board’s processing capability.

A useful parameter in the stepper status structure is the signed 32-bit step counter that keeps track of the step count over a range of ±2,147,483,647 counts. Positive values represent clockwise rotation, and negative values represent counter-clockwise rotation. The Step_Count function returns a 32-bit pointer to this 32-bit variable in common RAM; it accepts the motor index as the input parameter. The Revolutions function in the demo program shows how to read and write this value. If the motor is stopped, the step count will not change during the interval.

You can set the step counter to any value you want as long as the specified motor is not moving. For example, if you perform a HOME operation in which a microswitch is used to detect the home position of stepper motor 0, you could then set the motor's step count to zero. If the motor is configured for full stepping, the count indicates the number of full steps that have been taken since the status array was initialized or since the step counter was last zeroed. If the motor is configured for half stepping, the count indicates the number of half-steps that have been taken. In each case the counter is a signed 32-bit value. To calculate the total number of revolutions, simply divide the step counter by the number of steps (or half-steps) per revolution for your motor. The default stepper motor provided by Mosaic has 200 full steps or 400 half-steps per full 360° revolution.

The specified direction constants are CW (clockwise) =1, and CCW (counter-clockwise) = –1. Note that stepper motors purchased from different vendors may be wired differently internally, and the most common difference is that they spin in the opposite direction than the default motor supplied by Mosaic. If this happens with a custom-specified motor, the simplest fix is to define new direction constants that have the opposite values compared to the default (that is, swap the 1 and –1 values).

Another useful parameter in the stepper status structure is the byte that keeps track of the motor state. This variable is controlled by the interrupt-driven control functions, so to the application program it is a "read-only" parameter. The pre-coded Motor_State function returns the value that encodes the state. Pre-defined constants MOTOR_STOPPED (value 5), and MOTOR_AT_FINAL_SPEED (value –1) are useful for detecting when the motor is stopped or has reached the specified terminal speed, respectively. The Revolutions function in the demo program illustrates how this function is used. After a command such as Steps_At_Speed is executed, the background (that is, interrupt-driven) code sets up the ramp data structures which will control the motor to carry out the specified action. But note that the command (Steps_At_Speed in this example) finishes well before the stepper motor has finished the physical action. Thus the program must wait until a specified state has been reached before giving the next motor command; otherwise the stepper motor’s physical action will be interrupted. In the demo program, the Motor_State function is called repeatedly until it returns the MOTOR_STOPPED value, and only then is the next motor command given. The glossary entry for Motor_State provides additional operational details.

You may specify several default speeds and accelerations for each motor at initialization time. One user-specified speed parameter is called the jog/start speed; it should be chosen as a speed in the safe starting region of the motor's speed/torque characteristic. In other words, the motor should be able to abruptly move from a stopped state to a steady motion at the jog/start speed without losing any steps. The jog/start speed is used by the stepper control software for several purposes. First, when ramping up from a stopped state, the driver hops the motor speed right up to the jog/start speed, and then linearly increases speed (using the specified acceleration) to attain the specified final speed. Second, the jog/start speed is the default speed used by the Jog_Steps function to move from one position to another.

The demo program defines the DEFAULT_JOG_START_SPEED as 100 half-steps per second. This constant is used in the Init_Motor_x functions to specify the jog speed for each motor in the demo program.

Another user-specified speed parameter is called the steady speed; this is typically specified as the fastest speed that the motor can operate at smoothly under load without losing steps. The Ramp_To_Steady and Steps_At_Steady functions use this speed as the final/maximum speed. The demo program defines the DEFAULT_STEADY_SPEED as 500 steps per second, corresponding to 1000 half steps per second. Because the interrupt fires 1000 times per second, this is the maximum speed that the software can support in half stepping mode. This constant is used in the Init_Motor_x functions to specify the steady speed for each motor in the demo program.

The other user-specified motion parameters are the acceleration (used during ramp-up to higher speeds) and the deceleration (used during ramp-down to lower speeds). These are used by the high level motion control functions to generate ramps during speed changes. For example, if a motor is stepping at 500 steps per second and its deceleration parameter is 2500 steps per second per second, a linear ramp-down to a stopped state will take 500/2500 = 0.2 seconds. A slower deceleration rate would result in a longer ramp-down period, and a faster deceleration rate would result in a shorter ramp-down period. Typically, lower acceleration/deceleration values are required for motors and loads with high inertia; the resulting slower ramp-up and ramp-down profiles avoid loss of steps during speed changes. Lightly loaded motors with low inertia can use higher accelerations and decelerations without losing steps. The demo program defines the DEFAULT_ACCELERATION and the DEFAULT_DECELERATION as 2500 steps per second per second. These constants are used in the Init_Motor_x functions to specify the acceleration and deceleration for each motor in the demo program.

Each Power IO Wildcard has an associated modulenum in the range 0 to 7 that is specified by the hardware jumpers and the module port that hosts the Wildcard. The jumper settings are specified the table above, and must match the modulenum declared in the stepper demo program.

Each Power IO Wildcard can accommodate one or two stepper motors with wiring as specified in Table 2. The table shows the wiring connections for two motors, labeled Motor_0 and Motor_1. Motor_0 is interfaced using the Power IO Wildcard outputs Out0, Out1, Out2, and Out3. Motor_1 is interfaced using the Power IO Wildcard outputs Out4, Out5, Out6, and Out7. The demo software declares the address of these motors as the constant MOTOR_0_1_ADDRESS which has value 00, because the Power IO 8-bit output port is mapped to offset 00 in the Wildcard’s address space. To distinguish the two motors attached to this port, the constant MOTOR_0_MASK has the value 0x0F, meaning that motor_0 is interfaced to the lower nibble at bits Out0-Out3. Similarly, the constant MOTOR_1_MASK has the value 0xF0, meaning that motor_1 is interfaced to the upper nibble at bits Out4-Out7.

These constants are used in the Init_Motor_x functions to specify the address, modulenum and port mask for each motor in the demo program.

A periodic interrupt generated by an output compare (OC) is used to invoke the Call_Step_Manager function to control the motor speed. The interrupt is called with each "tick" of an output compare-based interrupt clock. The frequency at which the service routine is called is set by the constant MSEC_PER_TICK which has a default value of 1. Based on this value, the source code calculates the value of the TICKS_PER_SECOND constant, whose default is 1000. This means that 1000 full- or half-steps per second is the maximum speed per motor. If half-stepping, the maximum speed is 500 steps per second, corresponding to 1000 half-steps per second. To change this timing, edit the value of MSEC_PER_TICK (milliseconds per tick); for accuracy, the value should divide evenly into 1000. For example, specifying MSEC_PER_TICK as 2 would halve the maximum speed of each stepper motor, and would reduce the load on the processor by a factor of two. The calculations that convert the specified MSEC_PER_TICK into the value of TICKS_PER_SECOND are documented in the demo source code.

There is a trade-off between the number of motors being controlled and the maximum stepping speed on the QCard. Given that each interrupt-driven step requires 120 µsec per motor on the QCard, while all 4 motors are stepping at their maximum speeds (1000 steps or half-steps per second in this application), the processor is busy about 50% of the time managing the motion via the low-level interrupt-driven utilities. Thus most applications would either use fewer motors or would raise the value of the MSEC_PER_TICK constant to decrease the maximum attainable speed of each motor. The PDQ Board has a more powerful processor, so using four motors at 1000 full- or half-steps per second consumes only 8% of the PDQ Board’s processing capability.

The source code file uses OC3 (output compare 3) to generate the periodic stepper control interrupt. You may select a different output compare channel if you wish, but recall that on the QCard OC2 is used for the multitasking executive's timeslicer, and OC4 is used to support the optional secondary serial port. On the PDQ Board, all eight timer outputs are available for use by the application code. The interrupt service routine simply Call_Step_Manager, updates the TOC3 register, clears the interrupt flag bit, and returns. As described earlier, Call_Step_Manager performs the real-time motor control. See the commented source code in the demo program for additional details.

Some functions that control the motor speed assuming a known starting state (either stopped, or rotating at a known speed). Many of the motor control functions expect as input parameters a direction specifier and a motor index. The direction parameter is +1 to indicate clockwise rotation, and –1 to indicate counter-clockwise rotation. The CW and CCW constants are defined in the source code as +1 and –1, respectively. The motor index ranges from 0 to (MAX_STEPPERS – 1).

The Ramp_To_Speed function assumes that the motor is initially stopped. It expects the direction, target speed, and motor index as input parameters, and returns the number of full or half steps taken during the ramp-up. The motor is left running at the specified final speed. This function is used to ramp up from a stopped state to a final specified speed using the acceleration specified in the status array. As always, speeds are expressed in steps per second if the motor is configured for full stepping, and half-steps per second if the motor is configured for half-stepping.

For example, if motor 0 has been configured for half stepping using Init_Steppers and is currently stopped, the following command causes motor 0 to accelerate up to a speed of 420 steps per second in the counter-clockwise direction:

Ramp_To_Speed( CCW, 420*2, 0 )

(Note: if you are interactively calling a motor control function from the terminal, you must type the numeric direction indicators 1 or –1 instead of CW or CCW)

The Ramp_To_Steady function simply calls Ramp_To_Speed, specifying the motor's steady speed as defined in the status array as the target speed. The demo program specifies the DEFAULT_STEADY_SPEED as 500 steps per second, corresponding to 1000 half steps per second. This value is instantiated by Init_Steppers. Ramp_To_Steady expects the direction and motor index as input parameters, and returns the number of full- or half-steps taken during the ramp-up. This function is used to ramp up from a stopped state to the default steady speed.

The From_Speed_To_Stop function assumes that the motor is initially moving at a known speed, and ramps down to the stopped state. It expects the starting speed and motor index as input parameters, and returns the number of full or half steps taken during the ramp-down. The motor is left in a stopped, energized state with holding torque.

The Soft_Stop function is the most versatile and safest way to stop without losing track of the step count. If the motor is already stopped or disabled, this function does nothing and returns a 0 to indicate that no steps were taken. If the motor is moving (either at steady speed or in a ramp), this routine smoothly ramps it down to a stopped condition and returns the number of steps (if full stepping) or half-steps (if half-stepping) that occurred during the ramp down.

The E_Stop function causes an abrupt emergency stop within 1 tick of the timebase interrupt, without a ramp down. It can be safely used to stop when stepping at jog speed, but at faster speeds, uncounted steps may occur due to motor inertia. E_Stop leaves the motor stopped with a step pattern applied so that the motor still has holding torque. It can also be used to undo the effect of Disable_Motor by energizing the motor coils (but note that before first using a motor, you must call Init_Motor_x as done by Init_Steppers).

The Change_Speed function is the most versatile and safest way to attain any target speed regardless of the initial speed or state of the motor. This routine can be used to ramp up to a specified speed from a stopped state, or ramp up or down to a new speed from a speed that is now in effect. It can even be called while the motor is in the middle of a ramp up or ramp down; this smart routine carefully avoids writing over a ramp that is currently in use by the background interrupt routine.

The remaining high level routines assume that the motor is stopped when the function is called:

• Steps_At_Speed ramps up, steps at the user-specified speed, and ramps down for the total specified number of steps (if full stepping) or halfsteps (if halfstepping).

• Steps_At_Steady is very similar, except it uses the steady speed parameter that is stored in the motor's status structure as the stepping speed between the ramp up and ramp down. The demo program specifies the EFAULT_STEADY_SPEED as 500 steps per second, corresponding to 1000 half steps per second. This value is instantiated by Init_Steppers.

• Jog_Steps performs the specified number of steps at the jog/start_speed as specified in the demo program. No ramp-up or ramp down is performed because the jog speed is typically specified in the safe start/stop operating region of the motor.

• One_Step simply performs 1 step in the specified direction.

All initialization functions in the demo program are performed by the Init_Steppers function. The function expects a single flag that determines whether all of the motors are configured for full or half stepping. The initialization of the var_ticks_per_sec variable to equal the constant TICKS_PER_SECOND is required for proper operation. Disable_Stepper_IRQ is invoked to ensure that the stepper motor interrupt is not running while Zero_Stepper_Arrays we writes over all the control arrays and structures. Then the Init_Motor_x (where x is the motor index) is invoked once for each motor in use. Clear_Motor_Port is called for each motor in use, and only then is Energize_Stepper invoked for each motor in use. Init_Stepper_IRQ locally enables the stepper motor interrupt (OC3 in this example) and globally enables interrupts to start the background interrupt that services the stepper motors.

The Revolutions function is the high level routine that turns Motor 0 in a specified direction for a specified number of revolutions. This routine assumes that Init_Steppers has already been called by Demo_Stepper. The Revolutions function initializes the Step_Count to zero, calculates the number of steps to be taken to do the specified number of revolutions, and calls Steps_At_Speed to set up the ramp structures used by the background interrupt routine. Then a software loop monitors the Motor_State variable, waiting until the state equals MOTOR_STOPPED. The contents of the Step_Count are read and printed out. The high level Demo_Stepper function invokes Revolutions twice, once clockwise and once counter-clockwise. If you have wired up a stepper motor, you can execute the high level function interactively from the terminal (via main in C, or Demo_Stepper in Forth) to see the motor turn.

For a complete list of the motion control functions available in the stepper motor driver, with a brief summary of the function's action, consult the Stepper Motor Control Function Glossary.