Skip to content
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

UART Communication Delays and Data Loss #10420

Open
1 task done
mightChamp opened this issue Oct 4, 2024 · 7 comments
Open
1 task done

UART Communication Delays and Data Loss #10420

mightChamp opened this issue Oct 4, 2024 · 7 comments
Assignees
Labels
breaking-change 💥 A change that changes the API or breaks backward compatibility for users. Peripheral: UART Priority: High 🗻 Issues with high priority which needs to be solved first.
Milestone

Comments

@mightChamp
Copy link

Board

ESP32 Wroom 32E 4MB Flash

Device Description

We are making an Uart Data logger, an external device send uart data, which stored in SD card.

Hardware Configuration

GPIO13- Uart TX, and GPIO14- Uart RX
Uart setup:
Baud Rate: 115200
Flow Control: Disabled
Buffer Size: 4096

Version

latest development Release Candidate (RC-X)

IDE Name

Arduino IDE

Operating System

Windows 11

Flash frequency

80Mhz

PSRAM enabled

no

Upload speed

921600

Description

We are encountering an issue with UART communication on ESP32 where data reception is delayed, and sometimes data is lost. This issue occurs intermittently and was not present in version v1.0.6.

Sketch

void setup() {
    Serial.begin(115200);  // UART initialized at 115200 baud rate
}

void loop() {
    if (Serial.available()) {
        String data = Serial.readString();
        Serial.println(data);
    }
}

Debug Message

No Debug Message

Other Steps to Reproduce

Set up UART communication between ESP32 and another device.
Send continuous data streams over UART.
Observe occasional delays and missed data.

I have checked existing issues, online documentation and the Troubleshooting Guide

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@mightChamp mightChamp added the Status: Awaiting triage Issue is waiting for triage label Oct 4, 2024
@lbernstone
Copy link
Contributor

The HardwareSerial library has been modified to have more capabilities for handling intermittent and burst data flows. Take a look at the OnReceive and RxTimeout examples to see how to handle high activity and sporadic flows.
@SuGlider This could definitely use some doco

@SuGlider
Copy link
Collaborator

SuGlider commented Oct 4, 2024

@mightChamp - The issue is related only to Core 3.1.0-RC1? Does it also happen with Core 3.0.5?

@SuGlider SuGlider added Peripheral: UART Priority: High 🗻 Issues with high priority which needs to be solved first. breaking-change 💥 A change that changes the API or breaks backward compatibility for users. and removed Status: Awaiting triage Issue is waiting for triage labels Oct 5, 2024
@SuGlider SuGlider added this to the 3.1.0 milestone Oct 5, 2024
@SuGlider
Copy link
Collaborator

SuGlider commented Oct 5, 2024

This sounds related to #10397
After testing the sketch from the issue, it seems clear that IDF 4.x and 5.x UART Driver used by ESP32 Arduino HardwareSerial is not efficient and causes a huge performance issue.

The evidence is that whenever Serial0.begin() is executed, there is a significative time slot reduction to the main Arduino Task, affecting the time that loop() has to process data.

In Arduino Core 1.0.6, the UART driver was local one, faster and way more efficient.
The solution for this issue is to refactor HardwareSerial and create its own Arduino UART Driver, the same way it is done for SPI.
@me-no-dev - FYI.

@SuGlider
Copy link
Collaborator

SuGlider commented Oct 7, 2024

@mightChamp - Could you please check if PR #10428 solves this issue too?
This PR improves the loop() execution efficiency and may give it more "CPU cycles" in order to solve the data loss issue.

@mightChamp
Copy link
Author

We have tested the fix from PR #10428, but unfortunately, we are still facing the same issue.

This issue is currently blocking our development progress, and we would greatly appreciate an estimate of how long it might take to investigate or resolve this. If there are any further tests or adjustments we could try, we are ready to assist.

@SuGlider
Copy link
Collaborator

SuGlider commented Oct 7, 2024

@mightChamp - based on what @lbernstone wrote, there are a few new methods to deal with UART that were not available in 1.0.6.

@SuGlider
Copy link
Collaborator

SuGlider commented Oct 7, 2024

I'll build a Python script + the sketch example that is here listed to find out more about the issue.
If I find out something else, I'll write about it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change 💥 A change that changes the API or breaks backward compatibility for users. Peripheral: UART Priority: High 🗻 Issues with high priority which needs to be solved first.
Projects
Status: Under investigation
Development

Successfully merging a pull request may close this issue.

3 participants