In the neural network of automotive electronics, industrial control and even smart home, CAN-bus is like silent blood, carrying massive instructions and data.
Whether it is the simple signal to control the window lifting in the traditional fuel vehicle or the complex status message in the battery management system of the electric vehicle, they all depend on the efficient and reliable communication of the CAN-bus protocol.
However, when engineers are faced with the growing number of network nodes and complex communication requirements, a fundamental but crucial question often arises: Can standard frames and extended frames with different identifier lengths coexist harmoniously and work side by side in the same CAN network?
This is not only related to the design of the protocol itself, but also directly affects the flexibility and future scalability of the system architecture.
Can standard frame and the extended frame of the CAN appear at the same time?
1 What are the standard and extended frames for CAN?
The CAN network communication is performed through five types of frames,
- Data frame
- Remote frame
- Error frame
- Overload frame
- Inter-frame space
In addition, data frames and remote control frames are available in both standard and extended formats.
The standard format has an 11-bit Identifier (ID), and the extended format has a 29-bit ID.
A Data frame is a frame for transmitting data from a transmitting unit to a receiving unit.
Remote frame is a frame for the receiving unit to request data from an ID transmitting unit.
The data frame of the CAN consists of 7 segments:
- Start of frame:segment indicating the start of data frame (same as standard and extended format)
- Arbitration section:a section indicating the priority of the frame (the standard format and the extended format are formed differently here)
- Control segment:a segment representing the number of bytes and reserved bits of data (the standard format and the extended format are formed differently here)
- Data segment:the content of data, which can send 0 ~ 8 bytes of data (the standard and extended formats are the same)
- CRC segment:a segment of a frame that is checked for transmission errors (same as standard, extended format)
- ACK segment:indicates the segment for confirming normal reception (the standard and extended formats are the same)
- End of frame:segment indicating the end of data frame (same as standard and extended format)
CAN standard frame format
CAN standard frame information is 11 bytes (3 + 8), including two parts: information and data. The first 3 bytes are the information part.
Byte 1 is the frame information. The 7th bit (FF) indicates the frame format, FF = 0 in standard frame; the 6th bit (RTR) indicates the frame type, RTR = 0 indicates data frame, RTR = 1 indicates remote frame;
Bytes 2 and 3 are message identification codes, i.e. ID, and 11 bits are valid.
Bytes 4 to 11 are the actual data of the data frame and are invalid in the remote frame.
2 Comparison of Arbitration Field Standard Frame and Extended Frame
Identifier (ID)
Standard format: 11 bits
Extended format: 29 bits
Used for prioritization and filtering. Used to prioritize frames and allow arbitration when multiple nodes are sending data simultaneously.
RTR (Remote Transmission Request)
1 bit
Distinguish between data frames and remote frames.
If it is 0, it indicates data frame; If 1, indicates a remote frame.
IDE (Identifier Extension)
1 bit
Distinguish between standard and extended frames.
If it is 0, it indicates a standard frame; If it is 1, it indicates an extended frame.
r0 (Reserved)
1 bit
Bits are reserved or substituted to ensure the consistency of the frame structure.
Reserved bit, usually recessive (logic 1).
SRR (Subs titute Remote Request) (in extended format only)
1 bit
Bits are reserved or substituted to ensure the consistency of the frame structure.
Used in extended frames in place of the Remote Request bit.
Total length of the arbitration segment
Standard format: 14-bit
Extended format: 32 bit
Arbitration segment design point
The arbitration section is a section indicate that priority of the frame (the standard format and the extended format have different configuration here), and can,
1) The priority mechanism is implemented through the ID field, and the priority sorting ensures that the data with high priority can be transmitted first.
2) Support standard frames and extended frames, and provide larger address space and more flexible application scenarios.
3 Control Field Standard Frame and Extended Frame Comparison
The control segment is DLC and contains 4 bits indicating the number of bytes (0 to 8 bytes) of data contained in the data field.
It tells the receiver the length of the data field. Ensure that the receiver can correctly parse the data field and improve the communication efficiency.
The composition of the standard format and the extended format is different.
Relationship between data length code and number of bytes
4 Difference between standard frame and extended frame
As can be seen from the above,
1) The range of the frame ID of the standard frame is 000-7FF, and the range of the frame ID of the extended frame is 00000000-1FFF FFFF, so that a larger ID group can be realized.
2) The DLC (data length) in the control section of the standard frame and the extended frame are exactly the same, but the reserved bits are different. The standard frame IDE, R0, and the extended frame R1, R0.
3) Everything else is the same, so, in fact, the CAN standard frame and the extended frame are only different in the length of the frame ID, so that more CAN nodes can be extended to better support the upper layer protocol.
Can I use both standard and extended frames?
The standard frame is suitable for systems with a small number of nodes and simple functions (such as lighting, window control, on-board CAN bus transmission of vehicle speed and fuel quantity data of traditional vehicles). The advantage is strong compatibility, which is supported by all can nodes.
Extended frames are suitable for complex systems (such as battery management and automatic driving of new energy vehicles), supporting more nodes and complex communication needs. The advantage is that the expansibility is strong, and the number of IDs is much larger than that of standard frames.
CAN protocols such as CAN 2.0B explicitly support the use of a mix of standard and extended frames.
5.1 Notes on Application of Extended Frame
(1) Reasonable communication planning
Pay attention to priority interference
It is technically feasible to mix standard frames and extended frames on the same CAN bus network, but in practice, it may cause problems such as priority imbalance, identifier conflict and network load increase. In the complex system, it is necessary to allocate ID reasonably to avoid the ID conflict between the standard frame and the extended frame.
During the arbitration phase of the frame, standard and extended frames are compatible and are distinguished by the “IDE bit” (identifier extension bit), which is 0 for standard frames and 1 for extended frames.
In the arbitration phase: if both frames contend at the same time, the standard frame has a higher priority in the arbitration because of its shorter identifier field (assuming that the first 11 bits of the identifier are the same). That is, the priority of the standard frame is compared with that of the extended frame by ID, and the priority of the standard frame is higher. For exampl:
Standard Frame ID = 0x123 has a higher priority than Extended Frame ID = 0x123 + 0x00000.
Attention should be paid to priority interference. The priority of the standard frame is naturally higher than that of the extended frame, which may cause the extended frame to be delayed frequently in the network with higher load.
If the extended frame in the application carries time-sensitive data, special attention should be paid.
Be careful to distinguish between the IDE bits
In the design phase, try to assign different functional domains to the standard frame and the extended frame to avoid identifier conflicts.
The first 11 bits of the extended frame may be the same as the identifier of the standard frame, which is easy to confuse. The application layer processing logic should pay attention to correctly distinguish IDE bits.
For example: Standard Frame Identifier: 0x7FF. Extended frame identifier: 0x7FF1234.
If mixing is unavoidable, frame type discrimination logic can be added to the application layer protocol to ensure correct parsing of the IDE bits.
(2) Load management
Standard frames are used as much as possible for critical real-time data to reduce arbitration latency. Evaluate the network load regularly to ensure that the introduction of extension frames does not cause congestion on the bus.
The frame length of the extended frame is longer than that of the standard frame, and the transmission of the extended frame takes more bus time.
In high-load networks, the use of extended frames may aggravate the bus congestion and affect the real-time communication.
(3) Filter configuration
Early CAN controllers may only support standard frames (e.g. CAN 2.0 A only). Most modern CAN controllers support the CAN 2.0B protocol and are capable of receiving and processing both frame formats.
If both standard frame and extended frame devices exist in the network, ensure that the standard frame node does not generate an error due to its inability to parse the extended frame.
In case of mixed use, it is necessary to ensure that the CAN controller supporting the mixed mode is used, the hardware with sufficient filter resources is selected, and the filter and mask of the CAN controller are reasonably configured.
If the filter is not designed properly, it may cause the standard frame or the extended frame to be incorrectly discarded or misidentified.
Some hardware filters have limited resources, and the identifier length of the extended frame is long, which may increase the complexity of the filtering configuration.
It is not only allowed by the protocol, but also a common requirement in the evolution of complex systems that CAN standard frames and extended frames appear simultaneously in the same network.
The core answer to the question has long been supported by the CAN 2.0B protocol, but the real challenge is how to do it elegantly.
This requires engineers to go beyond simple “usability” thinking and delve into engineering details such as priority design, identifier planning, network loading, and hardware filtering.
The standard frame guards the real-time cornerstone of the system with its simplicity and efficiency, while the extended frame reserves a runway for future innovation with its vast address space.
Understanding and navigating the coexistence of these two frame formats in the path to a smarter, more connected system is like mastering the art of balancing between technical compatibility and performance optimization to find the best path for the current project.
The shape of the frame may continue to evolve with the popularity of new generation protocols such as CAN FD, but this understanding of the nature of communication will always be the cornerstone of a reliable digital base.
