Serial Communication

I know I was supposed to talk about the power supply schematic, and I promise I will get to that. Right now I plan to talk about serial communications between two microcontrollers and the outside world. Since I decided to go with 2 microcontrollers for my new mini sumo board, I realized they needed to communicate. There were several choices that could be used. You have the USART, SPI, and I2C/TWI ports on the AVR. Each serial comm port has its uses and issues.

USART

USART stands for universal synchronous/asynchronous receiver/transmitter. The USART (or UART) was a serial communications port that used to come with your computer, though that has mostly been replaced with USB. The USART is some times called RS-232. Really RS-232 is an electrical specification that also specifies a connector. The USART was either an external chip or hardware built into the microcontroller. I could go through the entire history of the USART and RS-232, but I won’t. That is information you can look up on your own if you want it. These days you will use a USB to Serial port  converter or bridge IC. One end will plug into your computer, while the other will connect to your micro. This is the interface I’ll use for my board to talk to my PC. As I start working on the software development, I will revisit this interface.

SPI

SPI or the serial peripheral interface was designed to allow microcontrollers with limited numbers of pins to control external peripherals like I/O ports and serial EEPROM. Where the USART was normally used for computers to talk back and forth, the SPI bus was mainly used in a master and slave configuration. The microcontroller was the master and the peripheral was the slave. This allowed the designer a way to save pins on their microcontroller, which can be a limited resource. Since the microcontroller typically has all the required hardware, you can make the chip either a master or a slave depending on the needs of the design.

I2C/TWI

I2C/TWI is a serial communications interface originally designed by Philips (now NXP Semiconductor). I2C stands for Inter-Integrated Circuit bus. Where as the name I2C is copy written, TWI (two wire interface) is not, so many semiconductor companies use TWI to mean I2C because of licensing issues. None of that is really important here. Just remember that when I write I2C, I also mean TWI.

The I2C interface was designed from the beginning to be a multi-master bus. This meant several masters and slaves could share the simple two wire communications bus. This bus also has electrical specifications you need to be aware of. Most importantly is that the data and clock lines need pull up resistors. The value of these resistors is dependant on how strong of a pull up you need and capacitive loading on the signal lines.

OK, so…

XBee Pro Radio Module

Why am I going over all of this, so you can understand why I designed the circuits the way I did. I am planning to use the USART for communication back to a PC. Wireless communication could also be used. One of the most popular is the XBee radios. This would give you a way to send data back and forth between your computer and microcontroller without wires. The software overhead of communicating with the USART is minimal, around 100 bytes. Software is not the issue, just the fact I am using this interface to talk with a computer means I will have to use one of my other options. So how about using the SPI bus to talk between the micros? Again the amount of software over head is small. The issue is that the SPI port is also the in circuit programming interface. This complicates programming the devices individually, requiring some extra hardware. I will have to explore this a little more. That leaves the I2C port. The hardware requirements are not an issue, so this looks like a good idea. The only issue is the software, it requires a greater amount of code to handle the internal hardware. That could be an issue for flash limited devices.

So as I look at the problem in front of me, what I really need to do is write some code to test the 3 serial busses between a mega328 and a tiny24 micro. This way I can figure out which interface to use. This is also going to need some reading of the data sheet of the tiny24 as it has USI (universal serial interface) which is all 3 interfaces combined into one module in the micro. So much for things being easy.

So I am off to do some coding to test the serial busses. Then I can work on finishing the schematic and finally present the power supply and the rest of the electronics. Until then I hope this has been informative.

Brain Design

Microcontroller

An Atmel ATmega328 microcontroller

Last time I said I was going to use 2 microcontrollers – a mega328 and a tiny24. If I feel like I am going to run out of code space on the tiny24, I can quickly swap it out for tiny44 or 84. The surface mount vs. through hole debate has morphed into “why not both”. The schematic will be the same for both, just the PCB layout will be different.

Serial Port

Having a USB port would be nice, but it is not a main requirement. Neither is having an RS-232 level serial port. I can get by with a TTL level serial port. I have USB to serial port adapters that provide RS-232 and TTL voltage levels. I will think about these some more.

Driving Motors

Sparkfun Motor Shield

One of the big decisions to make is about a motor driver. The design of my first robot brain had headers to plug-in a motor driver daughter board. Sparkfun makes a motor shield for the Arduino that plugs in as a daughter board. The issue that comes up is how much prototyping space do I want. If I leave off the motor driver circuit, then I leave myself a larger area for prototyping. Then again I could include the motor driver and make a prototype expansion board. Pololu makes the 3pi robot and they offer an expansion board that mounts on top to give you a good-sized prototyping area. The 3pi has a cool look to it when the expansion board is mounted. It is a good idea to give yourself some area to experiment with. I like to add a few LEDs for debugging purposes or other circuitry for more functions.

