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

Fix to avoid lost characters on USBUS CDC ACM STDIO #12402

Merged
merged 4 commits into from Jan 15, 2020

Conversation

ant9000
Copy link
Contributor

@ant9000 ant9000 commented Oct 9, 2019

This small commit implements a fix for #12384 , and modifies the provided test to make sure it is actually fixed.

@bergzand bergzand self-requested a review October 9, 2019 09:29
@bergzand bergzand added Area: USB Area: Universal Serial Bus Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) labels Oct 9, 2019
@benpicco benpicco requested a review from dylad October 9, 2019 15:51
@benpicco
Copy link
Contributor

benpicco commented Oct 9, 2019

Please squash!
Maybe @bergzand has some comments still?

Also tests/usbus_cdc_acm_stdio looks kind of ugly now - maybe there is some better test output you could use? Like Lorem ipsum or the Free Software Song - be creative 😉

@benpicco
Copy link
Contributor

benpicco commented Oct 9, 2019

What happens when you unplug the device (and it's not powered over that USB connection)

Will it get stuck in that loop forever or will the bytes be discarded?

@ant9000
Copy link
Contributor Author

ant9000 commented Oct 9, 2019

What happens when you unplug the device (and it's not powered over that USB connection)
Will it get stuck in that loop forever or will the bytes be discarded?

Latest commit implements the behaviour I was expecting. The driver will buffer data, without blocking. When the bufffer gets full, it will start discarding the oldest bytes.

@ant9000 ant9000 force-pushed the pr/usbus_cdc_acm_stdio_fix branch 6 times, most recently from e73c224 to ccc113c Compare October 11, 2019 06:34
@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 14, 2019
Copy link
Member

@dylad dylad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some nitpicks on coding style.

sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
@MrKevinWeiss
Copy link
Contributor

@bergzand Have your comments been addressed?

@fjmolinas
Copy link
Contributor

ping @bergzand!

@fjmolinas fjmolinas added this to the Release 2020.01 milestone Jan 10, 2020
@fjmolinas
Copy link
Contributor

@bergzand will you have time to look at this one before 2020.01.15?

Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delays, two remaining comments from my side. Code otherwise looks okay to me. I'm happy to ack this if somebody can give it a final test.

sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
@fjmolinas
Copy link
Contributor

fjmolinas commented Jan 14, 2020

@ant9000 would you have edit time to address? I would like to get this in before the hard feature freeze tomorrow.

@fjmolinas fjmolinas self-requested a review January 14, 2020 21:22
Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Final round of nitpicks, thank you for your patience so far!

sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
sys/usb/usbus/cdc/acm/cdc_acm.c Outdated Show resolved Hide resolved
@bergzand
Copy link
Member

This should be good to go, for good measure I will give this a final test this evening. Feel free to squash to a reasonable set of commits in the mean time.

@fjmolinas
Copy link
Contributor

Testing:

  • reproduce issue on master cherry-picking 09d3d4d

The test doesn't seem to be a valid way of reproducing the issue.

2020-01-15 10:46:08,991 # text 1024
2020-01-15 10:46:08,993 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:08,994 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:08,995 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:08,996 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:08,997 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:08,999 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,000 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,001 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,002 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,004 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,006 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,007 # 01234567890123456789012345678901234567890123456789012345678901234567890123456789
2020-01-15 10:46:09,009 # 0123456789012345678901234567890123456789012345678901234567890123

MASTER

2020-01-15 10:56:47,933 #  reboot
2020-01-15 10:56:48,016 # Serial port disconnected, waiting to get reconnected...
2020-01-15 10:56:49,031 # Try to reconnect to /dev/ttyACM1 again...
2020-01-15 10:56:49,032 # Reconnected to serial port /dev/ttyACM1
2020-01-15 10:56:49,033 # main(): This is RIOT! (Version: 2020.01-devel-1726-g19774-HEAD)
2020-01-15 10:56:49,033 # RIOT USB CDC ACM shell test
2020-01-15 10:56:49,033 # 1 RIOT USB CDC ACM shell test

THIS PR

2020-01-15 10:54:20,812 #  reboot
2020-01-15 10:54:21,063 # Serial port disconnected, waiting to get reconnected...
2020-01-15 10:54:22,084 # Try to reconnect to /dev/ttyACM1 again...
2020-01-15 10:54:22,085 # Reconnected to serial port /dev/ttyACM1
2020-01-15 10:54:22,085 #  test
2020-01-15 10:54:22,085 # 2 RIOT USB CDC ACM shell test
2020-01-15 10:54:22,085 # 3 RIOT USB CDC ACM shell test
2020-01-15 10:54:22,086 # 4 RIOT USB CDC ACM shell test
2020-01-15 10:54:22,086 # 5 RIOT USB CDC ACM shell test

BTW @bergzand any tips of terminal to use to not get a serial disconnect every time the device is rebooted?

@bergzand
Copy link
Member

BTW @bergzand any tips of terminal to use to not get a serial disconnect every time the device is rebooted?

Not really, when rebooting the device, the USB connection between the host and device is lost and the host will (and should) remove the ttyACM%u device and add it after re-initializing the USB connection.

@fjmolinas
Copy link
Contributor

@bergzand are there any other tests you wold like to be ran? I can perform them for you.

@fjmolinas
Copy link
Contributor

Feel free to squash to a reasonable set of commits in the mean time.

@ant9000 please squash! we can avoid running the ci twice.

@bergzand
Copy link
Member

bergzand commented Jan 15, 2020

The test doesn't seem to be a valid way of reproducing the issue.

Is the output the same with this PR and on master? On master it should truncate the output at some point, with this PR it should instead remove old content and show output from some point until the end (expressed in slices it would be something like: master: output[:CDC_ACM_BUF_SIZE] and with this PR it would be output[-CDC_ACM_BUF_SIZE:])

@fjmolinas The interesting behavior is in the connects and disconnects of the terminal. The USB peripheral receives an USB notification when an application (such as miniterm.py or pyserial) opens the ttyACM%u device. The code correctly handling buffer limits while the terminal is closed is something that is the most interesting to test here. I think you've tested this in the last test you performed.

Other than that the tests/usbus_cdc_acm_stdio/ should still provide a decent shell experience :)

@fjmolinas
Copy link
Contributor

@fjmolinas The interesting behavior is in the connects and disconnects of the terminal. The USB peripheral receives an USB notification when an application (such as miniterm.py or pyserial) opens the ttyACM%u device. The code correctly handling buffer limits while the terminal is closed is something that is the most interesting to test here. I think you've tested this in the last test you performed.

In that case I would count as tested. But I get the same output if just using the text cmd without any serial connect or disconnect.

Other than that the tests/usbus_cdc_acm_stdio/ should still provide a decent shell experience :)

Still the case.

Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack!

@bergzand bergzand merged commit 5fd981b into RIOT-OS:master Jan 15, 2020
@ant9000 ant9000 deleted the pr/usbus_cdc_acm_stdio_fix branch January 16, 2020 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: USB Area: Universal Serial Bus CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants