Success #1: The Brain is Chosen, and It's All Right

I spent a fair amount of time scouring the net to find the right microcontroller to use for Bing's "main brain."  I had several criteria:  first, I looked at the typical 8-bit microcontrollers used in hobby robots, but they seemed kind of underpowered for the complex programming I expect will be required -- very little RAM, 8-bit registers, small instruction sets, and not many MIPs.  Second, I wanted something that I could grow into as time went by, even after Bing is done.  I had decided that a particular board featuring the Motorola MC68332 would be a decent option, but after a few weeks I found out that I couldn't get that particular board because the guy wasn't going to make the boards any more.  So, a helpful fellow on the chat forum at The Robotics Club of Yahoo pointed me to another 68332 board sold by Axiom Manufacturing and it looked pretty cool.

But while there I found a different chip and fell in love with it immediately:  Motorola's MPC555 (a microcontroller version of their PowerPC line).  I instantly decided that I had to have one, and now I do.  Here is a picture of the board:

The board is 3.5" x 3.5" which is a little larger than I wanted but it has the prototyping area at the top which might be useful.  It is constructed very well, but except for the serial port it really is just a carrier for the MPC555 chip.

This chip rocks unbelieveably!  Look at those connection pins: 272 of them, plus the debugging port which I don't understand very well but might use someday.  And look at these features:

• 52 MIPS at 40 MHz, including an integrated hardware double-precision floating point unit
• Timers
• 32 Time Processing Units to do tasks like pulse width modulation and counting without main CPU intervention
• 70 or more general purpose I/O pins
• 32 channels of 10-bit A/D conversion on-chip
• > 400 kbytes of flash memory
• 26 kbytes of RAM (my only complaint is that I wish this number was a little higher)
• Scads of parallel and serial communications features
• A bunch of other stuff

Holy @%#! I thought.  This thing could just about run the Pentagon.  So I hovered by the mailbox until it arrived.

Axiom fills part of the flash memory with a little monitor program that allows binary code to be rather clumsily downloaded to the chip using hyperterm; it works great.  They supply a little program which you can download and it says Hello back at you.  Cool, but now I want to write my own.  Hmm, where's the compiler?  Where's the assembler?  There isn't one, except for some demos of commercial packages.  Hmm, kind of irritating, so I go to Motorola's site looking for their reference compiler or at least assembler (like the cool one Atmel has for the AVR).  Can't find it.  Nothing.  Doesn't exist.

Gulp.

Ok, what about those commercial packages?  How much are they?  Uh, ok, never mind (CodeWarrior, for example, is $2500, which is probably fine for industrial developers, but is way out of the basement hobbiest league).

After searching, it appeared that the GNU set of open-source GCC tools have a version that supports the powerpc and some hints are found on mailing lists that it might work with the MPC555.  After a very long time downloading the 30 megs or so of various source code tar archives, I'm in major panic mode.  This will never work.

Sure enough, I try to configure the thing to cross-compile from my Windows system to generate some flavor of powerpc executable (eabi format? elf format? did I suddenly get transported to some other planet?), and twenty minutes into bizarre gyrations, I get incomprehensible compile errors attempting to build the compiler.  Bummer.

Quick note:  I have nothing but gratitude toward the GNU folks.  The massive free stuff they put out enables the "little guy" all over the world and that is very, very, neat.

Well, I won't go through all the details (and I actually don't remember them) but many hours of  Guinness-fueled random tweaking later, success!  Well, at least something has compiled.  Quick bullets summarizing the agonizing efforts that followed (each bullet point looks simple enough but it was a big learning curve for me):

• Try to build a little program that does nothing just to prove that I can download some code to the board.  Undefined symbol: _start
• Manage to map the entry point to main with switches to the linker, which creates an "elf" format executable.
• Figure out how to use the objcopy program to convert the elf format executable into an "s-record" format.
• Try to download it.  No luck, the monitor program doesn't recognize the s-record format.
• Thank God, Axiom included the source code to the monitor program on the CD that came with the board.  Hmm.  Careful examination of the gnu-generated s-records reveals that they are different than the ones the Axiom monitor can deal with.  By the way, their monitor has a bug in it where addresses above a certain range will be handled improperly.  I hope it won't be an issue, but it's good to remember.
• Learn about the s-record format and write a C program to translate the gnu format to the Axiom format.
• Yay, the program downloads!  It doesn't do anything but it wasn't supposed to.
• Compile their sample program which echoes Hello World out to the serial port.  Download it.  It doesn't do anything.
• Figure out that the text, code, and bss segments are being mapped to the wrong address range and map them manually with linker switches.
• And... it works.  Since I don't understand half of what is going on I was beginning to get a little panicky but... it works!

