I'll get back and add more news, photos and maybe even some code shortly!

May 23, 2004

It's been a while since the last update, partially because of lack of motivation, but we've got some big accomplishments done. We now have an HD44780 16x2 LCD (with red LED backlight) and 5 buttons connected to the PIC. This took some doing as we want to save space on the PIC. The first thing was to add the buttons. We decided we wanted 5 interface buttons (basically 4 directional buttons and an "select" button). We also want the buttons to be interrupt driven so we're not polling them all the time. The PIC16F876 has four pins (RB4-RB7) that can generate interrupts when the value on the pins change. That still leaves us short a pin for five buttons directly connected. One solution is to OR all the buttons together with some diode logic and connect that to one of those pins and then read the five pins to find out which buttons was pressed. However a better way, which will save pins on the PIC, is to encode the 5 buttons into 3 lines using a priority encoder (we're using a TI SN74HC148). These three lines (and the GS encoder pin) are connected to RB4-RB7. Now when a button is pressed, it is encoded into a unique 3-bit code, which triggers the RB port-change-interrupt. We read pine RB4-RB7 and decode which button was pressed. The GS pin really doesn't need to be connected, but I figured why not use a nice even four pins on the PIC? The buttons we have at the moment are momentary tactile switches. The encoder inputs are tied high, so when a button is pushed, it will force the encoder pin low. Getting the buttons working wasn't as hard as the LCD...

The LCD was somewhat of a bastard to get working for a couple reasons, mainly that we were interfacing with it in 4-bit mode and finding accurate documentation on how to do this was nigh impossible. Normally, if you've got the pins to spare, you can connect to an LCD in normal 8-bit mode, where you have 8 data lines, a R/W line, RS (data/control) line and an enable line. That's 11 lines if you use them all. We wanted to fit the LCD interface onto the 6-pins of portA. So, first we cut the data lines in half and used a 4-bit interface mode and we also tied the R/W line to ground (always write, can never read from LCD, but we should never need to anyway). That gets us down to 6 lines. I managed to find a couple examples of people interfacing a PIC to an LCD in 4-bit mode. However, all of them had different LCD initialization routines. Also, no one ever used just portA in 4-bit mode like we are. Long story short, I eventually debugged the LCD initialization routines and presto the LCD is displaying characters. It took a little while longer to get a table read (for output) to work correctly. One very important thing to note about using just portA is that when RB4 is set to output, it is an open drain type, so it is necessary to connect RB4 to Vdd through a resistor so that it will work correctly.

We also got bit-banged rs-232 working, which is nice, since the current plan is to use the bit-banged rs-232 interface to communicate with the ELM323 chip and use the internal UART for communicating with the PC, so to query the ELM323 from teh PC, all commands will go thru the PIC. More on this later.

March 26, 2004

Added photos of the scantool circuit and OBDII cable I made to the design info page. Also figured out why we were having problems going from a 4MHz ceramic oscillator to a 20MHz one. The problem turned out to be the oscillator configuration was still set to XT, but for ceramic resonators >~8MHz, you have to set it to HS (high speed). That done, the rs232 echo circuit worked fine. The next step was to make the rs232 echo program interrupt driven. The 16F876/F73 have the ability to generate an interrupt when a byte is received by the UART (however this interrupt cannot wake the PIC from sleep mode when in asynchronous serial mode), so it took a few hours, but now we have an interrupt driven echo program where the main loop is nothing but NOPs and the receive buffer is read and placed in the transmit buffer all in the interrupt handler. Oh yeah, in case you didn't catch it, we've switched to using the 16F876 for the time being (which is almost identical to the 16F73, but has more memory)

March 21, 2004

Finished assembling the scantool circuit and tested it out. After replacing some 220k resistors with some 220 ones (whoopsie!), it worked great. Had it hooked up to my laptop (using the free software from scantool.net) and using the OBD to serial cable I made. Jerry and I had a taco supernova and built up another breadboard so we should be able to work in parallel as soon as Jerry gets a programmer for these bigger Pic chips.

March 15, 2004

Received all the parts to assemble a scantool OBDII interface circuit. This is the same circuit that www.scantool.net sells and also the same example circuit listed in the ELM323 datasheet. We decided to try to make our own OBDII interface cables since the cheapest ones we could find to buy were ~25/ea!!! We obtained some OBDII shells and terminals from Power and Signal Group and will need to assemble our own cables. Power and Signal was the only place I could find that sold these OBDII connector parts and they were a big hassle to order. Power and Signal does not generally deal with small orders like the one I made. The part numbers you need are 12110252 shell, 12047581 pins, 12110254 locking clip. Many of these have minimum orders (I had to order enough to make about 20 connectors) and they only ship C.O.D. unless you have an account. So, overall this will be more expexpensive than buying 1-2 prebuilt cables, but where's the fun in that? However, since we could build 20 cables, it will effectively be much cheaper this way (even though we'll only need a couple). And we'll have enough extra connectors to make 20 of these projects for friends and enemies! Next step is to assemble an OBDII interface cable to connect to the scantool circuit and test out the ELM323 chip and circuit. Scantool.net offers free software to use with this circuit, so that's what I plan to use to test it. It's been brought to my attention that Multiplex Engineering also sells OBDII cables and individual connectors, terminals and shells. While more expensive, per unit, than Power and Signal, they may be good if you just want a few connectors.

February 29, 2004

Divide and conquer! We decided to take the projects in steps. One of the first things to do was to get a simple RS-232 interface working with the PIC chip so that we could communicate with it, which should help with future debugging. We breadboard a simple RS-232 interface circuit and spend a while debugging it with little success. Part of the problem was that we were using an unknown ceramic resonator, so we didn't even know the frequency. Ordered up some new ceramic resonators and made a few other changes and a few days later rs-232 communication is working! Huzzah!

February X, 2004

Jerry and I get together and do some brainstorming on the design. We come up with a block circuit diagram to start from. It's basically an ELM323 OBDII interface chip, a PIC chip, some EEPROM, LCD display, some switches and an RS-232 interface. Now the fun starts! We start reading up on OBDIII, ELM323, PICs, etc and start ordering lots of components from Digi-key and Jameco. This also involved some pizza and vanilla cream soda pop.

January X, 2004

Project idea is created. The genesis for this project was somewhat derived from the recent speeding ticket I received where the officer stated he clocked me on radar at 10mph over what I know I was going. Unfortunately in Maine, "With respect to speeding ticket cases, Title 29-A Maine Revised Statutes Annotated Section 2075(4)(A) requires the Judge to find that the results of a measurement of your motor vehicle's speed by radar must be considered "prima facie" evidence that your motor vehicle was in fact proceeding at the speed measured by the radar." This means that the radar reading has to be taken at face value and really can't be argued. That got me wondering if there was a way to record my speed or my top speed myself so that I could have a counterargument. Too late to do anything about the violation, but perhaps I could design something for the future. Something that could record speed and diagnostic information directly from the onboard computer and display it.