trp3.asmAssembly code for the Enhanced Simple Robot.
trp3.bas SBASIC for the Enhanced Simple Robot.
In the previous issue of TRP (the second issue), I presented the various pieces needed to build a simple robot. It used the Motorola 68HC11 microcontroller for the brains, two modified hobby servo motors for locomotion, four AA batteries for power, and a front bumper using two micro switches to "see" things in front of it. The program in the HC11 would allow the robot to move about, bumping into things and making its way around them. My 10 year old son Tommy, who enjoys working on electronics and computers with me, built a Lego robot which used the same program. I would like to extend a thank-you to those readers who worked on your own robots and shared your experiences with me.
In this issue I will expand the capabilities of the two robots from the last article (Figure 1). I will add a sensor onto my Clear-Cube-roBot (CCB) to allow it to track a black line drawn on white paper. This is one of the robotic competition events called line-following. At the Seattle Robotics Society (SRS), we try to have line-following competitions once or twice a year. A couple of months ago CCB, with his new sensor, finally beat the reigning SRS line-following champion: Karl Lunt's CBE (crude but effective) line-following robot. (I must admit that both CCB and CBE were beaten badly by another new contestant built by Gary Teachout. His winning robot was controlled by a simple digital flip-flop circuit--not a microprocessor--so Karl and I feel that we had a good competition for "our class" of robot.) Tommy and I will also be adding a sensor onto his Lego robot which will allow his Bot to see a light and move towards it. Both of these robot projects build on top of the information and hardware presented in my previous TRP article.
Figure 1. Light-seeking sensor on the Lego robot (left) and line-following CCB.
Software notes: In the last article, the robots turned by pivoting; the programs used this time will be using arcing turns. The servo-motor control subroutines in the program are slightly modified as compared to the last article to accommodate this. I am also using a different technique for generating the PWM signal which controls the motors. Last time we used interrupts to reset the PWM output lines as well as tracking a counter. This time I am using a feature of the OC1 timer to set the PWM lines automatically. Using this method eliminates the need for interrupts. As an added programming bonus, I will include a version of the program written in Karl Lunt's SBASIC. Look for Karl's article on his BASIC compiler for the 68HC11 elsewhere in this issue of TRP.
The rules for line-following are relatively simple. Lines are made with a black permanent marker, 1/4" wide, on white butcher paper. A course is made up of a grid of one-foot squares. Within each square of the grid there will be one of ten possible grid paths (actually three path types with different orientations) as shown in Figure 2, including straight lines, 90¡ turns, and 90¡ 6-inch radius arcs.
Figure 2. The 10 possible grid paths for line-following.
A line-following course is drawn on a single piece of white butcher paper. Figure 3 shows a possible course which is rather challenging. Each line-following robot takes three turns on the course and the fastest time is used. The robot with the fastest time wins. A maximum time limit is used to disqualify a robot who gets hopelessly lost or stuck in the course. The layout of the course on a large grid with known pieces allows you to design a robot to navigate through the pieces, which should allow it to successfully complete any possible course. Some robots will do better on the straight-aways while others will do better on the curves, so a course with variety makes for a good competition. We have also made interesting circular courses. This allows for a competition where you place two robots on opposite ends of the course, both going the same direction. The first robot to bump into the other robot from behind is the winner. At SRS we are expanding our line-following competitions to have two additional types of courses: a course with branches, and a course with branches and loops. We are still working out the exact rules, but the intent is to map out the course and locate certain goals, which requires more sophisticated programming.
Figure 3. An example line-following course.
There are a variety of ways to make a line-following robot. The two additions we need to make to our simple robot are to add a sensor which can see the black line, and to provide a program which will use the sensor and actually follow the line. In a moment we will detail a sensor to use, but first let's consider what the sensor should do.
The line-following sensor is made up of one or more line-detectors. A line-detector must have two different states: one state when it is over the white paper and another state when it is over the black line. Suppose we have a good detector which can see the difference between the paper and the black line. How many of these detectors do we need in our sensor, and how should they be placed? If we only use one detector, we can know when we are seeing the black line, but when we then see the white paper, what should the robot do? Did the line turn to the left, to the right, or is the line going straight and the robot just moved off the line? If we use two detectors in our sensor, side-by-side about an inch apart, we can try to keep the line in between the detectors. We will start the robot moving forward with the line in between the detectors. When one of the detectors sees the black line, the robot turns in that direction until the other sensor sees the black line; then the robot turns the other direction until the first sensor sees the black line, and so on. The robot is now successfully tracking the black line!
This method is widely used, but it has an inherent problem with speed. After the first detector sees the line, the robot will continuously arc back-and-forth to track the line. Even on a straight section the robot will arc from side-to-side. If the arcing motion is achieved by turning one motor on and keeping the other motor off, the fastest the robot can move is 1/2 of its normal straight-ahead speed. If the arcing is really pivoting, the robot will just stay in place pivoting from side-to-side until the batteries go dead. Not too good! What if we added a third detector in-between our two detectors. We can use the same logic to arc when one of the outside detectors sees the line; but when the middle detector sees the line, the robot can stop arcing and proceed forward. This allows the robot to move at its full speed on straight paths. If the robot is arcing half of the time and going straight the other half, its average speed will be 3/4 of its full speed, much better than 1/2 speed in the two-detector sensor.
I've tried other sensors with more than three line detectors, using layouts other than a simple side-by-side layout. Detectors can be placed farther to the sides and also placed forward of the other detectors to attempt to determine the course layout. My multi-detector sensors haven't been any more successful than a simple three-detector sensor. Additionally, the placement of the line-following sensor in relation to the robot's wheels can have a dramatic effect on the robot's behavior. I've tried sensors directly under the wheels as well as sensors at different distances out in front of the robot. Have fun experimenting with different configurations.
The detectors for the sensor must distinguish between the white paper and the black line. Along with the detector we must also provide a light source which will be reflected off the white paper, but will not be reflected by the black line. I've tried infrared (IR) transmitters and detectors. A problem with IR is there are too many natural sources of infrared light. Last year I brought CCB with a five-detector infrared line-following sensor to an SRS competition. In my basement CCB performed flawlessly; at the meeting, the IR sensor didn't work well. We tried closing the curtains in the room and dimming the lights, but still no luck--even with dynamic calibration on my sensor board. After that experience, I tend to stick to visible light for simple sensors.
A common detector to use with visible light is a photoresistor. This device has two leads and changes resistance in different light. Two examples I see in the current (Spring 1995, #395) All Electronics catalog are 16K½ and 500K½ in the dark, and 1K½ and 100½ in the light. These are typically used with a resistor in series, connected to power and ground as a voltage divider. The voltage between the photoresistor and the resistor is monitored and changes with changes in light. I have found a different detector which I use for my line detectors, but stay tuned as we will be using photoresistors for Tommy's light-seeking sensor later in this article.
All Electronics is one of a few surplus electronics mail-order catalogs I receive. I really enjoy surplus catalogs for two reasons: I am exposed to items I normally wouldn't see, and the prices are quite low so I can buy a bit of this and a bit of that just to play with. One item I tried last year from All Electronics is their photovoltaic detector (item number PVD-1; page 39 in their Spring 1995 catalog), made by Centralab (Centralab # EA7). This detector is a miniature glass-encapsulated, hermetically sealed silicon solar cell; the size is 0.8 by 0.53 inches. Being a solar cell, it actually generates a voltage. At 75 cents each, or 10 for $5.00, I just had to pick up 10 of them. I've used them for a couple of different sensors--really cool. Just today I ordered 20 more to have on hand for future projects.
OK, let's use three of these photovoltaic detectors (PVDs) for our sensor. How do we hook them up to the BOTBoard? The BOTBoard has eight analog-to-digital inputs which would work quite nicely. However, the program in the HC11 would have to read the A/D inputs and also determine what voltage indicates black and what voltage indicates white. Also, we would have to provide some way to adjust this black/white threshold. This would require somewhat complicated software to operate. I like to build sensors which are a bit more intelligent and are easier to use (for those of you interested in the HC11 A/D capabilities, we will be using them for Tommy's light-seeking sensor, detailed later in this article). I want a sensor with three digital outputs, one for each detector which indicates if that detector sees the white paper or the black line. Each of the detectors has an LED for a light source, to provide a reflection off the paper. I also want to be able to calibrate the sensor for the sensitivity between the paper and the line. One last thing I want on the sensor is three LEDs on top which are controlled by the HC11 to indicate which of the detectors sees the line. This allows the program to be rather simple with regard to the sensor and provides visual feedback to allow for manual calibration without changing the program.
Figure 4. Schematic of my three-detector line-following sensor.
The operation of the sensor is fairly basic (Figure 4). The light-source LEDs (LED1, 2, and 3) are always on; they provide a constant light source which is reflected off the paper and is seen by each PVD. The photovoltaic detector (PVD1) directly controls the plus input of a comparator (A+). The minus input of the comparator (A-) is given a reference voltage using P1 and R4. The output of the comparator (A) is connected to the HC11, PortC, bit 0, with the pull-up resistor R7 providing a good comparator-to-HC11 voltage match. The other two PVDs are wired up in the same manner, connected to the HC11 using bits 2 and 4 on PortC. The three feedback LEDs (LED4, 5, and 6) are driven using PortC, bits 1, 3, and 5, and are controlled by the software in the HC11.
I built a prototype of the sensor using a 2.75" x 1.625" piece of protoboard (Figure 5). For the three potentiometers (P1, P2, and P3), I used black multi-turn pots. This gives the precision needed to calibrate the detectors, and I also used their physical size to build isolated compartments for the three LED/PVD pairs. I used a forth pot (Px) as a side wall to isolate the third detector; it isn't actually used for the electronics. I used a permanent black marker to mask off the light from the sides of LEDs 1, 2, and 3 to shield the PVDs from their side-light: I want to only see the reflected light. To shield the PVD detectors from front light, I filled in the area between the four pots with a wall of hot-glue applied in successive layers. Once cooled, I used the black marker to darken the hot-glue. Each of the three PVDs were secured to the PC board with a drop of hot-glue. Make sure to position the photo cell upward on the board, with the red dot on the PVD up. The red dot also marks the positive wire which is wired up to the + inputs on the LM339. The two wires on the PVD are not shielded, so be sure to keep them from touching. I placed the remaining resistors on the protoboard and ran wires to connect everything as shown in the schematic. Be sure to wire the PortC connector to extend through the top of the PC board.
Figure 5. Prototype line-following sensor (left) with new sensor on CCB (right).
I built a second sensor based on the above schematic diagram using Protel's Autotraxª software to lay out a printed circuit board. To get all of the traces on a single-sided board, the sensor grew to a size of about 3" x 2". I used the same exact physical layout for the pots, LEDs, and PVDs, with black cardboard used to isolate the front and back of each PCD compartment, as well as to cover the top of the sensor to keep light from getting through the board (Figure 6). Additional shielding for the sensor from external light may be needed depending on the physical layout of your sensor, the type of circuit board used, and the environment the robot will be operated in. Figure 7 shows a close-up of the new sensor.
Figure 6. Physical layout of the prototype line-following sensor, bottom side.
The sensor should be placed out in front of the robot (Figure 5) and is connected to the BOTBoard using ribbon cable with 2x5 IDC connectors on each end. I used copper wire (12 gauge, from some extra Romex house wire) soldered to the sensor board with loops to connect to four metal PC mounts hot-glued to the bottom of my robot. I made similar wire mounts for both sensors to allow interchanging them, or to allow removing them altogether if I want CCB to do other tasks. I achieved good results by placing the sensor detectors about 3.5" in front of the axis of the wheels. If the sensor is placed out farther, the sensor sweeps left-and-right too far when the robot turns. If placed too close to the robot, the robot must turn farther left-and-right to track the line. Of course the physical placement of the PVD compartments will also affect the operation of the sensor. All of these parameters must be synchronized with the driving software for best performance.
Figure 7. New line-following sensor, bottom side, connected to CCB.
The line-following software includes code to calibrate the detectors in the sensor. To invoke the calibration routine, assemble (using AS11.EXE) and load the file TRP3.ASM into your HC11 (using PGBUG11). When you start the program, touch either of the front bumper switches (PortA, bits 0 and 2). This invokes the calibration routine, which shuts off the servo motors. The calibration routine is in a loop which reads the values from the three PVDs and sets the three feedback LEDs accordingly. If the feedback LED is on, the PVD sees the line. Using a piece of white paper with a thick black line on it, position a PVD over the line and adjust the corresponding potentiometer so the feedback LED is on when the detector is over the line, and the feedback LED is off when the detector is over white paper. Do this for all three detectors. Once calibrated, the robot is ready for its test-run. I use a simple line-following track which is a rectangle with two of the corners being 90¡ turns, and the other two corners arcs (pieces 7-5-9 on top and 2-5-4 on the bottom of a 3x2 grid). This way I can continuously watch the robot without chasing it too far. The robot can be sent either clockwise or counter-clockwise to test turning either left or right. I found that without a lot of physical shielding, the sensor was sensitive to other light sources. Covering the top of the sensor with black paper or plastic helps, as does making sure the sensor is as close to the paper as possible. Once running, you may need to fine-tune the calibration for optimal performance.
Since we have a fairly sophisticated sensor, the software to use the sensor will be quite simple. The basic algorithm, expressed in pseudo-code, is this:
Initialize the Servo Motors. Start moving forward. Loop Forever If either bumper switch is closed, Calibrate the detectors. Else If the LEFT detector sees the line, Set motors to arc to the LEFT. Else If the RIGHT detector sees the line, Set motors to arc to the RIGHT. Else If the MIDDLE detector sees the line, Set motors to move FORWARD. End-of-Loop
This works amazingly well for being so simple. However, there are problems when encountering the 90¡ turns. For example, depending on the exact orientation of the robot when the left detector sees a 90¡ turn, the left detector may clear the outside corner of the turn, followed by the middle detector catching this corner. Once the middle detector sees the line, the robot will stop arcing and continue forward, thus losing the line. Not too good. What to do? We could do a geometric study of the placement of the detectors in the sensor and build a new sensor to try to overcome this problem. Another solution is to adjust for this in software; since I just built the hardware, let's take the easier route and adjust the software. By implementing a short delay after starting a left or right arc, we can cause the middle detector to not be looking for the line at the crucial moment when the middle detector passes over the corner of a 90¡ turn. We must be very careful not to delay for too long or we will overshoot the line with the other side sensor. The delay in the program listing works well with CCB using 2.25" diameter wheels. The final program design is seen in Figure 8.
Figure 8. Flow diagram of the line-following program.
The wheels on Tommy's Lego-BOT are 3.5" in diameter. When I use them on CCB, I get a 56% increase in forward speed (7" wheel circumference versus an 11" circumference). Thus, a course which CCB can navigate in one minute with the 2.25" wheels can be done in about 38 seconds with the 3.5" wheels. Theoretically, 6" diameter wheels will yield a time of about 22 seconds while 8" wheels yield 17 seconds. The limiting factor is the rotational speed of our servo motors, as well as the tracking ability of the sensor/software combination. The speed of the modified hobby servo motors cannot be changed or controlled, but I have seen robots using them which drive them with 9 or 12 volts instead of the normal 5 to 6 volts. This will get them to turn faster, but may shorten their life span considerably. For really high performance, different motors should be used, or the servos could be geared up for faster wheel rotation. Adjustments in the software timing will be needed to work with different sized wheels.
The light-sensor robot is much easier to build and to program. I wanted a simple project to demonstrate the use of photoresistors and the A/D converters on the HC11. A photoresistor will change its resistance based on the amount of light it sees. They are typically constructed from cadmium sulfide (CdS) or cadmium selenide (CdSe), according to Floyd's Electronic Devices text. They are also known as "photoconductive cells", or CDS devices. The schematic symbol is a variable resistor in a circle, along with a lambda character (lambda for light-waves). Again, from All Electronics I found a couple of photoresistors to try. I used a pair (item number CAT # PRE-10; page 47 in their Winter 94/95 catalog) which have a very large change in resistance: 50½ in bright light, to 1M½ in dark. These devices are about 1/4" square, larger than most photoresistors (although I've seen some a lot larger), which look good as robot eyes. Other types of photoresistors can also be easily used without any changes to the circuit or program.
Each photoresistor is configured with another resistor in a voltage-divider setup. The voltage in between the photoresistor and the resistor is monitored by an analog-to-digital (A/D) input on the HC11. As the photoresistor is exposed to more light, its resistance decreases, which makes the voltage seen by the HC11 increase. The A/D converter has an 8-bit resolution, which yields 256 discrete voltage measurements. The sensor I built for Tommy's Lego robot used a 0.75" x 1.0" piece of protoboard. On this board I placed the two photoresistors sticking up about 0.75" above the board, with their leads bent to point about 30 degrees away from each other in the plane of the floor. I also put two 1K½ resistors on the board (Figure 9) and connected the board to the HC11's E port, along with power and ground, with an 8" length of thick ribbon cable.
Figure 9. Light-seeking sensor using photoresistors: Circuit and top-down physical layout.
The algorithm for the light-seeking behavior is quite simple. I read the values from the two voltage-divider photoresistor circuits with inputs 0 and 1 of the HC11's A/D converter. Whichever value is the largest (left or right), I turn the robot in that direction. Like the line-following code, I use arc turns rather than pivots to always provide forward movement. The program is a continual loop looking at the sensors and either arcing left or right towards the light.
Well, we did slightly modify this simple program (Figure 10). Since the HC11 can scan the A/D converters every 64µS, or over 15,000 times a second, the result was very jerky. The first modification was to delay for about half a second each time through the loop. This resulted in the robot going in slow arcs--still not what we were looking for. What we settled on was an arced turn for about a quarter of a second, then forward movement for another quarter of a second. This is the behavior implemented in the program.
Figure 10. Flow diagram of the line-following program.
Getting analog input into the HC11 is really quite easy. There are a handful of Control Registers to use, as detailed in chapter 10 in the Motorola HC11 E Series Technical Data book (one of the pink books). I won't detail all of the various options of the A/D converter here, but let's look at the necessary settings to get the basics working. For the HC11 to determine an analog voltage, it takes some time. We must tell the A/D converter to start converting the input signals, then wait for the conversion to be complete.
The OPTION register (address $1039) is used to initialize the A/D converter. We need to look at the effect of each bit in this register and set the bits correctly. We want to use it powered-up (bit 7 on), using the system clock (bit 6 off), ignore IRQ changes (bit 5 off), delay to let the crystal oscillator to stabilize (bit 4 on). Bits 0-3 are used for resets and interrupts, so let's ignore them by setting them to zeros. After all of this, we know we want bits 4 and 7 set to 1 with the other bits set to 0. To do this, we can load the appropriate number into the A register in the HC11, then write the A register to the OPTION port using the commands:
ldaa #%10010000 staa $1039
The A/D converter is now initialized. To use it we can either look at a single A/D input line, or we can look at a bank of four input lines (lines 0-3 or 4-7 on port E). For our purposes, let's read a bank of four and then use the first two, lines E0 and E1, which are our photoresistor voltage dividers. To start the A/D conversion and to monitor if the conversion is done or not, we use the control register ADCTL (A/D Control/Status, address $1030). Bit 7 is the Conversion Complete Flag (CCF), which is 0 when the conversion is working and 1 when the conversion is done. Bit 6 is not used. One-time or continuous scanning is set by bit 6, off being a one-time scan and on scanning continuously. I prefer to do one-time scans when required, so I set bit 5 to a zero. To choose between a single input channel or a bank or four, clear bit 4 (for single) or set it to a 1 for a bank. Bits 0-3 are used to choose which input line(s) are used. For multi-channel mode, which we are using, bits 0 and 1 are ignored. If bits 2 and 3 are 00, the first bank (0-3) of input lines is used. If bits 2-3 are set to 01, then the second bank (4-7) of inputs is used. The other two possibilities are reserved and used for factory testing of the A/D converter. So, from all of this, we want to set bit 4 on and the rest off:
ldaa #%00010000 staa $1030
This starts the A/D conversion on input lines 0-3 on port E. We can't read the values until the conversion is done, which is indicated by bit 7 in the ADCTL register (0=not-done, 1=done). We can use the branch-if-clear instruction to test the desired bit and branch back to the same instruction. However, the brclr instruction cannot use extended addressing, so we must first set up an index register to use as an address offset. I typically use the X register to point to the start of the HC11 Control Registers (address $1000). The resulting code to wait for a finished conversion is:
ldx #$1000 Conversion_Not_Done: brclr $30,X $80 Conversion_Not_Done
The $30,X takes the number in the X register ($1000) and adds $30 to it, giving us the needed address of $1030. The $80, which is %10000000 in binary, is a mask indicating which bit(s) to check to see if they are zero. If all bits specified by the mask are set to 0 at the address indicated ($1030), then the instruction will branch to the label (in this case, back to itself). If all of the masked bits are not 0, then the program continues with the next instruction.
OK, the HC11 has just finished an A/D conversion on the first bank of input lines on port E. Where are these values? The four values are found in the ADR1 through ADR4 registers, addresses $1031 through $1034. We can read line 0 at address $1031 and input line 1 at address $1032. Tommy's robot code does this and compares the two values, turning in the direction of the larger value (brighter light).
Figure 11. Finished light-seeking Lego-Bot.
I constructed the light-seeking sensor using the two photoresistors and the two 1K½ resistors on a small piece of protoboard. I used a heavy 5-wire ribbon-cable, about 12" long, to connect this board to the BOTBoard (Figure 11), connected to 5-volts, ground, and port E bits 0 and 1 (one of the 5 wires in the ribbon cable was not used). Tommy bent the ribbon cable to get the sensor to the desired height and orientation: about 9" from the ground, level with the floor, and pointing forwards. We discussed mounting the sensor closer to the robot, and making an enclosure to shield the photoresistors, but Tommy likes the look of a small sensor suspended about 4" above the robot. He can easily reposition the sensor by bending the ribbon cable differently, and can also easily change the angle of the photoresistors (Figure 12). During Lego-Bot testing that evening, Tommy was in the kitchen (a great place to find smooth floors when robots don't like carpets) directing the robot with a small flashlight, when I happened to open the refrigerator for some juice. The robot quickly decided it liked the light from the fridge much better and made a bee-line for it. We spent the evening playing with the robot, flashlight, fridge, and I think we got the oven involved too.
Figure 12. Tommy with his upgraded Lego-Bot.
Karl Lunt has been working on a BASIC compiler for the HC11. I have had the privilege of being one of his beta testers for the compiler, trying to break it as well as think of features it needs. As of this writing I have version Beta 0.8, which should be fairly close to his release 1.0 version. The SBASIC code included here does exactly the same thing as the assembly language code. A few things to note: for my assembly code, I use an older version of AS11.EXE to assemble the code, SBASIC requires the assembler ASM11.EXE, and the resulting .S19 file from either assembler can be loaded into the HC11 with PCBUG11. Please refer to Karl's article for the specifics on using SBASIC.
The line-following robot is a good start on a competitive robot. You may want to try different wheel sizes for increased speed. You could use other types of motors, either faster servo motors, or regular DC motors, for even more speed. The line-following logic should work well for these different configurations.
Tommy's light-seeking robot shows the basics of photoresistors and the A/D converters in the HC11. The resulting program does not use the front bumper on the robot, so as Tommy's Lego robot is running around the kitchen, it blindly will run into things (like me) without noticing or avoiding them. As Tommy has already pointed out to me, the next logical program to write would be to combine the light-seeking logic from this issue with the bumper logic from the last issue. This would make the robot much more intelligent and impressive; I will leave this as an exercise for the reader. A fun option to the light-seeking behavior is light-avoiding. The change needed is to look at the two photoresistors and to turn towards the one with the lowest value (the dark). Just change the two branch-subroutine calls on either side of the Right_Brighter label: Arc_Right and Arc_Left, to be in the reverse order, Arc_Left and Arc_Right. The program now is a light-avoider. Maybe I'll try changing the robot from being a light-seeker into a light-avoider when the bumper is hit. Well, enough of this writing; I'm heading back to the kitchen to play with robots. I have a 4-legged walking robot which I just finished building today. Now I need to write some code...
I would like to express thanks to my son Tommy for his help and excitement in our robots running around the kitchen. I would also like to thank Karen Klamm and John Piccirillo for helping review the article, Marvin Green for the incredible BOTBoard (now over 1,000 sold!!!), and to SRS for their continued inspiration in robotics.
Tom Dickens works for Boeing Computer Services in aerodynamics research, and also teaches evenings.
BOTBoards Marvin Green: email@example.com Zorin HC11 Kits Christpher Nielsen: Zorin (206) 282-6061 firstname.lastname@example.org P.O. Box 30547 Seattle, WA 98103-0547 68HC11E1 chips Beall and Glenn Enterprises Machine Shop (Surplus parts) 1-800-874-4797 Route 1 Box 243 Lacey's Spring, AL 35754 Servo Motors & Wheels Tower Hobbies 1-800-637-4989 (or visit your local hobby shop) Various Electronics Active Electronics 1-800-677-8899 Digi Key Electronics 1-800-344-4539 Mouser Electronics 1-800-346-6873 Surplus Electronics All Electronics 1-800-826-5432 B. G. Micro 1-800-276-2206 Electronic Goldmine 1-602-451-7454 MECI (Mendelson) 1-800-344-6324
HC11 MCHC11 Reference Manual (M68HC11RM/AD Rev 3): Reference for entire 68HC11 family of devices. THE source for 68HC11 assembly language. M68HC11 E Series Technical Data (MC68HC11E/D): E series specific hardware and internals reference. Motorola Contact: Motorola Literature Distribution Center 1-800-441-2447 P. O. Box 20924 Phoenix, Arizona, USA 85036-0924 (or visit your local Motorola sales office, check the phone book)
(I use the Miller book in my college class):
Microcomputer Engineering by Gene H. Miller 1993 Prentice Hall ISBN 0-13-584475-4 544 pages Microcontroller Technology The 68HC11 by Peter Spasov. ISBN 0-13-583568-2, library congress number TJ223. M53S63 1993 004.165--dc20 copyright 1993 by Regents/Prentice Hall, Englewood Cliffs, NJ 07632 The 68HC11 Microcontroller By Joseph D. Greenfield (at R.I.T. BTW) Saunders College Publishing, (Harcourt Brace Jovanovich), NY 1992 ISBN:0-03-051588-2
Electronic Devices by Thomas L. Floyd 1984 Charles E. Merrill Publishing Co. ISBN 0-675-20157-8
AS11 Motorola's 68HC11 assembler program. Free from Motorola and available from various electronic bulletin boards. Motorola BBS: (512) 891-3733. PCBUG11 Motorola's 68HC11 communications program. Free from Motorola and available from various electronic bulletin boards. Motorola BBS: (512) 891-3733.
AS11_Primer.txt and PCBUG11_Primer.txt: These are documents I have written for my students about the AS11 and PCBUG11 programs.
trp3.asm & trp3.bas The HC11 programs as published here. (see top of page for the code).