Our design turned out to be very robust, yet very simple to understand. The scheme we used to
control the menu selections was very structured, making it easy to add features and transition
between different menu screens. By storing and manipulating a few global state variables, we
were easily able to implement the different features of the device. Timing was not an issue with
this project since none of the features were very time sensitive. The only feature that needed to
be time accurate was the clock, which was controlled by timer1. Thus, the clock was accurate
for our purposes.
Although our database consisted of a small set of cities and interstates, there is a large potential
for usability of our project in a commercial setting. The database is easily expandable, subject
to memory limitations, and the functionality is easily extendable.
We first tested our device in Manual mode and all of the features worked as expected. We did
not notice any bugs or glitches in our implementation. In order to test our device in NMEA mode,
we needed a GPS receiver capable of outputting NMEA sentences through an RS232 connection.
In place of a GPS receiver, we obtained a GPS simulator software that outputted configurable
NMEA sentences through the COM port of a PC. As a result, we were able to connect the PC
to our device and test our features under a variety of circumstances, such as constantly changing
position. Again, our device worked as expected and we are convinced that our device is compatible
with any commercially available GPS receiver capable of producing output to the above specification.
One issue we encountered while developing our device was memory limitations. The memory
available for implementing our device was limited, due to the large amount of information stored
in the database. We made an initial guess as to how many cities we could afford to represent in
our map and it turned out to be very close to the maximum number of cities we could store, given
the set of features we wanted to implement. There was a point at which we ran out of RAM due to
the information we needed to store. To rectify this, we reorganized our memory usage so that we could
utilize available flash memory. Flash memory turned out to be an issue also as we implemented more
and more features. Since the instructions are stored in flash and we had a lot of conditions to handle,
we had to eliminate some of the features we originally intended so our program could fit on the chip.
Click here to see pictures demonstrating our project