View Single Post
Old 03-20-2017, 07:04 PM   #3065 (permalink)
Master EcoModder
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,261

ChargE - '92 Mazda MX6 LX
90 day: 33.89 mpg (US)

WinterTransport - '07 hyundai Sante Fe SE
Thanks: 691
Thanked 450 Times in 361 Posts
Originally Posted by freebeard View Post
Can you describe how CANbus deals with collisions by making messages dominant and recessive? I know EVTV did.
My info on CANbus came in large part from EVTV. If you want more details, it would make sense to go there directly. Wikipedia is good as well, but they get fairly technical early in the description. Here is a summary:

The CANbus message arbitration is handled in hardware, based on the address of the device. Lower is more important. The device transmitting monitors the bus and verifies that what they 'sent' is what is on the bus. Since the address is first, and active low is 0, 0 trumps 1. So the lowest address wins - ie 000 0000 0001, or decimal 1 as 11 bits of binary. If a device sends a 1 and reads back a 0, it stops sending and waits for the message to end before retrying.

Any device can transmit 'whenever it wants' if the bus is not busy. 'Not busy' is defined as no active bits (low or 0), plus wait until the end of a message in progress - End of Frame (7 high bits) followed by 3 more high bits (recessive). After that you can try to transmit as long as you monitor the bus and make sure someone with a lower address is not transmitting at the same time.

There are only 8 bytes of payload or data in CANbus, the simple version. So any one device does not have to wait for long to transmit.

This collision stuff is .. handled in hardware .. and as long as you are not looking at the data with a data scope ... it doesn't really affect your programming at all. The physical layer takes care of it.
In THEORY there is no difference between Theory and Practice
  Reply With Quote
The Following User Says Thank You to thingstodo For This Useful Post:
MPaulHolmes (03-20-2017)