UHS notes - not issues - just looking for discussion about uhs30 HOT 6 CLOSED

There are several people actively working on this code; however, If you're the same guy who e-mailed me the other day asking how to clone the repo and other basic questions then I'm afraid you're not ready to discuss anything here.

from uhs30.

Yes, its alive
On Mar 10, 2016 3:11 PM, "VaclavSal" [email protected] wrote:

Anybody actively using / working this UHS?
Like to discuss some issues, but if there is nobody home, why bother.
Please reply first.

—
Reply to this email directly or view it on GitHub
#11.

from uhs30.

Yes, there are folks working here. Be prepared as this code base is very unstable, and if you are just trying to get something to work (like with Arduino) I would suggest moving back to v2.0 or even earlier. A quick google search will also find some other GitHubs that have various mods to this and the original code base perhaps in a form more suitable for sketches.

My project involves a custom MK20DX256 based board (not a teensy) with pure bare-metal arm code. The board contains a MAX3241E and supports host mode. The Kinetis MCU does the USB device work, and the MAX3421E provides host support. I have worked through many issues in the UHS3.0 code to get some level of stability, and have just started working on drivers for various devices (enumeration is very reliable). This setup is using both IRQ and GPIO pins via interrupts to the kinetis, as well as the software IRQs added to UHS30. I found it difficult to work with the .h files containing all of the code, so I broke out drivers into separate .cpp/.h files with each driver deriving from various base classes. HID, and hubs are working fairly with good stability, I have a working FTDI serial port driver working, and just 30 minutes ago, I got Android Accessory Mode to kick in and get configured. (Don't have an android app talking with it yet, but enumeration and switching to AOA is working nicely). There are still a few bugs with hubs plugged into hubs. For example, I have a device (Wifi/Bluetooth interface) that contains a built in hub with two separate devices, one for Wifi and one for the Bluetooth module. Things work nicely if plugged into the host port directly, but if I plug in a USB hub, and then this device, I have problems with releasing drivers correctly when the device is unplugged (hub into hub issue).
As it turns out, the UHS method for reading descriptors doesn't work very well for drivers because of the NAK and timeout requirements and retries of the base code. I wanted the drivers to quickly be able to poll IN endpoints for data with no timeouts and no NAK retries, so I added some code for that.

Once I think this stuff is stable, I will post on github. I don't want to merge back into the original UHS30 code base because of the reorg of the code trying to get away from everything in .h files.

from uhs30.

On Mar 10, 2016 4:37 PM, "marketideas" [email protected] wrote:

Yes, there are folks working here. Be prepared as this code base is very
unstable, and if you are just trying to get something to work (like with
Arduino) I would suggest moving back to v2.0 or even earlier. A quick
google search will also find some other GitHubs that have various mods to
this and the original code base perhaps in a form more suitable for
sketches.

The core is already soid....

My project involves a custom MK20DX256 based board (not a teensy) with
pure bare-metal arm code. The board contains a MAX3241E and supports host
mode. The Kinetis MCU does the USB device work, and the MAX3421E provides
host support. I have worked through many issues in the UHS3.0 code to get
some level of stability, and have just started working on drivers for
various devices (enumeration is very reliable). This setup is using both
IRQ and GPIO pins via interrupts to the kinetis, as well as the software
IRQs added to UHS30. I found it difficult to work with the .h files
containing all of the code, so I broke out drivers into separate .cpp/.h
files

No need to do this, as the inline headers are already C++. The reason for
this structure is to allow full config and control from a sketch.

with each driver deriving from various base classes. HID, and hubs are
working fairly with good stability, I have a working FTDI serial port
driver working, and just 30 minutes ago, I got Android Accessory Mode to
kick in and get configured. (Don't have an android app talking with it yet,
but enumeration and switching to AOA is worki ng nicely). There are still a
few bugs with hubs plugged into hubs. For example, I have a device
(Wifi/Bluetooth interface) that contains a built in hub with two separate
devices, one for Wifi and one for the Bluetooth module. Things work nicely
if plugged into the host port directly, but if I plug in a USB hub, and
then this device, I have problems with releasing drivers correctly when the
device is unplugged (hub into hub issue).

As it turns out, the UHS method for reading descriptors doesn't work very
well for drivers because of the NAK and timeout requirements and retries of
the base code. I wanted the drivers to quickly be able to poll IN endpoints
for data with no timeouts and no NAK retries, so I added some code for that.

Enumeration structure already provides this. There is no need to re-read
it.
As far as NAK, we follow the specs, and your code is wrong.

Once I think this stuff is stable, I will post on github. I don't want to
merge back into the original UHS30 code base because of the reorg of the
code trying to get away from everything in .h files.

Sorry about that, but since the Arduino ecosystem lacks any sane way to
config, it is the only option. Since you are using something else, it
doesn't apply to UHS3

—
Reply to this email directly or view it on GitHub.

from uhs30.

Thanks for Arduino.cc style forum welcome.
I am pretty happy muddling thru the code and if it is too difficult to accept intruders like me I'll continue on my own.
Sorry for the intrusion.

from uhs30.

Emmm.... LOL? Really?
On Mar 10, 2016 11:59 PM, "VaclavSal" [email protected] wrote:

Thanks for Arduino.cc style forum welcome.
I am pretty happy muddling thru the code and if it is too difficult to
accept intruders like me I'll continue on my own.
Sorry for the intrusion.

—
Reply to this email directly or view it on GitHub
#11 (comment).

from uhs30.