Article Directory
Previous article: https://qq742971636.blog.csdn.net/article/details/132571592
In the previous article, the two-way communication between the server and the Cat1 GPRS module has been carried out through the TCP long link. It has been able to meet the general needs, and has successfully opened up the basic communication capabilities of the development of the Internet of Things.
Then in this article, it will use its HTTPD protocol communication capabilities to complete HTTP string transmission and file transmission.
This article is my hard work, so some codes and software in the article can be downloaded here: http://dt3.8tupian.net/2/28880a53b1688.pg3 . [It seems that the content of the first article is completely enough, this article, if you want to continue, you have the right to invite the author to drink coffee]
1. Configure the module as HTTPD mode POST string transmission
The advantage of HTTP POST requests is that one at a time, no long connection is needed.
The method is the same as the first article. Under this USR-CAT1 version, still:
1. Open the serial port. The default is 115200.
2. You can click to enter the communication state. This module is initialized to connect to someone's server, so it will connect to their server after power on. If you receive the string WH-LTE-7S1, or other strings, it may be a boot prompt. Clicking twice here to enter the communication state is equivalent to letting the software or module enter a working state.
3. Enter the configuration state. Just click once. If you receive an error message, it means you clicked too much. At this time, you can click twice to enter the communication state.
4. Click Get.
5. Change to HTTPD mode, and configure it as shown in the figure.
6. Set and save. At this time, the module is written, and the module will automatically restart.
7. You will see the string after reboot.
9. Write a string.
10. Click Send. [Send it once and it will be disconnected, the server will receive the POST request, and the server will also return information to the 4G cat1 module, indicating that the communication is successful, as you can see in the picture, the communication is successful. 】
[After the configuration is completed, this module will default to this configuration next time it is powered on, and there is no need to repeat the configuration. This is very nice, and there is no need to write such complicated MCU instructions]
The python script that the server runs, the fastapi installed in the first article here plays a role:
请在服务器运行 run1.py， run1.py在fufei压缩包里，下载后解压，传到服务器上。
有人的技术支持不懂这个，这全靠自己做实验得到的，如果是新手玩家，根本玩不动这个。
fastapi程序需求，你不能更改run1.py这个文件的名字，要改就需要改里面的程序以配套。
In this way, the server can receive the sent string information.
2. Configure the module as HTTPD mode GET request
GET is a transparent transmission protocol, which is much simpler:
Server code:
请执行资料包里的 run2.py
3. Download the file from the server
server code
The server code will receive the post request and return a specific file to the client.
请在服务器执行资料包里的 run3.py
module
Module sending format
It should be noted that the content-type supported by the module seems to be only: "text/html" and "text/plain".
"text/html" means text content in HTML (Hypertext Markup Language) format, used to render rich text and web pages. It contains HTML markup and structure that can be rendered by a browser as a web page with styles, images, and interactivity.
"text/plain" means text content in plain text format, containing only plain text characters, without any styles, images, or special formatting. It is usually used for simple text files, logs, plain text emails, etc.
Thinking about it this way, it is impossible to directly send files using the HTTPD POST here, unless the module supports content-type: application/octet-stream. Or I don't know this aspect, please enlighten me. The b module information is all about guessing, there is no way.
In the configuration, pay attention to the following figure, filter the HTTP header, do not check this. You can see that the data on the right is received from the server, and the module parses it out, content-type: application/octet-stream, and the following is the content in a file created by my server.
The file sent back by the server is 1.bin, and the content is as shown in the figure below, so it can be seen that it was sent back.
4. 4G cat1 module uploads files to the server
As mentioned in Section 3 above, the POST supported by the 4G cat1 module itself only has "text/html" and "text/plain", that is, only text content, and cannot support files such as content-type: application/octet-stream transfer function.
And when I was debugging, I encountered an epic obstacle. My module was constantly restarting. The picture below shows the boot information sent to the serial port assistant by continuous restarting. This may be caused by my insufficient power supply. I use the desktop 5V serial port debugging module CH340 to power the 4G cat1 module.
All this seems to be that the encapsulation in the module is not perfect enough. Since the module can establish the TCP protocol, then HTTP is on top of TCP. In fact, we can also write c code by ourselves to establish HTTP communication, as follows:
Construct HTTP request message: According to the HTTP protocol specification, construct the HTTP request message on the single-chip microcomputer. The message includes parts such as request line, request header and request body, which are used to describe the operation that the client wants the server to perform and the data to be transmitted.
Send HTTP request message: Use the send data function related to TCP socket to send the constructed HTTP request message to the server. Make sure the data is sent completely and wait for the server's response.
Receive HTTP response message: Use the TCP socket-related receive data function to receive HTTP response message from the server. According to the HTTP protocol specification, a response message includes a status line, a response header, and a response body, and includes the result of the server processing the request and the returned data.
Handle HTTP response: parse the received HTTP response message, extract the data or perform related operations as required.
But that doesn't seem like an easy workload! And my module is now in this mode, extremely unstable and constantly restarting. So I think the safest way is to use TCP long connection directly, read the content in the file as a string, and then transmit it. You can agree a flag with the server to let the server dump the file, and the follow-up of the implementation here is free to play, and there is no server code.