I *may* attempt to do this "binary socket tunnel" interface initially as a wrapper for a couple of the AT+ commands,Īs a proof of concept, but i'm concerned that could end up wasting a lot of time. If there's no way to get PPP/SLIP running without compiling my own ESP8266 firmware, Which would need only a very minimal, lightweight 'C' API library on the external MCU to replicate the socket API to my application.
To that end what i imagine as an ideal solution for me is a kind of binary socket tunnel through the serial link, Longer term i'd prefer to avoid the duplication of IP stacks and use only the one on the ESP8266 Using a couple of IO pins for handshaking / flow control might be useful for efficiency, but not really necessary. In this mode ESP8266 is essentially acting as a proxy/router. Ideally i would love to have an AT+ command to start PPP on the same uart (after some setup & switching to a higher baudrate)
Though connecting that cleanly into ESP8266' lwIP stack to route through would take more knowledge of lwIP & ESP8266 internals than i have or care to learn at this time. SLIP is so simple its 1 page of 'C' code, thus easy to port into any system, PPP is built-in to lwIP, so its reasonably safe to assume its supported (or can be) on ESP8266.
I'm thinking a fairly quick & easy short-term solution would be to use SLIP or PPP. If it doesn't work, try swapping them around) GPIO0 to ground (for the duration of firmware upgrading.
You need to hookup these pins from the ESP8266 to your USB<->Serial board: VCC to 3.3V GND to ground CHPD to 3.3V TXD to RX, RXD to TX (this may depend on the USB<->Serial board you are using.Hacking that to directly use AT+ commands instead would be a bad idea. Above is a pin out diagram for the ESP8266 Module. In my case i have a large codebase running on my host micro that's expecting a socket interface, and currently running on lwIP. I'm kinda in the same boat - looking for a better solution.