Deprecated: outdated ESP8266 Mbed OS driver
Home Page: https://github.com/ARMmbed/mbed-os/tree/master/components/wifi/esp8266-driver
NOTE This driver has been deprecated and development continues in Mbed OS starting from the version 5.10
The last available release from this repository is v1.7.1. No new features or bugfixes is going to pushed on this repository and you should rely on the Mbed OS version solely.
New location: https://github.com/ARMmbed/mbed-os/tree/master/components/wifi/esp8266-driver
Normally, WiFi consumer device could support soft AP mode for user setting through smart phone or NB.
Moreover, ESP8266 firmware also could support WiFi soft AP mode by AT command.
Why ESP8266 interface not prefer to support this soft AP mode ?
There is now some timing issue most probably in the driver side. With following patch client gets stuck even the traces are disabled. With 5ms delay problem occurs every time, changing to 2ms client works fine.
[delay.zip]
Can someone in the driver side check this a bit more?
Cloned from ARMmbed/mbed-os-example-client#223.
Check the last comment from the above issue.
I run Device Identity flow using WiFI interface (esp8266 driver). We have some big certificate which should arrive from Identity Server. It's network packet size is relatively big (above 1500 bytes). This packet is disappeared. All over packets were sent/received successfully.
The same code runs perfect with Ethernet interface.
I tryed to get the ESP library working with active uVisor, but it stuck after sending a reset to the module. During measurements on the portpins of the MCU I only saw one single character gets out. So I started to debug it a bit:
By a call of _parser.send("AT+RST") the method vsend seems to write characters properly by calling putc() inside the loop of line #L168. But on the hardware I only can measure the first sign A.
During stepping through the code I observed the loop and found out, that the characters apears one by one on the wire if I step through this loop. Maybe this is some kind of timing problem and the MPU isn't fast enought for the loop and the buffered serial throws the other characters?
I tested this with ESP8266-driver at commit dc37b6 and commit 86ed47
used mbed-os is at commit a1c084
and uVisor is at version is v0.25.1
My ESP8266 module and setup (connection to uart, power supply...) works properly without active uVisor.
For a bit of history, the ESP8266 class existed before the NetworkInterface classes were designed. Now that the NetworkInterface has become pretty well established, the ESP8266 class only exists as a vestigial organ that we can probably remove.
I got some failure after bootloader starts downloaded firmware through wifi.
I compared good case and bad case as following.
I had updated esp8266 firmware following this guide
It is possible to avoid the bad case? or lowering reproducibility?
good case: esp8266 module reacts reset command well.
[BOOT] New active firmware is valid
[BOOT] Application's start address: 0x8020800
[BOOT] Application's jump address: 0x8021261
[BOOT] Application's stack address: 0x20018000
[BOOT] Forwarding to application...
9LStart simple mbed Cloud Client
Start developer flow
Developer credentials already exists
[EasyConnect] IPv4 mode
[EasyConnect] Using WiFi (ESP8266)
[EasyConnect] Connecting to WiFi botren01
AT> AT+RST
AT< AT+RST
AT<
AT= OK
AT<
AT< 0,CLOSED
AT< WIFI DISCONNECT
AT<
AT< ets Jan 8 2013,rst cause:1, boot mode:(3,7)
AT<
AT< load 0x40100000, len 816, room 16
AT< tail 0
AT< chksum 0x8d
AT< load 0x3ffe8000, len 788, room 8
AT< tail 12
AT< chksum 0xcf
AT< ho 0 tail 12 room 4
AT< load 0x3ffe8314, len 288, room 12
AT< tail 4
AT< chksum 0xcf
AT< csum 0xcf
AT<
AT< 2nd boot version : 1.2
AT< SPI Speed : 40MHz
AT< SPI Mode : QIO
AT< SPI Flash Size : 32Mbit
AT< jump to run user1
AT<
AT< Äãœìpƒoì|sƒŸcc
l
lll`Œãœï›lŒlŒT= ready
_esp.reset() passed.
Bad case : esp8266 doesn't respond reset command.
[BOOT] New active firmware is valid
[BOOT] Application's start address: 0x8020800
[BOOT] Application's jump address: 0x8053861
[BOOT] Application's stack address: 0x20018000
[BOOT] Forwarding to application...Start simple mbed Cloud Client
Start developer flow
Developer credentials already exists
[EasyConnect] IPv4 mode
[EasyConnect] Using WiFi (ESP8266)
[EasyConnect] Connecting to WiFi botren01
AT> AT+RST
AT> AT+RST
get_mac_addres() started.
AT> AT+CIFSR
AT<
AT< busy s...
AT<
AT< Recv 34 bytes
AT<
AT< SEND OK
AT<
AT< +IPD,0,23:[EasyConnect] ERROR - No MAC address
[EasyConnect] Connection to Network Failed -3012!
Failed to initialize connection
If you have two simultaneous requests come in (e.g. Firefox requesting both / and /favicon.ico, the data from both requests might get mangled. Maybe add a mutex around reading the IPD data...
F.e. here's the data I get back on one of my sockets:
GET / HTTP/1.1
Host: 192.168.1.12:8080
User-AgenGecko/20100101 Firefox/56.0
Accept: text/html,application/xhtml+xml,Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrasts: 1
Pragma: no-cache
Cache-Control: no-cache
While the request actually was:
GET / HTTP/1.1
Host: 192.168.1.12:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
While compiling the given example on https://docs.mbed.com/docs/mbed-os-api-reference/en/5.1/APIs/communication/wifi/#example with this lib there are multiple errors.
Target
NUMAKER_PFM_NUC472
Version information
mbed-os-example-client (mbed-os-5.5.2)
mbed-os-example-client (868f1585f40e)
|- easy-connect (cc471beb7e26)
| |- atmel-rf-driver (0ae76ce17ae5)
| |- esp8266-driver (918caa01b4cd)
| | `- ESP8266\ATParser (269f14532b98)
| |- mcr20a-rf-driver (d5905fefa54c)
| `- stm-spirit1-rf-driver (09e4b9664de1)
|- mbed-client (31e5ce203cc0)
| |- mbed-client-c (ecfa619e42b2)
| |- mbed-client-classic (4e66929607c3)
| `- mbed-client-mbed-tls (7e1b6d815038)
|- mbed-os (8828635da469)
`- pal (60ce64d5ec35)
Steps to Reproduce
Without modification, K64F can connect to mDC but NUC472 cannot.
Starting mbed Client example [EasyConnect] IPv4 mode [EasyConnect] Using WiFi (ESP8266) [EasyConnect] Connecting to WiFi VVVVVVVVVV [EasyConnect] Connected to Network successfully [EasyConnect] MAC address a0:20:a6:09:95:db [EasyConnect] IP address 192.168.43.196 SOCKET_MODE : TCP Connecting to coap://api.connector.mbed.com:5684 simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered simulate button_click, device not registered [ERROR:] M2MInterface::SecureConnectionFailed
With further check into ESP8266 driver, there is mismatch between driver and AT command. According to +IPD - Receives Network Data command in AT command set, there is no "OK" in response. So _parser.recv("OK") always returns false and socket layer needs another ESP8266::recv call to get packet data. If this happens as a complete packet has received by driver, there will be no further interrupt to inform socket layer and this ESP8266::recv call is the last one. That's why NUC472 fails to connect to mDC.
int32_t ESP8266::recv(int id, void *data, uint32_t amount)
{
while (true) {
// check if any packets are ready for us
for (struct packet **p = &_packets; *p; p = &(*p)->next) {
if ((*p)->id == id) {
struct packet *q = *p;
if (q->len <= amount) { // Return and remove full packet
memcpy(data, q+1, q->len);
if (_packets_end == &(*p)->next) {
_packets_end = p;
}
*p = (*p)->next;
uint32_t len = q->len;
free(q);
return len;
} else { // return only partial packet
memcpy(data, q+1, amount);
q->len -= amount;
memmove(q+1, (uint8_t*)(q+1) + amount, q->len);
return amount;
}
}
}
// Wait for inbound packet
if (!_parser.recv("OK")) {
return -1;
}
}
}
If I make the following modification,
int32_t ESP8266::recv(int id, void *data, uint32_t amount)
{
while (true) {
...
// Wait for inbound packet
if (!_parser.recv("OK")) {
// MY FIXUP
struct packet **p = &_packets;
if (*p && (*p)->id == id) {
continue;
}
return -1;
}
}
}
NUC472 can connect to mDC successfully.
Starting mbed Client example [EasyConnect] IPv4 mode [EasyConnect] Using WiFi (ESP8266) [EasyConnect] Connecting to WiFi VVVVVVVVVV [EasyConnect] Connected to Network successfully [EasyConnect] MAC address a0:20:a6:09:95:db [EasyConnect] IP address 192.168.43.196 SOCKET_MODE : TCP Connecting to coap://api.connector.mbed.com:5684 simulate button_click, device not registered Registered object successfully! simulate button_click, new value of counter is 1 simulate button_click, new value of counter is 2
Got this:
mbed compile --build .build/K64F_iar_arm_default/ -m K64F -t IAR -c
Building project mbed-os-cliapp (K64F, IAR)
Compile: at24mac.cpp
Compile: driverAtmelRFInterface.cpp
Compile: driverRFPhy.c
Compile: ESP8266Interface.cpp
Compile: ATParser.cpp
[Error] ATParser.cpp@328: [Pe029]: expected an expression
_oobs.push_back((struct oob){strlen(prefix), prefix, cb});
^
"Z:\builds\ws\ARMmbed\mbed-os-cliapp\nsapi_changes\mbed-os-cliapp\esp8266-driver\ESP8266\ATParser\ATParser.cpp",328 Error[Pe029]: expected an expression
[ERROR]
_oobs.push_back((struct oob){strlen(prefix), prefix, cb});
^
"Z:\builds\ws\ARMmbed\mbed-os-cliapp\nsapi_changes\mbed-os-cliapp\esp8266-driver\ESP8266\ATParser\ATParser.cpp",328 Error[Pe029]: expected an expression
[mbed ERROR] "python" returned error code 1.
link for new esp8266 driver is malfunction.
After performing a gethostbyname on a domain name that is long, such as firmware-catalog-media-ca57.s3.dualstack.us-east-1.amazonaws.com, or 3.141592653589793238462643383279502884197169399375105820974944592.com, the ESP8266 stops responding.
tests/net/gethostbyname/main.cpp to read#define MBED_DNS_TEST_HOST "firmware-catalog-media-ca57.s3.dualstack.us-east-1.amazonaws.com"
$ mbed test -n tests-net-gethostbyname --compile -DMBED_CFG_ESP8266_SSID=<omitted> -DMBED_CFG_ESP8266_PASS=<omitted>
$ mbed test -n tests-net-gethostbyname --run --verbose
esp8266-driver/ESP8266Interface.cpp
Line 319 in 1d0be78
Are the udp_open and tcp_open called somewhere? I could not easily find. Might be that this socket_open should call the correct one based on proto parameter?
Using easy-connect with Nucleo F429ZI + ESP8266:
00:03:53.750 [EasyConnect] IPv4 mode
00:03:53.750 [EasyConnect] Using WiFi (ESP8266)
00:03:53.750 [EasyConnect] Connecting to WiFi systest
00:03:53.750 [EasyConnect] ERROR - No MAC address
00:03:53.750 [EasyConnect] Connection to Network Failed -3004!
This is rare event, but seems to be some issue with the driver.
Wifi Scan in (mbed-os-example-wifi) is not working first time after the boot and works subsequent times.
Versions:
mbed-os: tag: v1.3
mbed-os-example-wifi: mbed-os-5.4
esp8266-driver/ESP8266Interface.h
Line 147 in 1d0be78
the default calls get_stack()->gethostbyname, where is that implemented
esp8266-driver/ESP8266/ESP8266.cpp
Line 717 in 1d0be78
Should the line be in the else statement following this if?
Have been trying this driver with mbed Client against recent versions of Espressif (1.5 and 2.0)... Basic stuff works fine like joining the network, but then...
AT> AT+RST
AT< AT+RST
AT<
AT= OK
AT<
AT< WIFI DISCONNECT
AT<
AT< ets Jan 8 2013,rst cause:2, boot mode:(3,7)
AT<
AT< load 0x40100000, len 1856, room 16
AT< tail 0
AT< chksum 0x63
AT< load 0x3ffe8000, len 776, room 8
AT< tail 0
AT< chksum 0x02
AT< load 0x3ffe8310, len 552, room 8
AT< tail 0
AT< chksum 0x79
AT< csum 0x79
AT<
AT< 2nd boot version : 1.5
AT< SPI Speed : 40MHz
AT< SPI Mode : DIO
AT< SPI Flash Size & Map: 8Mbit(512KB+512KB)
AT< jump to run user1 @ 1000
AT<
AT< rlAT= ready
AT> AT+CWMODE=3
AT<
AT< AT+CWMODE=3
AT<
AT= OK
AT> AT+CIPMUX=1
AT<
AT< AT+CIPMUX=1
AT<
AT= OK
AT> AT+CWDHCP=1,1
AT<
AT< AT+CWDHCP=1,1
AT<
AT= OK
AT> AT+CWJAP="janUK","XXXX"
AT<
AT< AT+CWJAP="janUK","XXXX"
AT< WIFI CONNECTED
AT< WIFI GOT IP
AT<
AT= OK
AT> AT+CIFSR
AT<
AT< AT+CIFSR
AT< +CIFSR:APIP,"192.168.4.1"
AT< +CIFSR:APMAC,"5e:cf:7f:14:0d:ee"
AT= +CIFSR:STAIP,"192.168.43.208"
AT<
AT< +CIFSR:STAMAC,"5c:cf:7f:14:0d:ee"
AT<
AT= OK
[EasyConnect] Connected to Network successfully
AT> AT+CIFSR
AT<
AT< AT+CIFSR
AT< +CIFSR:APIP,"192.168.4.1"
AT< +CIFSR:APMAC,"5e:cf:7f:14:0d:ee"
AT= +CIFSR:STAIP,"192.168.43.208"
AT<
AT< +CIFSR:STAMAC,"5c:cf:7f:14:0d:ee"
AT<
AT= OK
[EasyConnect] IP address 192.168.43.208
[SMC] Device name ba7731fe-ec2f-4a73-9c63-554edfd4103b
AT> AT+CIPSTART=0,"UDP","8.8.8.8",53
AT<
AT< AT+CIPSTART=0,"UDP","8.8.8.8",53
AT< 0,CONNECT
AT<
AT= OK
AT> AT+CIPSEND=0,40
AT<
AT< AT+CIPSEND=0,40
AT<
AT< OK
AT= >
AT<
AT< Recv 40 bytes
AT<
AT< SEND OK
AT<
AT! +IPD
AT= ,0,56:
After this: nothing. On an ancient version of the Espressif firmware it does work.
Currently, there isn't a way to throttle TCP data since +IPD packets are sent by the ESP8266 as soon as TCP data is received.
The master branch of the ESP8266 SDK now has support for commands to allow true TCP flow control. These were added on this commit but have not been released yet. A summary of the commands are:
AT+CIPRECVMODE=<1=No +IPD data, 0=Old behavior>AT+CIPRECVDATA=<link_id>,<len>Further details on these commands can be found on the commit which adds them.
To experiment with these new commands I build the lastest version of the NONOS SDK at the time of this post - espressif/ESP8266_NONOS_SDK@89920dc. The steps I used to build this firmware are below:
ESP8266_NONOS_SDK/examples/at to ESP8266_NONOS_SDK/at and switch your working directory to itgen_misc.sh using below settings OR run make COMPILE=gcc BOOT=new APP=1 SPI_SPEED=40 SPI_MODE=QIO SPI_SIZE_MAP=2ESP8266_NONOS_SDK/bin/upgrade/user1.1024.new.2.binFor ease of access I attahed the firmware I built:
flow_control-NONOS_SDK-89920dcc.zip. ESP8266 firmware update instructions can be found here. All files in this zip are identical to the existing update package except user1.1024.new.2.bin which is what I built.
Finally, below is a script which can be used to demonstrate the new commands. To use this script first load the board use are using with the SerialPassthrough program. Then in the below script replace <FILL IN> with appropriate values and run the script. It will create a local TCP server and then have the ESP8266 connect to it and use the new commands to limit TCP data via flow control.
from serial import Serial
from socket import socket, AF_INET, SOCK_STREAM
from threading import Thread
# Host IP address to use for listening and for device to connect to
HOST = <FILL IN>
# Host port to listen on and for device to connect to
PORT = <FILL IN>
# Serial port of the device
SERIAL = <FILL IN>
# SSID of wifi for device to use
SSID= <FILL IN>
# Password of wifi for device to use
PASS= <FILL IN>
def main():
server_start()
s = Serial(SERIAL, baudrate=115200)
s.timeout = 1
s.write("AT+RST\r\n") # reset device
print s.read(1024)
s.write("AT+GMR\r\n") # print version info
print s.read(1024)
s.write("AT+CWMODE_CUR=1\r\n") # station mode
print s.read(1024)
s.write("AT+CIPMUX=1\r\n") # enable multiple connections
print s.read(1024)
s.write("AT+CWDHCP_CUR=1,1\r\n") # enable DHCP
print s.read(1024)
s.timeout = 10
s.write('AT+CWJAP_CUR="%s","%s"\r\n' % (SSID, PASS)) # Connect to wifi
print s.read(1024)
s.timeout = 1
# New command to change +IPD behavior
s.write("AT+CIPRECVMODE=1\r\n") # disable +IPD data
print s.read(1024)
s.write("AT+CIFSR\r\n") # get IP
print s.read(1024)
s.write('AT+CIPSTART=0,"TCP","%s",%s\r\n' % (HOST, PORT)) # Connect socket
print s.read(1024)
while True:
# New command to read data
s.write("AT+CIPRECVDATA=0,32\r\n") # Read data
print s.read(1024)
def server_start():
server_socket = socket(AF_INET, SOCK_STREAM)
server_socket.bind((HOST, PORT))
server_socket.listen(1)
thread = Thread(target=server_main, args=(server_socket,))
thread.daemon = True
thread.start()
def server_main(server_socket):
conn, addr = server_socket.accept()
print 'Connected by', addr
count = 1
while True:
# Send an incrementing count with no delay in between packets to test flow control
msg = "count: %s\r\n" % count
print("HOST sending count %i" % count)
conn.sendall(bytearray(msg))
count = count + 1
conn.close()
if __name__ == "__main__":
main()See ARMmbed/mbed-os-example-client#80
GCC_ARM works, ARMCC does not...
e.g. AT+CWCOUNTRY_CUR
The channel usage may differ in US an Europe, so this should be done
Need a configuration parameter and interface to get/set the speed/baud of the ESP. Similar pattern to Ethernet where it may be set to 10/100/1000.
Example user had it running at 230Kbps. Default value is ESP8266_DEFAULT_BAUD_RATE 115200
https://os.mbed.com/users/4180_1/notebook/using-the-esp8266-with-the-mbed-lpc1768/
I'm not sure if mbed_app.json is the best place for this, or a driver level setting.
esp8266-driver/ESP8266/ESP8266.cpp
Line 423 in 1d0be78
Socket open (both UDP and TCP) can return from modem "
If the TCP connection is already established, the response is:
ALREADY CONNECTED"
We do not handle that, we only get boolean "done" with open command && OK. and then we return the wrong status at the end, because modem has the port open
Original issue by @LiyouZhou:
Using ESP8266 and a Serial port to PC at the same time. This means k64f is running 2 separate serial port. The ESP8266 serial port is set to baud 115200.
If I set the PC serial port to 9600:
If I set the PC serial baud to 115200:
mbed-os sha
(git describe --tags)
https://github.com/ARMmbed/mbed-os/#cd5c9564fd09138085ecf4a0ac4afdb53255f362
mbed-cli version
(mbed)
0.7.4
According to TCPSocket in mbed OS 5 spec calling recv() on a closed socket should return 0.
When you do this on esp8266-driver the socket hangs forever.
Reproduce:
Find a server which closes the connection directly after the response (e.g. Philips Hue hub).
Make a request (send()).
Call recv() a few times, e.g. via:
socket.recv(buffer, 1024);
socket.recv(buffer, 1024);
socket.recv(buffer, 1024);At some point you'll see:
AT<
AT< SEND OK
AT<
AT! +IPD
AT= ,0,17:
AT<
AT= OK
recv1 17 <--- first packet, is OK!
AT<
AT<
AT! +IPD
AT= ,0,481:
AT<
AT= OK
recv2 481 <--- second packet is OK too!
AT<
AT< 0,CLOSED <---- socket is closed
AT<
AT< ERROR <---- third recv() call hangs forever now
Now the whole app hangs.
esp8266-driver/ESP8266/ESP8266.cpp
Line 675 in 7bb1d8e
should this be handled as status update to app, and reconnect logic?
esp8266-driver/ESP8266/ESP8266.cpp
Line 571 in 1d0be78
I do not really understand this [id].id != id, if the socket is closed, should we check the connected status?
[ERROR] In file included from ./esp8266-driver/ESP8266Interface.cpp:18:0:
./esp8266-driver/ESP8266Interface.h:20:41: fatal error: network-socket/NetworkStack.h: No such file or directory
#include "network-socket/NetworkStack.h"
Should be netsock/NetworkStack.h now.
The ESP8266 sends received TCP data over its uart with +IPD packets. The AT command set does not expose a way to stop these packets without closing the socket. Because of this, if the remote TCP connection continues to send data the devices buffers could fill and overflow, dropping TCP data.
One possible way to address this problem is to add additional AT commands with the ability to throttle +IPD packets. I have created a post to investigate this possibility further:
https://bbs.espressif.com/viewtopic.php?f=16&t=9740
Daplink v243
mbed CLI 1.1.1
mbedgt 1.2.5
Windows 7
Both PC and ESP8x connected to same local wifi network
esp8266-driver sha: 95908fb
mbed-os sha: 5d0ce3c53158c69b5456d1d2ef4ecc12fdcfc49e
Test summary
+--------------+---------------+------------------------------+----------------------------------------+--------+--------+--------+--------------------+
| target | platform_name | test suite | test case | passed | failed | result | elapsed_time (sec) |
+--------------+---------------+------------------------------+----------------------------------------+--------+--------+--------+--------------------+
| K64F-GCC_ARM | K64F | tests-net-connectivity | Bringing the network up and down | 1 | 0 | OK | 5.5 |
| K64F-GCC_ARM | K64F | tests-net-connectivity | Bringing the network up and down twice | 1 | 0 | OK | 10.96 |
| K64F-GCC_ARM | K64F | tests-net-gethostbyname | DNS literal | 1 | 0 | OK | 0.09 |
| K64F-GCC_ARM | K64F | tests-net-gethostbyname | DNS preference literal | 1 | 0 | OK | 0.1 |
| K64F-GCC_ARM | K64F | tests-net-gethostbyname | DNS preference query | 1 | 0 | OK | 0.24 |
| K64F-GCC_ARM | K64F | tests-net-gethostbyname | DNS query | 1 | 0 | OK | 0.21 |
| K64F-GCC_ARM | K64F | tests-net-tcp_echo | TCP echo | 0 | 1 | FAIL | 6.13 |
| K64F-GCC_ARM | K64F | tests-net-tcp_hello_world | TCP hello world | 1 | 0 | OK | 7.52 |
| K64F-GCC_ARM | K64F | tests-net-udp_dtls_handshake | UDP DTLS handshake | 0 | 1 | FAIL | 36.83 |
| K64F-GCC_ARM | K64F | tests-net-udp_echo | UDP echo | 0 | 0 | ERROR | 0.0 |
+--------------+---------------+------------------------------+----------------------------------------+--------+--------+--------+--------------------+
mbedgt: test case results: 2 FAIL / 7 OK / 1 ERROR
Full log attached.
k64_esp8x_tests.txt
@geky What would be the reason for this?
Could it be a timing issue in the driver or the tests?
_parser->send("AT+CIPSENDBUF=%d,%d", id, amount) fails.
Probably the firmware in the chip have a bug as previously we had seen a failure with CIPDOMAIN command which got resolved by updating the chip firmware to the latest.
By default the device is either in AP mode or AP+client mode.
Driver seem to touch only the current setting AT+CWMODE_CUR, not the default one AT+CWMODE_DEF
This should be changed so that by default, it will mode fixed to client mode and that setting should be saved to flash using AT+CWMODE_DEF
Reference: ESP8266 Instruction set
esp8266-driver/ESP8266/ESP8266.cpp
Line 426 in 1d0be78
UDP open returns status, not just bool. And if the socket is now open, we return false for TCP, which the client probably can not match to already open
esp8266-driver/ESP8266/ESP8266.cpp
Line 835 in 1d0be78
It is target state for network interfaces that the drivers try to reconnect if connection drops. Seems the driver does not do that. In the wanted operation, the state is is informed to application and the driver tries to reconnect.
I am not sure how implement HTTPS/SSL request. Could you please advise on this.
Currently, the recvfrom for UDP is just a thin wrapper over recv, because of this no valid SocketAddress is returned to the application.
Either the command set needs to be updated to obtain the recvfrom IP address, or the IP address of the connection should be stored for future recvfroms.
esp8266-driver/ESP8266/ESP8266.cpp
Line 560 in 1d0be78
Seems there is no check if the actual data Len is bigger than amount. AT command spec doesn't seem to prevent this
Currently, _process_oob is being called from a recurring task in the event queue that runs every 2 second. It would be more efficient if the task was only inserted into the queue whenever the UART sigio callback is triggered similar to how the cellular AT handler is doing it:
[ ] Question
[x] Enhancement
[ ] Bug
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.