ESP8266: Fix serial flow control inconsistency on reconnect #15240
Conversation
ciarmcom
added
the
release-type: patch
|
@ccli8, thank you for your changes. |
| * @return true if started | ||
| */ | ||
| bool stop_uart_hw_flow_ctrl(); | ||
| bool stop_uart_hw_flow_ctrl(bool board_only); |
There was a problem hiding this comment.
As this is public method, this would be breaking, wouldn't it?
What if we add overload adding boolean argument, we could deprecate the old method if it is necessary.
There was a problem hiding this comment.
How about C++ default argument:
bool stop_uart_hw_flow_ctrl(bool board_only = false);The call to stop_uart_hw_flow_ctrl() without board_only specified will translate to stop_uart_hw_flow_ctrl(false) for compatibility.
There was a problem hiding this comment.
Also was considering this, https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-default-args - lets go with the default parameter
There was a problem hiding this comment.
Updated to go with default parameter
The commit will address the test failure of connectivity-netsocket-tests-tests-network-interface. In the test, serial channel will break with the sequence: ESP8266Interface::connect() > disconnect() > connect() In the first connect, both board's and ESP8266's serial flow control default to disabled, and then enabled. In the second connect, board's serial flow control keeps enabled but ESP8266's resets to disabled, causing inconsistency between two ends. The approach: Explicitly disable board's serial flow control on re-power or reset in (re-)connect
ccli8
force-pushed
the
nuvoton_esp8266_flow_control_reconnect
branch
from
08e9732
to
0d2de99
Compare
|
CI started |
Jenkins CI Test : ✔️ SUCCESSBuild Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
mbedmain
added
release-version: 6.16.0
Release-pending
and removed
release-type: patch
Summary of changes
The PR tries to address the test failure of
connectivity-netsocket-tests-tests-network-interface. In the test, serial channel will break with the sequence:In the first connect, both board's and ESP8266's serial flow control default to disabled, and then enabled. However, in the second connect, board's serial flow control keeps enabled but ESP8266's resets to disabled, causing inconsistency between two ends.
The approach is explicitly disable board's serial flow control on ESP8266 re-power or reset in (re-)connect.
Pull request type
Test results