CAN message packing signals

# 14 Aug 2013

Hello!

I am trying implement CAN with mbed as one of the nodes. The mbed node is required to send out predefined set of messages containing measured analog signals and strings. Every messages contains several signals, each with a predefine start bit and signal length. Since all signals are assigned different signals lengths 4 bits to 32 bits, what is the best way of creating the data field (/packing the signals) for the CAN messages?

Sample CAN message specification
msg name = mCANmsg1
msg ID=0x33

mCANmsg1 signal1 StartBit=0
mCANmsg1 signal1 length=14
mCANmsg1 signal1 PhysicalValue=10.4262 (simulated analog value)

mCANmsg1 signal2 StartBit=16
mCANmsg1 signal2 length=14
mCANmsg1 signal2 PhysicalValue=1.2367 (simulated analog value)

mCANmsg1 signal3 StartBit=31
mCANmsg1 signal3 length=32
mCANmsg1 signal3 PhysicalValue=531.6487 (simulated analog value)

Thanks! -A

David Smart

# 16 Aug 2013

Hi Aaron, You ask a difficult question - "what is the best way". A few things to consider - available bandwidth, existing protocol, development and maintenance, and uniformity of nodes. Each of these has some influence on the others.

Available bandwidth

If bandwidth is quite limited, then packing as much as you can into a single frame may be the most important aspect. If this is not a concern, then you may send them as several messages, which might be more consistent from message to message and more scalable.

Existing protocol

If your messages are riding on an existing network, it may make the most sense to follow the "convention" for that network. How would these parameters be sent - grouped into a single packet or several.

Development and Maintenance

I guess in this category I'm thinking of the organization of the data structures, and how to move them to/from the network. What SW design pattern can you apply, and by applying it consistently you are more likely to get it right and ease any ongoing maintenance.

Uniformity of Nodes

For this, I'm thinking pretty much of the CPU architecture at each node on the network. With big vs. little endian processors, and the possibility of standarized vs. not-so-standardized floating point formation, you may be able to "drop the data structures" into a message and recover them on the other end very simply. On the other hand, if one is big endian and another little, if one has floating point and the other is a smaller (perhaps 8-bit micro) node, then you might need to consider scaled integer representation.

strings

For strings, if they are all incredibly short and fit in a packet, there is nothing special here. But more typically, you have a message to communicate and it is longer. Many/most of the standardized protocols have a "transport protocol" method, where you can take a larger block of data and break it into packets, stream them and reassemble properly at the other end of the network. This will often tag a "sequence number" into one of the bytes. CAN, as you may know, works very well, but there are situations that could cause a repeated packet. Without the sequence number you would not recover the original message.

**Hi Aaron**, You ask a difficult question - "what is the best way". A few things to consider - available bandwidth, existing protocol, development and maintenance, and uniformity of nodes. Each of these has some influence on the others. ===== Available bandwidth ===== If bandwidth is quite limited, then packing as much as you can into a single frame may be the most important aspect. If this is not a concern, then you may send them as several messages, which might be more consistent from message to message and more scalable. ===== Existing protocol ===== If your messages are riding on an existing network, it may make the most sense to follow the "convention" for that network. How would these parameters be sent - grouped into a single packet or several. ===== Development and Maintenance ===== I guess in this category I'm thinking of the organization of the data structures, and how to move them to/from the network. What SW design pattern can you apply, and by applying it consistently you are more likely to get it right and ease any ongoing maintenance. ===== Uniformity of Nodes ===== For this, I'm thinking pretty much of the CPU architecture at each node on the network. With big vs. little endian processors, and the possibility of standarized vs. not-so-standardized floating point formation, you may be able to "drop the data structures" into a message and recover them on the other end very simply. On the other hand, if one is big endian and another little, if one has floating point and the other is a smaller (perhaps 8-bit micro) node, then you might need to consider scaled integer representation. ===== strings ===== For strings, if they are all incredibly short and fit in a packet, there is nothing special here. But more typically, you have a message to communicate and it is longer. Many/most of the standardized protocols have a "transport protocol" method, where you can take a larger block of data and break it into packets, stream them and reassemble properly at the other end of the network. This will often tag a "sequence number" into one of the bytes. CAN, as you may know, works very well, but there are situations that could cause a repeated packet. Without the sequence number you would not recover the original message.

Aaron Swartz

# 16 Sep 2013

David

Thank you for you time. Courtesy your guidance, I was successfully able to create a message structure, and the requisite code for creating data frames.

Important changes to forums and questions