Hey all, long time viewer of the EEVblog, first time on the forums. I've read the rules, but please let me know if I've messed anything up.
I am working on a USB project which involves implementing a variable number of downstream HID devices (between 1 and 4, depending on the user's configuration), and presenting them to the computer on a single upstream physical USB connection. The physical input device modules contain their USB Device Descriptor, and interface with the USB controller via SPI. The user may configure the device to have multiple identical modules (ie: having identical device descriptors), all-different modules, or with any combination of occupied and unoccupied module slots:
I have researched two possible options for presenting these physical input devices as HID Class USB Devices on the host computer:
- Composite Device - One bus address with multiple, independent interfaces for each HID device. Ex: a webcam with a microphone, with each presenting as a USB CDC class interface.
- Compound Device - Present the HID devices as if they were connected to an 'internal USB hub'. Each device (including the 'hub') has a unique bus address. Ex: a printer with a 5-in-1 memory card reader built-in.
I am equipped to create a
Composite Device solution right now, using my
MSP430 F5529 Evaluation Kit, but this type of a solution is not ideal as it requires the entire device to be re-enumerated in the case of the user changing the input module configuration on-the-fly (fair warning: I haven't written that re-enumeration code yet, so there may be some issues with my understanding here. If nothing else, I know that this type of re-enumeration procedure would be unorthodox.).
A
Compound Device solution is better, as it more naturally lends itself to on-the-fly input module configuration changes and isolates each module to its own device on the host bus, meaning that a change to one module will not require re-enumeration of all other modules. A typical n-way compound device will be an (n+1) chip solution, featuring a
usb hub controller and (n) usb device controllers. I would instead prefer to implement a single-chip compound device, but the excellent "USB Complete" by Jan Axelson warns:
Controller chips for hubs contain dedicated silicon to perform hub functions. Due to timing requirements, implementing a hub function with a general-purpose device controller chip isn’t feasible. For single-chip compound devices, chips that contain an embedded hub and a generic device controller are available.
Which brings me to my question: I have researched some of these 'hub+device' controllers, but none seem to meet my requirements:
- 4 downstream usb ports
- Ability to map downstream usb ports to the 'generic device controller' part of chip, which in-turn interface to the input modules via SPI on GPIO pins
- Speed is not terribly important, unless my calculations are off.
I'm starting to think that my single-chip hopes for this compound device just aren't going to work out, but then again I am very inexperienced with USB (and embedded solutions in general). To be certain, I am not married to the single-chip solution I've presented above; I am mostly concerned about minimizing overall production + (sub-)licensing cost, while maintaining a compound device architecture. Maybe a more orthodox solution would be overall cheaper?
Also, how does the whole vendor id sub-licensing agreement work with compound devices? Would a 4-way compound device demand a minimum of 5 vendor id licenses from the ~10k budget? Are there any generic vendor ids I could assign to the HID devices to maximize my usage of that budget?
I hope that the EEVBlog Forum community will help to point me in the right direction, or direct me to resources that may help me solve this problem for myself. I'm sure I've missed some important details, so please don't hesitate to ask for clarifications. Thanks for reading <333
Home
Help
Search
Login
Register
