Skip to content

failure in high speed communication #542

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

Closed
ROBOTIS-Will opened this issue Jul 9, 2020 · 3 comments
Closed

failure in high speed communication #542

ROBOTIS-Will opened this issue Jul 9, 2020 · 3 comments
Assignees

Comments

@ROBOTIS-Will
Copy link
Contributor

Hi,

This issue is an explanation of test result regarding the PR #541.
While we've been testing with Arduino MKR boards, there was an issue with unsuccessful transmission caused by the flushUART().

In our test we were using half duplex communication(TTL) over the UART to control TX and RX direction with the direction control GPIO pin. After flushing the UART, direction control will be switched, but the flushUART does not wait until the completion of TX.

Please see below oscilloscope graph where the direction control(in blue) drops too early before the end of TX(in green), therefore, the actual TX data is missing the last bit(in yellow).

Torque On 2Mbps #1

After commenting out the isDataRegisterEmptyUART() section, flushUART() waits until the end of transmission as below.
Torque On 2Mbps #2(check TXC only)

As we are not sure the reason of skipping the checking transmission completion, please review this modification(#541) and let us know.
Thank you.

@matedl
Copy link

matedl commented Aug 27, 2020

I have the same problem when writing a single byte over half duplex RS-485. When I write multiple bytes, flush() works as it should but when I write a single byte it does not work. When writing a single byte "isDataRegisterEmptyUART()" probably returns true since the byte is already in the shift register and flush() returns without waiting for TXC. Maybe this problem was introduced when fixing the issue "Fix Serial.flush() blocking if called immediately after Serial.begin() #144"?

@ROBOTIS-Will
Copy link
Contributor Author

@facchinm Hi, I'm just checking in for any updates or progress on this issue. Hope you are safe from the Covid-19.

@facchinm
Copy link
Member

Patch #541 merged, will be part of core 1.8.11 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants