What approach would you take to handle complex USB devices like recording/synthesiser/lights/etc. where you have many controls to monitor?
Depends. Do I make the hardware and write firmware or someone else has already done it? Could all controls fit in standard USB HID class or not? Could recording fit in standard USB audio class? Can everything fit in standard USB classes to avoid writing drivers or custom driver must be developed? Is composite USB device an option? Would there be benefits if all communication goes via simple virtual COM port? When is the deadline? Many, many questions rise and answers guide us toward the solution... Personally, although there are no details in your question, if one has a development control of both firmware and driver parts, it smells to me like the best solution would be to make a composite USB device in firmware, with standard HID, MIDI and AUDIO to avoid drivers on host side, and to expand it with DMX which would request custom USB driver on host side.
How would you approach interfacing to something like this?
Interfacing like writing a driver or like communicating with the device using provided driver? If latter is the case, then I would probably use API (although FT245B used in the device creates virtual COM port so this might also be an option). If former is the case then for this particular device I would avoid USB complexity and use standard MIDI interface since they are both supported and provide the same features, and MIDI interface means much less work then USB. That would save hundreds of hours and a client would be much happier with the bill for the driver. In general, if USB must be used, the chosen solution path for creating the host driver would depend on many things. The easiest path (but highly unlikely with usual short time to market) is when you write both sides of the communication (microcontroller firmware and driver on USB host side, like x86 Windows/Linux PC or some embedded ARM Linux board). Little harder would be when you just have access to the sources or the author of the device firmware. Next would be if you must comply to some USB class or some specific well documented protocol. And of course, the hardest and most time consuming would be to spy USB communication of the device and to try to recognize or understand the protocol and replicate it's functionality (for example you have just Windows binary driver and you need to write Linux driver for the device). All these things greatly affect choosing the right solution path, and there is no universal recipe.
Some interesting links:
http://cryptomys.de/horo/V-USB-MIDI/index.htmlhttp://www.fourwalledcubicle.com/LUFA.phphttp://www.ladyada.net/make/x0xb0xhttp://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1084&item_type=projecthttp://www.mikroe.com/eng/products/view/227/mikropascal-pro-for-avr/http://e-lab.de/AVRco/index_en.html
Recent
