Our present car controller runs on a single PIC16F870 micro and provides functions for remote door locks, headlight reminder, and car finder.  It is constructed using wire-wrap to allow for future expansion and is mounted using Velcro on the passenger side of the center console.

The downside of this design is that changes to the system require a lot of work for removal, rewiring, reprogramming, and reinstalling.  It could also be stolen which would be a major bummer - making something the first time is interesting, having to do it all over is not.

New Approach

The idea it to replace this with a set of microcontroller modules networked together.  Several of these modules have already been constructed on single-sided circuit boards (see how we do this).

Since each of these modules does a specific job, the system can be expanded and enhanced by creating new modules with (hopefully) little or no changes to existing ones.

Each is powered by 12 volts DC and has a network connection.

The entire system is orchestrated from the control Console Unit (velcrod to the top of the dash board).  The front panel has a 2 line by 8 character LCD display, momentary push button, and rotary encoder.

The rear panel has the 12 volt power connector, network RCA jack, daylight sensor (solar cell from old calculator), and 5-pin din connected to directly reprogram the internal PIC without opening the case.  Pulling the power and network connections, the unit can be hauled into the shop for easy reprogramming.  Or, using a laptop computer, can be reprogrammed while still mounted in the car.

Both the front and back panels of the project box have been replaced with Lexan. Unlike the older type of Plexiglass, you can just drill, cut, and generally mangle this material without it shattering.

Development and Debug -

From previous experience doing network style designs, it was decided to do all communications in ASCII.  This allows individual units to be debugged using a PC terminal program.  It also allows the entire system's network traffic to be monitored and logged. An interface device using a PIC12F675 was constructed to convert the RS-232 serial from the computer to the speed independent, open collector, network signals.

Network Communications

Hardware Level -

The network communication uses 5 volt logic-level signals of the 'open collector' variety. Each ASCII character is composed of 10 pulses: an attention pulse, a reference pulse, and 8 data pulses...

;-----    -  -   -   - -   - - - -   -----
;     ---- -- --- --- - --- - - - ---
;     attn rf  1   1  0  1  0 0 0  1

Attention: 4 time units  (gives other units some time to notice incoming data)
Reference: 2 time units  (sets the 'slice' point for zeros and ones)
Zero bits: 1 time unit  (any time less than the reference time is a ZERO)
One bits: 3 time units  (any time greater than the reference time is a ONE)

Since every ASCII data byte comes with its own timing reference, this eliminates the need for crystals on each module. The internal oscillators are more than accurate enough to communicate using this method.

Protocol Level -

All communications are initiated by the Console Unit. Each command begins with a '/' (forward slash) and ends with a CR (carriage return). This prevents any unit from confusing a command from the console with data comming back from one of the other units.

The second character is the Unit Type character; the third is the Unit Number. Characters that follow are individually defined by each type of Unit. Here are some examples:

/V2PABD<cr> (Voice Unit #2: play words A, B, and D).

/S1QI<cr> (Sensor Unit #1: Send port bit status)

/D2L<cr> (Door Unit #2: Lock door)

Every unit echos back a single line (possibly containing nothing) but always ending in a CR. This lets the Console Unit know that the unit is active and has recieved the command.

Here is what is working so far:

The console unit's functioning is currently rudimentary, I hope to get time to install and finalize this design in the next few weeks.