Just a quick update

Finally got picbasic delivered early last week, but to update it to the latest version (which I need) required forum membership and proof of purchase etc. Anyway 2 days later I was promoted to a licensed user and got everything set-up.

Ive also gone crazy on ebay and bought a few protoboards, press & peel PCB etch kit and various parts. I was also naughty and told the supplier the PIC I bought from them wasnt working so they sent me another free of charge. So ive loads of spare bits to make a few units/correct a few mistakes.

To test that the circuit is working properly I needed to knock up a test setup on the bench. Rather that using two PIC's talking to each other I thought I might as well get the PIC talking to the ELM327 interface I have, so I now the recieving part is working fine.

In the picture below you can see the green/blue twisted wires - this is the CAN bus. The CAN spec insists that both ends of the bus are terminated with 120ohm resistors to make it work correctly (its a differential bus), you might be able to make these out on the pictures. The other twisted cables you see are just to provide power to the ELM327.

Then ensure sure both the speeds are the same at both nodes (I used 125k as the ELM is already pre-configured for it (protocol B)).

And it all works fine. Powering the circuit with the PicKit2, the PIC sends out out a message over CAN and it is recieved and displayed on the ELM327 by using the ATMA command.

Ive also been building up a protoboard rather than the breadboard/whatever board, image attached.

Dan

Another update.

Done quite a bit on it over the past week. Ive found out that my programming skills have slowly all but dissapeared. I had a bit of brushing up to do to get to where I am, and more to do before the thing is anywhere finished.

My test setup seems to be working okay, but the problem is the ELM goes a bit cuckoo every now and then and saying can error etc. A power down for five mins seems to do the trick.

I have coded in the serial port part. The chip basically outputs what it is doing to a serial port. The PIC has its own hardware serial port, but I have chosen not to use it as it would require more hardware to connect to a computer (MAX232 ~£2.50ea). So ive opted to use a software based one, which means although it uses more memory, it doesnt need the above extra hardware.

Ive started to code in the buttons to the software, ive written it so far for two, but at the minute there is only one as thats all I have.Ive also coded in the status LED's (4) which will mean the board can be used without an LCD or computer.

At the moment the program only writes the prompt to the serial port at 9600bps (see the pic below).

At each OK bit the program prompts for the button to be pressed before continuing. At the last prompt CAN is initialised and the data passed to the buffer and sent.

Quite how reliably I have yet to discover. Its sending the message to the ELM fine, but then repeating the message again and the CAN. At the moment the message wouldnt do anything when connected to the stilo as the message would be sent at the wrong speed (125k rather than 50k as in the Stilo)

The most diffcult part so far is translating what the people who wrote the ELM CAN commands into the same real world speak as the CAN spec for the PIC. To change the speed at which the CAN transciever operates, you have to work it out from various timings and delays - which at the moment is way above my head - Im hoping for some assistance

Onto the ID's. On an elm a CAN ID as people often refer to it, is actually both the NodeID and MessageID tied together, to calculate it for the CAN library for the PIC you have to convert the number into binary and split the number into two, covert to decimal and you end up with the node and message ID seperately... I think.

The stilo uses 11bit CAN so here goes

eg. 7B0 h = 11110110000 (11bits)

split that in two, the first part (NodeID) = 10000 = 10 h
the second part (MessageID) = 111101 = 3D h

Took me 3 hours to solve that, ive never used windows calc so much. I still have a lot of reading to do, but I will be doing the car testing later this week. If it works (Ill be suprised tbh), well its a hack but its a start.

The hardware is finally getting to the complete stage so I can have a look at doing a PCB and making this thing small. The code I have running so far uses just 4% of the memory.

You can see on the screenshot in hyperterminal, that is a CAN message, and the errors are there too. Also the debug output on the palmtop.

Bear in mind, the above is by no means correct. This is just the way I have interpreted things so far, I will probably rubbish these early posts as I get further.

Thats all for now.

Dan

Just a quick update. Not a lot to add but the first prototype is taking shape..

You will have to forgive the crap quality..

Uses a standard DB9 connector as used on most budget diagnostic tools.. Ive more to do on the software but will update on that soon.

Dan

Originally Posted by crosshairs

Nice one mate, not crappy at all, simple is best remember mate. Just so long as it works eh!

cheers rob, I meant the picture quality

Dan