You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we have a project where esp32 serial0 is connected to a 3rd party MCU (unknown, black box to us) via transceivers (to convert RS232 voltage levels to TTL ones).
When the transceiver of the 3rd party system -i assume- initializes (while serial0 has already began) it produces noise that is definitely not a valid byte for the configured 9600/8N1
However the available() and read() functions in arduino-esp32 both hit and give us 'normal' input. While the IDF serial api provides info on framing errors, Arduino apis seem to not carry this information.
In addition, all subsequent transactions (until a reset on esp32) now carry corrupt or extra bytes interleaved with the normal ones.
This may be related to #476 which while closed, has a final comment by @me-no-dev as "I hope all issue will be fixed once I change the driver with the IDF one."
is this something that is known and/or has a timeline for fixing?
The text was updated successfully, but these errors were encountered:
we have a project where esp32 serial0 is connected to a 3rd party MCU (unknown, black box to us) via transceivers (to convert RS232 voltage levels to TTL ones).
When the transceiver of the 3rd party system -i assume- initializes (while serial0 has already began) it produces noise that is definitely not a valid byte for the configured 9600/8N1
However the
available()
andread()
functions in arduino-esp32 both hit and give us 'normal' input. While the IDF serial api provides info on framing errors, Arduino apis seem to not carry this information.In addition, all subsequent transactions (until a reset on esp32) now carry corrupt or extra bytes interleaved with the normal ones.
This may be related to #476 which while closed, has a final comment by @me-no-dev as "I hope all issue will be fixed once I change the driver with the IDF one."
is this something that is known and/or has a timeline for fixing?
The text was updated successfully, but these errors were encountered: