-
Hi all. I am contemplating a personal project involving CAN bus. Something that will listen to existing communication between modules on my car, grab a couple of pieces of pertinent data, and do something according to the values. However, aside from playing around with a cheap Bluetooth ELM327 clone dongle and Torque Pro on my phone to query OBD data, I haven't ever done much with CAN bus at a lower level. I have been doing some research, which is making my head spin, and I have some questions that I hope some of you can answer.
I gather there are two major components needed: a controller and a transceiver. There are some MCUs that feature an integrated controller. Is it better to go for one of those, or a separate controller? Also, are isolated transceivers only necessary when your device is not powered by a source common to the other devices on the bus?
I have most experience with AVR, so have been looking at the AT90CAN and ATmegaXXM1 range. I get the impression the former is quite an old design, but the latter has a bunch of stuff I don't need like a PSC, current source, DAC, etc. Am also considering the STM8A, as I have been meaning to get into STM8, but for some reason they only come in packages with a massive number of IOs that I won't need. There's also the STM32F042 that looks appealing (and cheap), but getting into Cortex M0 seems intimidatingly complex to me. For standalone controllers, it seems the MCP2515 is essentially the only game in town, which must be why everyone and their dog is using it. Is it better than integrated controllers from Atmel or ST? No such dearth of transceivers, though. The NXP TJA1057 looks good to me and is cheap, but again, for some reason everyone seems to use the MCP2551...
If I want only to silently tap into existing communications on the bus (I will never be transmitting any data), I gather I need to do so with a controller that supports 'listen-only' mode, right? I also see transceivers commonly feature a 'silent' mode where the transmitter is disabled; is this necessary too or just a fail-safe? On a related note, if I wanted to put my device into a standby/sleep mode (woken up only by user input, not bus activity), would it be a good idea to power-down the transceiver? Or do I need one that specifically has a 'sleep' mode?
What kind of clock source will I need for an MCU with integrated controller? They all say that an external crystal is recommended, but does this apply even if I'm only listening on the bus? Or, if I were to use an MCP2515, can one crystal run that and the MCU? That is, by hooking the crystal to the MCP2515, then take its CLKOUT and run the MCU off that? Or vice-versa?
Regarding the general procedure for receiving messages, it seems to me that a common overall principle shared by many controllers is thus:
1. Set some kind of filter or mask on the intended message ID in the controller - the controller will then only act on matching messages appearing on the bus.
2. A receive interrupt can be configured to occur whenever such a message is received, so that I may act upon it.
3. The controller will store such messages in a buffer, from where my code can retrieve the data.
What happens if you don't read the message data from the buffer before another is received? I guess it would just be overwritten? Or will it block new reception? Also, all the controllers I've looked at have a varying number of message buffers, but I'm not sure how they're used. Is it so you can have some kind of FIFO of received messages? Or so that you can receive and store messages with multiple widely different IDs at the same time?
Finally, my vehicle has the CAN bus self-terminated within the two modules at either end of the bus (the PCM and instrument cluster), so any potential device I add will effectively be in the middle of the bus. Is this what's called a 'stub' or 'spur'? I previously understood that such stub connections didn't need any kind of termination, but I saw reference in a datasheet of a transceiver (I forget which one) that some kilohms of termination may be required on stub nodes. I don't understand why that would be.
Sorry for the barrage of questions.
But I hope you all can throw some light on some of these matters for me.
-
Here is an application note that might be useful -
http://www.cypress.com/documentation/application-notes/an52701-psoc-3-and-psoc-5lp-getting-started-controller-area-network
http://www.cypress.com/file/96411/download
https://www.electronicsweekly.com/news/can-bus-design-kit-has-arduino-headers-2016-04/
There is a discussion of clock requirements in the application note.
Regards, Dana.
-
This might help: http://canable.io/
-
There is a discussion of clock requirements in the application note.
I wondered when Mr. PSoC would turn up.
Which app note? You linked to two different ones. Either way, this business of Time Quanta and Sample Points is confusing me even more. I guess I'll just take it as a given that I need an external crystal for an MCU with integrated CAN controller.
The second app note at least answers my question about controller buffers. I understand now that they work like a mailbox, where you will dedicate a single box to receiving a certain message ID (or small range perhaps). So basically, a controller with more mailbox slots/buffers/objects (or whatever terminology is used) is capable of dealing with a wider range of message IDs at once?This might help: http://canable.io/
Thanks, but I want to build my own circuit with CAN integration, not buy one. Although I suppose being based on the open-source CANtact board, it at least serves as somewhat of a reference for an STM32F042 implementation. -
Anybody else can offer any advice? Please?
-
from what i know NXP TJA parts were the "standard", now the 2551... actually the 2561 is "standard", the 2551 has gone NRND.
don't know the reason, i use the 2561, works well, no issues.
one thing for sure is that the 2551/2561 is guaranteed to be working with low speed fault tolerant lanes (IE: the second canbus line in fiat/abarth/alfa romeo and such which runs at 50kbps)
for sure other transceiver are able to do it but i never found the information explicitly written in the datasheet.
regarding going lower level i suggest you download busmaster and get yourself a canbus analyzer that is supported (there is a 3rd party plugin to use the elm327 but we use a kvaser interface so i haven't tested it...)
another thing, different manufacturers use different pinouts and/or have different kinds of traffic in the obd port.
all cars FIAT group for example have both the lanes available, the high speed that go under the hood and the slow speed that talks between body/dashboard/steering wheel/radio and such
BMW same thing but just one higher speed lane for everything
Renault/Mercedes group is something simillar to fiat in this aspect
Audi/VW however have only the obd available to the obd port: you can only talk with the obd protocol, the data goes to a gateway that redirects the obd requests to the ECUs you want to talk to, so no "lower level stuff"
Citroen/opel/ford.. haven't poked into those yet
for MCU.. your MCU of choice, i can't really recommend one... only avoid THE CANBUS IN OLD DSPICS, thing is bugged as cow shit in the mountain valley. Canbus in newer PIC18,dsPIC and PIC32 is fine, they use a peripheral made by kvaser (which only do canbus tools)
i used canbus in dspic, pic18, pic32, nxp, atmel. they were all fine for what i have to do.
Oh and be careful about ST, apparently you can't use both CANbus and USB at the same time on certain F1 parts
regarding termination, the obd tool or anything attached to the OBD port is NEVER terminated, or so say the relevant iso standard... i don't remember the number but you can find all the pdf documents on google
the "stub termination" may be what is referred in the standard as AC termination (suggested for OBD scan tools) -
Probably the cheapest, simplest starter would be to use an Arduino with a CAN bus shield. As most AVR processors don't have a native CAN controller, these CAN shields tend to use the Microchip external CAN bus controller (MPC2551 iirc) and they exchange data over the SPI interface. All of the libraries to enable CAN TX and RX are all already available and work, although as is usual with Arduino they tend to be not so well optmised. However, that doesn't really matter for starting out.
"Listen only" is a specific mode on a CAN controller because the CAN 2.0B Standard requires all nodes that have heard a message on the bus to reply with a "i got that" bit, which effectively terminates the message on the bus. If the node that has transmitted onto the bus does not hear any other node add the extra bit, it knows it's not been heard and can act appropriately (the standard sets up the course of action the controller should carry out in this case)
If you select "listen only" then your controller will NOT add that extra bit, even when it has heard a message on the bus, so in effect, the other nodes on that bus have no idea it is even there. For a normal operating bus, that would already have more than one node, then there will already be an end of message recipt bit put on there by the other nodes, so really that listen only setting doesn't achieve much.
Plenty of projects already have been done with such a set up:
ie https://learn.sparkfun.com/tutorials/can-bus-shield-hookup-guide
Be warned though, transmitting additional messages, or causing the bus to crash could have un-expected results, especially if you are driving the vehicle in a public place at the time. An extreme example would be to accidentally transmit the "fire airbag" command! (airbag EOL and diagnostic commands are well secured, requiring complex checksums and validation codes before they will fire, but it is technically possible (if not actually statistically that likely) to randomly hit the firing message codes and get a nasty surprise! -
regarding going lower level i suggest you download busmaster and get yourself a canbus analyzer that is supported (there is a 3rd party plugin to use the elm327 but we use a kvaser interface so i haven't tested it...)
Oh, cool. Looks useful. Thanks for the tip.another thing, different manufacturers use different pinouts and/or have different kinds of traffic in the obd port.
...
you can only talk with the obd protocol, the data goes to a gateway that redirects the obd requests to the ECUs you want to talk to, so no "lower level stuff"
My car only has a single CAN bus, so pretty simple.
The OBD port is directly on that bus, so I should be able to talk to everything. Not that I am planning on occupying the OBD port, but permanent connection instead - but it will effectively be on the same spur as the OBD connector.Oh and be careful about ST, apparently you can't use both CANbus and USB at the same time on certain F1 parts
Yes, I think I read somewhere the same regarding the STM32F042 too. Wouldn't be a problem, as what I have in mind has no need for any USB functionality.regarding termination, the obd tool or anything attached to the OBD port is NEVER terminated, or so say the relevant iso standard... i don't remember the number but you can find all the pdf documents on google
the "stub termination" may be what is referred in the standard as AC termination (suggested for OBD scan tools)
Good to know, thanks.
If you select "listen only" then your controller will NOT add that extra bit, even when it has heard a message on the bus, so in effect, the other nodes on that bus have no idea it is even there. For a normal operating bus, that would already have more than one node, then there will already be an end of message recipt bit put on there by the other nodes, so really that listen only setting doesn't achieve much.
This is exactly what I want to do. Transparently listen in on certain message IDs being sent from one existing module to another. I don't want to interfere on the bus in any way.Be warned though, transmitting additional messages, or causing the bus to crash could have un-expected results, especially if you are driving the vehicle in a public place at the time. An extreme example would be to accidentally transmit the "fire airbag" command! (airbag EOL and diagnostic commands are well secured, requiring complex checksums and validation codes before they will fire, but it is technically possible (if not actually statistically that likely) to randomly hit the firing message codes and get a nasty surprise!
Do some vehicles really have the capability to fire the airbags via commands transmitted over CAN bus?!
Unless you are just making a contrived example...
But anyway, the airbag control module is not on the CAN bus in my vehicle, so no danger of that happening.
According to the wiring diagrams, it is on a separate single-wire bus, together with the stability control module. I think it is probably a ISO9141 K-Line bus. I have no plans whatsoever of tinkering with that.
-
There is nothing keeping you from emptying the controller FIFO buffers into a much larger circular buffer in RAM whenever you get some kind of interrupt. Your application talks to the larger buffer, not the internal FIFOs.
It may even be possible to do this as a DMA operation.
-
Of course you can fire the airbag through canbus. Hell, when i was reverse engineering the canbus network in an abarth, one of the messages i sent had the right bits set to tell the body to tell the engine a mid-serious accident happened
not strong enpugh to fire the airbags and tell tell the engine the car was kaput for good, but strong enough to cut the fuel pump it took a while before i understood the procedure to get out of this safety mode
-
ISO 15765-4 has some hardware requirements for your tool
-
I would highly recommend MBED (for any project), they have very decent CAN support for a wide range of targets that have native CAN support:
https://os.mbed.com/users/WiredHome/notebook/can---getting-started/
https://os.mbed.com/docs/latest/reference/can.html
You would still need a tranceiver which you can breadboard up easily, or get a shield. -
Just a quick revisit to my own thread with another query regarding CAN transceivers:
I note that many CAN transceivers on the market are often specified as conforming to ISO 11898-2, but then others are specified as ISO 11898-5 (and sometimes both). According to Wikipedia, 11898-5 is an extension of 11898-2, "dealing with new functionality for systems requiring low-power consumption features while there is no active bus communication".
What is the practical difference between a transceiver that implements -2 versus one that implements -5? Which would be a more appropriate choice for an automotive environment, given my intended usage case as detailed in previous posts above?
Might it be simply that -5 transceivers implement a standby mode? Because that appears to me to be one noticeable thing when looking at datasheets. If I don't need this, will a transceiver conforming only to -2 suffice?