Automotive project

This summer I will be doing a frame-up restoration of my 1990 Jeep Wrangler. At that time I want to embark on a project that I've been thinking about for over 10 years, but only now have the capability to undertake.

My goal is to modernize the electronics - basically to make the vehicle smarter in various aspects. Take lighting for example. The vehicle of course has headlights, but it also has driving lights, fog lights, off road lights (on the lightbar), 25W reverse lights, as well as emergency lighting (for rescue squad). I'm currently using a switch panel I designed a decade ago, which allows me to operate each light manually, as well as put it in an "on-road" legal mode (for example, fog lights come on only with the low beams, driving lights operate only with hi-beams, rear lighting only in reverse, etc). If I were to control the whole deal with a microcontroller, then I could change the mode of the entire lighting system with a single button (on-road, off-road, emergency response, fog/rain/snow, etc). It could also be intelligent, for example to turn off any lights after 30 minutes if the key is not in the ignition, to save the battery.

I also will be replacing the current indicator light panel (indicates turn signals, 4x4, hi-beams, etc) with a dot-matrix display. I want to capture all gauge data (speed, RPMs, water temp, oil pressure, etc) and display it digitally, as well as provide warnings when any values are out of range.

My plan is to use a couple PICs to do the various A/D conversions, because there will be so many data lines (most just hi/lo), then feed the data to a master PIC via I2C.

My main question at this time, while I'm daydreaming about it months in advance, is would a high-end PIC be the appropriate master controller for this project. What concerns me most is the LCD panel. I wish to use a non-character based dot-matrix LCD panel. 240x64 would best fit the aspect ratio of the current indicator panel, but I could also enlarge it and go with 320x240. Full RGB would be nice in some ways, but is not a requirement (I'm concerned about visibility of RGB in all lighting conditions. Also RGB displays have a smaller range of operating temperature than monochrome - most are rated only above 0 C). Of course I would be using icons to represent various things, like turn signal indicators, hi-beam, etc. I also need the capability to display custom fonts - I would use a very large font (ie nearly the height of the display) for speed. I also want the ability to display virtual analog-style gauges, as well as possibly graph values over time.

ROM for the images and fonts would be the biggest obstacle, especially if I were to go RGB (which I seem to be leaning away from the more I think about it).

Finally, I would like to implement my own cruise control, where I could explicity set the target speed (which would be indicated on the display).

Would a PIC be up to the task, particularly in respect to the display? Anyone have any suggestions or recommendations? Has anyone implemented something like this before (if only in part - ie Cruise Control)? Any feedback would be appreciated.

Dan East

This is very similar to one of my projects for my track car. My plan was to have two remote modules. One would control systems in the front: lights, fogs, fan overides, turn signals, horn, fuel pump2, ... One would control rear items, fuel pump1, brake lights, turns, reverse, ...

I made up the front module, but the project stalled, cuz the car project stalled. You can see the front module here:
**broken link removed**
Actually it's completed now, I'd have to take new pictures of the completed module.

The top has the relays for high load items, low load items like horn and turn signals would be switched with TIP120's. You can see the microcontroller (not a PIC) and a MCP201 LIN driver, which is a simple 1 wire data connection made for automotive use.

Well, the remote works perfectly, but I never put together the main controller which would communicate with the remotes, and communicate with the dash display, which was a seperate module. For the dash display I was looking into aircore gauges, but never managed to get them working properly using passives...

**broken link removed**

Nice. Are you driving those relays directly from the pic, because I don't see any transistors. I have several standard automotive relays mounted in a box, but I will need to switch to something the pics can drive directly.

I want to make the system as modular as possible for a few reasons. First and foremost is safety. If a pic will have the ability to turn off the headlights, even if the manual switch is in the on position, then I want that portion of the system to be fail-safe. So a pic dedicated for only that purpose - controlling the headlight - would minimize the code that pic will run. Thus I can really go through it with a fine-tooth comb to make sure it is bug free.

The other reason is expandability. So for example I would have a pic whose purpose is purely A/D. It would sample the speed, then send that data out over i2c for the consumption of whatever other devices need it. So the pic driving the LCD panel could then display the speed. If I try to implement cruise control then that pic would also use the speed data.

