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

ESP32: EOI - high-speed UART driver #2857

Closed
jmattsson opened this issue Jul 26, 2019 · 4 comments
Closed

ESP32: EOI - high-speed UART driver #2857

jmattsson opened this issue Jul 26, 2019 · 4 comments
Assignees

Comments

@jmattsson
Copy link
Member

The UART driver provided by Espressif in the IDF is full featured, and integrated into the IDF VFS and all those things. It is also big and complex (three levels of buffering - aaah!). And the UART ISR sits in flash. The latter turns out to be a show stopper if you're using high baud rates like 1Mbit and are wanting to write to flash at the same time. While the flash erase/write is taking place, the UART interrupt is blocked (since the ISR resides in flash, and the flash is inaccessible during an erase/write) and this leads to lost bytes.

At $work we had to work around this, so I have written a replacement, high-performance UART driver specifically for NodeMCU. Its ISR sits in RAM so it does not get blocked by flash operations, and it also provides full configurability of the RAM FIFOs (queues) used, so they can be dimensioned according to the particular project requirements, per UART. We're for example using an 8K receive queue and 512byte send queue on one of the UARTs, and 2k/8byte on the second.

Is there any interest in me PR'ing this UART driver here? Comments for and against below, please :)

It's a Kconfig option whether to use it or the standard IDF driver, and it defaults to off (i.e. use IDF driver). The downside to it is that it uglifies the platform.c a bit, as there are effectively two implementations there depending on which driver is used. I should also mention that the console UART is not affected by the driver change, as it already has its own driver.

@jmattsson jmattsson self-assigned this Jul 26, 2019
@stale
Copy link

stale bot commented Jul 20, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 20, 2020
@NicolSpies
Copy link

@jmattsson, @galjonsfigur, maybe this should not be closed in light of #3104.

@stale stale bot removed the stale label Jul 20, 2020
@jmattsson
Copy link
Member Author

If there's actual interest then sure. I'd let this one languish since there were no comments here.

@stale
Copy link

stale bot commented Jul 21, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 21, 2021
@stale stale bot closed this as completed Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants