-
Notifications
You must be signed in to change notification settings - Fork 32
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
…eensy4-rs into mitchmindtree-rtic-example-usb
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
bors try |
bors r+ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.