Another decision I need to make is whether or not to go with i2c, or my own proprietary communication protocol. I'm really not familiar with i2c, so I can't make an informed decision. Instead of using explicit device to device communication (ie device A sends data specifically for device B), or master / slave, I would go with a purely command based paradigm. So if pic A wanted to turn the headlights on, it would just send out a command "turn headlights on", which would be handled by whatever pic does that job. Thus pics don't even have to be aware of one another, or know which is responsible for what. Whichever pic handled the message could send out an acknowledgement, so pic A would know the message was received. Otherwise it would resend the command. Other devices would only broadcast packets, like devices dedicated to A/D. One thing I'm not quite sure of is switch / button states. I guess that data would have to be transmitted continuously as well.

So the main thing I would have to work out is preventing collisions, and what (if any) supporting components would be required to reduce noise and allow communication over wire several feet long.

Dan Eas

Yes, the relays are activated with transistors, they are in TO-92 packages on the board. You can see 2 of them in the pictures. There is also flyback diodes to take care of reverse current. I don't know of any mechanical relay that you would want to drive directly with a uC, certainly not the standard Bosch 30amp relays.

So, I'm getting from this that you want an individual uC to control each load, lights, horn, ... Why would you even want uC's for this, then? What advantage would it give you over traditional direct connect? uC's are pretty robust devices, there's a reason your ECU isn't divided up into 5 different modules. Also, everything we are talking about here is very basic programming wise. Seperating everything out that much should overcomplicate and make things more prone to failure, not less.

I2C is a nice inter uC communication bus. It's meant for short distance communication, usually between components on the same PCB. It is not meant for long distance communication, so if you have to communicate more than a few centimetres, you would just use direct serial, or you can use LIN, which is what I'm using for longer distance communication between the car modules. If you google search LIN, you should find some information on it. It's a 1 wire automotive hardware and software protocol (though you can ignore the software protocol unless you plan on communicating with an OEM LIN device. The MCP201 for Microchip is a nice little hardware level shifter for it, and is pretty cheap from digikey. LIN is faiily slow though, so don't plan on sending critical datalog info on it or anything. For faster communications, you can use a CAN bus, but it's complicated and not so easy/cheap to work with. The single white wire on the board I have pictured is the single LIN communications wire. All commands to turn on/off each load comes through that wire, and any error reporting goes back through it.

I'm not certain what you are going to use the AtoD for. Speed, rpm... are all calculated using tachometer pulses. Maybe if you want to check the pressure / temp sensors?

Button status can simply be registered with an on and off command set. If you want to be extra careful that the remote module has received the on or off commend, just make sure it sends back an appropriate acknowledgements for each command sent. You will want some kind of error status LED visible on the main control unit to show wether any modules are not responding to commands.

DirtyLude said:

So, I'm getting from this that you want an individual uC to control each load, lights, horn, ... Why would you even want uC's for this, then?

Click to expand...

I would only use dedicated pics for fail-safe reasons, like the headlights. If I have a single PIC doing everything, including a bunch of complex but unimportant crap, like drawing analog controls for the LCD, then a bug anywhere in that code could potentially turn off the headlights (while I'm driving on the interstate at night). So the functionality of turning off the headlights, even when the manual headlight switch is on, because they have been left on for more than 30 minutes while the key is not in the ignition, will be handled by a single dedicated PIC. Now other devices can ask for the headlights to be turned on, but nothing else can turn them off but the code embedded in that one controller. I would use the same thing (dedicated controller) if I decide to make the ignition controllable by the system as well. Everything else will be packed into as few pics as possible.

If you google search LIN, you should find some information on it. It's a 1 wire automotive hardware and software protocol (though you can ignore the software protocol unless you plan on communicating with an OEM LIN device. The MCP201 for Microchip is a nice little hardware level shifter for it, and is pretty cheap from digikey.

Click to expand...

I'll take a look at it. I assumed i2c was just a serial protocol. I'll probably just go with serial via UART.

I'm not certain what you are going to use the AtoD for. Speed, rpm... are all calculated using tachometer pulses. Maybe if you want to check the pressure / temp sensors?

Click to expand...

Speed (which I'm pretty sure is 100% mechanical on that vehicle), voltage, oil pressure, temp, fuel level, external temp, ambient lighting to automatically adjust interior lighting, I might play around with automatic headlight dimming and even automatic windshield wipers too (many years ago I saw a sensor that can detect moisture on the outside of the windshield through the glass).

Thanks for your advice - this thread is really helping me to head in the right direction before I even get started.

Dan East