Can't get correct CAN ID from CAN shield V2

Huang.Eason 2023-06-01 16:41:55 153 Views2 Replies
I use two pieces of DFR0370
https://wiki.dfrobot.com/CAN-BUS_Shield_V2__SKU__DFR0370_

When I send a message with the following code, the CAD ID on the other end is always 0x1AA
What is the reason? How do I send it with the correct ID 0x1B0201AA?

code:
//------------------------------------------------------------------------------------------------------------------
if(CAN.sendMsgBuf((0x1B0201AA), 0, 8, LED_Config)==CAN_OK)
{
Serial.println("(m)0x1B0201AA LED_Config：");
for(int i=0;i< sizeof(LED_Config);i++)
{
Serial.print(LED_Config[i],HEX);
Serial.print("\t");
}
Serial.println();
Serial.println();
}

2023-06-02 17:42:53

Just double checked the GitHub, I noticed that the shield also support to send the extend data frame.

You could also try to change this parameter into 1, to see if it support 0x1B0201AA as it's canID.

The extend data frame support the 29-bit CAN identifier, so it could range from 0~0x1FFFFFFF

Yeez_B

2023-06-01 22:23:00

At first, I thought the problem was that you were passing in arguments that were outside the scope of the parameter definition.Because your CAN id is a hexadecimal 1B0201AA, this is a large number that may exceed the data format defined by the CAN id parameters in the source code.

But after I checked the souce code posted on the GitHub.

https://github.com/DFRobot/DFRobot_MCP2515

I thought that the CAN id was define as a 32bit int format in the function you called up.

And then we could get back to the sendMsg() function in the first picture.

But in sendMsg(), the function that actually sends the CAN message is mcpWritecanMsg(), the others are basically functions that handle timeout exceptions.

So I gotta trace to the mcpWritecanMsg() function, what a tough job🤣. But luckly, these function name and parameters are all straightforward.

And in the mcpWritecanMsg() function, finally we called up the mcpWriteid()function to send the CAN id out.

And at here, the canID is still as a private member parameter, which is defined as a 32 bit int

The 32-bit int data ranges from -2147483648 to 2147483647. And your 0x1B0201AA is 453116330 as decimal format.

So it's not a matter of parameter definition in the code.

On the contrary, I think the sample library file presented by DFRobot is well written.

Then I realized if it's the limitation of the CAN open protocal?

And I had found this artical about the CAN open:

https://copperhilltech.com/blog/controller-area-network-can-bus-tutorial-extended-can-protocol/

Here it metioned the standard format(which is the CAN shield used) only support the 11-bit identifier.

In another word, the standard format CANid could only ranges from 0x00~0x7FF

And then I checked the datasheet of the onboard chip MCP2515 to confirm my guess.

Here is the datasheet: https://www.dfrobot.com.cn/images/upload/File/DFR0370/20160406122457ihx0zy.pdf

You could see that the chip only reserve 11-bit to the canID

So you could try to set your CAN id in the range of 0x00~0xFF to see if it could solve your problem.

Yeez_B