Isn't the CAN protocol some form of low-level RPC?

[VinzC]

Hi guys.

I've been diving into the CAN protocol for my professional projects and I start to wonder if all the implementations I've seen could follow some form of Remote Procedure Call paradigm. CAN has two distinct forms of messages (frames):

• messages that correspond to node data broadcast,
• messages that request specific data from any node able to provide them.

The former is a one-way communication. The latter is two-way and even includes the number of bytes the requesting node expects as the DLC field, which is exactly some form of RPC (Request-Response); the message ID could be mapped to a function name and the DLC field as the number of expected byte arguments. That's low level RPC of course but from what I've understood so far CAN implementations could as well be generalized into a low level RPC library, what do you think?

I see one big difference, at least: RPC usually involves 2 specific peers in a client-server communication by using IP sockets, for instance, while CAN frames are broadcast, which means RPC calls would be asynchronous. But the microcontroller has all it takes to buffer messages, which is one problem solved at the hardware level. In my opinion this kind of programming would be best implemented as a state machine as the latter can also work around delayed loops easily (an example here which I based my state machine code on).

Anyway do you know or are there CAN libraries implemented as [low-level] RPC around?

[nctnico]

I have not used CAN as an RPC protocol (although it seems very usefull for it and it solves many problems in the hardware) but I have used other protocols for that purpose. However, the biggest problem with distributed systems is how to recover from a transmission failure (a message doesn't arrive for some reason or a node stops responding) and what the higher level software should do about it.

[max_torque]

Controller Area Network doesn't have a mandated higher level protocol.

 The Hardware and Transport layers are mandated (eg for "normal" CAN, it is a differential two wire bus and the message packet is between 1 and 8 bytes long).

However lots of higher level protocols exist, such as CANopen or Can Calibration Protocol (CCP) for example, that build on the basic architecture to create information/data transfer layers.

[VinzC]

I have not used CAN as an RPC protocol (although it seems very usefull for it and it solves many problems in the hardware) but I have used other protocols for that purpose. However, the biggest problem with distributed systems is how to recover from a transmission failure (a message doesn't arrive for some reason or a node stops responding) and what the higher level software should do about it.

I've discovered that Atmel micros do a lot of processing in the hardware — for instance when a 2.0. message is not acknowledged it is resent until it is. And I believe (still have to read the data sheet again though) the flags available from a CAN interrupt do tell a lot about what error occurred so it's only a matter of "a few" lines to code... if I may say so.

Controller Area Network doesn't have a mandated higher level protocol.

Not sure what you mean with that though...

However lots of higher level protocols exist, such as CANopen or Can Calibration Protocol (CCP) for example, that build on the basic architecture to create information/data transfer layers.

I've roughly checked CANopen and it indeed provides the application layer. I haven't checked whether they use RPC-style programming though. That said the language they use would hint they do. I'll dig further.

[Jeroen3]

You can get modbus, canking, canopen, j1939, use any.
CAN (ISO 11898) just provides layer 1 and 2. (physical and data link)

[VinzC]

You can get modbus, canking, canopen, j1939, use any.
CAN (ISO 11898) just provides layer 1 and 2. (physical and data link)

From what I found modbus is implemented on serial and Ethernet lines. It looks like it's a layer 1-2 protocol as well. I might be wrong but it doesn't seem to support CAN for the lower layer. As for canking search results with that name are about CAN monitoring tools (e.g. Kvaser, Amplicon or Micromax) . J1939 seems to rely upon extended (29-bit) identifiers only as far as CAN is concerned. Though not a big deal my implementation uses 11-bit IDs.

[Jeroen3]

J1939 actually uses the identifier field more fancy.
modbus is hackable for CAN, it's not very common. More often found on rs-485. But I have never actually seen a modbus it's usually just point-to-point or for parameters only.

[magetoo]

To me it's always looked a lot like the memory bus in a computer.

Address => CAN id
Write access => a regular frame with data
Read access => remote frame
DMA => node-to-node communication that doesn't involve the master

From that perspective, CAN just lets you "extend the address/data buses" and hook up more dumb I/O further away than a plug-in card would.