There are many chips with the ESP8266, but the most popular ESP-01 only has two GPIO inputs. Others have more, but sometimes even this is not enough. I was thinking of creating a universal program for ESP to mediate between the computer network and other chips having RS (especially ATMEGA). I am asking for your pins, comments on the concept. Criticism of the concept also welcome 
Concept description:
The ESP when first switched on and after pressing the Config button (button connected to GPIO0) enters AP mode and starts up as a server running on TCP/IP, it also switches on DHCP. The AP has a fixed name and a fixed password - only one device can be configured at a time. After logging into this AP (e.g. using a smartphone) and connecting via its browser to the IP address of the ESP server (fixed address), a simple page appears with the possibility of entering our WiFi network ID, password and IP address of the module (it will continue to act as a server – hence the fixed IP). After saving the configuration, the ESP restarts, connects to our network and starts to act as a kind of „tunnel” – that is, a universal data relay. Our controller accepts requests in the form of a GET in two forms – data request or data transfer. All transmitted data is encoded in HEX.
After receiving the data, it transmits it via Tx/Rx to our actual control module. The idea was to simplify the transmission as much as possible, so that when programming the ATMEGA (or other) processor afterwards, you don't have to bother too much about e.g. waiting times etc. Communication takes place at a fixed speed of 9600 in the following format (each entry is one byte):
1. length of data sent
2. sent data (as many bytes as in point 1)
3. CRC of the transmission (XOR of previously sent bytes).
The microcontroller also calculates the CRC when receiving data and sends the calculated CRC back after reading all bytes:
4. sending the calculated CRC, if it differs from the received CRC it is the end of the transmission,
5. sending the number of response bytes (data length),
6. sending data (as many bytes as in point 5),
7. sending CRC (analogous as before),
8. end of transmission.
ESP operation:
After receiving a CRC (point 4) different from the one sent, it sends a reply to the client:
CRC1=xx
(where xx is the HEX of the CRC sent in point 4) – generally indicates an error, the CRC value can serve as a debug.
After receiving a CRC (point 7) different from the calculated one, it sends a response to the client:
CRC2=xx
(where xx is the HEX of the CRC sent in point 7) – generally indicates an error, the CRC value can serve as a debug.
In case of a CRC match, ESP sends:
DATA=xxxxxxxx...
i.e. received data encoded in HEX.
As you can see, ESP programmed in this way is a universal communication module allowing up to 255 bytes to be sent to the microcontroller at one time and up to 255 bytes to be read, while the number of bytes sent and received can be zero (e.g. only reading device status). The microcontroller should accept and send data at the full 9600 speed, so when sending the status of devices that need to wait for a long time, it should query them in a loop, and send the last memorised data from its cache. Of course, reading the states of inputs or the ADC can be done on the fly.
The interpretation of the meaning of the bytes is handled by the program sending the requests, e.g. a PHP script or directly by the browser (via an invisible IFRAME), and on the other hand by a program in the microcontroller.
The circuit was conceived for home use, i.e. assuming that only trusted computers are on our WiFi network. Otherwise, you would have to think about some kind of authorisation or signing of requests. The simplest solution is to add some kind of password in the configuration (described at the beginning). The computer sending the request to the ESP always sends this password as well
Please give me your opinion – maybe someone has created something like this?
Concept description:
The ESP when first switched on and after pressing the Config button (button connected to GPIO0) enters AP mode and starts up as a server running on TCP/IP, it also switches on DHCP. The AP has a fixed name and a fixed password - only one device can be configured at a time. After logging into this AP (e.g. using a smartphone) and connecting via its browser to the IP address of the ESP server (fixed address), a simple page appears with the possibility of entering our WiFi network ID, password and IP address of the module (it will continue to act as a server – hence the fixed IP). After saving the configuration, the ESP restarts, connects to our network and starts to act as a kind of „tunnel” – that is, a universal data relay. Our controller accepts requests in the form of a GET in two forms – data request or data transfer. All transmitted data is encoded in HEX.
After receiving the data, it transmits it via Tx/Rx to our actual control module. The idea was to simplify the transmission as much as possible, so that when programming the ATMEGA (or other) processor afterwards, you don't have to bother too much about e.g. waiting times etc. Communication takes place at a fixed speed of 9600 in the following format (each entry is one byte):
1. length of data sent
2. sent data (as many bytes as in point 1)
3. CRC of the transmission (XOR of previously sent bytes).
The microcontroller also calculates the CRC when receiving data and sends the calculated CRC back after reading all bytes:
4. sending the calculated CRC, if it differs from the received CRC it is the end of the transmission,
5. sending the number of response bytes (data length),
6. sending data (as many bytes as in point 5),
7. sending CRC (analogous as before),
8. end of transmission.
ESP operation:
After receiving a CRC (point 4) different from the one sent, it sends a reply to the client:
CRC1=xx
(where xx is the HEX of the CRC sent in point 4) – generally indicates an error, the CRC value can serve as a debug.
After receiving a CRC (point 7) different from the calculated one, it sends a response to the client:
CRC2=xx
(where xx is the HEX of the CRC sent in point 7) – generally indicates an error, the CRC value can serve as a debug.
In case of a CRC match, ESP sends:
DATA=xxxxxxxx...
i.e. received data encoded in HEX.
As you can see, ESP programmed in this way is a universal communication module allowing up to 255 bytes to be sent to the microcontroller at one time and up to 255 bytes to be read, while the number of bytes sent and received can be zero (e.g. only reading device status). The microcontroller should accept and send data at the full 9600 speed, so when sending the status of devices that need to wait for a long time, it should query them in a loop, and send the last memorised data from its cache. Of course, reading the states of inputs or the ADC can be done on the fly.
The interpretation of the meaning of the bytes is handled by the program sending the requests, e.g. a PHP script or directly by the browser (via an invisible IFRAME), and on the other hand by a program in the microcontroller.
The circuit was conceived for home use, i.e. assuming that only trusted computers are on our WiFi network. Otherwise, you would have to think about some kind of authorisation or signing of requests. The simplest solution is to add some kind of password in the configuration (described at the beginning). The computer sending the request to the ESP always sends this password as well
Please give me your opinion – maybe someone has created something like this?
