Hello,
Because performance concerns the USB driver has been modified by removing the "queued" API, now the driver is generally simpler and only supports linear transfers. The Serial-USB driver has been modified to work with the linear API and uses a new buffering mechanism.
At application level there are no visible changes except that the SOF callback must call sduSOFHookI(), it is used for periodic buffers flushing.
The change allows to use DMA for PMA<->Memory transfers where a DMA is available, the queues requirement made the use of DMAs too complex or impossible.
Existing drivers must be modified by removing references to the queued code, matter of minutes.
Something I am considering is adding to the USB driver a synchronous API like other drivers: usbReceive() and usbTransmit() would complement usbStartReceive() and usbStartTransmit(). That would make the driver easier to use without Serial-USB.
Thoughts?
Giovanni
[INFO] Changes to USB driver
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [INFO] Changes to USB driver
Hi,
Changes finished, look at the new \testhal\STM32\STM32F7xx\USB_RAW demo, it uses the new synchronous API and, I hope, it is easy to understand and efficient. It implements a CDC device without the Serial-USB abstraction.
The direct USB API is recommended when the maximum performance is required from USB.
While at it I implemented various optimizations to the USBv1 driver, it is smaller and faster now.
Giovanni
Changes finished, look at the new \testhal\STM32\STM32F7xx\USB_RAW demo, it uses the new synchronous API and, I hope, it is easy to understand and efficient. It implements a CDC device without the Serial-USB abstraction.
The direct USB API is recommended when the maximum performance is required from USB.
While at it I implemented various optimizations to the USBv1 driver, it is smaller and faster now.
Giovanni
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: [INFO] Changes to USB driver
Is there a way to have a timeout for the synchronous API?
I would like to have a standard chunk to read, but if no more data comes for xxx ms or so, then it should return.
I would like to have a standard chunk to read, but if no more data comes for xxx ms or so, then it should return.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [INFO] Changes to USB driver
It would be problematic to abort an USB transaction once it is started, this is why there is no timeout. The wait is only interrupted if the USB becomes non-active.
Giovanni
Giovanni
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: [INFO] Changes to USB driver
Ahh, I see. And with non-active, is it enough that no data is coming or does it have to suspend or something like that?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [INFO] Changes to USB driver
By non-active I mean a reset or suspend condition, it happens when you unplug the cable for example.
Giovanni
Giovanni
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: [INFO] Changes to USB driver
Sorry, this confuses me. For sending data I understand the usage, but how is this then applicable for read operations?
As you generally cannot know the amount of data that is coming, so the transaction might wait indefinitely if there is no continuous data stream.
Or is there a way around this? Maybe I have misunderstood its usage?
As you generally cannot know the amount of data that is coming, so the transaction might wait indefinitely if there is no continuous data stream.
Or is there a way around this? Maybe I have misunderstood its usage?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [INFO] Changes to USB driver
The read operation continues until the specified number of bytes have been received OR a short packet is received. This is how the host signals that there is no immediate data to follow, it is part of the USB specification.
You could specify 1024 and receive a single byte. The amount you specify is what you can handle in a single transfer.
Giovanni
You could specify 1024 and receive a single byte. The amount you specify is what you can handle in a single transfer.
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 9 guests