The center convenience module is supposed to be an inexpensive, simple module
that is connected to the switches on the center console, namely the power window
and power mirror switches. The module is connected via a LIN subbus to the
left door control module, and the two modules communicate at 19200 baud with each
other. The door control module queries the center convenience module for switch
status, and can also send messages to the module e.g. to set lamp brightness
(the module also features a dimmable output for the
two/three ashtray/gear selector illumination lamps). These functions can
be used with the larger of the two connectors.
The second connector is meant for a system expansion. It features two extra inputs for seat heater switches, and two status outputs for LEDs or small lamps built into the seat heater switches. Finally, two auxiliary inputs for two extra switches can be used for future expansions.
Except for the auxiliary inputs, all inputs (2xwindow, 4xmirror, 2xseat heater)
are "tri-state" inputs, i.e. they know three states: open, grounded and
powered (12V). This way I only need 4 wires for both mirrors, one for each direction and
one for each side. The auxiliary inputs are simple switches to ground.
The illumination lamp output is well protected with an Infineon PROFET smart switch, and the CPU uses pulse width modulation to set the brightness from 0-100%. This method is far more efficient than the transistor GM uses for dimming, which burns the remaining power as heat. The status lamp/LED outputs switch to ground, and an optional resistor can be put on the board for LED use.
The CCM is based on the less powerful MC68HC908GT16, which is more than adequate for this job, and features a UART, which is nice to have for a LIN node and makes implementation much easier. Programming is done in C and assembly, because we have the HC12 C-compiler at work, and Motorola/Metrowerks gave away a 4K code limited version of the awesome HC08 C-Compiler for free. The catch here is that the debugger is limited to 1K object code, but if you write and test your software in modules, the package is still useful. The CCM software is around 2K of object code, so the GT8 would also have sufficed. I don't use the on-chip watchdog/voltage monitor, instead I am using an external MAX1232 watchdog/voltage monitor circuit. If this was meant for mass production, I probably wouldn't do that, but with external components, at least I can measure and see what's wrong if there's a problem.
A switching power supply was initially planned, but was dropped in favor of an ultra-low quiescent current, low dropout linear regulator for automotive use. You can still see the layout for the switching regulator on top though (the space is necessary for the two connectors anyway, so I used it for the optional switching regulator. One nice feature of the power supply is that the LIN subbus interface chip can (together with the CPU) power down the power supply and thus the entire circuit, and wake up and power up the circuit again if a telegram arrives.
I have (ab-)used an old K-line interface box I built years ago to communicate with the CCM, and it worked just fine. After all, LIN is K-line with better EMC. My small diagnostic program on the PC can simulate a LIN-Master and read all switches, as well as general status of the CCM (e.g. communication errors, ROM checksum, etc.). My tiny LIN driver also lets me read and modify memory, set the status outputs and dim the illumination lamp.
With the CCM in a working condition I could finally start programming the DCM.
Finally, one more noteworthy thing: I am glad how well I could solder the subminiature resistor arrays, again with just a steady hand, a regular soldering iron, and no microscope! Take a look at the picture below and try if you can find them in the bigger pictures...