usb hub support

[catfact]

hit the books

[catfact]

have hit the books. ok there is a kind of hub support implemented in the ASF but it is not enabled and probably doesn't work. it's also overly generalized for our purpose.

all we really need to do is implement the hub class host controller, find up to 2 or maybe 3 devices, and enumerate them. we don't have to worry about hubs-on-hubs, high-speed hubs, or whatever.

see asf/common/services/usb/uhc/uhc.h , uhc.c

[catfact]

if supporting multiple monomes is "priority-high" then this must also be "priority-high" as it is a dependency.

[flyingoctopus]

Bump. Just digging into source now and feel a personal attachment to this gh-issue. Any idea how deep this rabbit hole goes?

[catfact]

it's kind o deep. the ASF sources cited above are a place to start looking.

i'm also totally willing to switch the whole host stack over to LUFA if that proves to be easier... though i don't see any specific indication that it would be for this purpose, iit might be worth a shot to start adding LUFA host code to the avr32_blank template in aleph/utils, and see where that gets you,.. ( @darrengit )

[catfact]

i managed to build the blank avr32 template with LUFA linked. it is easy. so i think that's worth investigating. happy to help and share code if anyone wants to look at this, otherwise i just don't have time.

[ngwese]

A few questions:

• By LUFA are we talking about https://github.com/abcminiuser/lufa?
• Is there any pro/con of LUFA versus the usb bits provided via ASF?
• Hardware wise do we have to worry about power draw? powered vs. unpowered hubs?
• Switching to LUFA; would that require tackling the USB slave / debug serial stuff as well? (I don't have JTAG device nor experience using that kind of thing... wouldn't want to be flying blind while implementing stuff).

[catfact]

1. yes that seems to be the same thing: http://www.fourwalledcubicle.com/LUFA.php
   ... which hasn't been updated in a while. i think dean c got a new job in 2013 and hasn't been putting time into maintaining or extending the lib. maybe there has been progress from other parties on github somwhere.

2. the ASF verison we used has what looks like incomplete implementation of hub support (see: https://github.com/tehn/aleph/blob/master/avr32_lib/asf-3.7.3/avr32/drivers/usbb/usbb_host.c#L1466 , and elsewhere in that file.)
   IIRC, Lufa doesn't even have that. either way it would mean rolling that functionality ourselves from USB spec. it's nasty stuff but certainly doable with determination...

i guess it's possible that Atmel has completed the host stack with newer ASF verisons. but i doubt it since the changelogs i've looked at have been focused on newer parts lines like SAM (their ARM architecture.) makes more sense for them from a business perspective.

3. i wouldn't worry about it because there is just so much variation in current draw, even among monome devices. @tehn might know better but IIRC we were drawing >1A with the biggest bus-powered monome grids and i think maxing out around 1.5A for the total draw on the aleph+peripherals. i would have to look up the specs on the regulator and then estimate the draw for the preamps and stuff. the USB overcurrent pins could be used to conditionally disable the driver in software when appropriate. in any case i don't think there's any danger involved, power regulator will just starve the device before blowing up or melting or whatever. powered hub probably a good idea if there is any doubt, and certainly for something like m128 + arc4.

4. see 2)... if LUFA had support for the functionality we want i would advocate pulling it in and replacing the ASF stack. but i don't think it does. either way, i think we need to do it ourselves, and indeed using a debugger would make the process less painful. it's not difficult to set up the debug bridge with GDB; i haven't tried anything else. if you're really interested i can send you my avr32 ICE dongle, haven't touched it in a while. or if you want your very own, they can be had for ~100$, official atmel version, or substantially cheaper for chinese clones on ebay.

[catfact]

before i forget: we were talking about LUFA in the first place because there was a claim that it provided hub support; on scrutiny this proved to be true for the device stack but not for the host stack (which is more bare bones and also presents a much thornier problem.)

everything i'm saying is recollected from years-old research so do feel free to correct it.

[ngwese]

I just diff'ed asf-3.7.3 (aleph) against asf-3.24.3 (latest) and there is almost no change between hsbb_host.c, bummer.

[tehn]

i don't think the ASF has improved on the hub front unfortunately.

