Skip to content

Send an USB remote wakeup if data need to be written #5135

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

Merged
merged 1 commit into from
Jul 21, 2016

Conversation

facchinm
Copy link
Member

On Linux, setting autosuspend_delay_ms to N and control to auto allows the host pc to suspend the peripheral. Some Linux distro (Ubuntu, Mint) apply this behaviour by default.
If the sketch's prints where less frequent than N milliseconds the sketch prints would never arrive.
This patch allows sending a remote wakeup event to unsuspend the peripheral and allow the serial prints to be received.

On Linux, setting autosuspend_delay_ms to N and control to auto allows the host pc to suspend the peripheral. Some Linux distro (Ubuntu, Mint) apply this behaviour by default.
If the sketch's prints where less frequent than N milliseconds the sketch prints would never arrive.
This patch allows sending a remote wakeup event to unsuspend the peripheral and allow the serial prints to be received.
@matthijskooijman
Copy link
Collaborator

This sounds like it has been a fun debugging session, but I guess it's a good thing to fix (can't really comment on the implementation, though).

Is a similar fix needed for the 16u2 on the Uno and similar?

@facchinm
Copy link
Member Author

Quite funny debug session indeed 😄 On 16u2 it shouldn't be necessary, the OS should never suspend a peripheral if it doesn't expose the REMOTE_WAKEUP capability.

The kernel never applies the autosuspend policy automatically (from https://www.kernel.org/doc/Documentation/usb/power-management.txt This means that non-hub devices won't be autosuspended unless the user or a program explicitly enables it ).

In any case, we know how to handle it now 😉

@NicoHood
Copy link
Contributor

Have you tried compiling it for the u2 series? If this function is useless, you could add a #define around it, so we don't use an additional overhead for the small flash we have.

@facchinm
Copy link
Member Author

Hi Nico, I didn't test on 16u2 using the AVR core but I believe it should behave like the 32u4 (so the fix is needed). My answer was about stock 16u2 firmware on UNO (which doesn't expose as REMOTE WAKEUP). The overhead is 16bytes in flash, 0 bytes in RAM so I'd keep it without ifdefs

@NicoHood
Copy link
Contributor

Looks like the 16u2 should support this from the datasheet.

@matthijskooijman
Copy link
Collaborator

matthijskooijman commented Jul 18, 2016

Looks like the 16u2 should support this from the datasheet.

Yes, but AFAIU the regular USB-to-serial 16u2 firmware does not advertise support, so there is no problem. The Arduino core intended for the 16u432u4 does advertise it, so it should also actually support it.

@NicoHood
Copy link
Contributor

There is not a single board available with a 16u4, so I do not understand what you are trying to point out.

@matthijskooijman
Copy link
Collaborator

Uh, that should have read 32u4. I mean the Arduino core that runs on e.g. the Leonardo.

@facchinm facchinm merged commit ce81675 into arduino:master Jul 21, 2016
@cmaglie cmaglie added this to the Release 1.6.10 milestone Jul 21, 2016
@facchinm facchinm deleted the usbsuspend_resume branch September 20, 2016 14:03
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

Successfully merging this pull request may close these issues.

5 participants