After our last unsuccessful try to communicate with the Vectra CANBUS, we decide to take a step backward and ensure that we were doing things the right way. In particular, we were interested in knowing if the CANBUS chip was connected right and if the logic of the program was correct.

To test this we got another breadboard and tried to replicate our current circuit so that we would eventually have two CANBUS connected PICs that could talk together, confirming we were doing things right.

So this was the breadboard at the actual state of the project:

And this one is the new breadboard with the essential part of the circuit cloned:

We went on and attached the programmer to the new breadboard but it did not work. The programmer simply could not find the PIC. We feared we had burned some chip due to incorrect power connections and proceeded checking differences with the original circuit. There weren't any.

To check whether we had really burnt the chip, we put it in the original breadboard and worked as expected. After putting it back in the new breadboard we could not figure what was wrong and spent really a lot of time trying to iron this out. In the end, we removed every chip and connection from the board and put them back in a different position paying extra attention to any connection. This time the chip worked and could be finally programmed and run.

We proceeded to connect the boards and wrote a different program on each chip, one that transmitted one message and the other that printed to the serial port the messages received (only the original breadboard has serial port chips). It didn't work. We tried to change the programs but it was already too late and we had to stop there.

Next time we hope to have the two boards communicate via CANBUS.

BZZZAAP!!!

Hi ALL!! After a long, long time we are back! Holidays, work and H1N1 (well... not really, only ordinary flu :-) ) have delayed our serious work, but yesterday we restarted it. As you can see...

some ruffled wires were connected to the EODB port. This is not really the first time that we interface our circuit to the car, but the last try was a failure. After some changes (both in code and wires) we do it again.

Results:

not many, really. We detect correctly the start of trasmission on the bus: when we turn on the ignition switch our circuit start receiving packets. Unfortunately the PIC module signals "overflow" status on CAN receiver, so we haven't received nothing meaningful. We hope we have guessed right the bus transmission speed, but we have to investigate further.

We did some exeriments on receiving packets (echoing on serial port, binking led...) to locate the problem, but the available time runs out quickly. But there will be the second round. :-)

Looking in the photos (sorry about the quality, the pictures are taken with a cellular phone in the dark, so noise is clearly visible) you can see the wires connecting EOBD in the hole above the shift lever and the circuit. The grey cable (a chunk of CAT5) on the right is connected to the serial port of laptop (not shown), you can see it a little better on the above photo. The dark box with leds turned on is PICkit2, the PIC programmer (also connected to laptop). We were doing real-time debugging of firmware :-)

That's all folks! We will be back as soon as possible, to continue this first part of the project. Stay tuned!

Playing a bit with SocketCan and its utilities

This time I had a better look at the SocketCan utilities that I mentioned in a previous post. As I have already told, you can get and install them with these commands:

svn checkout http://svn.berlios.de/svnroot/repos/socketcan/trunk canbus
cd canbus/can-utils/
make
make install

And you will end up with lots of new programs under /usr/local/bin:

asc2log canbusload candump cangen
canlogserver canplayer cansend cansniffer
isotpdump isotprecv isotpsend isotpsniffer
isotptun log2long slcand slcanpty vcan

To see how canbus works, I tried to setup a virtual can bus with these commands:

modprobe vcan can-raw
ip link add dev vcan-test type vcan
ifconfig vcan-test up

These basically creates a canbus named vcan-test and set the interface up.
Then I opened two terminals and ran the command candump on one terminal and the command cansend on the other terminal. These are the outputs:

# cansend vcan-test 5A1#11.2233.44556677.88
# cansend vcan-test 5A1#11.2233.44556677
# cansend vcan-test 1F334455#1122334455667788

# candump vcan-test
vcan-test 5A1 [8] 11 22 33 44 55 66 77 88
vcan-test 5A1 [7] 11 22 33 44 55 66 77
vcan-test 1F334455 [8] 11 22 33 44 55 66 77 88

That are the message id and the data. The number between the brackets is the data length and the last case is with an extended id.

This could also be the text format used by the slcan driver to communicate via serial port.

I have tried to use slcanpty to attach the vcan-test interface to a pseudo terminal but without success so far. I will have to try again soon as it could be the way to gather the data on the Linux machine without writing an additional custom layer.

