Report and Demo Due Dates:

Objectives:

• To gain experience interfacing a microcomputer to a stepper motor.
• To gain experience programming the Motorola Time Processor Unit (TPU) in both SM and DIO mode.
• To gain experience debouncing buttons with software.
• To gain experience reading manufacturer's documentation and providing solutions based on that documentation.

Equipment, Parts and Provided Software:

Documentation:

Background:

Microcomputers are sometimes used to control rotating mechanisms, such as shafts and axles as well as attached pulleys, gears and/or wheels. A stepper motor is a motor whose rotor position can be controlled precisely by switching direct current (DC) voltages to two or more stator windings. Each winding can be energized in the forward direction, energized in the reverse direction, or not energized at all. Such a motor is convenient to control using a microcomputer since only buffered digital H-bridge input signals are required. Motorola's Time Processor Unit (TPU) is a programmable sub-system in the MC68332 microcontroller that has built-in functions that greatly simplify the generation of the digital waveforms that are required to control a stepper motor.

The stator windings in a stepper motor must be energized in the correct direction and in the correct sequence in order to produce controlled rotation of the rotor. The first six steps in the full-step sequence are given in the table below, which assumes the use of the L298 dual H-bridge driver IC. Note that the provided TPU driver controls the L298 enable inputs EnA and EnB using TPU timer channel 12 and 13 , and drives L298 inputs IN1, IN2, IN3 and IN4 using TPU timer channels 8, 9, 10 and 11, respectively, with the built-in stepper motor function. Each step in the full-step sequence advances the rotor of the Jameco motor by 3.6 degrees; thus 100 steps advance the rotor through one full revolution. Each step in the half-step sequence advances the rotor by 1.8 degrees. 200 steps are required for a complete revolution in half-step mode.

Note that in the full-step sequence, the total current drawn by the motor from the DC power supply is roughly the same in every step position. If one relaxes this constant-current restriction, then one can double the resolution of the rotor positioning by using the half-step sequence, which is shown in the table below. The additional cost of the half-step sequence is that the control waveforms are slightly more complicated and the total drawn current becomes position-dependant. In the case of the laboratory set-up, the two L298 enable inputs (EnA and EnB) are controlled separately using two different TPU timing channels. Thus the recommended hardware configuration assumes that EnA and EnB channels are properly disabled whenever the winding current is supposed to be off.

The stepper motor that you will be controlling in this set of laboratory exercises will be operated in open loop mode. By this we mean that the microcomputer sends out digital signals to the stepper motor and assumes that the rotor will always rotate through precisely the correct number of steps. The microcomputer lacks the feedback means to verify the actual position of the rotor before and after each step command. Open loop operation is more risky in the sense that the microcomputer cannot verify that it does indeed have accurate control over the rotor's position. The rotor position may in fact deviate from the expected position if, for example, the limited torque of the motor is unable to rotate the loaded shaft fast enough to keep up with the stepping commands. A better alternative to open loop operation would be to operate in closed loop mode. To do this one would need to provide feedback through a shaft encoder sensor that would allow the microcomputer to independently verify the actual position of the rotor. But we will not be using feedback in this lab. Instead you will initially set the rotor pointer to the "12 o'clock" position, which the TPU driver software will then associate with step number $7FFF, which is the middle position in the full range of 16-bit unsigned positions.

The stepper motor module also contains three buttons and three LEDS. The three LEDS have been included to provided status information about the motor. The buttons will act as inputs and will control the rotation of the motor.

Debouncing swtiches and buttons, while conceptually simple, is typically a non-trivial problem. Switches and buttons do not act in an ideal way. Overshooot and undershoot result from pressing on the switch or button. This non-ideal behaviour makes it hard to process button presses in digital systems.

In the lab, transitions on the input pins generated by pressing the buttons and releasing them will be used to debounce the buttons in software. Hardware solutions do exist for this problem and are the subject of a question in the Report Requirement section of this lab.

Pre-lab Work:

1. Compute the address locations for your three ISRs on TPU channels 3, 4 and 5. TPU channels 3, 4, and 5 must all be driven using interrupts. Their respective ISRs must be correctly inserted into the vector table in order for your solution to this lab to succeed. Consult the references above and the code in tpu.s to determine the correct location. Channel 8 has already been computed. Use this as your guide. You must provide the actual address to get full points for this one. (2 pts)
2. Compute the values for HSRR1, HSQR1, and the channel control values for channels 0-2 for output to the LEDs and Channels 3-5 for input from the buttons. The LEDS are in output mode using the Discrete IO function with no interrupts. The buttons are in input mode also using the Discrete IO function but using interrupts to detect transitions on the pins. You must initialize channels 3-5 to detect both negative and positive transitions. (5 pts)
3. Provide a flowchart (or pseudocode) for your solution to the EventTask in exercise 3. In this code you must maintain a state for each button. Button presses are composed of one negative transition, and one positive transition. The transitions will be detected by your ISRs in exercise 2 and placed into the EventQueue. Your EventTask must pend on the EventQueue and determine the current state of each of the buttons before determining the next step. Include the LED requirements in your flowchart. Consult the references above for information on the Discrete IO function of the TPU. You may also need to consult the schematic for the stepper motor driver board provided above as well. (3 pts)

Exercise #1: Verify Initial Build and Hardware Setup

• Download the lab4 tar file and place it into your cmpe401 directory. Untar it by typing

  tar xvf lab4.tar

