2
\$\begingroup\$

I'm a novice to CAN; however, I've hooked things up before via a CAN bus. From my point of view, it's all just fields of data. I'm trying to move away from my pure-C upbringing and embrace (however awkwardly) Microchip's Harmony framework for a project.

For a CAN interface, there exists a series of "channels". I've seen reference to CAN channels on Google, but they are never described. Can anyone point me to a reference for CAN "channels" or explain how they fit into the Extended Frame Format as I do not see any obvious channel bits.

\$\endgroup\$
6
  • \$\begingroup\$ Are you coming from a National Instruments (labview) background? \$\endgroup\$
    – jonk
    May 25, 2017 at 2:47
  • \$\begingroup\$ no, a pure C background. i read the NI documents and they were just as vague on what a channel is. i generally just interrupt on the correct mask, but these abstractions have their own language \$\endgroup\$
    – b degnan
    May 25, 2017 at 2:57
  • \$\begingroup\$ CAN is just a physical layer and "data link" layer (roughly speaking, covers about the same scope as RS-232, except that its physical layer allows for the detection of collisions and for priority negotiation during the transfer.) Channels, if they exist, must be forged at a higher level. At the transport layer? Which is outside of CAN's area, I think. (But I'm not an expert, either, so I'll quickly bow to those who are.) \$\endgroup\$
    – jonk
    May 25, 2017 at 3:37
  • 1
    \$\begingroup\$ I agree with the others. From what you write, this channels are something on top of CAN. May be, you configure a CAN address, and then have a read and write function to the device with that address? That could be called a channel. However: could you post a reference to something that mentiones that channels? \$\endgroup\$
    – sweber
    May 25, 2017 at 7:58
  • \$\begingroup\$ @sweber What you describe is apparently what it is. It seems to just be a notation issue. From here ni.com/white-paper/2732/en , it says: "CAN Signal – an individual piece of data contained within the CAN frame data field. You also can refer to CAN signals as channels. Because the data field can contain up to 8 bytes of data, a single CAN frame can contain 0 to 64 individual signals (for 64 channels, they would all be binary). " \$\endgroup\$
    – b degnan
    May 25, 2017 at 10:35

3 Answers 3

2
\$\begingroup\$

The basic CAN spec does not define Channels. Essentially, a CAN network is a facility for passing messages around a group of devices. A message can be transmitted by any device, and is available to every device. A message has two parts: its Identifier and some Data. That's CAN in a nutshell.

There are higher level protocols built on top of CAN (e.g. CANopen) that give meanings to messages: defining what kind of data they contain, and how and when these message get on the network. These protocols typically add features, such as node addresses, network masters, and block data transfers, that are not part of the basic CAN spec.

"Channel" is a somewhat equivocal term; its meaning depends on the context. Broadly, a channel is some kind of conduit for data. For example, incoming messages might be directed into channels that are used by different processes. This way a process wouldn't need to search through all received messages to look for ones that are relevant, it would only need to check for messages in its channel.

I'm not familiar with Microchip Harmony, but from the description of the CAN interface it looks like "channel" essentially means "buffer". It appears that received messages are sorted into channels (message buffers) based on which acceptance filter it passes through. So you can direct messages to different buffers based on the message identifier. Channels are used for transmit as well, as a mechanism for buffering and setting relative priority of outgoing messages. The channel is not part of the actual message, so it doesn't have any meaning at the network level.

\$\endgroup\$
2
\$\begingroup\$

The channel concept simply provides an abstraction layer into CAN messages. The channel name provides a bit index into, and the number of bits of a CAN message. The correlation is generally maintained in a data table in the abstraction layer.

\$\endgroup\$
1
\$\begingroup\$

I'm still getting up to speed on all this myself but it definitely appears that channels are higher level objects that organize and contextualize signal data.

One place you find this terminology in use is in the context of the serialization of CAN bus data. It's sort of a post-processing organization of the CAN signals on a bus collected into an mdf4 file from some data logging application that was able to monitor the CAN bus. See these bits over here to find the word show up.

The possibly most important elements in an MDF file, apart from the data blocks, are the channels (CN blocks). Each channel describes a recorded signal and how its values are encoded in the records for the channel’s parent CG block.

Each channel has a name, typically the name of the recorded signal. It is also possible to specify “alternative” names, for instance a shorter “display name”. https://www.asam.net/standards/detail/mdf/wiki#c480

An example of an mdf4 reader library can lend additional context


In another context channels help initialize objects in libraries to make various constructs able to transmit and receive on a live bus. The Channel is a key component for organizing and setting up state in the software to accomplish this task. See examples such as these for additional context

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.