You can imagine how amazed and happy I was when I saw my message come back to me from this board, after all the messing around.  I did a little dance.  I can now build a simple C program and send it to the board and run it and it works.  Many issues remain to be resolved, like the standard libraries which I am just not using at all but will want, and so on, but this feels like a major success.

Life is good!  Note to self:  time to make a backup!

I am so impressed with the specs of this microcontroller chip that I am radically rethinking my design of the processing components.  I had been intending to have at least two Atmel AVR processors running on their own boards as sensor interfaces, and a few more acting as servo controllers, since I have recently decided that I want to build my own servo controller system instead of using an off-the-shelf board.  I'll explain the reasoning behind this decision in a future report.

But this chip is so amazing that I am now thinking that it should be able to handle all of these tasks by itself without other processors -- which, if true and workable, means that Bing will be a one-chip robot.  That would be very excellent (I will still need to make a few small circuit boards so I won't miss out on that bit of fun).  If I can do this, then several steps get cut out of the sensor processing development tracks, which should help me a bit in getting it done, plus the complexity and weight will be impacted in a good way.  This is now my Plan A.

Success #2: Fetching pictures from the Gameboy camera

In parallel with the above effort, I have been using an Atmel 4434 microcontroller in an effort to fetch images from a cheap Gameboy camera I got from buy.com.  This will be Bing's vision sensor, which will be used for navigation in the firefighting contest maze.  Here is a summary of the steps that were involved in developing this:

After laboriously ripping the other connector off of the gameboy camera's main board, I built a 9-pin cable so it could be attached to a connector on the breadboard.

There is a very simple circuit and software for programming these Atmel controllers from a PC parallel port (see the links page).  I built cables for this and installed the circuit on the breadboard.  It works!

I put a LED on the board and learned enough of the Atmel assembly language to make it blink.  Up until the very end when I needed all of the controller's pins for other functions, the blinking LED was my debugging tool.

A guy named Andy Clark has a great site where he describes how he accomplished this task.  Although my program and circuit are in some ways different from his, it is heavily based on his work and I thank him for putting that stuff on the web; my job would have been a lot harder without it.

Next, I added the RS232 chip and software so I can communicate with the AVR from my PC.

After that, I added the SRAM chip into the circuit and tested it to make sure that it worked.

Then, I got the camera control signals working.  I could tell by the timing of the READ coming back from the camera after the START pulse that it was doing something, though I wasn't fetching data yet.

I worked the A/D converter into the circuit, testing it with a potentiometer and seeing which values get sent back.

Finally, I coded the image fetching loop and hooked the AVR up to the camera.  This particular version only stores a 32x32 image because the 4434 ran out of pins.  If I decide to continue with this circuit instead of transferring the functionality to the MPC555 main brain, I will switch over to the 8515 flavor of the AVR, which has two more pins that I can use.  Here is one of the first pictures I fetched (pointing the camera at myself).  It is tiny because of the current 32x32 plan:

There are still a few things to do whether or not I continue with the AVR path: the timing is not very optimized; I think I should be able to play with the register settings to get the exposure time lower, and I know I should be able to increase the speed of fetching the image from the camera.  Right now, it takes about 0.1 seconds for these tasks... I have to cut that in half to make my goal.  I also need to play with putting capacitors and so forth in the circuit to try to improve the noise characteristics of the images.  I'm not sure I know how to do this but I imagine I can figure it out.

Because I don't know whether I'll continue developing this circuit in its current form, I suppose that there isn't any harm in putting my code up on the slim chance that it will be useful to somebody (but note that this is NOT a plug and play solution!).  Here is the AVR assembly program in its current state, and here is the code for the program that runs on the pc (which is complete except for some timer functions that I have buried in a support file I use sometimes).

The circuit is very similar to Andy Clark's except I use different pins for things and I address the memory directly (slowly) because the 4434 doesn't seem to support the fancy memory tricks of the 8515 and also I didn't want to use a latch since I was content to downsample the image and use fewer address lines.

Whew!  A lot of typing this week!