Got the second wheel encoder hooked up, and replaced the other wheel. I also hooked up the MMC, but for whatever reason have not been able to get the serial communication between it and the ’32. I can see the pulse train on the ’scope, but the MMC fails to recognize the transmission.
Outstanding success! I figured out the problems I was having getting PORTC’s pins to Respect My Authoritaaa…
Turns out that JTAG is enabled by default on this device, and for some reason disabling JTAG internally didn’t work. I tried writing the bit by assigning it twice in succession in gcc. Instead, I changed the fuses to disable JTAG, and that cleared up the problem.
An interesting side note about how I realized it was the JTAG settings getting in the way: I was thinking that perhaps some alternate function of the PORTC pins might be getting in way, but it didn’t dawn on me which function until I ran a simple sequential count on the pins in fairly rapid succession, using the STK500 LEDs to show the output. Lo and behold, only the least- and most-significant two bits changed state. Checking the docs, sure enough, the remaining bits were all dedicated to JTAG.
Once I got PORTC in order, I reconnected the LCD which I had wired up a couple nights ago. It worked like a champ, with the otherwise untested code I wrote then. This image shows the LCD displaying my friend’s name and the current encoder count (more on that below).
After the success with the LCD, I couldn’t resist getting at least one wheel encoder working. So I took a stab at setting up an AVR interrupt handler, set a few configuration bits, enabled interrupts, and presto! It worked.
I’m taking this approach to the quadrature decode: I feed the “A†channel from each encoder into one of two interrupt-generating inputs on the ’32, which is configured to interrupt only on rising edge transitions. Then, in the interrupt handler, I check the state of the “B†channel for the corresponding wheel, and if it’s low, I subtract one from a 32-bit counter, otherwise I increment the counter.
A little impromptu testing (marking the tire, counting a few revolutions forward and the same number back, should get a result count close to zero) seemed to indicate very little error (no missed counts) using this scheme. There’s enough resolution in this encoder that it registers a step even in the play present in the gearbox.
Another check was to see how long the ’32 spent in the interrupt handler. The image below is a shot of the oscilloscope. The top trace indicates the low-to-high transition of encoder channel A, and the lower trace roughly indicates the time spent in the interrupt handler (I set a pin high first thing in the interrupt handler, and clear it as the last step before returning). The handler is much faster than the encoder half-period, and this is only on a 4 MHz prototype. (The larger image has some annotations).
Okay. It’s very late, and I’m going to pay for my stubbornness in the morning. Here’s an image of the bench after tonight’s fun. The colorful board is the STK500.
A couple days after I bought theBasic Stamp, my Atmel kit arrived, pretty much destroying any hopes for the poor Stamp to be a part of this project.
I set up the STK500 and the pre-programmed AT90S8515 started pulsing an LED on the board. Then I installed the AVR gcc toolchain on my PowerBook, and a couple of hiccups later (you have to explicitly erase it before programming), I was writing C code and watching LEDs blink. The AVR gcc toolchain worked very well on Mac OS X, but I did have to make a minor change to one of the include files to get it to compile for the ATmega32. Targetting the AT90S8515 that came with the STK500 worked without modification.
I’ve started building a new main board around the ATmega32 controller. I cleaned up the layout and added some LEDs to give status info. In the picture below you can see the PIC16F877-based board on the left, and the new board on the right. The new parts placement should allow marginally better cooling (the fins of the MMC heatsink are now aligned with the primary direction of the airflow when the bot is in motion). I also superglued most of the components down before wiring, which helps keep them in place as I work on it.
The board on the left is still populated with the PIC, Solutions3 Motor Mind C module and Analog Devices linear accelerometer.
The board on the right is a little farther along than is shown in the image. I've wired the LCD header (in the lower-right) as a first step, but I'm having trouble getting the AVR to actually output onto PORTC what I've specified in the code.
Since Capilano finally came out with a Mac OS X version of DesignWorks, I’ll probably get a real board designed and fabbed in the next couple of weeks. I have a couple of ATmega128 parts which have, among other things, two USARTs, and a couple more I/O ports. Since one USART is used for communicating with the MMC, it’ll be nice to have the other one for relaying data back to a host computer for analysis.
Now, it’s time to do homework. I’ll try to write more soon.
I haven’t worked on this project much for the last six months. Between full-time school and a full-time job, it was really very difficult to spare time for anything else. Having made this project into a priority for my eductional efforts helps me to justify working on it.
Given the difficulty I’ve run into getting a C compiler for the PIC to work on Mac OS X, and taking the advice of a friend, I’m going to switch from plans to use a PIC18Fxxx to instead using an Atmel AVR. There’s an open-source toolchain that works on Mac OS X and includes gcc. I expect the programmer and chips to arrive on Wednesday.
In the meantime, I’ve discovered the Parallax Basic Stamp. I don’t really intend to do too much work in Basic, but thanks to the availability of the very nice MacBS2, I bought a BS2p40 from JameCo and had it blinking an LED in under an hour (including the time it took to make a serial cable).
We’ll see if I can make it interface to the MMC and inertial sensors; it has no A-to-D converter, so I’ll either have to add one, or find some alternative. I don’t know what peripherals are available on the SX core used in the BS2, and I really don’t know if it will be fast enough to do all the necessary things.
I’ve added some shots of the ’bot so that you can see there’s more to it than just some beautiful hubs & tires.
I’m watching the egress of Opportunity live on NASA TV right now. Very exciting. I wish there was more live video.