• Change into the newly untarred lab4 directory and type

  make

• Remove power from the board and turn output off on the Instek power supplies before connecting anything.
• Connect 12 V from Channel 1 of the Instek supplies to the top red connector labeled 12 V on the Stepper Motor module.
• Connect 5 V from the fixed 5 V supply of the Instek supplies to the middle red connector labeled 5 V on the stepper motor module.
• Connect the ground from either the 5 V or the 12 V supplies of the Instek power supplies and connect the grounds of the 5 V and 12 V channels together. DO NOT USE THE GREEN EARTH TERMINAL ON THE POWER SUPPLIES FOR ANYTHING
• Connect the stepper motor to the stepper motor module in the correct direction. The stepper motor module has a four pin header marked with WGRB. This refers to the colours on the cable connected to the motor. Orient the four pin connector based on the wire colour in the cable.
• Power on the board.
• Push the output button on the power supply to provide power to the stepper motor module.
• Grasp the spindle of the motor and orient the shaft so that the dot is placed in the 12 o'clock position. Originally all of the motors had pointers connected to the spindles but many of them have fallen off. Don't be concerned by that.
• Use the normal download procedure to download the lab4.s19 to the board and run it by typing

  go 10000

• This initial build will test your hardware setup. The specifications for this initial build are as follows:
  1. Stepping the stepper motor using polling
  2. Half-Step Mode
  3. 14 Step Rates
  4. Min 25 steps/sec, Max 200 steps/sec
• The PollingMotorTask will rotate the motor continually using a consistently repeating pattern of one rotation clockwise,and one rotation counterclockwise. Ten rotations will occur before the Task calls OSTimeDly with a delay of five seconds.
• If the motor is not rotating or the red light indicating power-supply overload is illuminated on the Instek power supplies, turn the power to the motor off immediately. Damage to the power supplies or the 68332-based boards may result if you don't take prompt action to turn off the power to the motor during improper operation.

Exercise #2: Motor Control Using Interrupts

• Comment out the line of code that creates the PollingMotorTask and uncomment the line that creates the InterruptMotorTask. Note the similarities and differences between the PollingMotorTask and the InterruptMotorTask.
• Create the code that inserts your ISR addresses into the correct locations in the vector table. You will be coding ISRs for channel 3, 4, 5 and 8. Consult Freescale's Engineeering Bulletin and the tpu.s file for how to determine the correct location for your ISRs.
• Create the code that inserts the correct values for HSQR1, HSRR1, and the channel control values for TPU channels 0-5.
• Create the code for the Channel 8 Interrupt that posts to the StepSem semaphore to signal to the InterruptMotorTask that the previously requested step request has completed.
• Create the code for the Channel 3, 4, and 5 Interrupts that post input transition events to the supplied EventQueue. You must detect which transition occurred and on which button. Post an appropriate event into the EventQueue once you have detected which button produced which transition. In this exercise you will be calling C code from assembly in exactly the same way as in lab #2. The only difference is in conforming to the OSQPost prototype.
• You will be processing these events in exercise three. In this exercise, printing out a string to indicate an interrupt on a negative transition or positive transitive would be the suggested approach for verifying that your ISRs on channels 3, 4, and 5 work correctly. Do this inside the ISR using the macros you learned in EE380. Consult the lab manual for EE380 to review these macros.
• The lab instructor's solution in .s19 format will be available for you to view for guidance.

Exercise #3: Motor Control Using Events, Interrupts, and Push Buttons

• Comment out the line creating the InterruptMotorTask and uncomment the line creating the EventTask.
• You are only required to deal with two states in the EventTask. If a negative transition on any of the buttons is retrieved from the EventQueue, store it in a STATE variable. If a positive transition is retrieved from the EventQueue process it as a "button press" only if the STATE variable of the button is "negative transition already received". If any other state was stored when a positive transition is retrieved, the state of the button should be changed to the RESET state for that button.
• If a "button press" is detected on TPU channel three (S1) then retrieve the current position of the motor and add 200 steps (one revolution in half-step mode) to it.
• If a "button press" is detected on TPU channel four (S2) then retrieve the current position of the motor and subtract 200 steps (one revolution in half-step mode) from it.
• If a "button press" is detected on TPU channel five (S3), reset the current position of the motor to the centre (= 0x7FFF).
• Once your motor is rotating correctly insert the code that turns the LEDs off and on based on the state of the motor.
• The lab instructor's solution in .s19 format will be available for you to view for guidance.

Report Requirements:

• Briefly describe the L298 hardware and its interface to the NMIX 332.
• Summarize the initialization required to operate TPU channels 8-13 in SM mode, and TPU channels 0-5 in DIO mode, if you did not provide an initialization summary in your design section for exercise 2 and 3.
• Switch debouncing is quite simple in principle, but can be non-trivial in practice. Suggest one hardware method of debouncing the three buttons.
• Your typed report is to briefly describe your design solution for the two laboratory exercises.
• Be sure to provide neatly formatted and well commented code for the two exercises. Include any code that you inserted or modified. Do not include the code you were explicitly instructed to modify unless you modified it in a different way.
• Briefly describe your test cases for verifying that each of your solutions was working properly. Describe which cases were tested, as well as the anticipated and actual results for each test case and place these test cases in a table.

Marking Scheme:

Last modified November 14, 2005