Mg_connect_http delay UART sending

General
1

If you are asking a question, please follow this template:

  1. My goal is: [Have both UART and WiFi communicate in real time]
  2. My actions are:
    [
  • Using the ESP8266 platform.
  • Using UART port to receive DATA packet and response with ACK packet
  • A timer mgos_set_timer() is used to process the UART packets
  • When 2000 bytes is received, it formats HTTP packet and send to server using mg_connect_http()
    ]
  1. The result I see is:
    [
  • Case #1 : when mg_connect_http() is not called (not sending to server), the response of the ACK packet is <100ms
  • Case #2 : when mg_connect_http() is called, the response of the ACK packet is >500ms
    ]
  1. My expectation & question is:
    [
    Seems like the mg_connect_http() is blocking all others events during HTTP connection and sending data.
    I would like UART port be highest priority.
    Is there a way to lower the priority of the mg_connect_http() or adjust priority of both Timer and UART ??
    ]
2

You are using an event-driven framework, there are no tasks nor priorities involved when using mOS.
If you first connect to your server and then send your ACK, it is normal to have the HTTP client processing time delaying the ACK, since there are no parallel tasks running and no other handler can be called until the one calling the HTTP client returns. I can’t help you here, but Mongoose (the HTTP client, server, etc.) has its own set of events; that might help.
You should not process packets on a timer callback but on proper msg framing.
All events will be queued when occurring and handled as soon as possible, and that depends on you returning control as soon as possible, and that means exiting all callbacks as soon as possible, since all handlers run to completion.
The UART driver already takes care of collecting chars into a FIFO, your callback will be called when there are enough chars available or enough time has elapsed since last one, according to how you’ve configured it. Internally, the UART has the priority it has to have to guarantee no chars will be lost. However, you have to return control to mOS (exiting your callbacks asap) for it to call your UART handler (callback) or timer expired handler (callback)
100ms can be an eternity or an excellent timing depending on frame length and link rate.

3

I have made some changes to decode packets during the RcvUart_cb() but result the same.
mgos_uart_set_dispatcher(UART_NO, RcvUart_cb, NULL /* arg */);

Here are a print out of the responding time of the receiving packets.
The time show the delta between each received data packet and ACK response packet.
From what I see, each time “SW ECDH curve 3” is called, UART callback is delayed >600ms
I have tried to access a site with TLS disabled , then the delay will be <200ms.

main.c:206 Put : 21 ms
main.c:206 Ack : 3 ms
mg_ssl_if_mbedtls.c:30 0x3fff4cbc ciphersuite: TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
main.c:206 Put : 66 ms
main.c:206 Ack : 3 ms
main.c:206 Put : 28 ms
main.c:206 Ack : 4 ms
SW ECDH curve 3
mgos_mongoose.c:66 New heap free LWM: 4480
main.c:206 Put : 692 ms
main.c:206 Ack : 3 ms
main.c:206 MG_EV_CONNECT : 9 ms
main.c:206 Put : 23 ms
main.c:206 Ack : 3 ms

I have tried to search for the “SW ECDH curve 3” line but could not find it.
Do you think this is limitation due that call ?

4

ECDH key establishment operations are definitely computing intensive and maybe the current implementation does not yield during the whole operation. Sources have been recently published here, look at them or try to catch the attention of one of the developers. I don’t know how much of it is open source.
Anyway, 200ms looks excessively long to me. How are you getting those times ?

5

I measure the time from calling mg_connect_http() to event MG_EV_CLOSE on 2 different links

http://example.com (200ms)
https://example.com (700ms)