Communication method between single chip microcomputer and eView touch screen under Modbus protocol

Publisher:翅膀小鹰Latest update time:2012-01-09 Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

The Modbus protocol has become the first choice of communication protocol in today's industrial field due to its openness, transparency, low cost and easy development.

This article introduces a communication method between the eView touch screen and the commonly used 51 single-chip microcomputer based on the Modbus communication protocol. This method realizes Modbus communication through C51 programming, is universal on the 51 series of single-chip microcomputers, and has a certain reference value.

In industrial control, it is often necessary to observe the operating status of the system or modify the operating parameters. The touch screen can intuitively and vividly display the operating parameters and operating status, and the system operating parameters can be directly modified through the touch screen, with good human-computer interaction. Single-chip microcomputers are widely used in the field of industrial control, and can form a good human-computer interaction environment in conjunction with touch screens.

For the touch screen to communicate with the microcontroller, it is necessary to write a corresponding communication program for the microcontroller according to the communication protocol used by the touch screen. The Modbus protocol is a protocol introduced by Modicon in the United States that effectively supports communication between controllers and between controllers and other devices via a network (such as Ethernet). This article takes the STC89C51 microcontroller and the eView touch screen of Human-Machine Electronics Co., Ltd. as examples to introduce the development process of its communication program.

1 System Structure

To achieve communication between the touch screen and the single-chip microcomputer, the main problem is to solve the communication protocol. This article uses the open Modbus communication protocol, with the touch screen as the master station and the single-chip microcomputer as the slave station. The eView touch screen itself supports the Modbus communication protocol. If the single-chip microcomputer also supports the Modbus protocol, communication can be carried out. The eView touch screen supports two communication interfaces, RS-232 and RS-485. In the field of industrial control, RS-485 has the advantages of high reliability, long transmission distance, and strong anti-interference ability. Therefore, in this system, the touch screen and the single-chip microcomputer communicate using RS-485 connection, and the transmission rate is set to 9600 kbps. RS-485 signal transmission is a half-duplex transmission mode. The single-chip microcomputer converts the 232 signal into a 485 signal through an RS-232/RS-485 passive converter and connects it to the eView touch screen. Figure 1 is the schematic diagram of the system.

System Schematic

The single-chip control system uses the STC89C51 series single-chip, which integrates the MAX810/STC810 ​​dedicated reset circuit (the original external reset can be retained and is compatible with the Intel 8051 pin). It has the characteristics of strong anti-interference ability, strong encryption, high anti-static (ESD), ultra-low power consumption, and low price. In this system, the touch screen is the upper computer and the single-chip is the lower computer.

2 Modbus protocol

2.1 Introduction to Modbus Protocol

Modbus protocol is a universal language used in electronic controllers. Through this protocol, controllers can communicate with each other and with other devices via a network (such as Ethernet). It has become a universal industrial standard. Control devices produced by different manufacturers can be connected to an industrial network through it for centralized monitoring.

The Modbus protocol defines a message structure that a controller can recognize and use, regardless of the network they communicate through. It describes the process of a controller requesting access to other devices, how to respond to requests from other devices, and how to detect and record errors; it establishes a common format for the message domain structure and content.

When communicating on a Modbus network, the protocol determines that each controller needs to know their device address, identify the message sent by the address, and decide what action to take. If a response is required, the controller will generate feedback information and send it using the Modbus protocol. On other networks, messages containing the Modbus protocol are converted to the frame or packet structure used on this network.

2.2 Modbus RTU communication data transmission mode

When the controller device communicates in RTU mode based on the Modbus protocol, each byte in the message contains two 4-bit hexadecimal characters. The main advantage of this method is that more data can be transmitted than the ASCII method at the same baud rate.

The encoding uses 8-bit binary, hexadecimal numbers 0 to 9 and A to F; each 8-bit field in the message is composed of 2 hexadecimal characters. The organizational structure is as follows:

Organizational Structure

2.3 Modbus RTU message frame structure

The Modbus RTU message frame structure is as follows:

Modbus RTU message frame structure

(1) Address code

The address code is the first byte of the communication transmission. This section indicates that the slave with the address code set by the user will receive the information sent by the host. Each slave has a unique address code. Only slaves that meet the address code can respond and return, and the response and return start with their respective address codes. The address code sent by the host indicates the address of the slave to be sent, and the address code sent by the slave indicates the address of the slave to be returned. Address 0 is used as a broadcast address so that all slave devices can recognize it.

(2) Function code

The function code is the second byte of the communication transmission. The Modbus communication protocol defines the possible code range as 1 to 255 in decimal. Of course, some codes are applicable to all controllers, some are only applicable to certain controllers, and some are reserved for future use. The host sends a request and tells the slave what action to perform through the function code; the slave responds to the request, and the function code sent by the slave is the same as the function code sent from the host, indicating that the slave has responded to the host to operate. If the highest bit of the function code sent by the slave is 1, it means that the slave has not responded to the operation or the transmission is wrong. After the master device application receives a response to the objection, the typical processing is to resend the message. Table 1 lists some of the function codes supported by common Modbus.

Some function codes supported by common Modbus

Take reading coil status as an example. The master sends the command: [device address] [command number 01] [starting register address high 8 bits] [low 8 bits] [number of registers to read high 8 bits] [low 8 bits] [low 8 bits of CRC check] [high 8 bits]. The slave responds: [device address] [command number 01] [number of bytes returned] [data 1] [data 2]… [data n] [low 8 bits of CRC check] [high 8 bits].

(3) Data area

The data area varies according to the function code. The data area contains what action the slave needs to perform, or the return information collected by the slave. This information can be actual values, set points, addresses sent by the host to the slave or by the slave to the host, etc. For example, if the function code tells the slave to read the value of a register, the data area must contain the starting address of the register to be read and the read length. For different slaves, the address and data information are different.

(4) Error Check Code

The host or slave can use the check code to determine whether the received information is wrong. The error detection field contains a 16-bit value (implemented by two 8-bit characters). The content of the error detection field is obtained by performing a "cyclic redundancy check" on the message content. The CRC field is attached to the end of the message, first the low byte and then the high byte, so the high byte of the CRC is the last byte of the message sent. Error checking uses the CRC-16 check method.

3 Software Programming

The following is the software written in C5l, which mainly includes CRC check, terminal reception and baud rate setting, etc. Due to limited space, other programs are omitted.

Software Programming

Software Programming

Software Programming

4 Conclusion

Since Modhus protocol has the characteristics of openness and transparency, and 51 series single-chip microcomputer technology is mature and has low development cost, the combination of the two will continue to be the first choice for various communication system designs. This design method has been applied to the communication design between touch screen and single-chip microcomputer, and has achieved good results. This method has a certain reference role in compiling similar communication software, and some programs can be directly transplanted.

Reference address:Communication method between single chip microcomputer and eView touch screen under Modbus protocol

Previous article:Voice and audio compression/decompression technology based on MSP430
Next article:Sensorless Field Oriented Control Using an 8-bit Microcontroller

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号