A wasted week – Hapsim to the rescue! 02/16/2009Posted by aliasmrjones in The Build.
In our previous post, we talked about some of the hardware and software we are going to use to construct our gps driven autonomous r/c car. In this post, we’ll talk about actually getting some things wired up. Somehow we wasted an entire week getting the LCD and serial input working. A couple of dumb problems cause all the trouble and in once case a very useful program helped solve the problem. In the other case, it was part of the problem.
Milestone 1 was to get the LCD working with the microcontroller. The Atmega32 has 1 serial port and we’ll be using this to bring in the data from the gps so we need some way to output information while we’re testing. The 2X16 character LCD will allow us to display everything from simply, “The microcontroller is starting up,” to lat/long to debug info if things aren’t working like we expected. There is a lot of great info about interfacing LCD displays to AVR microcontrollers. One page with all the info you’d need is here.
My first thought was to immediately start soldering connections to our final board starting with the LCD connections. Boy am I glad I didn’t!
Instead, I thought I would put the Atmega32 into the STK-500 prototyping board and quickly wire up the LCD and see if I could get messages to display. 90% of character LCDs are based on the Hitachi HD44780A driver and they all work basically the same. They have an 8 bit and a 4 bit mode. 4 bit mode takes about twice as long to transfer data, but it requires fewer connections. I decided to try and save a few solder connections and use 4 bit mode. I connected the 4 data lines, E, RS, RW, power and ground wires and got…a bunch of black squares. Ruh roh.
I double-checked all the connections and everything was correct. After doing some searching I found a program that works with AVRStudio and simulates buttons, LEDs, serial ports and LCDs connected to pins on the simulated AVR in AVRSTudio. The program is called Hapsim and you can find it here. One small problem I had at first is it complained about not being able to connect to AVRStudio. You have to run the AVR simulator by starting your program in the debugger before you start Hapsim. Hapsim has hooks into the AVR simulator and it isn’t happy unless it finds the AVRStudio simulator running.
Trying my little LCD test program with the Atmega32 simulator in AVRStudio and an LCD hooked up in 4 bit mode in Hapsim gave similar results to what I saw with the real devices. Nothing was being displayed on the simulated LCD. I decided to take things one step further and displayed the output of the pins on the simulated Atmega32 in AVRStudio. You can do this by first clicking the green arrow on the toolbar to start debug mode, then choosing View-Toolbars-I/O from the menu. It will show each bit of each port as a box that is either filled in or empty to show 1 or 0.
Stepping through the program and AVRLib LCD library showed the problem – for some reason the bits that signal the LCD is ready for writing were being set wrong and the library was going into an infinite loop waiting for access to the LCD. I made a few changes trying to fix the problem, but they only worked temporarily before the problem occurred again.
I decided to try 8 bit mode and see if it would work. It would mean soldering 4 more connections, but if it worked it would be worth it. It is also faster than 4 bit mode. After quickly making a few adjustments in Hapsim and changing the configuration in LCDConf.h in the library, I tried the simple test program again. Success! So 8 bit mode it is.
The next step was to get gps data from the gps device. The gps device outputs standard nmea data at 4800 bps, 81N. I connected the serial cable to my computer and started up hyperterminal with the correct parameters and saw data flowing down my screen. There are a number of nmea sentences, all of which start with “$”, then some letters to identify which sentence, then a comma-delimited set of data. I’m interested in the ones that show latitude/longitude, heading and speed.
Hapsim has the ability to connect a real serial port on your computer to the serial port of the simulated Atmega32 in AVRStudio. I set it up and created a simple program in the AVR that simply output whatever came in the serial port to the LCD. After turning on the gps the LCD displayed…garbage. I tried turning things off and on several times and sometimes the LCD would display what looked like the beginning of an nmea sentence, but after a few characters displayed garbage again.
I spent several days trying different settings, re-testing direct connection to the serial port on the computer, changing the clock speed of the simulated Atmega32 and single-stepping through the library. I finally thought maybe the simulator just wasn’t fast enough to keep up with the constant stream of data from the gps and decided to load the program into the real Atmega32 and see if the the real microcontroller would get good data instead of garbage.
The STK-500 board has an RS-232 converter built in which makes it easy to use the UART on AVRs for debugging. In this case, I hooked up the serial cable from the gps to the serial port and connected the LCD to the correct pins of the AVR using breadboard wires.
I put the gps device against the window and fired up the STK-500 with Atmega32 programmed to read the serial port and send whatever it saw to the LCD. In a couple of seconds, I was seeing nmea data flying across the LCD. Everything was working like a charm.
Next I hacked up some code to continuously loop, reading the serial port into a buffer using an interrupt driven function, parsing lat/long/heading/speed from the gps nmea data stream each time through the loop and displaying the latitude and longitude on the LCD so I could see if the library was correctly parsing out the data I need. After programming the microcontroller and turning things on I saw this:
I wasted a solid week on getting the LCD and serial gps input working. The moral of the story: When using AVRLib with an LCD, don’t use 4 bit mode – always use 8 bit mode, and the AVRStudio simulator is probably too slow to handle long streams of data.
But, we now have the LCD displaying debug information and we have the Atmega32 reading the gps data from the serial port and correctly parsing latitude and longitude. This is a big step. The next step is to be able to calculate bearing and distance to a waypoint — what direction and how far away where we want to go is. In our next post we’ll show the math involved in calculating these things, some problems we encountered and a little more about how to control printing to the LCD using AVRLib.