So far received packets were parsed (at AT command level) and allocated
in [esp_rx] thread. Then they were submitted to [esp_workq] thread for
processing (calling application callback).
This flow results in following deadlock when esp_workq thread waits on
response to some AT command:
- [esp_rx] waits on allocation of new RX packet
- [esp_workq] waits for [esp_rx] to process response to AT command
that was just sent
- blocked [esp_workq] prevents processing and deallocating RX packets
- [esp_rx] times out on allocation and closes socket
Process RX packets directly from [esp_rx] thread to prevent above
deadlock.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
net_context contains both net_sock_type and net_ip_protocol, which are
static during the lifetime of net_context. net_context has basically the
ownership of esp_socket, so we can be sure 'type' and 'ip_proto' are
always accessible through net_context API.
Remove 'type' and 'ip_proto' members from 'esp_socket' structure, as
those are already accessible by net_context API.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Change type of esp_socket->flags from uint8_t to atomic_t, so that read
and write access to those flags is done in atomic (thread-safe) manner.
Introduce esp_socket_ref() and esp_socket_unref() functions, which
operate on atomic refcount variable. esp_socket_ref() role is to
increase refcount if it was already non-zero. If it was zero then NULL
is returned, which means that socket is not used by net_context at the
moment.
Role of refcount:
* socket instance is assured to be between net_offload->get() and
net_offload->put() when refcount > 0,
* makes sure that socket instance can be used (its members can be
dereferenced) when refcount > 0,
* 'context' member is always valid and its members can be dereferenced
when refcount > 0.
esp_socket_get() gets unused socket, as previously. Additionally it sets
refcount to 1 at the end of call, which basically means that from that
point such socket can be referenced by other parts of the driver. Each
esp_socket_get() call should be followed by esp_socket_unref() and
esp_socket_put() to properly invalidate socket and prevent other parts
of driver from using it.
Add ESP_SOCK_WORKQ_STOPPED flag, which is now used to prevent scheduling
more work into driver workqueue. This flag is set in net_offload->put()
callback, so that no more socket work (such as processing RX/TX packets
or closing socket because of errors) is submitted after that.
Introduce mutex lock, which has following role:
* protects dst, connect_cb + conn_user_data, recv_cb + recv_user_data,
* assures that checking ESP_SOCK_WORKQ_STOPPED flag and actually
submitting (or not if net_offload->put was already called) new socket
work to workqueue is done in atomic way.
As there is a mechanism to prevent submitting new work items to
workqueue when net_offload->put() has been executed, then there is no
need to explicitly call esp_socket_ref() in esp_workq thread. This is
because one reference is being held by net_context (after calling
net_context->get()). This is why all the esp_socket_in_use() were simply
dropped. Code running from esp_rx thread on the other hand always uses
esp_socket_ref_from_link_id() helper function (which is backed by
esp_socket_ref()), so that it replaces previous esp_socket_in_use()
calls and additionally makes sure that socket stays valid ("in use")
until esp_socket_unref() is called.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
So far a dedicated FIFO was used for all RX packets, which was consumed
in single submitted work. This work was also responsible for closing
socket and notifying uppper network layers if some errors occurred
previously or socket was simply closed by peer. There is however a
potential race condition in scenario described below:
esp_rx thread | esp_workq thread
--------------------------|-----------------------------
| ---- esp_recv_work ----
| handle RX packets from FIFO
|
---- on_cmd_ipd ---- |
put new RX packet to FIFO |
---- on_cmd_ipd ---- |
|
---- on_cmd_closed ---- |
mark socket as closed |
---- on_cmd_closed ---- |
|
| handle close
| ---- esp_recv_work ----
In this case we assume that esp_workq was preempted just after
processing all RX packets from FIFO and before checking if socket was
closed. In such scenario RX packet put to FIFO just before doing close
is going to be unhandled, so application layer will miss part of the
data.
Change the way RX packets are scheduled to workqueue, by using the
already available net_pkt->work objects (used for example in native TCP
stack). Create a separate work for closing connection. As a result all
RX packets and close handlers are on the same queue and there is no risk
of handling close events before handling all previously received data.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
There might be some scheduled work related to socket currently requested
to be destroyed/closed. Schedule a dummy work to make sure all
previously running work items in workqueue are finished.
When talking about TX packets, this makes sure that all previously
scheduled data is actually sent (flushed) before closing socket.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
It is enough to initialize work structures once during driver init,
because work handlers do not change during driver lifetime.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Currently there are two code paths when sending packets:
asynchronous (using workqueue) when zero timeout was specified and
synchronous in other cases. This doesn't seem to be justified, so
convert code to always schedule packet sending using workqueue.
Each net_pkt has an embedded work item, so use it instead of esp socket
specific work that was shared across all sent packets. This gives a
possibility to schedule multiple packets for sending.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Callback and user data are saved in net_context structure. Those members
are used by native networking stack (net_if), so simply follow the same
pattern.
First of all this allows to reduce runtime information for driver socket
instance. Second and most important benefit is that it allows to move
send handling entirely to workqueue thread.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
ESP chip send number of available RX data using
+IPD=<sock>,<avail_bytes> command. This exact number (truncated to MRU)
was used to read data with AT+CIPRECVDATA=<sock>,<num_of_bytes>.
Use always MRU when sending AT+CIPRECVDATA=<sock>,<mru> request. When
there are less bytes available, then +CIPRECVDATA will just return less
bytes, which is fine for the driver.
There are two advantages to this new behavior:
* there is no need to follow how many bytes were notified by +IPD
message, thus reducing implementation size,
* when data is constantly received by ESP chip, then the last number of
bytes notified by +IPD is no longer up-to-date when sending a
AT+CIPRECVDATA; always requesting MRU number of bytes allows to
always receive maximum currently available number of bytes buffered
by ESP chip.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Dump of communication between ESP chip and Zephyr shows that
+IPD:<sock>,<bytes_avail> is always received after +CIPRECVDATA. This
means that we don't need to update sock->bytes_avail in esp_workq
thread. Additionally there is no need to schedule next AT+CIPRECVDATA
request, as that will be done by +IPD handler anyway.
Relying on +IPD to be received after each +CIPRECVDATA (as long as there
is some more data to be received) allows to simplify operations on
sock->bytes_avail. From now on only esp_rx thread will update its value
and schedule AT+CIPRECVDATA in esp_workq thread. Then in
sock->bytes_avail will be treated as "readonly" in esp_workq
thread. This allows to prevent race condition when both esp_rx and
esp_workq threads could potentially update value of sock->bytes_avail
value at the same time.
<sock>,CLOSED message is received always after retrieving all data from
ESP chip (using AT+CIPRECVDATA), so there is no need to check whether
there are more bytes to be received before marking socket as closed in
Zephyr driver.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Deduplicate final part of RX data processing for two supported cases:
passive (+CIPRECVDATA) and non-passive (+IPD). Move implementation to
esp_socket module, as this is strictly related to socket.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Current on_cmd_ciprecvdata handler is a bit overwhelming to follow.
Add a cmd_ciprecvdata_parse() helper, which is responsible only for
parsing received metadata (message offset and length), leaving socket
instance untouched.
Consume received payload later on, just after verifying that socket is
in valid state.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
After a synchronous (timeout > 0) connection attempt was made, it was
being checked if there is some packet to be sent. If positive, then a
send work was queued.
This behavior makes little sense, as TCP connection is not even
considered established at this point (from net_context perspective) if
function has not returned yet. Additionally it differs from
asynchronous (timeout == 0) connection attempt. In case of UDP (and
calling esp_connect() from esp_sendto()) sock->tx_pkt is assured to be
NULL. Drop this piece of code as it doesn't seem to be justified.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
2 (out of 3) components used CONFIG_WIFI_LOG_LEVEL, while the last one
didn't specify explicit log level. Always use CONFIG_WIFI_LOG_LEVEL in
all components.
While at it switch to LOG_MODULE_REGISTER(<module>, <log_level>), which
is a more compact way to define log level.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Calculate size based on the real message, instead of assuming some
arbitrary size. This consumes slightly less stack space, but more
importantly gives an idea what has been taken into account when
calculating the size.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Set NET_CONTEXT_CONNECTED when stream socket got connected. This fixes
TCP connection when using ESP WiFi driver, which got broken after
sockets layer started to validate net_context connection state before
allowing to receive any data.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Change internal API operating on ESP driver flags to support multiple
bitwise ORed flags at once. This allows to improve resulting code when
multiple flags are read or modified at once.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
All except one invocations of modem_cmd_send() pass the same interface,
command handler and semaphore. Create a helper function in order to make
invocations slightly more readable.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Constifying global data allows to save lots of RAM. Defining data inside
function as 'static const' allows on the other hand to save stack usage
and reduced code size (because data doesn't have to be copied on stack
in runtime).
This improvement allows to save 640 bytes of RAM and 64 bytes of ROM
when compiled on ARM.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
There is no reason to keep active stream socket when there was some data
loss. Mark such socket for closing and close it when all (so far)
received packets have been processed.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
It can happen that the command '>' is received between
modem_cmd_send_nolock and modem_cmd_handler_update_cmds. Since the
command handler for '>' is not set, sem_tx_ready will not be given
and _sock_send will timeout. Make sure the command handlers are set
before the send by also passing them to modem_cmd_send_nolock.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
- Fix passive mode protocol selection depending on AT versions
- Use Kconfig value for reset timeout
- Fix bug with parsing security from scan result
- Re-order some AT commands during init due to some commands having
dependency on other commands
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
The driver should only call net_pkt_unref on packets that get
successfully handled, ie where send/sendto return 0. If the packet
cannot be handled, net_context layer still owns the packet and should
take care or the unref.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
This fixes some cases where an integer timeout received as a parameter
was not converted to a timeout before being used in standard API.
Changes to the POSIX library were not included as that's being
reworked in a separate PR.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Run the int_literal_to_timeout Coccinelle script to fix places where
it is clear that an integer duration is being passed where a timeout
value is required.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This adds support for the Espressif ESP8266 and ESP32 devices to be used
as peripherals on a UART.
There are two main AT command versions that can be selected, 1.7 and
2.0. Since they behave a bit different it is important to select the
one that matches the used in the firmware on your device.
When downloading large amounts of data it is highly recommended to
enable CONFIG_ESP_PASSIVE_TCP and flow control on the UART so that
data is not lost due to UART speed or receive buffer size.
Currently unsupported:
- Changing UDP endpoint with a sendto()
- Bind to a specific local port
- Server socket operations, ie listen() and accept()
Official AT firmware for ESP8266 and ESP32 can be found at:
https://github.com/espressif/esp-at
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
