Editing Experimenting with Stepper Motors as Rotary Encoders using a PIC running BoostC Project

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 203: Line 203:
  
 
== Microcontroller Program Design ==
 
== Microcontroller Program Design ==
There are several different ways the software can work: 
+
I no longer have the patience for assembly language. I have moved on to C in particularly BoostC, see link below. I like this compiler it has both a free version with some restrictions and a very reasonably priced full version. Writing in C should make the program fairly easy to read. Most of the design should be evident by reading the program, however a few notes here may help.
  
*Simple polling when the encoder is checked as often as you can get to it.
+
The idea is to put each activation sequence in a table and then step through that table and activate the corresponding port bits and thus stepper coils. The four wires can be activated in a total of 6 different ways, one table corresponds to each permutation. The particular table to use is set using the permutation command ( p ).  
  
*Timer driven interrupt programming where the encoder is checked based on some timer.
+
The series of wires to energize is specified in the arrays StepperStepsN where N is the number of the wire permutation. Each step just increments its way through the array wrapping around the the beginning and the end.  
  
*Interrupt driven programming where changes in the encoder output trigger the interrupt ( I have not worked this one out here )
+
Commands are received via an interrupt driven routine, the main loop checks each time around to see if a complete command has been received. Because commands are only interpreted in the main loop all commands are ignored until the program returns to the main loop. The exception to this is the stop command which will terminate a g or x command and return to the main loop quickly. RS232 transmission is not driven by an interrupt and so during transmission from the pic no stepping takes place.  Commands which do not result in motion execute very quickly, most of the time is for communications.
  
The software remembers the last state of the encoder and compares it to the current state: one of the following must be true:
+
Currently drive to the motor is half step drive. This gives twice as many steps per revolution as is labeled on the motor. I plan later to let you select half step, full step or wave drive. See the links below for more information.
  
*There is no change which we take to indicate that there is no rotation ( true if we have not missed any changes ).
+
==== Compiling ====
 +
The zip file contains the entire source bootst project.  Unzip into a directory and open in source boost.  Set the target to 16F877A.  See the comments in the program header for other setup before compiling.   After compiling my compiler reports something like:
  
*There is a change indicating a positive or negative rotation of one step ( which we add or subtract from our step count )
+
Memory Usage Report
 
 
*There is a change but it does not correspond to a one step rotation, this can happen when we miss a step or when the hardware sends bad data.  It can easily happen any time rotation speed drops so low that the hardware cannot detect the rotation, or when the rotation speed starts up and our old rotation state is not accurate.  The software counts this as an error.
 
 
 
All variables are unsigned, this keeps speed up.  Since the rotation is bi-directional the reset of the count is to a middle value for the range of the variable 32000.
 
  
The software also logs the data received any time it changes, this is limited to about 100 changes because a whole byte is use for logging, with a little packing of data 400 changes could be recorded.
+
*RAM available:368 bytes, used:139 bytes (37.8%), free:229 bytes (62.2%),
 +
*Heap size:229 bytes, Heap max single alloc:95 bytes
 +
*ROM available:8192 words, used:2118 words (25.9%), free:6074 words (74.1%)
  
Control of the software is via the serial communications library that I have described in other articles.  It yields a command driven interface described above.
+
I think you could contract the program a bit to get under the 2K free compiler limit.
  
==== Compiling ====
 
The zip file contains the entire source bootst project.  Unzip into a directory and open in source boost.  Set the target to 16F877A.  See the comments in the program header for other setup before compiling.    After compiling my compiler reports something like:
 
  
Memory Usage Report
 
  
*RAM available:368 bytes, used:248 bytes (67.4%), free:120 bytes (32.6%),
 
*Heap size:120 bytes, Heap max single alloc:95 bytes
 
*ROM available:8192 words, used:1239 words (15.2%), free:6953 words (84.8%)
 
  
The program seems to be safely under the 2K free compiler limit.
 
  
  

Please note that all contributions to OpenCircuits may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see OpenCircuits:Copyrights for details). Do not submit copyrighted work without permission!

Cancel Editing help (opens in new window)