1. Using AT commands and standard firmware.
I have the standard component in our firmware that can manage sockets through AT commands and expose them to loopback nif. So other parts of firmware can open socket on the loopback adapter and use it exactly in a way as in the case of other transports (Ethernet, USB). The weak points of this approach are using two sockets per connection instead of one socket on other nifs and impossibility to implement SSDP protocol for device because it need to send multicast UDP to 239.255.255.250 address and it seems that sending multicast UDP is impossible with AT commands. Also it seems that standard firmware do not supports any type of handshake on UART so the channel overflow may occurs. Also the problem of standard firmware is that receiving strings "\x11[12]" and "[11]\x12" translates to +IPD,X,5:[11][12] in the both cases.
2. Create the custom ESP8266 firmware with PPP or SLIP implementation (IP packets transfer).
This is more preferrable way than using AT commands. We have the PPP implementation already, the SLIP implementation is trivial. So the main question is how to route the IP packets from SLIP to WiFi? It is definitely impossible with espconn_* function. Is there any possibilities?
3. Create the custom ESP8266 firmware with SILP like protocol for MAC packet transfer.
The most preferrable way, because it is not need to routing implementation. So we need simple receive MAC packet from the main processor and send it to WiFi. But is the MAC level API accessible to end users?
So which of this three ways is easier to implement on ESP8266?Statistics: Posted by AndrewD — Wed Nov 19, 2014 10:22 pm
]]>