L'Hexapod: First steps in embedded programming; first build the hardware...

Previously published

This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.

This week I managed to scrape together some time to play with some of the non prototype bits and pieces that I purchased for this project. First off was breadboarding a MAX232 chip so that I could talk via my PCs serial port to my ATtiny2313 microcontroller. The MAX232 does the required level shifting and talks RS232 signals on one side and TTL signals on the other. The result is that it makes it possible to connect a microcontroller’s internal UART to a PC. I jumped into this particular sub-project early last week and didn’t bother with breadboarding the circuit because it was so simple; I soldered up a nice little bit of strip board with the MAX232 socketed on it and some little TX and RX LED indicators. Unfortunately I made several “schoolboy errors” and the board didn’t work. Due to lack of tools, frustration and impatience I eventually managed to break a couple of legs off of the MAX232 chip as I wrestled with repeated removal and re-insertion of the chip whilst debugging the board with a multi-meter…. Grrrr!

The errors were:

  • Not reading the MAX232 spec sheet correctly and putting the wrong capacitors in because I was following a tutorial that used a slightly different chip which needed different caps (I don’t think this was fatal as the smaller caps would simply have reduced the max baud rate of the chip that I had).
  • Not connecting the ground from the RS232 cable correctly - this caused all manner of weird behaviour that was probably the main cause of my problems.
  • Attempting to be clever and add the TX and RX LEDs in the ‘obvious’ way. Unfortunately I didn’t realise that the TTL level serial lines were held high when inactive and so my RX LED was permanently lit. I’d put the TX LED in back to front (Doh!) and so that never lit. Both LEDs were wired in to expect to source current from the MAX232 and sink it to ground. All in all, completely wrong :(

I only had a single MAX232 so breaking a leg was pretty fatal, though I did manage to debug further and breadboard a new circuit using a bit of wire conveniently pressed into the place where the leg had sheered off from…

Once I got some new chips (and a chip leg straightener, and insertion and removal tools, and a respect for how fragile they are, and some patience), I breadboarded the circuit again. This time with the proper caps, a correctly grounded RS232 cable and no LEDs to distract me. This worked fine. Unfortunately I’m out of stripboard so I can’t build the circuit in a more permanent manner. I also, eventually, worked out that the LEDs had to be the other way around and had to sink current to the MAX232, so they now work properly (this link has a schematic that clearly shows how the LEDs are set up, I’m pretty sure that several other schematics that I found either had the LEDs sourcing current from the TTL lines or I’m just an idiot who sees what he wants to see). To test this circuit I hooked it up to the servo controller (even though the controller has the option to run at TTL levels or RS232 levels; I used the TTL level connections and put my own level shifting circuit in between it and my PCs serial port).

Next on the list of things to do was to put together a programmer for the AVR chips I have. I purchased a serial PG1 cable and so just had to follow this tutorial and adjust for the fact that I have a different chip. This was more successful and pretty much straight after putting the circuit together I could download code to the chip. Unfortunately it wouldn’t run. It turned out that I had put the reset switch in incorrectly and it was holding the chip in a permanent reset state. Once that was fixed I had a blinking LED and a working C Compiler and development tool chain. Wooo! Now all I need to do is get the assembler working as well and I’m in business.