Okay, I’m a dork. I made so many mistakes trying to figure out this serial communications thing, it’s not even funny. But, I’ve got it working now.
Two major things went wrong. First, I failed to realize that the ’32, by default, operates off of its internal 1.0 MHz oscillator. You have to program clock selection bits as a separate step to get it to use an external crystal (which I had connected, but didn’t realize wasn’t being used). Since all of my baud rate calculations were being done assuming a 4.0 MHz clock, they were way off (which explained the bizarre timings I was seeing on the TX pin).

Unfortunately, try as I might, I still can’t seem to get the external crystal to work. I’ve succesfully driven a PIC16F877 at 20 MHz on perf board, so I’m not sure why I can’t get the ATmega32 to run at 8 MHz.
So I punted on trying to get the crystal to work, and configured the MMC to operate at 9600 bps instead of 38.4 kbps (the ATmega32 can’t drive a serial line at 38.4 kbps with less than 8.5% bit-rate error, and that may be too much for the MMC). After much futzing with this speed, I still couldn’t make it work, which brings us to my utter stupidity: the MMC wasn’t fully seated in its socket, and so wasn’t actually getting the signal!
It’s working for now, and so I’m going to spend some time actually writing software. I’ll write code to run the motors at a constant speed, regardless of load (within limits), and then drive the bot around in a small square or triangle. It won’t balance, so I’ll add a stabilizing caster wheel, but it will give me enough of a platform to work on that I can develop a basic PID controller.

The reorg is well under way. Some of you may experience issues with the rendering. All I can say is, “get a better browser!” In general, I’m using Safari, and only occaisionally testing on IE/Mac 5.2. Windows users, well you can just fend for yourself. Sorry!

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, Solutions³ 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.