Regarding the CAN communication problem, I don't quite understand the sending function in the routine. Can you please help me?

ena

Regarding the CAN communication problem, I don't quite understand the sending function in the routine. Can you please help me? [Copy link]

First the routine:

void CAN1_SendMesg(uint32_t id, uint8_t len, uint8_t *dat)
{
uint16_t i = 0;
CanTxMsg TxMessage;

/* CAN_RTR_DATA */
if(len > 8)
{
return ;
}

TxMessage.StdId = (id & 0x7FF);
TxMessage.ExtId = (id >> 11);
TxMessage.RTR = CAN_RTR_DATA; //
if((id & 0x7FF) == 0x7FF) //Judge whether it is a standard frame or an extended frame
{
TxMessage.IDE = CAN_ID_STD;
}
else
{
TxMessage.IDE = CAN_ID_EXT; //±ê×ID
}
TxMessage.DLC = len; //·¤

/* · */
for(i=0; i<len; i++)
{
TxMessage.Data[i] = *dat;
dat++;
}
CAN_Transmit(CAN1, &TxMessage);
}

The above is a routine provided by a development board manufacturer. The problem is as follows:

1. TxMessage.ExtId = (id >> 11); Shouldn't it be equal to id&0x1fffffff?

2. Is it possible to distinguish between standard frames and extended frames?

dingzy_2002

The standard frame of CAN consists of 18 bits: 11 identification bits + 1 remote transmission request bit + 6 control fields, a total of 18 bits

The CAN extended frame consists of 29 bits: on the original standard frame, an extended 11-bit extended identification bit (including the extended ID identifier and the replacement bit, SRR)

In LZ's program, id should be 1 word data (4 bytes), which may be a standard frame or an extended frame. This depends on the specific data.

If the data is > 0x7FF (exceeds 11 bits), the program determines it as an extended frame, otherwise it is considered a standard frame.

TxMessage.ExtId = (id >> 11); This program indicates that the extended frame data is placed in TxMessage.ExtId (note: it is shifted right by 11 bits and the original standard frame data is removed), instead of being related to 0x1fffffff.

ena

dingzy_2002 posted on 2021-6-7 09:33 The standard frame of CAN consists of 18 bits: 11 identification bits + 1 remote transmission request + 6 control fields, a total of 18 bits. The extended frame of CAN consists of 29 bits: in the original...

Well, I don't know why it should be removed. In the library function CAN_Transmit(), the ID is not a combination of the standard frame and the extended frame, but is assigned separately. If it is removed, the ID will be incomplete.

huo_hu

The extended id is a subset of the standard id. When sending the extended id, the standard id is a part of it, just like a subnet mask. Of course, you can also not follow this rule.

dingzy_2002

ena posted on 2021-6-7 11:07 Well, but I'm not sure why it was removed? In the library function CAN_Transmit(), the ID does not combine the standard frame and the extended frame together...

When the ID is entered, the extended frame and the standard frame are separated, but the function encapsulates them into a 1-word (4-byte) data

In this way, in TxMessage, it is necessary to split it into standard frame TxMessage.StdId and extended frame TxMessage.ExtId

The benefits of doing this are:
1. It can clearly judge and enter standard frames/extended frames

2. Friendly and convenient processing of CAN received ID.

freebsder

The expression and register (buffer) do not have to be the same, you can refer to the chip manual for details.