current draw-- current limiting is handled on the hardware side. i doubt
we're detecting overcurrent at this point, however-- usb connection is
simply lost. that said, we're permitting a substantial current draw over
the usb spec, as most computers do now-- ie, apple, to allow high speed
charging.

we've created various outboard grid powering solutions, but the opportunity
for a powered hub would also address these issues.

you wouldn't need to change the avr8 serial debug chip, if that's what you
were asking. you could possibly debug the USB stuff just with serial
printing, though yes the JTAG would be helpful.

brian

On Tue, Jul 7, 2015 at 2:39 AM, Greg Wuller notifications@github.com
wrote:

I just diff'ed asf-3.7.3 (aleph) against asf-3.24.3 (latest) and there is
almost no change between hsbb_host.c, bummer.

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

[catfact]

a couple more libraries have been brought to my attention:

this seems relatively platform -agnostic, and not too hard to grok. unfortunately doesn't support interrupt transfers on hubs, but i'm not sure that would matter for our purposes (i think all the relevant device classes only use bulk transfers, but don't quote me on that...)
https://github.com/Chadderz121/csud/blob/master/source/hcd/dwc/roothub.c

another one. more closely targeted at cortex m3 and m4, and relying heavily on their own HAL, so maybe less directly useful. still might be worth mining for hints.
https://developer.mbed.org/users/mbed_official/code/mbed-src/

we're already using the ASF host library pretty successfully, and it does a lot of low-level interrupt and endpoint handling for us. so i think the path of least resistance is to just fill in the gaps in that library...

[electropourlaction]

I'm just starting up an attempt to connect an stm32 board to the Aleph usb host port, the goal is to get power from the Aleph (communication is by i2c, maybe at a later stage I will look at usb communication too but it's not necessary atm), I need to understand if this issue could potentially stand in the way of what I want to do? I'm done configuring the stm32 as a generic HID controller and crossing my fingers this rabbit hole is not too deep...

[catfact]

You should have no problem using the aleph to communicate with a generic HID device and provide power. If your concern is current draw then that has more to do with the other bits of your circuit than with the device mcu.

[electropourlaction]

I'm not sure if this is the right thread... I'm trying to connect an stm32 but no success so far, are the aleph usb functions made to work with generic HID devices or specific to only monome grids?

[tehn]

any generic HID device should be able to connect to the aleph. tested with
keyboard, mouse, gamepad.

grid uses FTDI.

On Mon, May 23, 2016 at 2:42 AM, electropourlaction <
notifications@github.com> wrote:

I'm not sure if this is the right thread... I'm trying to connect an stm32
but no success so far, are the aleph usb functions made to work with
generic HID devices or specific to only monome grids?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#67 (comment)

[electropourlaction]

oki, then it's on the stm32 side!

[catfact]

so yeah, not really the right thread :)

but anyways:

aleph supports three usb classes: FTDI, HID and MIDI:
https://github.com/tehn/aleph/tree/dev/avr32_lib/src/usb

what are you testing with? if you're using BEES, use the HID operator. since HID takes many many forms, this operator is very basic and generic: for each instance of the op, you specify the byte offset of the word you're intrerested in, and whether the word is 8 or 16 bits wide. you can have multiple instances for different fields. i've used this in performance with an xbox360 controller and a standard mouse.

if you're not using BEES but rather a custom app, implement the relevant handlers for connect / disconnect / RX:
https://github.com/tehn/aleph/blob/dev/apps/bees/src/handler.c#L158-L169

the actual RX data is just in a global variable:
https://github.com/tehn/aleph/blob/dev/avr32_lib/src/usb/hid/hid.c#L14

[electropourlaction]

I'm testing with a nucleo f429zi, however it's beginning to dawn on me that I might settle on a usb power only solution first, it looks like I will need an ftdi in-between if I want to draw power and communicate with the same cable with this board (atm I'm communicating by i2c so just power would be an ok first step), seriously have some reading to do before I continue to crash this thread!

[catfact]

indeed, i'm increasingly unclear on what your issue really is. so far you have mentioned HID, FTDI, i2c, and the USB power rail. but you have not really said what functionaliy the aleph is lacking in any of these areas.

you haven't mentioned USB hubs, which is the topic of this issue. :)

please make a new issue, if there is something specific we should adress, or if you just want to have an open-ended conversation / troubleshooting session, maybe a forum thread would be more appropriate.