Isn't the CAN protocol some form of low-level RPC? - Page 1
Forum section: electronics / projects

author: VinzC
author_rank: Frequent Contributor
timestamp: August 27, 2016, 08:12:41 am
content: 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 ofexpectedbyte 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 beasynchronous. 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 astate machineas the latter can also work around delayed loops easily (an exampleherewhich I based my state machine code on).Anyway do you know or are there CAN libraries implemented as [low-level] RPC around?

author: nctnico
author_rank: Super Contributor
timestamp: August 27, 2016, 09:56:17 am
content: 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.

author: max_torque
author_rank: Super Contributor
timestamp: August 27, 2016, 10:54:40 am
content: 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.

author: VinzC
author_rank: Frequent Contributor
timestamp: August 29, 2016, 11:52:29 am
content: Quote from: nctnico on August 27, 2016, 09:56:17 amI'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.Quote from: max_torque on August 27, 2016, 10:54:40 amNot sure what you mean with that though...Quote from: max_torque on August 27, 2016, 10:54:40 amI'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.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 29, 2016, 11:59:58 am
content: You can get modbus, canking, canopen, j1939, use any.CAN (ISO 11898) just provides layer 1 and 2. (physical and data link)

author: VinzC
author_rank: Frequent Contributor
timestamp: August 29, 2016, 04:12:46 pm
content: Quote from: Jeroen3 on August 29, 2016, 11:59:58 amFrom 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,AmpliconorMicromax). 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 29, 2016, 05:05:35 pm
content: 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 modbusit's usually just point-to-point or for parameters only.

author: magetoo
author_rank: Frequent Contributor
timestamp: August 30, 2016, 12:14:36 pm
content: To me it's always looked a lot like the memory bus in a computer.Address => CAN idWrite access => a regular frame with dataRead access => remote frameDMA => node-to-node communication that doesn't involve the masterFrom 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.