1. Architecture and Terminology Explanation
I will put a module diagram in each section of BSW in the future, so I will put the picture first:
since the CAN bus is generally used in the car, you can treat the bus in the picture as CAN. If you use LIN or other , and correspondingly replace it with its bus. In the follow-up practice chapter, there will be a section to do communication experiments, but everyone needs to master and understand the basic content. Otherwise, in the later experiments, everyone may not know what the blogger is doing (although I will try to talk about it later) Be more specific). Therefore, these chapters in BSW may be more bitter and difficult to understand, but I hope that everyone can browse through them patiently and have a general impression in their minds. It will be much easier to look back at the follow-up experimental class
Module details:
- COM: The data transmitted from the application layer first enters here. The application layer does not need to care about the bus through which the sent and received data is transmitted. The application only needs to transmit it to COM. These sent and received data are already defined by the user's DBC file or ARXML file (these files are generally made by the OEM when the vehicle is designed. What bus should be taken is defined, so the application layer does not need to care, it only needs to exchange data with COM gracefully). Similarly, the data uploaded by COM is also very simple data. There is no meaningless information about what kind of data is uploaded by the bus. The application layer cares about the actual meaning and data size of the data. So COM mainly plays the role of a signal interface and gateway.
- PDU Router : PDU------Protocol DataUnit, protocol data unit. The function of this module is to distribute the signal data sent by COM to the corresponding protocol bus; or to convert different protocols into the same signal and upload it to COM.
- IPDU Mux: Used to parse some special protocols, such as CANFD or some user-defined protocols. It plays the role of a unified CAN ID and different signal layouts.
- CAN Tp: Packet data transmission and error detection, generally only used for diagnosis.
- CAN Interface: It has nothing to do with the hardware. What is related to the hardware is the work done by the following two Drivers. This Interface can mainly configure the transceiver queue; frame (FlexRay); manage the time-triggered bus schedule (LIN, FlexRay).
- CAN Driver: It is the driver package for the CAN module on the main chip in MCAL.
- Trcv Driver: Trcv --- the abbreviation of Transceiver, is the meaning of the transceiver driver. If it is an external CAN transceiver, Trcv will be used here
- Driver is the driver, not CAN Driver.
It feels so simple to list the above terms, maybe you still can’t understand, the following is an explanation of the simple sending and receiving process (CAN is too huge, I can’t finish it here for a while, so I will use the simplest way to explain it. one time)
2. Sending process
- 1. The application layer sends a data into COM
- 2. COM write signal into PDU Buffer
- 3. PDU is PDU
The Router sends immediately or periodically (each PDU has an independent ID), and then the PDU
Router identifies the bus type and sends the PDU to different lower-level modules
- 4. Interface writes messages into different queues according to different channels
- 5. Driver sends the message immediately according to the priority of the message
3. Receiving process
Interrupt or cyclic reception (here assumed to be interrupt):
- 1. The hardware receives the message
- 2. The Rx interrupt (function) is issued by the Driver, and then the data is passed to the Interface through the RxIndication
- 3. Pass to PDU Router
- 4. Pass to COM (if SWCs use Data
- ReceptionTrigger, notify RTE; otherwise temporarily store in Buffer)
- 5. The signal is read by RTE and then read by the application layer