If the article is an original article, please indicate the source of the original article when reprinting it.
The blog address of this article: https://hpzwl.blog.csdn.net/article/details/132869448

The collection of red fat man’s network technology blog posts: a collection of development technologies (including Qt practical technology, Raspberry Pi, 3D, OpenCV, OpenGL, ffmpeg, OSG, microcontroller, software and hardware combination, etc.) is being continuously updated...

Rockchip Development Column

Previous article: " RK3568 Development Notes (8): Burn the buildroot firmware on the development board (supports HDMI screen), build a Qt cross-compilation development environment, compile a Demo, and run the Demo test on the target board" Next article: Stay tuned
...

Preface

Qt has been transplanted in the previous article. Now it is not a problem for us to transplant the entire application. Now the external interface of the application uses the RS485 interface, and there is an RS485 onboard, so it needs to be adjusted to be compatible with the RS485 of this development board.

Replenish

It seems very simple, but if you don’t understand how to do it, you just don’t understand. Even if you understand, you still need to spend time to study the characteristics of the development board, communicate with the manufacturer, and change the code. Thanks to the previous use of HI3559DV300 to do similar RS485, so this It didn't take much trouble to get it done.

Tuning through RS485 process

Step 1: Connect the RS485 debugging equipment to the development board

First, you must have an RS485 debug converter to USB, so that you can debug. For the limit, the author needs the RS422/485 port of GreenLink, as shown below:
Insert image description here

Development board 485 port schematic diagram:
Insert image description here

So I connected the wiring. By the way, this hole is a 2.54mm 4dip dip connector. Hardware manufacturers usually keep some stock of this. It is a universal interface. Back then, they had a little stock of various types:
Insert image description here

Cut one half of one, and then connect it in the order of adding plug-ins. Because pins 1 and 4 are the ground of China Unicom, the multimeter measured the connection to the copper layer (GND), and pins 1 and 4 were directly connected together. , then connect A to correspond to T/R+, and B to correspond to T/R-, as shown below:
Insert image description here

Access to open meal:
Insert image description here

The other USB end is connected to the PC and can be opened with the serial port (PS: the 485 USB module is a serial port for the PC).

Step 2: Open the development board RS485 debugging tool

Here, because of the buildroot used by the development board, there is really no device similar to the serial port to open RS485. Thanks to the author's project research and development, phased debugging tools will be produced, so the following tools are available (PS: There is an official RS485 To debug Qt demo, readers can use the official one):
Insert image description here

(By the way, there is also cross-compilation and transplantation of related tools here. In fact, it is similar to compilation under x86. I won’t go into details. If you don’t know, you can check out the "RK3568 Development Notes (8): Burn the buildroot firmware on the development board (supports HDMI screen), build Qt cross-compile development environment, compile a demo, run the demo test on the target board, and the demo compilation process is actually the same.

Step 3: The debugging tool polls and receives the test port 485

Because the debugging tool passively receives 485 data, after opening 485 on the PC, it will be sent once every 1 second, and each port will be opened in turn to test which port 485 will try.
Insert image description here
Then, it turned out that every test failed, and then I became suspicious:

If the positive and negative wires of test AB are connected reversely , you can directly exchange them, test them once, or check them once.
Is the Rs485 port special and needs to be pulled up and down by yourself (official verification here, the default is pulled up, it can only send out but not receive)
(PS: Through customer service technical support, the port is ttyS7, and needs to be pulled up and down, the default is pull-up, send only)

So I added a button and sent it directly to test:
Insert image description here

The PC received the message sent:
Insert image description here

Confirmed, it needs to be pulled up and down. At this time, check the official documentation and there is no description of the pull-down. It can only be extracted through the official Qtdemo of RS485.

Step 4: Extract the key pull-down logic code in the official QT debugging RS485 demo

Insert image description here

To directly extract the code, you usually use echo input to a device file, file to open the device file, or ioctl. Let me briefly mention the differences between these three methods (which method is provided in the development board plan):

Echo method : cmd method, use system in the program, and QProcess in qt. This method is relatively inefficient and is not suitable for frequent sending and receiving.
File mode : File mode is a file mode. It is compatible with Linux systems and the most suitable way for Qt development. It can be used as file writing control. It handles environmental issues very well. It is more efficient than echo and lower than ioctl, but 5ms is enough for hundreds of words. The section is switched after completion (specifically, the call should be sent according to the actual situation).
ioctl method : The ioctl method is not very good in Qt. In some cases, Qt does not need to contact the dependent libraries under sysroot at all. You can directly cross-compile your own library with Qt. This development board has been integrated ( PS: Like HiSilicon, you can only reverse qt into the sample, because the environment is configured by the makefile) The
above three have their own advantages and disadvantages, but in fact the choice is not with us, but with the motherboard solution provider , so take it and use it, as long as it works, don’t be stubborn.
The extraction code is as follows:

Insert image description here

Step 5: Transform our serial port code

Add a macro definition:
Insert image description here

Add relevant code in the serial device management module.
When opening, add the code:
Insert image description here

When sending, add the code:
Insert image description here

When closing, add code:
Insert image description here

After the modification is completed, cross-compile the protocol debugging tool to test it.

Step 6: Debugging and parsing successful

Open the application on the target board, open the corresponding serial port, and then achieve successful transmission and reception:
Insert image description here

summary

After the RS485 debugging is passed, and the debugging tools in large projects are also passed, the only thing left is to transplant the application. During the transplantation application, new problems are encountered (when doing embedded work, there are no problems on all wheels. In fact, there are problems one after another. One, if you’re lucky, it won’t be troublesome. If you’re not lucky, you’ll be stuck for a day or two. If you’re not lucky, it’ll be troublesome for a week or two. It’s common.)