Hello Everyone
I purchased an MCP 2551 board to use with my PIC18F45K80. I want to control an LED connected with the MCP board using the CAN protocol.
A CAN message has different field in a message like Start of Frame, Identifier, Control Field, Data Field, CRC, Acknowledgment, and End of Frame.
Each node has a unique identifier, and a node knows if a message is for it by checking the message ID. I'm not sure about the message ID for my case. What would be message ID for my case and who decide it ?
Hi,
If this will be on a bus done by you, and not integrated in another bus( eg: car) you can freely decide the ID's of your frames.
You decide it however your wish. If you use extended (29-bit) IDs, you can fit more than one thing in those bits; for example, if your bus has maximum of 256 devices and you have assigned them addresses 0-255, you could use 8 bits of the CAN ID to denote who is talking, and still have 21 bits left to denote something else, e.g. what is this data all about, leaving the payload for actual content.
If you are interfacing to an existing system, then you read the documentation how they chose to use the CAN IDs and do the same.
You decide it however your wish.
When we have a setup with one PIC18F45K80 and three MCP2551 boards, totaling four devices in a CAN network. Each device is assigned a unique ID (e.g., 0x20, 0x23, 0x40). Identifier is 11 bit longs.
When we send a message with a specific ID (e.g., 0x23), how does the specific node with that ID know the message is for it and not for other nodes?
You decide it however your wish.
When we have a setup with one PIC18F45K80 and three MCP2551 boards
AFAIK PIC18F45K80 has only one CAN controller, and MCP2551 is only a CAN transceiver. I'm not sure I understand your setup with one PIC18F45K80 and three MCP2551. Can you post a picture(schematic) to better understand your setup?
In essence you will need a pair consisting of a CAN controller(PIC18F45K80 in your instance) and a transceiver(MCP2551) to successfully implement a CAN node.
Check the attached image to see how to implement three CAN nodes. Only using a transceiver will not help you. The CAN transceiver is only the interface between the controller and the CAN bus.
Check the attached image to see how to implement three CAN nodes.
Thanks! I just now understand that I can have only two nodes because I have only one PIC18.
Could you help me understand the distinction between Node Address and CAN ID?
We decide CAN ID so who decides node address I'm particularly interested in how it function within the protocol.
There isn't any such thing as a node address with basic CAN. Only message IDs. A node can broadcast and receive multiple message IDs. You may have some kind of node address when a higher level protocol is layered on top of CAN, though.
Every node on the bus receives every message. It is up to each node to listen and decide if the message ID is for that node, and if so it will acknowledge the message.
A transceiver doesn't do anything on its own. A transceiver only converts the CAN bus differential pair signal to single-ended RX and TX to be connected to a CAN controller.
Each node has a unique identifier, and a node knows if a message is for it by checking the message ID.
Can was designed with the idea that each CAN message has an ID that specifies the
content of the message. Any interested party could listen to these messages.
The
publish-subscriber pattern.
It should be avoided on CAN bus that two nodes to transmit the same ID, there could be an collision and the message will be lost.
Arbitration is not able to resolve this situation.
Other protocols on top of CAN, such as CANopen or J1939 do indeed create a Node Id or Node Address
within the CAN ID field using a bitmask.
Every node on the bus receives every message. It is up to each node to listen and decide if the message ID is for that node, and if so it will acknowledge the message.
When any node sends a message, the CAN ID is included in the message frame. Every node receives all messages. My question is, how does the receiving node decide if a message is meant for it or if it should be ignored?
The node's CAN controller implements message filters that match one or more message IDs. This is typically implemented in hardware. Filters take various forms, such as matching an exact ID, or a bitmask to match a range of IDs (with further matching of precise ID by software).
My question is, how does the receiving node decide if a message is meant for it or if it should be ignored?
Well, it's your responsibility, as a system designer, to program the nodes to accept or ignore messages with specific IDs or ranges of IDs.
Say, your "button controller" sends a message with ID=1 every 20ms. Another "rotary encoder controller" sends a message with ID=2 every 25ms. There is the third node, "GUI controller", which accepts both and makes sense of them.
Should your "button controller" receive messages with ID=2 ? No.
Should your "rotary encoder controller" receive messages with ID=1 ? No.
Should your "GUI controller" receive messages with ID=1 and ID=2 ? Absolutely.
Each node has a unique identifier, and a node knows if a message is for it by checking the message ID.
This is a fundamental misunderstanding! A Message ID does not determine the sender or the receiver as in other bus systems. A Message ID denotes the content of a message, and this is very different. A node can send out multiple messages with different values, parameters etc, and each message gets its own id. Each receiving node can choose to receive a certain message.
Example: Room sensor
The sensor sends three messages:
Message 1: ID 0x210: Temperature
Message 2: ID 0x211: Humidity
Message 3: ID 0x212: CO2
Each receiver can choose to receive none, some or all of the messages.
The only caveat is that no two nodes send messages with the same ID. Bus arbitration wouldn't work then.
In the control field, we determine how long the identifier is – either 11 bits or 29 bits – and also the length of the data byte. It appears that we're limited to sending a maximum of 8 bytes of payload.
Assuming a message ID of 0x10 and wanting to send the values of voltage and current (both float type variables occupying 4 bytes each):
Start of Frame: 1
Identifier: 11 bits
Control Field:?
What would data length in control field?
See the Wikipedia article for a good overview of CAN message frame structure:
https://en.m.wikipedia.org/wiki/CAN_busThe length field (DLC) is in bytes. So for a payload of 2x 4 bytes, it'll be 8.
You don't really need to be concerned with the details of how to build a CAN message frame. It's the job of the CAN controller to format the frame. Although understanding the details can of course aid diagnostics.
The length field (DLC) is in bytes. So for a payload of 2x 4 bytes, it'll be 8.
It appears that we face a limitation in sending more than 8 bytes in a single CAN message. For instance, if we need to transmit voltage, current, and power values, the combined size of these three variables exceeds the 8-byte limit, posing a challenge.
The length field (DLC) is in bytes. So for a payload of 2x 4 bytes, it'll be 8.
It appears that we face a limitation in sending more than 8 bytes in a single CAN message. For instance, if we need to transmit voltage, current, and power values, the combined size of these three variables exceeds the 8-byte limit, posing a challenge.
The obvious solution is to use separate messages for voltage, current and power, CAN ID denoting what the message is about. For example, you can choose so that device 0x05 sends on msgids:
050: voltage
051: current
052: power
Then if the other device is interested about 05's voltages, it can choose to subscribe only on that msgid.
Do not put multiple types of content in one message. Eg, do not index a CAN frame into multiple pages.
None of the tooling handles that correctly.
Go for the method Siwastaja suggests.
What would data length in control field?
Unless you are going to design your own CAN controller from scratch, which almost no one ever does, you don't have to think about the protocol level at all. The CAN controller (usually a microcontroller built-in peripheral, but separate chips are also available) handles the protocol details, and you just configure the controller like this: "send a normal message with extended ID 0x1234, with payload ac dc ab ba cd". On the other hand, you configure it "accept messages with standard ID 0x555 and put them in FIFO0". How you exactly do this, what registers are written etc., is explained in the manual.
I have a question regarding CRC (Cyclic Redundancy Check) in the context of error detection in transmitted messages. The CRC consists of 15 bits. Do I need to configure any specific hardware-related settings while coding for both the sender and receiver nodes, or is it handled in the software?
Answers to various questions:
1) The PIC18 has a single CAN controller to which you'll connect a single external CAN PHY. It will act as a single node on the CAN network. If you want two CAN nodes driven by that single PIC18, you'll need an external CAN controller as well, likely interfaced to the PIC18 via SPI.
2) The last eight bits of the 29 bit extended header is generally where nodes put the Source Address (SA), which is a unique 8-bit value for each node. This might be what was meant by "node address". This is how receiving nodes know where each message originates. The rest of the 29 bit header includes some sort of message type value (for J1939, NMMA, etc. it's often called the "PGN"). Receiving nodes typically look at the PGN and SA to decide if they care about any given message.
3) As far as a Destination Address (DA), that's protocol specific. If one is used, often it's the first byte of the eight bytes of payload data (if that PGN supports the concept of a DA at all). Remember that CAN is a broadcast network - everyone hears everything and makes their own decision about whether they care or not. Having a DA allows nodes to specify their intended target, but it doesn't prevent everyone else from receiving and acting on the message.
Others have covered hardware filtering, etc. If you're only going to have a couple of nodes on your network, you won't need to filter anything because there won't be traffic that you don't care about.