Is USB hub support planned in the future?

[lpcware]

Content originally posted in LPCWare by sturzi on Tue Oct 01 02:12:58 MST 2013
Hi,
I am currently evaluating the LPCUSBlib and saw that there is no hub support.
Is this feature planned for a future release?
If not, has anyone successfully implemented this feature? I'm guessing it would be quite a bit of work...

Thanks and Best Regards

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Fri Dec 20 09:18:22 MST 2013
Next hint: If you're editing Pipe_ConfigurePipe() add the DeviceSpeed variable, too. You will need it for low-speed devices.

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Wed Dec 18 03:22:19 MST 2013
Reread the the errata sheet. All lpc176x chips are affected, too. Well, this is a problem.

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Wed Dec 18 02:27:44 MST 2013
Hi!
Thanks for the hint. I'm using an LPC1766, so I should be fine, I guess (and hope).

There's another error in the library, which needs fixing: In Pipe.h function Pipe_GetPipeToken tries to get the pipe direction from reading the upper bit of the EndponitAddress (mind the typing error). This will never return a PIPE_TOKEN_IN, because it never gets added to the EndponitAddress.

You'll have to change the Pipe_ConfigurePipe() function in pipe.c and add the "Token" somehow to the EndpointAddress variable. (hint hint: if token == 1, bit 7 must be 1)

Now it should be possible to get data from IN pipes and not get stuck in an endless loop.

[lpcware]

Content originally posted in LPCWare by jdupre on Tue Dec 17 14:52:18 MST 2013
Check the errata for your chip.  The LPC177x/8x has a bug involving a "dribble bit" which will cause the USB subsystem to hang.  The dribble bit may be introduced by "hub switching skews".   I read that to mean that the system may not be stable with a hub.

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Fri Dec 13 02:51:30 MST 2013
Next hint in case someone wants to integrate hub support.

The device address a connected usb device gets is hardcoded. You'll have to edit Pipe.c and change Pipe_ConfigurePipe to be able to set the address the pipe should point to. Shouldn't be too hard. (You can remove the FIXME annotation afterwards)

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Wed Dec 11 08:41:37 MST 2013
Note: I found the part where the Device address gets set. It's a it above the empty USB_Host_SetDeviceAddress function. But why this function is still there, although it's not needed, I have no idea.

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Wed Dec 11 04:51:36 MST 2013
So I did some digging. And it looks like the lpcusblib is derived from LUFA: http://www.fourwalledcubicle.com/LUFA.php

It is a USB library for ATMEL devices and if you take a look at the code, then you'll see some similarities. The author of LUFA doesn't seem to have integrated the Hub feature either, I guess because it's a lot of work and memory management is not easy (not running out of memory at all).

[lpcware]

Content originally posted in LPCWare by matthias.heinz on Wed Dec 11 03:19:17 MST 2013
Hi,

well I am very interested in an answer, too. I've taken a deep look at the source code and there's a lot of work to do to support hubs. If I've understand the code correctly the connected device doesn't even get an address. Have a look at Host.c line 174, there's: USB_Host_SetDeviceAddress(USB_HOST_DEVICEADDRESS). Now have a look at what the function does. Nothing, exactly. It's against the USB spec, but if you're just using one device on the bus, you don't have to change the address from 0, because there's only one device on the bus.

There are a few todos in the code. Pipe freeze, unfreeze are just blank functions. Even the version.h is not maintained. It'd be great to hear when they're planing to release a version different to 0x000000.

If NXP would provide a git repository it would be easy to write patches and fix some of this flaws. But instead it's made very hard to get a grip on the programmers...