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.
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 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.
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.
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.