Two interesting CANBUS projects and some links

This CANalyser tool is pretty similar to what we want to do at the moment and is built with very similar chips. The project seems a bit outdated but the information is still very useful.
The tool is composed by a PIC microcontroller PIC18F458, and a MCP2551 CAN transceiver. The main features are listen to the CAN bus in active or passive mode and forward data to the serial port to the PC and send data to the CANBUS. This is exactly what we need now.
Digging further in the web pages I discover that they have built a real-time kernel to run their software on the PIC. There is a company behind this (Pragmatec) but they have released the sources under a GPL license. The website of the os is at PICOS18
There is a new version of the pages here but the page about the CANalyser tool is the same.

Another very similar tool is CAN2PIC. This one uses PIC18F248 and MCP2551 CAN.
You can find there all the schematics of the circuit used and also all the software! So this page should provide all we need to get started and running very fast!

There are some other interesting links I found tonight:

• GNUPIC: a small directory site with information on PIC programming with GNU/Linux
• Another very good CANBUS learning page at CERN (yes they used it in LHC)
• PICMICRO WebRing: A collection of websites about the Microchip PIC microcontroller and related projects

Canbus programming under linux: SocketCAN

Well the good news is that someone already did the hard part for us!
The Linux kernel includes since several versions the support to the can protocol and provides what seems to be a very easy interface to it. It's called SocketCAN and it is modeled after the standard unix socket API.
The project page is at BerliOS and hosts the kernel patches (not needed anymore as it is included in mainstream) and some user space tools that I just downloaded and installed without a glitch. You can get them by accessing the project subversion repository with this command: svn checkout http://svn.berlios.de/svnroot/repos/socketcan/trunk canbus

More info on what is and how to use SocketCan can be found in the linux kernel documentation directory (available on the web here)

As for the device drivers, SocketCAN supports a few drivers alreay, two of which are particularly interesting: vcan and slcan. Vcan is a virtual CAN interface driver and is there for testing when there is no hardware available. This will be probably the first to try once I realize how the user space utilities work. The slcan driver is "For a bunch of CAN adaptors that are attached via a serial line ASCII protocol (for serial / USB adaptors)" and should match exactly what we are trying to do. I just wonder what is the data format the slcan drivers expects to receive from the serial port. I have only found a strange document here so far but the semantic is not clear to me and I will have to investigate this further.

Getting the tools part 2: a matter of levels

After choosing the main component of the project in a previous post, we also have to connect it :-)
On one side we have the CANbus connector, on the other (probably) a PC used to understand what informations are going up and down on the CAN. Unfortunately we can't connect PC directly to CANbus, due the lacking of a suitable peripheral on PC. So we choosed a PIC18F4682 to do the raw job. So is it all done?

NO

Connecting directly CAN, PIC and PC probably will result in a big roast, with nothing to eat :( . So we will use these two tiny chips, ready on the breadboard:

Their work is to convert voltage levels in a suitable way.



MAX232CPE from Maxim is a level converter for RS232 (serial) protocol. It converts +12/-12 signals from PC serial port to +5v accepted from PIC, and do the opposite job on the other direction. To do this it needs some condensers, not yet installed, to produce the necessary voltages, cause it's main voltage is only +5V.




MCP2551 from Microchip converts CANbus signals (what is the voltage on Vectra CAN bus? we still don't know...) to PIC level. We HOPE that this interface chip will do the job, cause the real implementation of CANbus on Vectra (voltage, speed, protocols, messages...) is still totally unknown. MCP main voltage is also +5V.



On the left side of the first photo you can see a bunch of components and wires. This will be our 5V power plant. LM7805 with 2 condensers will give power to all our chips and components we will use in this project. Now it is time to connect everything: stay tuned!

Can Bus specifications

The official (I think) CANBUS specification can be found at CIA, that stands for Can In Automation. There are both base and extended protocol. They seems to be very clear and intuitive and I think they will be very helpful as soon as we start coding some CAN sniffer or similar. I have to start thinking about how big the sniffed data will be and where to store that so that we can study it easily. Maybe the only choice for this is a database (for which I guess mysql would do pretty well).
We'll see soon. Coding time is approaching!