Research on the Design of Automobile Instrument Based on CAN Bus

Publisher:NatureLoverLatest update time:2010-06-29 Source: 电子设计工程Keywords:SAEJ1939 Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

The car instrument is the window for the car to communicate with the driver, and is the center of the car information. It can centrally, intuitively and quickly reflect the various dynamic indicators of the car during driving, such as driving speed, mileage, electrical system status, braking, pressure, engine speed, coolant temperature, oil level, and various danger alarms. With the advancement of science and technology, the performance of automobile emissions, energy saving, safety and comfort is constantly improving, and the degree of automobile electronic control is also getting higher and higher. The automobile electronic control device must process various information quickly and accurately, and display it through the instrument, so that the driver can understand and grasp the operating status of the car in time to properly handle various situations.

Here is a design of an automotive instrument based on the CAN (Controller Area Network) bus. The instrument uses the CAN bus to make it part of the vehicle body network and follows the SAE J1939 protocol to read information such as engine speed and water temperature. The instrument can also receive and display signals such as vehicle speed, fuel volume, oil pressure, and brake air pressure from sensors to provide the driver with real-time vehicle conditions. The designed instrument is mainly used in heavy-duty transport vehicles and other fields. The test results conducted in a heavy-duty vehicle factory show that the instrument can meet the requirements of data reliability and real-time performance.

1 CAN bus and SAE J1939 protocol

1.1 Introduction to CAN bus and SAE J1939 protocol

CAN bus belongs to the category of field bus. It is a serial communication network that effectively supports distributed control or real-time control and was developed by Bosch in Germany in the early 1980s to solve the data exchange between numerous control and test instruments in modern automobiles. The communication of CAN bus is highly real-time, and the data transmission rate can be as high as 1 Mb/s. The communication medium can be twisted pair, coaxial cable or optical fiber, and it can be easily connected through standard connectors. The data communication of CAN bus has outstanding reliability, real-time and flexibility, and is currently the most widely used automotive bus.

SAE J1939 is a vehicle network serial communication and control protocol published by the American Society of Automotive Engineers (SAE) with CAN2.0B as the core network protocol. J1939 is formulated with reference to the 7-layer benchmark reference model defined by ISO's open data interconnection model. The protocol clearly stipulates the address configuration, naming, communication method, and message sending priority of the ECU inside the car, and gives a detailed description of the communication of each specific ECU inside the car. It uses multiplexing technology to provide a standardized high-speed network connection based on the CAN bus for various sensors, actuators and controllers on the car, realizes high-speed data sharing between on-board electronic devices, effectively reduces the number of electronic wiring harnesses, improves the flexibility, reliability, maintainability and standardization of the vehicle's electronic control system, and gives full play to the excellent performance of CAN.

1.2 SAE J1939 data frame format

The SAE J1939 data frame is based on PDU (Protocol Data Unit), which consists of 7 fields: priority (P), reserved bit (R), data page (DP), PDU format (PF), PDU details (Ps), source address (SA) and data field (Date Field). The PDU other than the data field corresponds to the 29-bit identifier of the CAN extended frame. Among them, PS is an 8-bit segment, and its definition depends on the PF value. If the PF value is less than 240, PS is the target address (DA). If the PF value is between 240 and 255, PS is the group extension (GE).

Some CAN data frames are not defined in the PDU, including SOF, SRR, IDE, RTR, control field, CRC field, ACK field and EOF field. These fields are defined by CAN and are not modified by SAE J1939.

2 CAN bus automotive instrument design

2.1 Overall design of instrument

The automobile instrument system consists of three modules: data acquisition, processing and display. The data acquisition module is responsible for receiving various data of the vehicle and sending the data to the microprocessor after preprocessing. After the sensor signals such as analog signals, pulse signals and switch signals are collected at each sensor, they are sent to the microprocessor after voltage division, filtering and shaping, and photoelectric isolation. The CAN bus data such as engine speed, water temperature and fault code are sent to the CAN bus through the engine CAN module and received by the CAN transceiver. After receiving the required data, the microprocessor processes the data according to the predetermined algorithm and outputs the processing results. The display module includes the display of pointers, LCDs and various signal lights. The microprocessor outputs the results such as engine speed and vehicle speed to the motor driver, and the driver drives the stepper motor to rotate, thereby driving the pointer display; the microprocessor directly drives the LCD display and the LED lights to turn on and off. The structure of the automobile instrument system is shown in Figure 1.


According to the overall analysis of the car instrument panel, the car instrument panel consists of three sub-dials. The left sub-dial displays data such as engine speed and oil volume, the right sub-dial displays data such as vehicle speed and oil pressure, and the middle sub-dial is used to place the LCD display and various indicator lights. The instrument pointers are all driven by stepper motors. Among the various data received by the instrument, the engine speed, water temperature and voltage are obtained from the CAN bus, and the vehicle speed, oil volume, air pressure and oil pressure are obtained from various sensors.

2.2 System Hardware Design

The instrument uses Luminarv's LM3S2948 processor. This is a microprocessor based on the ARMCortexM3 core, using 32-bit RISC, embedded with CAN controller, analog-to-digital converter (ADC), analog comparator and other functional modules, reducing peripheral circuits and reducing system design costs. The built-in CAN module of the LM3S2948 processor facilitates the transmission of CAN bus data, while making the communication of the instrument easy to implement and improving reliability. Its built-in CAN module has the following features: supports CAN 2.0B protocol and supports message transmission of extended frames that comply with the SAE J1939 protocol: the bit rate can be as high as 1 Mb/s; has 32 message objects, each with its own identifier mask code; contains maskable interrupts, and for time-triggered CAN (1TrCAN) applications, the automatic retransmission mode can be disabled; seamlessly connected to the external CAN PHY through the CANOTx and CANORx pins; has programmable F1F0 mode.

The LM3S2948 microprocessor has the characteristics of fast computing speed, low power consumption, small size and low price. Its CAN controller module characteristics fully meet the application requirements of CAN bus automotive instruments. The processor has powerful processing capabilities and can reflect vehicle information in real time under various vehicle working conditions. At the same time, the processor has a large scalability space, which is conducive to subsequent development.

Since the LM3S2948 has a built-in CAN controller module, only an external CAN transceiver is needed to receive bus data. This instrument uses CTM8251T as the CAN transceiver. CTM8251T is a universal CAN transceiver with isolation. The device integrates all necessary CAN isolation and CAN transceivers. The device can be connected to any CAN protocol controller to realize the transceiver and isolation functions of the CAN node. The device is designed with a small size and high integration. It can replace the traditional CAN transceiver and its peripheral circuits, reduce the complexity of the circuit, and reduce the design cost, as shown in Figure 2.


The instrument uses VID6606 driver to drive the stepper motor. Each VID6606 can drive 4 stepper motors at the same time. By inputting pulse sequence F(SCX) at its frequency control end, the output end can be controlled to make the output shaft of the stepper motor rotate in microsteps. Each microstep motor output shaft rotates 1/12(°), and the maximum angular velocity can reach 600(°)/s. The motor driver has the following characteristics: hardware microstep drive, simple and easy to use, the motor only needs two control ends: speed F(sex) and direction (CW/CCW), all input pins have interference filters, wide working voltage, and low electromagnetic interference radiation. The instrument panel pointer is driven by VID-29 motor, which has a built-in gear system with a reduction ratio of 180/1, which can directly and accurately convert digital signals into analog display output. The motor has high display accuracy, and its minimum step angle can reach 1/2(°). Figure 3 shows the VID6606 driving instrument circuit.


The instrument uses LCD to display time, fuel consumption and fault name when a fault occurs. The signal sent by the processor is first amplified by 74HC245 power amplifier and then sent to the LCD screen F2000LCD for display. The LCD circuit is shown in Figure 4.

2.3 System software design

The system software design is divided into four modules: main program, CAN communication, data acquisition and processing, and data display. The main program module processes data by calling each sub-module program: the CAN communication module is responsible for sending and receiving data; the data acquisition and processing module completes the collection and calculation of various types of data; the data display module displays information such as vehicle speed, oil pressure, and signal lights on the instrument.


