Matt Meerian's Car Run-Time Computer

Since the project only needs power when the ignition is on, the project is powered from the ignition wire of the car. The place where I hooked up the to the accessory wire is at the fuse panel between the drivers side door and the dashboard. (This will very from car to car.) There is a cigarette lighter receptacle on either side of where the project box is mounted, but the receptacles have +12V applied even when the accessory line is turned off. Some probing around with a multi meter inside of the fuse panel was used to find a fuse that would only have power when the accessories of the car was turned on. It took about an hour to find the right place to hookup the power inside of the fuse box and to get the power cable strung up under the dashboard, out of the way.

An automotive environment can be a project killer if the hardware is not thought out before hand. First, the 12V power coming from the car can very noisy. So, the power supply must have adequate filtering. Second, the heat in the summertime tends to warp or even melt some plastic enclosures. So, an aluminum enclosure was used. Third, a standard, intelligent, commercial LCD display (which would have been my first choice for a project like this) tends to blank out in mid-western United States summer time temperatures. Even a Palm or Windows based device could have this problem. Another good thing about the LED display is you don’t have to worry about backlighting for nighttime use.

Speed is not super important to the software. Therefore, a 4MHz oscillator was used. Since the oscillator is rather large and didn’t fit between the processor and the wall of the enclosure, the oscillator was mounted on its side.

Coding around:

(Software)
In the past, when I make a project, I have used the Atmel assembly language. But for this project, the AVRGCC compiler was used. For those of you who are not already using AVRGCC, I would highly suggest that you try it. The time spent for this code development was significantly cut because of using “C” instead of assembly. Sure, there were a few gotcha’s in learning C on this microcontroller. One that was particularly troublesome was how to put a string into exclusively into flash and not have it loaded into ram.

This puts a string into ram:
            unsigned char strDplFrm[] = ("ABCDEFGH");
This puts the same string into flash:
            u08 __attribute__ ((progmem)) strDplFrm[] = ("ABCDEFGH");

The maximum speed that the SPI clock on the display can handle data is at 5 MHz, but there is a 600nS delay that needs to be kept in order to load rows of data into the display. The rows of data from each digit load from the top down to the bottom of the digit. There are 25 pixels in each digit. So, with overhead, there are 66-display clock cycles needed load in one digit and 528 clock cycles needed to load in all eight digits.

One thing I see often and cannot stress enough to myself in writing code is the use of “good” comments. By saying good, I mean comments that tell what the goal of the particular line or segment is doing.

Good example:

my_itoa(uDay);   //get the ram byte for day and convert it to a string (BCD form)

What I consider bad comments are telling what the code line is doing. I tend to do this when I’m in hurry or feeling lazy. (which happens more than I would like it to)

Bad example:

            my_itoa(uDay);   //pass the variable “uDay” to the routine “my_itoa”

I’m a firm believer that just about every line of code deserves a comment.

There are two interrupts used on the ‘8515. The first, which takes the load line to the display high, happens when an SPI transmission to the display is complete. The second interrupt is the timer 0 overflow interrupt. The main function of this interrupt is to count down to the 20ms “tock,” which will be serviced in the main loop.

On power up, the software initializes the microcontrollers peripherals and then loads the relevant EEPROM data into ram. If the EEPROM first-time-power-up key has never been written, then the software writes default values to the EEPROM. Once that happens, the main loop starts and goes into infinite loop, which consists of: resetting the watch dog timer, seeing if 20mS “tock” has passed, and seeing if it is time to write to the display. Since most trips last less than an hour, the software writes to the EEPROM every minute. This is to keep track of the hours the vehicle operates, accurate to the nearest minute. The datasheet for the ‘8515 states the EEPROM can endure 100,000 writes, then the EEPROM area storing the minutes integer would be completely useless after (if my math is right)

100,000 / 1440 minutes per day = 69.4 days of operation. One way around this would be to increment an EEPROM pointer to the next available EEPROM integer when the start date is set. (The count is reset when the date is reset) Another limitation that we have is the number of minutes in operation is stored in an in integer. Therefore, the software can only be accurate for the first 32,768 minutes since the start date time has been set. This figures out to be 32,768 / 1440 minutes per day = 22.8 days of continuous operation. That’s a long time to be driving a car.

A way to keep from writing to EEPROM every minute is to power the microcontroller shortly after the car has been turned off. (A large value capacitor could power the microcontroller temporarily) The microcontroller would have to detect when external power is lost, write the number of minutes in operation to EEPROM and then shut down in orderly fashion.

AVRGCC seems to only support writing a byte and reading a byte to EEPROM. Since the program needs to read and write integers, several routines were written to break up an integer into two bytes, then store and retrieve them from EEPROM.

The software has nine states of operation:

state 0: display software version number
state 1: display the author’s last name
state 2: display the number of hours and minutes in operation
state 3: display the number of times the car has been started
state 4: display the start of operation date
state 5: display the hours and minutes since the current power up
state 10: allow the user to set the start month
state 11: allow the user to set the start day
state 12: allow the user to set the start year

States 6 to 9 were left for future use. Making software follow the state machine simplifies things and keeps it easy to make changes to the software. The software starts up in state 0, moves to state 1 after one second, and then cycles between states 2 and 5, changing states every second. If the menu button is pressed at anytime when cycling between states 2 and 5, the software will go to state 10 to allow changes to the start month. Pressing the menu button two more times takes the software to allow the setting of the start day and year. Once the year is set, the EEPROM values for the number of hours and minutes in operation and the number of times the car has been started will be erased. One more menu button press will take the software back to state two, where the software cycles between states 2 and 5.

Note that the day month and year are static. They are used as a reference point to see the start date of the number of times the engine has started and the total run time. Sometimes it takes several try’s to get the car started. Therefore, the number of times the car has started is written to six seconds after power up.

On the street:

(prototype)

Since the hardware is so simple and only one unit is needed, point to point soldering was used to make the prototype. For me, this kind of prototyping is quick, simple, inexpensive and best of all, it allows for easy modifications. Soldered wire wrap wire was used to make the connections on the bare perf board. The prototype was split up into two boards: a horizontal board that has the microcontroller and a vertical board, which has the push buttons and display. A right angle, 0.1 inch, male header was used to make a structural connection between the vertical perf board and horizontal perf board. Several pins of the male header were cut to make room for the pins on the display and the push buttons. The linear 5V regulator and supporting components were point to point soldered in next to the horizontal board, which ended up being rather ugly. The tab of the 5V regulator was attached to the aluminum enclosure for the best possible heat dissipation. The project draws on average 170mA, which is enough to keep the enclosure warm to the touch. The power is brought into the enclosure by a 2.5 mm, panel mount, barrel connector.

Since the project is powered from the accessory wire from the vehicle, is a power switch necessary? Probably not, but it is nice to have manual control over the project being off or on. If the software would go awry, the power switch would save the user from searching around behind the enclosure for the power connector.

The enclosure for the project is made of aluminum. Its dimensions are 1x2x4 inches (2.54 x 5.08 x 10.16 cm). Four screws attach the cover. One of the more difficult things to do was putting the holes into the enclosure at the proper places. When the vertical circuit board was finished and soldered to the horizontal board, calipers were used to accurately measure the locations of display and push buttons on the vertical circuit board. The measurements were then entered into AutoCAD light ’97. Appropriate cut out’s were placed on the drawing. Then, the drawing was printed off at a 1:1 scale and double-sided sticky tape was used to paste the template onto the enclosure. The template was then used as a guide for drilling and filing away at the cutouts. (A handheld nibbler tool could not be used on the display cutout because the aluminum on the side of the project box was too thick) Once the enclosure had the proper cutouts, I put the button labels in on the AutoCAD drawing and printed it out. Instead of using white paper as a background, a color such as hunter orange can be used to be more of an eye catcher. The printout then had double-sided sticky tape put on the back and clear laminate was put on the front. (The peel and stick laminate is the easiest to use) The double sided tape-paper-laminate sandwich then had its crosshatched cutouts removed and the edges trimmed with an exacto knife. See Figure 2. The double-sided tape had the final wax paper taken off the backside and the one-piece label was placed onto the aluminum enclosure. Viola! A cute front-end label for the buttons and a project name on the front of the enclosure. Using this one-piece label gives the project a much more professional look.

Mounting hardware:

One thing that hobbyist tends to need is an ability to mount a PC board a certain distance from the enclosure. The best way I’ve found to mount the PCB is to keep a health supply of nylon, unthreaded, inch long, standoffs. The nylon standoffs can be then cut to the proper length with a hacksaw and ground down to smooth ends with a file.

The project enclosure was mounted inside where the ashtray would normally sit. (The car was missing the ashtray when I got it.) So, when the ashtray drawer is closed, the project is hidden from view. There were already two holes in the bottom of the ashtray area for a bracket that holds electronic equipment.    The L brackets to mount the enclosure inside of the ashtray are made out of aluminum. The brackets started life as sheet metal aluminum. A hacksaw was used to cut the estimated shape. A vise was used to hold one end of the aluminum piece while they were hand bent into an L shape. A hand, hole punch was used to make the mounting holes. Lock washers were used to keep the screws from vibrating loose. One thing that was kept in mind while the project was being mounted was that the display has to be easily visible to driver of the car.

Testing:

Testing of the hardware and software is something that unfortunately doesn’t get much attention in my hobbyist projects. Ideally, a document covering lab and field tests would be created to test out the majority of features of the project. This could find the little problems that tend to only be found after months or even years of operation. By the time these problems are found, the expertise and hardware to make the changes have fallen by the wayside. One bug in a project I remember from the past would lockup the software if a certain push button was held down in the power up sequence. Fairly easy for the user to avoid, but it was a bug nonetheless.

(Conclusion:)

There are several things that could be added to project through software. The average time the car runs could be computed by looking at the run time stored in EEPROM and the number of times started. The mileage of the car could be stored at the same time as the start date is stored. Useful hardware would be adding a real time clock and perhaps an inside and outside temperature reading. An automatic dimmer for nighttime running would also be nice. At some point, you have to say to yourself “enough is enough!” ‘Cause you’ll never finish a project if you let the design creep along.

Since there are only eight digits, many messages have to be abbreviated. When a new person familiarizes himself or herself with the operation of the project, there is small learning curve involved. One possible way to get around this would be to have each message that is larger than 8 digits scroll through the display.

I think that my goal of creating a useful project has succeeded. The car computer prototype has been operation for 25 days now. During that time, the car has been started 49 times and has run a total of 8 hours. During that time, passengers have given favorable reviews. The prototype is functioning as expected with no encountered bugs or failures.