-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32 HardwareSerial Callbacks has variable time delay #2445
Comments
The I went deep inside of the Sming framework. I think I found the issue. In the file Sming/Core/HardwareSrial.cpp line 184
The system quecallback takes variable time to call it. This calling time delay is too much for some protocol implementation like ModBus. |
If I'm not out of topic, I'm having a similar behavior with ModBus and a basic html page: when I "wget" the jquery.js.gz from spiffs, I'm having this result jquery.js.gz 100%[=============================>] 29,45K 5,04KB/s in 5,8s and this from the debug window
I'm using an ESP8266 with ModBus connected to the first serial and the debug (as in the example) at the second serial. The code is a simple join of the modbus example and a spiffs area where are placed an index.html, jquery.js.gz and bootstrap.css.gz With another my project non using ModBus,I catch this result with the wget |
I found a bug! Try this patch and see if it fixes your problem. Run
|
If you need tight timing on the callback (e.g. switching modbus transceiver from TX to RX) then use interrupt callbacks by calling
|
Also worth doing a search for 'modbus' in previous issues, there's been some discussion about this issue. |
@mikee47 Can you send a PR with the fix? |
Thanks everyone for the support. I replaced default Sming uart call back using According to my application, the ESP32 serve a web page over WiFi STA mode. When
I think (not sure), the problem is not in the UART ISR, it is in the System queues. System queue takes more than 30ms to call a CallBack function and it is varying even we have fast CPU on the board. |
@Asanga-Viraj please decode your stack trace. See here for more details https://github.com/SmingHub/Sming/blob/develop/samples/LiveDebug/README.rst#exception-handling |
@Asanga-Viraj Or run in the debugger https://smingdev.readthedocs.io/en/latest/arch/esp32/debugging/index.html. Re-build first though:
|
I've done some basic checks on system task vs. timer and cannot as yet see any difference. @Asanga-Viraj Can you push your app. or a simplified version to github? I can then investigate further... |
Thanks everyone. Sorry for my late reply. I called UART interrupts Tx complete delegate and RX complete delegate directly without going through the system queues. This was happened when ESP trying to send binary files to the web page on requests. I re-run the issue and got this back trace.
This make sense. Uart interrupted the flash operations because Uarts interrupt is not going over System queue. Sorry, I don't have ESP debug tool now. I will buy one. My initial question was System queues are not fast. It takes average time 30ms and it varies between 5ms-50ms. I think this is nothing to do with Sming framework. It is inside of the ESP FreeRTOS. For now, I can handle it. My app consist of lots of things. I will upload simplified version later. |
So I'm working on an esp32-s2 application which services interrupts via the task queue, and running into the 'slow task queue' issue here. When the interrupt service routine is triggered I queue a task to defer processing, and this appears to take exactly 10ms. This is exactly one FreeRTOS tick. The best resolution is 1ms which can be changed running The alternative is to use a short-lived https://github.com/espressif/esp-idf/blob/master/components/esp_timer/src/esp_timer.c#L456 With PR #2913 networked applications behave as described in this issue, whilst non-networked applications do not. So could it be the tcpip task which is responsible for this difference? The wifi task runs at the highest priority so it seems more likely that it is the cause of this delay. But that doesn't explain why timers don't have the delay! |
Hi,
My application is to implement a Serial2 handler to run serial protocol like ModBus on ESP32. My another microcontroller is polling for reply from ESP32 with baud rate 38400. The time between two packets is 25ms. I attached data received and transmit events like below.
I experienced that the receive complete event is not calling at the end of the receiving. I hooked up a oscilloscope and check the rx data line and receive event calling by toggling digital pin inside the event function. There is a variable delay from the end of the rx until calling the onDataCallback event. Also this issue is on transmit complete event as well.
One more thing. If I connected ESP32 RX2 with my other controller polling and initialise the Serial2 without 'Serial2.onDataReceived(onDataCallback);', ESP32 resets due to watch dog reset.
Thanks.
The text was updated successfully, but these errors were encountered: