✨ USB endpoint impl on stm32f103c8 #96
Draft
Conversation
This file contains hidden or 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
But this issue could be due to how I have the board wired up. `mod-stm32f1-v5` has swapped USB data pins which needed some fixes to the PCB which could be messing up the signal integrity.
The enumeration process is now very fast. The issue seems to come down to missing packets/events and responding to the wrong events. Rather overwriting the current command buffer, a circular buffer can be used to manage new messages coming in while we attempt to handle the current. I also believe that the usage of the ACT boolean was also to blame for the issues and slowness. The ACT boolean was being changed while the code was returning a response to the host. The problem is that the host can be quick and respond with an answer around the time we are printing to the serial port. At the end of the function we set act to false which means we miss a SETUP packet. The host then waits for us to respond then it send a new message. All of this confuses the host and it sometimes attributes this to having "multiple configurations" and will show up as "Composite Device" on mac using lsusb.
Extract the common parts of the control endpoint write operation into the write_endpoint function and leave the control endpoint specifics to the control_endpoint_write.
It turns out we do not need to over allocate 2 byte for the CRC16.
NOTE: Connecting to the port is fast, but reconnection takes a few seconds on mac. This is due to the `endpoint.write()` that is stuck waiting for a response from the HOST but it never comes because the host isn't asking for data from that EP.
In the demo, we use a write timeout to determine if the serial port has been disconnected. Now that we are no longer stuck in the wait for response, connect/disconnect works very well and is very fast.
NOTE: fixed the issue with data above endpoint size being ignored. This was due to the endpoint length being incorrect. The previous descriptor's length was much larger than 16 bytes and when the endpoint was sent data longer than its length, it ignored these. Now with the correct length, we get all of the data.
Closed
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.
No description provided.