Figure 5 is the main program flow of the system, which is divided into: 1) System initialization. System initialization mainly includes initializing the system clock, CAN node, LCD screen, stepper motor, etc., enabling CAN interrupt, setting CAN mask code and acceptance code. CAN node initialization mainly initializes the CAN controller and interrupts the CAN controller: 2) Read sensor and CAN bus data, drive pointer and LCD display, and wait for CAN receive interrupt. 3) CAN receive interrupt is generated, enter the receive interrupt subroutine to read data. Determine whether the data meets the data reception conditions. If it does, receive the data. This process compares the received 29-bit identifier with the acceptance code and mask code bit by bit. Only when the corresponding bit of the identifier is the same as the corresponding bit of the acceptance code, the system starts to receive data. 4) The processor parses the received message, extracts the required data and processes it. The processor processes and calculates the data sent by the sensor and the data read by the CAN bus, obtains the corresponding pointer drive parameters, calculates the pointer rotation angle, and calculates the pointer rotation speed according to the parameters of the initialized stepper motor. The pointer rotation speed is proportional to the corresponding parameter change speed. At the same time, the vehicle mileage is calculated and accumulated to the total distance. 5) The processor sends a set of pulse sequences containing the vehicle operating conditions to the stepper motor driver, and the driver drives the stepper motor to rotate in microsteps, indicating the corresponding engine speed, vehicle speed, water temperature and oil pressure, etc.; the processor sends data containing information such as the total distance of the vehicle to the LCD controller, and the controller controls the LCD to display the corresponding total distance, etc.: the processor changes the corresponding I/O pin status to directly light up/turn off the corresponding indicator light.

2.4 Fault Display

The instrument can receive fault codes from the CAN bus and parse the fault codes. After comparing with the pre-written fault codes, it finds the corresponding fault information and displays it on the LCD screen. Each type of data has a specific data frame ID, and the system determines the location of the fault based on the frame ID. If a single-frame fault is received, the system extracts the total number of bytes and the total number of packets; if a multi-frame fault is received, the system continuously extracts the fault diagnosis message to a specific byte, and then finds the fault type based on the fault code.

3 Conclusion

Based on the study of CAN bus and SAE J1939 protocol, a CAN bus automotive instrument is designed. This design makes full use of the functions of LM3S2948 and VID6606, greatly reducing the design and cost of the system's peripheral circuits. The results of multiple real vehicle tests show that compared with conventional instruments, this CAN bus instrument has the following advantages: strong anti-interference ability, high transmission rate, and can ensure effective, fast and stable data transmission; reduce body wiring, implement hardware solutions in software, simplify design and reduce costs; timely and intuitively check vehicle faults; CAN bus makes the entire vehicle a network system, which can improve the flexibility of the system, easily add equipment, and expand the space for development.

Keywords:SAEJ1939 Reference address:Research on the Design of Automobile Instrument Based on CAN Bus

Previous article:Design of a vehicle-mounted infrared night vision device based on PIC microcontroller
Next article:Application of PIC microcontroller in automobile electric window controller

Latest Microcontroller Articles
  • Download from the Internet--ARM Getting Started Notes
    A brief introduction: From today on, the ARM notebook of the rookie is open, and it can be regarded as a place to store these notes. Why publish it? Maybe you are interested in it. In fact, the reason for these notes is ...
  • Learn ARM development(22)
    Turning off and on interrupts Interrupts are an efficient dialogue mechanism, but sometimes you don't want to interrupt the program while it is running. For example, when you are printing something, the program suddenly interrupts and another ...
  • Learn ARM development(21)
    First, declare the task pointer, because it will be used later. Task pointer volatile TASK_TCB* volatile g_pCurrentTask = NULL;volatile TASK_TCB* vol ...
  • Learn ARM development(20)
    With the previous Tick interrupt, the basic task switching conditions are ready. However, this "easterly" is also difficult to understand. Only through continuous practice can we understand it. ...
  • Learn ARM development(19)
    After many days of hard work, I finally got the interrupt working. But in order to allow RTOS to use timer interrupts, what kind of interrupts can be implemented in S3C44B0? There are two methods in S3C44B0. ...
  • Learn ARM development(14)
  • Learn ARM development(15)
  • Learn ARM development(16)
  • Learn ARM development(17)
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号