[Playing with multi-core heterogeneity] Dual-core high-speed CAN-FD detailed evaluation
[Copy link]
*In order to let more engineers understand multi-core heterogeneous processors, Feiling Embedded has specially launched the [Play with Multi-core Heterogeneous] topic to help everyone solve the problems encountered in the development process of multi-core heterogeneous processors. [Play with Multi-core Heterogeneous] The topic is continuously updated, welcome to subscribe and follow.
Introduction
With the advantages of real-time, anti-interference and security, CAN2.0 has been widely used in the industrial and automotive industries, but its maximum rate is only 1Mbit/s, and each frame can only transmit up to 8 bytes of valid data. Only about 50% of the bandwidth in the message is used for effective data transmission. However, with the development of the industry, the number of various sensors and controllers has increased, and the amount of data on the bus has also increased sharply, which makes the shortcomings of the CAN2.0 bus in terms of transmission rate and bandwidth more obvious, so CAN-FD was born. CAN-
FD has significantly improved in transmission rate and bandwidth, with a baud rate of up to 8Mbit/s, up to 64 bytes of valid data per frame, and a transmission efficiency of about 80%. It can further improve the real-time performance of the bus, broaden the data bandwidth of the bus, and improve the transmission efficiency of the bus.
There are two CAN-FD channels on the Feiling Embedded OKMX8MP-C development board. Today, based on this development board, the editor will take the M core and A core of the processor each controlling one CAN-FD channel to communicate with each other as an example to explain how the M core and A core control CAN-FD high-speed communication from an application perspective.
The NXP i.MX8M Plus processor on the Feiling Embedded OKMX8MP-C development board has powerful performance, integrating 4 Arm Cortex-A53 multi-tasking cores with a maximum frequency of 1.8GHz (industrial-grade frequency is 1.6GHz) and 1 Cortex-M7 real-time core. Whether it is high-speed data throughput and processing, or complex human-computer interaction interface processing, it can handle it with ease.
![image.png](/img/bVbMDQ
01
M-core CAN-FD
- CAN-FD initialization
CAN-FD initialization mainly includes the initialization of bus clock, pins and corresponding registers. The details are as follows:
(1) CAN bus clock:
Now multiply the CAN bus to 800MHz, and then divide it by 10 to 80MHz.
CLOCKSetRootMux(kCLOCKRootFlexCan1, kCLOCKFlexCanRootmuxSysPll1); // Set the CAN1 bus clock to 800MHz
CLOCKSetRootDivider(kCLOCKRootFlexCan1, 2U, 5U); // The division factor is 25=10, set the CAN1 bus clock to 80MHz
(2) Pin configuration:
Select CAN1's transmit pin as pin 32 and receive pin as pin 34.
IOMUXCSetPinMux(IOMUXCSAI2TXCCAN1RX, 0U); // CAN1 RX
IOMUXCSetPinMux(IOMUXCSAI2RXCCAN1TX, 0U); // CAN1 TX
(3) CAN baud rate:
CAN-FD supports variable baud rate, that is, the baud rate of the control area and the data area can be inconsistent. The maximum baud rate of the control area is 1Mbit/s; the maximum baud rate of the data area is 8Mbit/s. The subsequent program allocates the values of seg1, seg2, etc. in the time period according to the bus clock and the set baud rate.
pConfig->bitRate = 1000000U; // CAN-FD control area baud rate is 1Mbit/s
pConfig->bitRateFD = 8000000U; // CAN-FD data area baud rate is 8Mbit/s
(4) CAN-FD enable:
In addition to enabling CAN-FD, variable baud rate also needs to be enabled, otherwise the maximum baud rate of the data area is the same as the rate of the control area, which is a maximum of 1Mbit/s.
base->MCR |= CANMCRFDENMASK; // CAN-FD enable
fdctrl |= CANFDCTRLFDRATEMASK; // Variable baud rate enable
(5) Turn off self-loopback:
If self-loopback is turned on, the CAN1 data will loop back inside the chip and will not reach the external pins. When debugging the program, the interference of the external terminal can be eliminated. However, in real applications, the self-loopback needs to be turned off and data is sent and received from the external pins.
pConfig->enableLoopBack = false; // No loopback, use external pins
(6) Frame format:
This time we use the 11-bit standard data frame, and friends will also try the extended frame later. You need to set your own ID to facilitate recognition by other devices on the bus.
mbConfig.format = kFLEXCANFrameFormatStandard; // 11-bit standard frame, non-extended frame
mbConfig.type = kFLEXCANFrameTypeData; // Data frame, non-remote frame
mbConfig.id = FLEXCANIDSTD(rxIdentifier); // Frame ID is used to distinguish different devices in the bus
(7) Receive filter:
The user can set receive filter rules so that only data with a specific frame ID can be received, reducing the amount of data processed by the application.
rxIdentifier = 0;
FLEXCANSetRxMbGlobalMask(EXAMPLECAN, FLEXCANRXMBSTDMASK(rxIdentifier, 0, 0)); //Receive all ID data
-
CAN-FD sending and receiving process
In this test, the M core acts as the master station. CAN1 first sends a frame containing 64 bytes of data. The A core CAN2 receives it and sends the 64 bytes of data again. The M core CAN1 receives it. Compare whether the 64 bytes of data sent and received are consistent. Repeat 100 times.
(1) CAN-FD sends data:
EXAMPLECAN is represented by CAN1, flexcanHandle is the CAN instance, which includes the send and receive callback functions, and txXfer is the 64 bytes of data to be sent.
FLEXCANTransferFDSendNonBlocking(EXAMPLECAN, &flexcanHandle, &txXfer); // CAN-FD sends data
(2) CAN-FD receives data:
EXAMPLECAN is represented by CAN1, flexcanHandle is the CAN instance, which includes the send and receive callback functions, and rxXfer is the 64 bytes of data received.
FLEXCANTransferFDReceiveNonBlocking(EXAMPLECAN, &flexcanHandle, &rxXfer); // CAN-FD receiving function
(3) Comparison of receiving and sending data:
for (j = 0U; j <= DLC; j++) // Compare the sent and received data, print if inconsistent
{
if (txXfer.framefd->dataWord[j] != rxXfer.framefd->dataWord[j])
{
LOGINFO("Data mismatch !!! j=%d \r\n",j);
}
}
02A core CAN-FD
A core device tree retains CAN2, and the kernel parses the device tree to generate can0 under /dev. After setting the baud rate, enable the can0 node, use the open function in the application to open the interface, use the write function to send data, and use the read function to receive data. We have used the CAN interface example as a cross-platform comprehensive demonstration program, and you can directly add parameters to call it.
- Assign nodes
(1) M core exclusively uses CAN1, A core exclusively uses CAN2, modify the device tree, delete the CAN1 device node in the device tree OK8MP-C.dts, and keep the CAN2 device node. Compile a new device tree;
(2) Copy the generated OK8MP-C.dtb and Image to
the /run/media/mmcblk2p1/ directory of the development board, enter the sync command to synchronize and restart the development board;
(3) Enter the command uname -r through the A core serial port to display the kernel version, change the folder name in the /lib/modbule directory to the kernel version, so that the module can be automatically loaded to generate the can0 node, and restart the development board.
EEWORLDIMGTK0
- DemoDemo
process name:
candemoUsage: ./candemoDevice name [parameter options]… …
The test interface is can0 (corresponding to the development board CAN2), the control area baud rate is 1Mbit/s, the data area is up to 8Mbit/s, 11-bit standard frame, frame ID is not filtered, data is not actively sent, and loopback is not performed. Therefore, the command is:
./candemo can0-b 1000 -fd 8000.
03Program
verification
-
Hardware connection
Use Dupont wire to short-circuit can-H of CAN1 and CAN2, and short-circuit can-L at the same time. Be careful not to connect them in reverse.
- M-core program
Modify the uboot environment variables to set the M core to start automatically, and put the M core program forlinxm7tcmfirmware.bin
in the /run/media/mmcblk2p1/ directory. For detailed operations, please refer to the previous article "[Playing with Multi-core Heterogeneous] Startup, Writing and Simulation of M Core Programs".
- A core program
(1) Use serial port Xmodem, network FTP, SCP, USB flash drive, TF card and other methods to copy candemo from the computer to the default directory of the core board, and enter the following command to modify the permissions:
chmod 777 candemo
(2) Enter the following command, the A core application candemo will set the baud rate and open the can0 node, wait for the data sent by the M core, and then send the received data to the M core through CAN2.
./candemo can0 -b 1000 -fd 8000
- Actual test
(1) After the OKMX8MP-C development board is powered on again, the M-core program starts. After CAN1 is initialized, information is output on the M-core debug serial port, and it waits for a key press.
(2) Enter the following command on the A-core debug serial port, and CAN2 will be in the receiving state:
./candemo can0 -b 1000 -fd 8000
(3) Press key A or a on the M core serial port, M core CAN1 sends 64 bytes of data, A core CAN2 receives the data and sends it again, M core CAN1 receives and compares the data sent, and outputs the result. Repeat 100 times;
(4) Through testing, we can see that relying on the powerful performance of i.MX8M Plus, both cores send a large amount of data at a high rate of 8Mbit/s, and no abnormalities occur.
The above is the use method of dual-core control CAN-FD based on Feiling embedded OKMX8MP-C development board brought to you by the editor. Do you feel that the performance is very powerful?
|