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

sam4l: usb: don't just queue resume in #1901

Merged
merged 2 commits into from Jun 4, 2020
Merged

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented Jun 2, 2020

Pull Request Overview

While working on #1048 #1893, getting UART.tx to work (sending from device to host) I noticed that transmissions only worked when a character was received. I tracked it down to this change.

Basically, we want to ask the host to send by asking to resume the IN endpoint. The SAM4L driver handled our request, but then queued it until some later event (hence why it didn't work until some receive event). With this change the SAM4L driver now immediately handles our resume in request.

I'm not sure why it was queued in the first place.

Testing Strategy

This pull request was tested by using hello_loop and console_recv apps on imix with the CDC driver.

TODO or Help Wanted

What am I missing? What was the queue for? Maybe this change is good enough since I don't know how much interest there is in debugging the SAM4L USB stack.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make format.
  • Fixed errors surfaced by make clippy.

no idea why this was written this way
@bradjc bradjc added the sam4l Change pertains to the SAM4L MCU. label Jun 2, 2020
Copy link
Contributor

@brghena brghena left a comment

Choose a reason for hiding this comment

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

I'm convinced this was an oversight to not be here.

There is a crazy amount of indirection going on with endpoint states that makes this pretty hard to follow. But I'm pretty sure that if you are ready to resume the endpoint, there's no reason for it to sit around in the Delay state anymore. Moreover, that this solves the problem in practice convinces me.

Copy link
Contributor

@brghena brghena left a comment

Choose a reason for hiding this comment

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

Assuming you're also convinced that this is the right change, we should modify the comments.

chips/sam4l/src/usbc/mod.rs Outdated Show resolved Hide resolved
chips/sam4l/src/usbc/mod.rs Outdated Show resolved Hide resolved
@brghena
Copy link
Contributor

brghena commented Jun 4, 2020

My opinion is that there seems like some unnecessary design choices in the SAM4L USB stack. However, since we're more focused on the nRF platforms in the long run, doing little things to get the SAM4L working in mostly in its current state seems good.

Co-authored-by: Branden Ghena <brghena@berkeley.edu>
@brghena
Copy link
Contributor

brghena commented Jun 4, 2020

bors r+

@bors bors bot merged commit 05a0938 into master Jun 4, 2020
@bors bors bot deleted the sam4l-usb-ctrl-out-resume branch June 4, 2020 22:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sam4l Change pertains to the SAM4L MCU.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants