AUTOSAR Dictionary: Full analysis of key points of CAN driver Mailbox configuration technology
Preface
First of all, I would like to ask you a few small questions. Do you know:
- Are the CAN driver keywords defined under the AUTOSAR framework? Are there some people who are always confused and confused?
- What key configuration parameters are worthy of our attention during the CAN driver Mailbox configuration process to prevent low-level errors?
- What are the differences between the three types of Tx Buffer, Tx FIFO, and Tx Queue of CAN-driven Mailbox?
Today, let’s explore and answer these questions. In order to facilitate everyone's understanding, the following is the topic outline of this article:
text
As an important driver module that is often encountered in daily development projects, the AUTOSAR organization has very comprehensive and accurate implementation requirements and related keyword parameter definitions for CAN Driver.
It is often found that people always ignore or confuse the definitions of keywords in these modules during the development process, resulting in many misunderstandings between the two parties during the communication process, and many unnecessary mistakes and bugs during the development process. Therefore, in this article, Xiao T will lead everyone to understand some very important keyword explanations and difficult-to-understand basic concepts of the CAN Driver of the AUTOSAR framework, to help us develop CAN drivers in our daily work.
Xiao T will continue to update the AUTOSAR dictionary column in the future. The dictionary will explain basic concepts and related important knowledge points that are difficult to understand or easily confused under the AUTOSAR framework. It will help everyone check for gaps and fill in the gaps like an "encyclopedia dictionary" and help everyone complete the task efficiently. Based on AUTOSAR software development, everyone is welcome to pay more attention to and forward this column.
CAN driver keyword definition
By studying the AUTOSAR CAN Driver standard document and combining it with his own practical experience, Xiao T organized the keyword definitions of the CAN Driver module as shown in the following table:
CAN driver Mailbox key configuration parameters
In the underlying MCAL CAN Driver configuration process, there are always many key configuration parameters that are easy to confuse. If these parameters are configured incorrectly, sometimes puzzling problems and bugs will occur. Therefore, in order to reduce the risk of such problems, Appeared, Xiao T combined his own practical experience to learn the definition of key configuration parameters and related precautions in the CAN driver.
Hardware Object
As mentioned in the above table, a Hardware Object is a CAN L-PDU buffer, used to store only one CAN ID Message . You will understand it as what we often call the Mailbox, which is the CAN controller hardware. A physical buffer space used to store a CAN ID Message for sending or receiving. The CAN ID Message naturally contains three parts: CAN ID, DLC, and Data .
The differences and connections between HOH, HTH and HRH
In order to better understand the differences between HOH, HTH and HRH, Xiao T organized the differences and connections between the three as shown in the following table:
CanHwObjectCount
According to the definition in the AUTOSAR official document, this parameter represents the number in the Hardware Object. However, it should be noted that the object of this parameter is HOH, that is, HRH or HTH. This parameter indicates whether the FIFO mechanism is configured for the HOH. If If the number is 1, there is no FIFO to cache data. If it is greater than 1, then the FIFO data caching mechanism is configured for the HOH. This caching mechanism is crucial to prevent the loss of important messages received or sent by CAN.
The following figure shows the configuration of CanHwObjectCount in HOH:
- As shown in Figure 1 above, we can know that the HOH is a sending type HOH, so it can be directly understood as HTH . Then the value of the parameter CanHwObjectCount defined in the HTH is 1, which means that there is no FIFO mechanism and it is just a unique buffer . If data is sent or received frequently, it means that new data may not be sent in time;
- As shown in Figure 2 above, you can know that the HOH is a receiving type HOH, so it can be directly understood as HRH . Then the HRH defines the parameter CanHwObjectCount with a value of 2, indicating that there is a FIFO mechanism with a depth of 2. If the data is sent or Reception is relatively frequent, and there is at least a FIFO buffer space with a depth of 2 to prevent the loss of important data.
Full CAN与Basic CAN
Full CAN and Basic CAN in MCAL CAN Driver are used to modify the type parameters of HOH, which can be defined through CanObejctType .
Full CAN: Generally means that there is only one Hardware Object corresponding to it, and the Full CAN type Hardware Object is bound to a specific CAN ID Message;
Basic CAN: Generally indicates that there are one or more Hardware Objects corresponding to it, and the Hardware Object of the Basic CAN type is bound to a non-specific CAN ID Message or a CAN ID Message within a certain range;
Precautions:
- For Basic Can type HOH, it is generally recommended to configure hardware filters to receive underlying irrelevant CAN Message data or receive messages within a specific range, thereby reducing unnecessary hardware interrupts and thus reducing the CPU load to some extent;
- When hardware resources are sufficient and there is no need to consider too much scenarios where new data may overwrite old data, it is generally recommended to configure the HOH as the FULL CAN type.
- During the HOH configuration process, it is generally necessary to configure the FULL CAN type HOH first and the Basic CAN type HOH last. Otherwise, it is easy to cause confusion in the use of Maibox in the generated code.
Recommended configuration plan
Based on practical experience, Xiao T summarized the four common message types in the software development process: application messages, network management messages, diagnostic messages, and the mailbox configuration scheme for sending and receiving Xcp messages as shown in the following table:
The recommended configuration solutions are summarized as follows:
- Because diagnostic messages are important messages, neither loss nor transmission is allowed and there is a strict timing relationship. Therefore, it is recommended to set up Basic CAN+FIFO for both transmission and reception;
- Xcp message sending and receiving are messages with specific IDs, so it is recommended to set Full CAN+Buffer for both sending and receiving;
- On the premise that the mailbox hardware is sufficient, the sending and receiving of application messages is preferably configured with Full CAN+Buffer. If the hardware resources are insufficient, it is recommended to use Basic CAN+FIFO configuration;
- The reception of network management messages is generally a certain range of messages, so it is recommended to use Basic CAN+Buffer to configure the reception. Since the ID is determined for sending, it is recommended to use Full Can+Buffer to configure it;
- After the configuration of sending and receiving all messages is completed, be sure to ensure that the total number of mailboxes sent and received by the CanHwObjectCount in all configured HOH cannot exceed the total hardware resources of the sending mailbox and receiving mailbox specified in the chip manual;
CAN driver hardware Buffer type
After understanding the above CAN driver recommendations, we need to further explore how the buffer used to store CAN L-PDU is defined within the can controller hardware resources?
Generally speaking, the hardware resources of mainstream CAN Controllers on the market can be divided into the following types of buffers according to sending and receiving:
- Sending hardware Buffer type: Tx Buffer, Tx FIFO, Tx Queue;
- Receive hardware Buffer type Rx Buffer, Rx FIFO;
Next, each hardware Buffer type will be explained separately:
Tx Buffer
Tx Buffer is also called Dedicated Tx Buffer. This Buffer will be bound to a specific CAN ID. The sending priority is completely through the CAN ID. The smaller the CAN ID, the higher the priority. High priority is sent first;
Generally, the Tx Buffer will configure the CanObjectType type of HOH to Full CAN mode.
Tx FIFO
The FIFO mechanism mentioned above can actually be divided into two types at the bottom of the hardware, one is Tx FIFO, and the other is Tx Queue, because both are themselves cache spaces.
As the name suggests, Tx FIFO transmits in a " first in , first out" manner, ignoring the CAN ID priority. Generally, in order to prevent priority inversion, it is not recommended to use the FIFO mode.
Tx Queue
As a kind of FIFO mechanism, Tx Queue is different from Tx FIFO itself in that new Message sending requests are placed in order, but when sending, it is the same as the Tx Buffer mechanism, according to the principle of sending first with high priority, that is The smaller the CAN ID, the higher the priority. If there are multiple messages with the same CAN ID that need to be sent, the Buffer ID with the smaller number will be sent first.
In addition to the above-mentioned single sending mode, the above-mentioned combination mode may exist in most cases. What needs special attention in the combination mode is the determination of the priority of outgoing messages:
Tx Buffer + Tx FIFO mode
As can be seen from the figure above, the priority of each transmission is determined as follows:
- Take out the minimum CAN ID in the Dedicated Tx Buffer and send the request;
- Take out the oldest CAN ID in the Tx FIFO and send the request;
- Compare the CAN ID sending requests taken out from the above Tx Buffer and Tx FIFO respectively. The sending request with the smaller CAN ID between the two is sent first.
Tx Buffer + Tx Queue mode
As can be seen from the figure above, the priority of each transmission is determined as follows:
- Take out the minimum CAN ID in the Dedicated Tx Buffer and send the request;
- Take out the smallest CAN ID in the Tx Queue and send the request;
- Compare the CAN ID sending requests taken out from the above Tx Buffer and Tx Queue respectively. The smaller CAN ID between the two is sent first.
Rx Buffer
Rx Buffer is the same as Tx Buffer. It is generally bound to a specific CAN ID. Generally, the Rx Buffer will be configured with the CanObjectType type of HOH as Full CAN mode. If the old data CPU has not finished processing it at this time, the new The data will not be processed.
Rx FIFO
Rx FIFO typically receives and processes CAN messages in a "first in, first out" manner. Generally speaking, there will be two Rx FIFOs, one is Rx FIFO0, and the other two are Rx FIFO1. This is selected according to the actual situation. .
At the same time, if the Rx FIFO is Full, there are two processing methods:
- Blocking Mode: Indicates that if the FIFO is full, new data can only be put in after the data processing is completed. This method is generally recommended;
- Overwrite Mode: Indicates that if the FIFO is full, new data can overwrite the oldest data. If OverWrite is used, it is necessary to ensure that there is no data consistency problem when obtaining data and receiving data;
For more exciting content, please pay attention to the official account "My opinion on ADAS and ECU!"