Operating the STM32 with ESP32 WiFi from a browser
Nucleo (STM32) is converted to wireless (WiFi) using the ESP32 wireless module and configured as a web server. We will introduce an application that remotely operates MCU by sending a string of command codes from a web browser on a client PC or smartphone. The details of setting up the ESP32 and browser and sending/receiving commands are explained in "Remote Remote control of WiFi enabled STM32Nucleo with ESP32 using a browser".
Table of contents
Points to keep in mind when configuring a web server
The basic program structure is similar to that of the "TCP communication (WiFi) receive of STM32 with ESP32" but you need to be aware of the peculiarities that are unique to receiving ESP32 using the HTTP protocol.
If the basic configuration of the program remained almost the same as in the case of TCP communication in response to the change in communication conditions from TCP to HTTP, but only the server port number and protocol format were changed, HTTP communication from the browser to the web-serverized ESP32 did not work, although it worked properly from the terminal.
At first glance, sending code from terminal software on a PC or smartphone to STM32 using the TCP protocol and sending code from a web browser to STM32 using the HTTP protocol seem almost identical, but they do not work without understanding how they work because the behavior of ESP32 in the middle is quite different.
The differences can be summarized as follows
- In the HTTP communication protocol from a web browser, ESP32 returns a response even if you just open or close the browser.
- Giving commands from a browser is to attach the command to the IP address (IP address/command code), so the connection is closed or connected each time. Therefore, a response (0,CLOSED/0,CONNECT) is also appended each time.
- Even if you just send a little code, the response string is quite long. (The area circled in red below)
- The longer the response string, the larger the waiting time before and after the AT command.
In other words, when a character code is sent from a browser, ESP32 returns more responses than expected, so MCU side will receive many things at unexpected times if it is not anticipated in advance. This can sometimes be the cause of a freeze.
Once we understood that this was the case (a feature of the HTTP protocol), I could deal with the problem. However, since I did not understand the cause at first, it took us quite some time to solve the problem and achieve stable communication.
Below are some tips on how to make ESP32 send character codes stably with the HTTP communication protocol.
Program Structure
The receive configuration can be the same as for TCP communication, but the sample application uses interrupt reception, and an LED is lit to indicate when an interrupt is received.
If reception occurs at an indeterminate timing, it is more reliable to use interrupts than by polling. We tried the polling method, but could not obtain stable operation.
The feature of this application is to initialize the USART and clear the registers once every time an interrupt occurs and the receive process is performed. Although there are many ways to clear the registers, here, in order to achieve the most elementary and simple clearing, the reset functions are grouped together and executed as shown below.
By performing a reset process on every reception, communication errors were cleared and operation was stabilized. Now that processing can be branched by code from the browser, it can be developed into a variety of remote applications.
If an IP address containing various codes is pasted as a link on an HTML page, the codes will be transferred from the browser to the microcontroller side when it is clicked.
ESP32 HTTP (WiFi receiving version)
This time, I introduced a sample that uses the HTTP communication protocol to perform simple code reception, which is done via TCP communication. I think this is sufficient for a small remote operation.
However, it is also true that using the HTTP communication protocol with AT commands is troublesome due to the need to specify the character code length and other restrictions. If you want to develop HTTP communication with ESP32 in earnest, you can use transparent mode to communicate seamlessly with MCU side without AT commands, so please try it if you want to develop it further.