CAN bus does not need a host computer, they say

Thread Starter

StrongPenguin

Joined Jun 9, 2018
210
From Wikipedia: "A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each others' applications without a host computer"

What is an (in the realm of microcontrollers) example of a bus, or protocol, which requires a host computer?

When my shiny new Curiosity HPC finally decides to arrive, I thought about making a crude automotive control system on a breadboard, with maybe two or three functions (Was thinking wipers[different speed settings], windows[on/off] and some engine function[using ADC, clogging a sensor with a potmeter]). The idea is to use CAN bus principals for this project, and learn a bit more about digital communication.

I'm still struggling to see the difference between a bus, and a protocol. Like RS-485 is mentioned as a protocol in Wikipedia, but it requires a specific set (CTS-, RTS-, TxD+, TxD-) of wires for it to work. Does it then make sense to say, that if I would use RS-485 for my project, I had a RS-485 bus?

In the CAN model, does it mean that the receiver does not necessarily need a MCU (but an address identifier), while if I were to choose I2C, all devices would require a MCU to be able to receive?

Sorry for the very messy post, but it pretty much reflects with my thoughts, when I read/think about communication :confused:
 

atferrari

Joined Jan 6, 2004
3,649
All what I did was based on reading about the CAN bus protocol in the official publication and the PIC 18F4585 IIRC datasheet.

They suggest that whatever you implement you test it against a working network. Myself, I set up three nodes which communicated to each other, flawlessly.

For some reason the transceivers were not from Microchip.
 

Papabravo

Joined Feb 24, 2006
12,774
From Wikipedia: "A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each others' applications without a host computer"

What is an (in the realm of microcontrollers) example of a bus, or protocol, which requires a host computer?

When my shiny new Curiosity HPC finally decides to arrive, I thought about making a crude automotive control system on a breadboard, with maybe two or three functions (Was thinking wipers[different speed settings], windows[on/off] and some engine function[using ADC, clogging a sensor with a potmeter]). The idea is to use CAN bus principals for this project, and learn a bit more about digital communication.

I'm still struggling to see the difference between a bus, and a protocol. Like RS-485 is mentioned as a protocol in Wikipedia, but it requires a specific set (CTS-, RTS-, TxD+, TxD-) of wires for it to work. Does it then make sense to say, that if I would use RS-485 for my project, I had a RS-485 bus?

In the CAN model, does it mean that the receiver does not necessarily need a MCU (but an address identifier), while if I were to choose I2C, all devices would require a MCU to be able to receive?

Sorry for the very messy post, but it pretty much reflects with my thoughts, when I read/think about communication :confused:
It just means that you can construct a peer-to-peer network with producers and consumers. No need for any kind of master device that directs or controls the network traffic.
 
The bus is the physical wires of the system. The protocol describes how the data is arranged on the bus.

A can network would be kind of like a circle of people taking turns saying a sentence and everyone listens. Whoever needs to react to the given sentence at the moment does what they need to do.

I2C would be more like having a person in the center who talks to everyone individually, relays relevant information from the rest of the circle, and always starts the conversation. Nobody in the circle can communicate with each other.
 

Thread Starter

StrongPenguin

Joined Jun 9, 2018
210
Ok, so an example of CAN in action is when your wipers are at low, and it suddenly starts to rain heavy, and the wipers speed up automatically, because they receive info from the rain sensor?

Why is CAN preferred over I2C in the automotive industry? Is it because of the clock, and sensors not being able to talk to each other?

Also, I read somewhere, that CAN is only for smaller (physically?) networks, but a 100m ship my company recently built is running CAN on some things. Don't have the whole specifics, but I know the valves in the bilge water system were hooked up with CAN.
 

atferrari

Joined Jan 6, 2004
3,649
@atferrari I just ordered a few different PIC's, going to see if I can program them as transceivers. And if I can't, I have a few PIC's to play with.

@geekoftheweek Great explanation, clear :)
If I get time I will try to retrieve my archives with the software for you.

First of all to identify what PICs were those.

18F family for sure. Maybe ending in "60" ? Vaguely recall the datasheet poorly explained some obscure registers.

Will revert.
 

Thread Starter

StrongPenguin

Joined Jun 9, 2018
210
@atferrari PIC16F18875, PIC16F1939, PIC18F24K40, PIC16F1719

They all fit in the Curiosity HPC. I really didn't think it would matter, as it seems like a pretty simple task for a MCU. I just picked them at random. For me, all MCU's are powerful :D
 

bwilliams60

Joined Nov 18, 2012
1,248
CAN is widely used in the automotive/trucking industry because it can be used as a high speed network and does not require a master controller for decision making. Because of CAN, we can reduce the amount of sensors and wiring used in our vehicles. It also gives us much better control over self diagnostics as components can be fitted with Microprocessors that can communicate faults quickly over the CAN bus. Protocols are basically rules which govern software and hardware used in the syste. For example, trucking used J1939 currently as the protocol of choice. It operates much fasterand smoother than the older J1708/1587.
I have seen CAN used on everything from washing machines to industrial lines so it must work well.
 

John P

Joined Oct 14, 2008
1,785
None of the common buses really "needs" a computer--they can all work with 8-bit processors like PIC or AVR chips. But I2C isn't in a class with the others, because it's designed for very short-range operation, within a few feet, but a lot of small processors are designed with I2C built-in, which makes it the cheapest system to use. CAN bus is very robust in operation, and doesn't require much in the way of overall control. I2C definitely requires a "master", and most people set up RS-485 with a master too, though it can work without. RS-485 can't match CAN bus's ability to allow any unit to start communicating at a random time, but to achieve that, CAN has a certain amount of complexity where units have to listen to the bus and decide whether it's clear or not, and also deal with the situation where two units start to communicate at exactly the same time. Plus CAN bus is proprietary, whereas RS-485 is all public domain. That's my understanding of how the various systems work.
 

atferrari

Joined Jan 6, 2004
3,649
@StrongPenguin

Found it (except the schematic). It was with the 18F4585 which is fitted with an ECAN peripheral.

It is all in Assembly.

Please say if you are interested. I do not intend to waste your time nor mine either.
 

Thread Starter

StrongPenguin

Joined Jun 9, 2018
210
Thanks for the great replies, all. So the (or one of the..) smart thing with CAN is that the master does not have to ping all the devices for info, and the devices them selves can talk to each other, while the master is busy doing important stuff? Like I said above, the rain sensor triggering the wipers to go faster.

@atferrari Thanks for the offer, but anything written in Assembly would be like reading gibberish for me. I will read about the ECAN peripheral, though, looks interesting.
 
Top