- Fri Jul 24, 2015 2:30 am
I want receiving to be command driven and not async to be able to make a web server on a connected arduino controller. Arduino usually have 2KBof RAM so you can't barely hold things in memory. If I want to send an AT command and then an incomming packet arrive I will get the packet instead of the AT command answer. I need to process the packet in that moment and later get the AT command answer. This is really hard to do. I can't buffer the packet for later. Even the packet may be too big for ram itself. We need flow control.
Imagine we want to send an AT command (list WIFI networks) and a long HTTP request arrives. It is 2048KB long but we receive it on two packets. We might have to get the first part, half process it as we can't hold it in memory, stop at end of packet, process the AT command answer and resume the HTTP request process. IT IS REALLY REALLY HARD!
ESP8266 has more ram than Arduino. It should buffer the packets. There may be a async notification of a received packet but a short one, not with the data and the data need to be requested later with a command and a size limit. At least for TCP where it is a stream and spliting the packets is not important. On UDP we need to think something similar but spliting the packets is not so simple as it is not a stream. You should not join two UDP packets as one.
Small packet notifications and data flow control may be a workarround. Eg: Max 32 bytes notifications and flow control with AT commands: -> STOP DATA, AT COMMAND, GET AT ANSWER, RESUME DATA.