A Pololu 3pi with expansion board mounted

So if I put the driver circuit on the main board, which motor driver should I use? I can use the old standby chips like the L293D/SN754410, the L298, a pair of LMD18200Ts, or a FAN8200 if I could find them. These are bipolar transistor parts that have a voltage drop and a bit of current draw while conducting. Looking into MOSFET drivers appeals to me for the lower voltage drop and less current wasted while driving motors. I could use something like a TC4427 or more exotic parts from Allegro and Freescale. They make motor driver chips with extra features. I just have to decide which components I want to use. Either way I have decided that like the Pololu 3pi robot, I will have a separate expansion board for prototyping. This way I can plug it in only when I need to and the robot’s main circuit board does not have to change.

So I still have a few more things to think about. Next time I will go through the pros and cons of having the motor driver circuit on the main controller board. I will also post a few more pictures and details on my current mini sumo robots. At some point talking about the software tools will come up. Schematics, PCB layout, and parts lists are going to be required at some point. Check back for the next exciting article, or at the very least better than average.

Related Articles

• New Brain Design (astram8179.wordpress.com)

New Brain Design

The Idea…

So all of that AVR overview was to get us here, the design of a new robot brain. I compete in Mini Sumo at different robotic competitions. What I like is that it involves mechanical, electrical, and software engineering. The competition is autonomous, so none of this radio control stuff. The robot has to compete on its own. It comes down to whether I made a good design, or do I need to go back to the drawing board (or in this case computer programs).

This is the first robot controller I designed

So let’s get into the design process. My original brain board used an Atmel ATmega48 microcontroller. The mega48 had more than enough program memory to handle mini sumo. Since I used the DIP (dual inline package) version, I ran out of I/O pins for a couple extra features I wanted. The original plan was to have 4 IR LEDs, on individual I/O pins, and 4 IR detectors. I changed the plan to use 1 output each for 2 LEDs. After a few more changes, I came up with the circuit board you see on the right. The board is blue because I liked the color of the Arduino, so I made mine the same. Though the boards are the same color, I did not design my board to be compatible with the Arduino or its programming tools. This time I think I will make the board compatible with Arduino. Not physically as I need it to fit the size requirements on mini sumo, but in function. I will use a mega328, which the Arduino boot loader can be programmed into the chip. Then the Arduino programming tools can be used.

Now that I picked a microcontroller (the mega328), I can work out some other details. Originally I used the 16 bit Timer 1 for creating the 38kHz frequency use for the IR LEDs. This left me with Timer 0 for driving the servos. After looking over the internet for code to drive servos, it became clear that everyone was using Timer 1. Now I had to write my code for driving the servos as I could not use anything from the internet. Where is this leading? Well this time around I will use Timer 1 for the servos. So what about the IR LEDs? Here is where I have a few choices. I could use a 74xx04 logic chip to create an adjustable oscillator centered around 38kHz, a 555 Timer chip – again to create a 38kHz frequency signal, or maybe another microcontroller. I really like the idea of adding another micro. In this case I am looking at using a ATtiny24. It will have enough I/O and timers to deal with IR object detection.

The Arduino Uno

What about USB? The Arduino only has a USB port for downloading the program into the micro. The board has a USB to serial port chip. Do I want to add this to my design? If I don’t, I would need an external USB to serial port converter to download programs using the boot loader. Should I put on a RS-232 transceiver chip (like a MAX3232E) to interface with a standard serial port?

Other Design Decisions

We have been dealing with some of the higher level design decisions. There are many smaller decisions to be made. Should I include a motor driver chip on the board? If so which one? The IR LEDs for the obstacle avoidance detectors need to be shielded from leaking IR light into the sensors. Is heat shrink ok, or should I use the plastic shrouds that Parallax (makers of the Basic Stamp) sells? How about having some prototyping area, or headers for plugging in a daughter board. These are just some of the decisions I have to make. The biggest decision I need to make now is to use surface mount components or go with through hole parts. This really depends on if I want to sell it as a kit. As a kit through hole components work better as more people could build it. If I go surface mount, then it might be left to me to install the parts and sell it as a partially completed product. Or what if I just designed both version, posted all the information here, and let you figure out which one you want to build, if any.

Well, that is all for now. Until next time here are a couple pictures of my Mini Sumo robots.

My very modified Parallax Sumobot

My brain board on Parallax Mini Sumo chassis