-
Notifications
You must be signed in to change notification settings - Fork 11
Fs over hs #50
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
base: main
Are you sure you want to change the base?
Fs over hs #50
Conversation
@AndrewCapon @facchinm @mjs513 - I will give this version a try with the different devices we implemented and hopefully everything will work 🤞 Quick note: I will try to see if the issue with the keyboard with a built in hub issue... It may be something similar to the issue, I originally had with it on the Teensy, about the sequences of messages sent tot he hub. More details in the thread: |
I just tried a keyboard with a hub with my multi driver stuff. Basically the underlying mbed stuff registers a hub, but nothing connected to it. I guess the keyboard is running off of the hub. I tried plugging a memory stick into the keyboard and the underlying mbed stuff did not even register a connection. I'm guessing |
Thanks, will take a look, once I have had some more coffee... It is only about 5:15am. Note: this is an independent issue and should not hold up integration of this PR. |
Memory usage change @ ac8c565
Click for full report table
Click for full report CSV
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix the typos in comments detected by the repository's automated spell checker as well as some additional typos I identified through a manual review.
// This effects the GIGA as it has no external PHY which is required in order to run at HS. | ||
// | ||
// 1. Transmitting length larger then packetsize can cause future issues reading, the NAK nightmare. | ||
// 2. Receiving multiple seperate packets can lead to lost data and the need to retry. | ||
// | ||
// So for transmitting we split the data into sizes of <= packet size, we initially set of a single transfer here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// This effects the GIGA as it has no external PHY which is required in order to run at HS. | |
// | |
// 1. Transmitting length larger then packetsize can cause future issues reading, the NAK nightmare. | |
// 2. Receiving multiple seperate packets can lead to lost data and the need to retry. | |
// | |
// So for transmitting we split the data into sizes of <= packet size, we initially set of a single transfer here | |
// This affects the GIGA as it has no external PHY which is required in order to run at HS. | |
// | |
// 1. Transmitting length larger than packetsize can cause future issues reading, the NAK nightmare. | |
// 2. Receiving multiple separate packets can lead to lost data and the need to retry. | |
// | |
// So for transmitting we split the data into sizes of <= packet size, we initially set off a single transfer here |
Fix typos in comment
// This effects the GIGA as it has no external PHY which is required in order to run at HS. | ||
// | ||
// 1. Transmitting length larger then packetsize can cause future issues reading, the NAK nightmare. | ||
// 2. Receiving multiple seperate packets can lead to lost data and the need to retry. | ||
// | ||
// So for transmitting we split the data into sizes of <= packet size and individually transfer them, only calling pPriv->transferCompleted() when all data is sent. | ||
// For receiving we receive all the data and call pPriv->transferCompleted(). | ||
// | ||
// If we get NAKS on the control OUT EPs we make sure that USB_OTG_HCCHAR_CHDIS ans USB_OTG_HCCHAR_CHENA are reset to the correct values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// This effects the GIGA as it has no external PHY which is required in order to run at HS. | |
// | |
// 1. Transmitting length larger then packetsize can cause future issues reading, the NAK nightmare. | |
// 2. Receiving multiple seperate packets can lead to lost data and the need to retry. | |
// | |
// So for transmitting we split the data into sizes of <= packet size and individually transfer them, only calling pPriv->transferCompleted() when all data is sent. | |
// For receiving we receive all the data and call pPriv->transferCompleted(). | |
// | |
// If we get NAKS on the control OUT EPs we make sure that USB_OTG_HCCHAR_CHDIS ans USB_OTG_HCCHAR_CHENA are reset to the correct values. | |
// This affects the GIGA as it has no external PHY which is required in order to run at HS. | |
// | |
// 1. Transmitting length larger than packetsize can cause future issues reading, the NAK nightmare. | |
// 2. Receiving multiple separate packets can lead to lost data and the need to retry. | |
// | |
// So for transmitting we split the data into sizes of <= packet size and individually transfer them, only calling pPriv->transferCompleted() when all data is sent. | |
// For receiving we receive all the data and call pPriv->transferCompleted(). | |
// | |
// If we get NAKS on the control OUT EPs we make sure that USB_OTG_HCCHAR_CHDIS and USB_OTG_HCCHAR_CHENA are reset to the correct values. |
if ((endpointType == EP_TYPE_INTR)) | ||
{ | ||
// Disable the channel interrupt and retransfer below | ||
// TOD: really this retransfer should be queued up and transfered on the SOF interupt based on interval from descriptor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// TOD: really this retransfer should be queued up and transfered on the SOF interupt based on interval from descriptor. | |
// TOD: really this retransfer should be queued up and transferred on the SOF interrupt based on interval from descriptor. |
uint32_t tmpreg; | ||
tmpreg = USBx_HC(uChannel)->HCCHAR; | ||
tmpreg &= ~USB_OTG_HCCHAR_CHDIS; | ||
tmpreg |= USB_OTG_HCCHAR_CHENA; | ||
USBx_HC(uChannel)->HCCHAR = tmpreg; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uint32_t tmpreg; | |
tmpreg = USBx_HC(uChannel)->HCCHAR; | |
tmpreg &= ~USB_OTG_HCCHAR_CHDIS; | |
tmpreg |= USB_OTG_HCCHAR_CHENA; | |
USBx_HC(uChannel)->HCCHAR = tmpreg; | |
uint32_t tmpreg; | |
tmpreg = USBx_HC(uChannel)->HCCHAR; | |
tmpreg &= ~USB_OTG_HCCHAR_CHDIS; | |
tmpreg |= USB_OTG_HCCHAR_CHENA; | |
USBx_HC(uChannel)->HCCHAR = tmpreg; |
Use spaces instead of tabs for indentation, as is done throughout the rest of the file.
|
||
case URB_DONE: | ||
{ | ||
// first calculate how much we transferred, HAL metrics aonly work for IN EPs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// first calculate how much we transferred, HAL metrics aonly work for IN EPs | |
// first calculate how much we transferred, HAL metrics only work for IN EPs |
Yet another go at getting USB Host on Giga reliable.
We now have three defines in
USBUserConf.h
for testing.ARC_USB_FULL_SIZE
andARC_FS_OVER_HS
are mutually exclusive so be careful not to enable both!ARC_USB_FULL_SIZE=1
will run the existing code.ARC_FS_OVER_HS=1
will run the new code, where output transfers are split into packets and input transfers are done full size.ARC_NO_RESUBMITREQUEST=1
will use the HCCHAR register, which I thought would fix the NAK issue, it doesn't seem to do this in all cases. Specifically setup control data.ARC_NO_RESUBMITREQUEST=0
will resubmit any out packets, not fully tested with all devices.So use:
run existing code for testing:
run new code with HCCHAR changes for testing:
run new code with retransmit for testing:
The last case is the one setup by default.