Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

The CAN Protocal is amazing!

Status
Not open for further replies.

dknguyen

Well-Known Member
Most Helpful Member
One of the first serial connections I looked at when I started was the CAN BUs. At the time I couldn't understand what the protocal standards meant. BUt I just went back to reading them again now and it's amazing how it works! How identical messages are transmitted until a higher priority identifier takes over. ANd if something is requested at the same time that something is sent, then the whole identifier stream is the same from both requester and requestee until the RTR bit which then lets the data transmission continue "ride over top" of the request transmission effectivelly cancelling the data request since the data is already on it's way.

And then there's the ACK bit that gets sent with the transmitter's bitstream, but is in reality a placeholder that allows the receivers to send back a true/false in the opposite direction, effectively allowing receivers to "manipulate" that bit in the middle of the transmitter bistream to indicate whether the message was received correctly. And if the transmitter sees this bit is not the right value, or if after the transmission is complete the receivers realize the CRC (which is inherent and automatically done!) doesn't check out and send an error frame message repeatedly, it causes the transmitter to repeat! But a limit's put on the error message a faulty receiver can't lock up the bus with error messages! Brilliant!

Then there's the bit stuffing that lets the entire asynchronous message keep itself in sync during long bitstreams. But, also, probably more importantly the violation of the bit stuffing rule IS the error message which destroys traffic on the bus and causes the the other nodes to also send their own error frame, which results in a repeat of the original transmission. Cool.
 
Last edited:
CAN is one of the protocols I have intended to look into but never got around to. Do you have a link to a good explanation of it? The multi transmitters until a contention appears and the ACK bit seem very similar to the I²C bus but you lost me on the bit stuffing stuff.

Mike.
 
CAN does not use a CRC32. The CRC for a CAN frame with either the 11-bit or the 29-bit identifier is 15 bits.
 
CAN is one of the protocols I have intended to look into but never got around to. Do you have a link to a good explanation of it? The multi transmitters until a contention appears and the ACK bit seem very similar to the I²C bus but you lost me on the bit stuffing stuff.

Mike.

Kvaser - an introduction to the CAN bus protocol
CAN bus (Controller Area Network), an overview

Bit stuffing is just something where if a particular message has 5 of the same logic state in a row, the logic will insert a dummy bit of the opposite polarity. That's all this bit is, it carries no information and is not treated as part of the normal message bitstream. This means the message bit length is variable and can be a slightly longer than what is specified in the message. The transmit logic adds it automatically and the receive logic automatically filters it out. If it does detect 6 of the same logic state in a row, then treats it as an error. Coincidentally, that is the exact same thing as the error frame is- 6 consecutive dominant states which destroys signal traffic and causes all nodes to signal an error and repeat the transmission.

I think the bit stuffing was actually added to make it so there was some kind of error message that could be sent that would override anything else happening at the time. It just also happened to allow for extra re-synching opportunities during constant bitstreams, additional chances to check for errors and and reduce DC bias levels.
 
Last edited:
It is pretty cool stuff alright. Our original DeviceNet media tester is approaching it's 20th birthday.
 
Last edited:
I don't understand why the error delimiter exists or is 8 bits long? It seems to me that one bit is enough. My understanding is that after detecting an error, an error flag of 6 bits is sent, and (and if there was no error flag overlap between nodes) that causes other nodes to send an additional 6 error flag bits right afterwards producing 12 consecutive error bits at most.

After each node is finished sending it's respective error flag, it waits and searches for a recessive bit. It searches for 7 bits after the end of it's error flag in order to accomodate the error flags being sent by responding nodes. So in any case, the 7th bit should be recessive. THis recessive bit is the beginning of the delimiter. But after the nodes detect the beginning of the delimiter (indicating all error flags from all nodes have been completed), they all send out an additional 7 recessive delimiter bits simultaneously. What's the point of this?
 
Last edited:
There are two kinds of error flags. Error Active and Error Passive. On an error active node one bit is enough to bust the transmission, but each node responds to the error flag by generating it own error flag, either active or passive. It akes a while on a long cable system for all the nodes to detect the problem generate their error flag and allow the bus to return to the recessive state. Also there is the three bit minimum interframe space to account for. After some amount of bus idle time another node will try to transmit.

As the error counter in a node crosses the boundry at 128 "error counts" it goes Error Passive and its error frame is 6 consecutive recessive bits which only causes a problem for the network if it is the transmitting node. As the node crosses the boundry at 255 error counts it goes "Bus Off"

In error counting each Tx error increments by 8, each receive error increments by 1, and each good packet Tx or RX decrements by 1.

It is complicated but quite ingenious as it prevents a malfunctioning node from "jabbering" and bringing the network down. A good way to generate lots of error frames is to have a network where one node is operating at a different baudrate with different bit timing parameters.

The other thing you have to guard against is having two nodes transmit the same identifier. It is best to consider the identifer space as a pool with each node restricted to a subset of the total space. It is perfectly permissible to borrow another nodes identifiers by mutual agrrement and negotiation however. Look for these features of the higher level protocols like CAN Kingdom and CANOpen and DeviceNet.
 
Last edited:
BOth active and passive error flags are followed by an 8-bit error delimiter though...why? The interframe space still follows the error delimiter so it's not like it is required as a deadtime between transmissions.
 
Last edited:
This is just a guess, but if the state machine running the CAN controller needs a certain number of recessive bits to return to an idle state then that may drive the requirement. It is the case that there is a 3-bit interframe space at the end of each data frame.

The Philips website used to have a boatload of application notes that explained the intricacies of bit timing parameters and other CAN minutia. I unfortuneately don't have ready access to my library anymore.
 
Last edited:
In FIRST robotics, we used to use motor controllers that would have individual PWM connectors that would have to be routed to the controller. This year we now use Motor controllers that have a CAN bus connection, and we can just daisychain them together. Next year we will be using CAN if they allow it.
 
CAN is cool, but I've not had a chance to implement it, and for the automotive products I've done, LIN has been a better choice, because it's much simpler and my data requirements are not that great. Also the uC I'm using now has hardware LIN built in, but I've bitbanged the LIN protocol before.

Maybe I'll setup a test CAN setup here to check it out, but I really don't have any decent project ideas that can use it right now. What have you guys used it for? Let me steal your ideas.
 
I'm going to use it on a helicopter/plane so the controller controls the motor drivers.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top