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

De-couple SysTick and USB; support USB and RTIC #91

Merged
merged 24 commits into from
Jan 2, 2021
Merged

De-couple SysTick and USB; support USB and RTIC #91

merged 24 commits into from
Jan 2, 2021

Conversation

mciantyre
Copy link
Owner

The PR separates the USB and SysTick drivers, so we can use USB CDC logging and I/O without running SysTick. Before this PR, the USB driver depended on SysTick for timing a polling loop. With this PR, the USB driver no longer depends on SysTick, and we can use these BSP features independently.

The PR addresses the limitations noted in #66 and #64. Now that we can use USB without SysTick, we can use the USB module with RTIC. The PR adds two RTIC examples that use USB for logging and direct CDC I/O.

The PR includes breaking changes throughout the USB interface. These changes should support BSP power-users who want to understand USB read / write events. The changes also make USB peripheral ownership explicit in user programs, and reduce the responsibility of the BSP. See the CHANGELOG for the specific breakages and migration tips.

This PR supersedes #66.

mitchmindtree and others added 20 commits July 5, 2020 16:28
Instead of busy looping in the usb_serial_write method, we will
permit a partial message write. The caller will need to handle
incomplete writes by themselves.
Don't silently drop errors, or pretend like they can't happen.
Don't block and fail when all transfers are active. Instead,
recycle all of the other non-current TDs.

By not recycling the current TD, we leave stale data in the
transfer queue. This is a won't-fix issue; it should be considered
when writing a Rust-based USB driver.
Update examples, docs, and tests
Remove caveat from BSP docs
We only link against it if the feature is enabled. We can skip
the copy if we don't need it.
After this commit, users are required to call usb::poll() themselves.
We recommend that they do this by defining the USB_OTG1 interrupt
handler, and calling the poll() method in the implementation. The docs
guide users towards the ISR approach.

The change supports advanced USB usage in RTIC. An RTIC user can now
implement the ISR, and check the poll status to see if there's data
from the host. Without this kind of change, the user would need to
poll the reader on an interval. Users can still do this, but now they
can schedule a "read from USB" task as necessary.
Leftover from some debugging; that shouldn't be there...
Just in case this ends up used in an embedded system. We'd want to
know that there was some issue with the build, and not just think
we're receiving no poll status.
@mciantyre

This comment has been minimized.

bors bot added a commit that referenced this pull request Dec 26, 2020
@bors

This comment has been minimized.

If you try to log just after initializing the USB stack, the device
might not be configured. This results in a return of 0 from serial
write, which fails the logging assert that all data makes it way
into a transfer descriptor.

We now signal the "not configured" error through the interface, and
we allow unconfigured errors to pass. The updated USB example was
sufficient to demonstrate the issue, then show that the issue was
resolved.
We can add a check for configuration into the logger's enabled()
check, and we can skip USB writes in the writer if the device isn't
configured.
Doubting that usb::poll is reentrant, so mark it unsafe, and tell
users they need to serialize their calls.
@mciantyre
Copy link
Owner Author

bors try

bors bot added a commit that referenced this pull request Dec 26, 2020
@mciantyre
Copy link
Owner Author

bors r+

@bors bors bot merged commit 3dd6135 into master Jan 2, 2021
@bors bors bot deleted the usb-rtic branch January 2, 2021 16:41
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.

2 participants