12
Return list

931

Posts

3

Resources
21
 
    I started debugging the serial port receiving program on September 18th, copying and printing sample codes, analyzing and debugging, but I still couldn't figure out how to receive serial port data after several days of hard work. Then I turned to debugging SPI, copying and printing sample codes as usual, and searching for other people's experience in the forum. Another two or three days passed, but I still achieved nothing. Finally, I had to write code to simulate SPI reception by myself, which took several days and made slow progress. During this period, the nmg moderator took the initiative to ask about the progress of the project. After knowing my predicament, he encouraged me to post for help. The moderator also invited everyone to help in the group, and many enthusiastic forum friends helped to give ideas and find solutions. With everyone's help, after two days of debugging, I finally successfully received the data sent by the 51 microcontroller. This may not even be a piece of cake for many forum friends, but it is undoubtedly like climbing a snowy mountain for a beginner like me. The main experience I learned is that you can't write all the code at once. You should debug a part while writing it, and then continue to write the next step of the code after completion. Only by proceeding step by step can you debug and troubleshoot. However, I didn't have enough experience, and I wrote a lot of code and then debugged it. It was very difficult to view the code on the limited screen, and I was confused in the end.

This post is from GD32 MCU
 

931

Posts

3

Resources
22
 
    Yesterday, I completed the debugging of the software simulation SPI communication module and successfully received the data sent by the 51 single-chip microcomputer. Then I started to debug the code of the control module. The code of the control module was written when the debugging of the communication was not going smoothly. In order to change my mood and relieve my brain thinking, I temporarily put aside the debugging of the communication. Now that the SPI communication is basically completed, it is natural to debug the code of the control module. The first thing is to convert the received character information into a numerical value. This problem, which is not complicated in itself, took me about two hours to complete. Then the simulated water level chart (left side of the screen) is used. This is based on the total height of the instrument installation height (the value displayed in the upper left corner of the screen) and displays the bar chart according to the current water level. The algorithm is to divide the current water level by the installation height and then multiply it by 48 (that is, the screen column dot matrix) to get the number of points to be displayed. When I was debugging, this value was always 0, and I was puzzled. Later, I realized that I should multiply first and then divide, because the result of the first division is a decimal less than 1. The variable type I defined is an unsigned integer, so the intermediate value is zero. Finally, I changed to multiply first and then divide to achieve the purpose. The debugging of the control module is relatively easy, and the code was basically written before, so it was successfully completed in more than a day. Now most of the whole project has been completed. The unit control circuit in the machine room was completed two years ago. At that time, a WIFI relay group was used. Through the Internet, the water inlet valve can be adjusted to open or close, the unit can be started or shut down remotely with a mobile phone. Now just add this automatic control part. Here are a few photos: This is the scene of the main control module debugging: This is the display screen. The leftmost is a simulation display of the current water level. The upper left corner shows the height of the ultrasonic detection instrument. The lower left corner shows the lowest water level 0m. The current water level is displayed in the middle. The normal water level is displayed in the middle. The high water level and the super high water level are displayed at the top, and the low water level and the super low water level are displayed at the bottom. At the same time, Chinese characters will be displayed in the middle right position of the screen. There is no output control operation at normal water level. At low water level, LED2 will go out for about one second (pulling down the signal), and at ultra-low water level, it will go out for about two seconds (controlling the water inlet valve to close for a longer time). The control principle of high water level and ultra-high water level is the same, but it controls LED3. When used on site, you only need to connect these two pins to the corresponding intermediate relay. When debugging SPI communication, in order to eliminate the problem of Dupont line, the connection wire was directly soldered from the pin strip so that the logic analyzer could take the signal, so a small pin grew on the development board. Now that the debugging is completed, this small pin should be cut off. The following is the development board with the small pin removed: In order to facilitate on-site debugging, I specially found a small box to give the development board a home. The development board, auxiliary board, and screen are all in place, and now have a temporary home. However, because the box is not transparent, the screen is a little blurry, so we will just use it for now.

主控制模块调试完成6.jpg (243.38 KB, downloads: 0)

主控制模块调试完成6.jpg
This post is from GD32 MCU
 
 
 

931

Posts

3

Resources
23
 
    Today is the National Day. The main functions of the project have been basically completed. I started to improve and optimize it. I referred to the posts of teachers such as ljj3166 and tinnu, carefully checked and adjusted my serial port receiving code, and finally I was able to receive serial port data smoothly. The next step is to see if the receiving function of SPI1 can be debugged well, and strive to complete the debugging of wireless communication.
This post is from GD32 MCU
 
 
 

931

Posts

3

Resources
24
 
The project is basically completed. It took me 4-5 days to organize photos, write a project summary, and record videos. I finally submitted the work today.
This post is from GD32 MCU
 
 
 

606

Posts

20

Resources
25
 
Learn from you...
This post is from GD32 MCU

Comments

I’m still in the process of getting started and need to learn from all of you!  Details Published on 2018-11-6 15:25
 
 
 

5

Posts

0

Resources
26
 
Tribute to veteran engineers
This post is from GD32 MCU

Comments

Thank you! Please advise me.  Details Published on 2018-11-6 15:25
 
 
 

931

Posts

3

Resources
27
 
I am still in the process of getting started and still need to learn from all of you!
This post is from GD32 MCU
 
 
 

931

Posts

3

Resources
28
 
Posted by Zhang Dengke on 2018-11-6 15:03 Tribute to the old engineers
Thank you! Please give me more advice.
This post is from GD32 MCU
 
 
 

12
Return list
Guess Your Favourite
Find a datasheet?

EEWorld Datasheet Technical Support

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews

Room 1530, Zhongguancun MOOC Times Building, Block B, 18 Zhongguancun Street, Haidian District, Beijing 100190, China Tel:(010)82350740 Postcode:100190

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号
快速回复 返回顶部 Return list