USB Compound Device with Virtual HID Endpoints - Page 1
Forum section: electronics / beginners

author: dobon
author_rank: Newbie
timestamp: December 11, 2014, 10:30:15 am
content: 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 aComposite Devicesolution right now, using myMSP430 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.).ACompound Devicesolution 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 ausb hub controllerand (n) usb device controllers. I would instead prefer to implement a single-chip compound device, but the excellent "USB Complete" by Jan Axelson warns:Quote from: USB CompleteWhich brings me to my question:I have researched some of these 'hub+device' controllers, but none seem to meet my requirements:4 downstream usb portsAbility 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 pinsSpeed 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

author: miguelvp
author_rank: Super Contributor
timestamp: December 12, 2014, 02:22:56 am
content: A PSoC 5LP (32bit ARM Cortex M3 based) or a PSoC 3 (8051 8bit core based) might do the trick, but I have not used it myself for a USB HID yet.http://www.cypress.com/?rID=39404More info about the USBFS component here:http://www.cypress.com/?rID=48924Edit: I don't know how many endpoints you can use, I know it allows at least 2 but it should be burried in the component datasheet:http://www.cypress.com/?docID=48885The downside is that the programmer is a bit pricey but I've heard they are working on making it more affordable,http://www.cypress.com/?rID=38154For example these two PRoC 4 kits include the miniprog3http://www.cypress.com/?rid=102637&source=tabhttp://www.cypress.com/?rid=102638But not sure when they'll be available.As for the actual PSoC5LP dev kit, this one has a built in programmer just to see if you can achieve what you need.http://www.cypress.com/?rid=51577You might be able to do it all with their Pioneer Kit for $25, which is really a PSoC4 but it has a PSoC5LP as the programmer, also you can do your own board and get the chip for under $5.