ESP8266 hardware I have doesn't have the flow control lines exposed. I need some mechanism to throttle incoming TCP data when my MCU is not ready to read it. Using xon/xoff is a possibility, but may not be ideal. I'm hoping to find an alternative solution.
The bulk of the AT commands consist of a request followed by a response, which has implicit flow control since you can send the next request when you are ready. The exception to this is the +IPD packet which can be sent at any time when you have an open connection. In the case of TCP, if the remote end sends data the device will keep receiving +IPD packets regardless if it wants to throttle the connection. If the device's buffers overflow then TCP data will be lost.
As a way to allow flow control and prevent overflow I was wondering if any of the following are feasible:
-Would it be feasible to add a new command to set the max amount of +IPD data that can be received, along with a command to indicate that the device is ready to receive more data?
-Alternatively, what about a mode where +IPD data is never sent and instead there is a new command the device issues to read data off of the device
Do either of these solutions seem reasonable to implement? Is this something that could by supported officially if a working version was made? Finally, do you have any tips on how I could attempt to make this change? I see there is an AT example in the ESP8266 SDK (ESP8266_NONOS_SDK\examples\at). Is this where the ESP8266 AT command firmware comes from? Is this the right starting point? Thanks in advance for the help.Statistics: Posted by c1728p9 — Sat Apr 14, 2018 7:04 am
]]>