Can a USB Device be reprogrammed as CopperLan?

[sounds]

CopperLan is described in a way that implies ethernet as the primary physical link, but there are claims that USB, FireWire, and MIDI devices can also become CopperLan devices. It was pointed out that a MIDI device cannot directly talk CopperLan, but what about a USB Device? It seems possible that the firmware for a USB Device could be rewritten to speak CopperLan.

On a related note, the USB Specifications cover many common Classes of Devices, such that generic drivers can be installed. Custom Classes are also available, but these can be less useful because they require a new driver for every new manufacturer or new model of device released. Are there any plans to create a CopperLan Class for USB such that manufacturers could implement a common set of protocols over USB for CopperLan?

Note: I design hardware, both digital and analog, and develop firmware and software for clients in the music industry. I have designed several commercial USB products, including a few USB-MIDI Devices, and my experience suggests that there is an opportunity here even if it is a little early to define a 'final' CopperLan Class Specification.

Comment: OSC missed out on a serious opportunity by failing to create a USB-OSC Specification with the universal connectivity of USB-MIDI (but hopefully without the drastic failures of design that are prevalent in the USB-MIDI Specification). Of course, OSC is not focused on USB Devices, per se, and OSC also suffers from significant interoperability issues as astutely pointed out in the General CopperLan Q&A section. All the same, I see that a common USB Class Definition is part of an overall solution that facilitates ease of use for end customers to attach various devices and have them function with minimal configuration.

[Copperhead]

CopperLan is described in a way that implies ethernet as the primary physical link, but there are claims that USB, FireWire, and MIDI devices can also become CopperLan devices. It was pointed out that a MIDI device cannot directly talk CopperLan, but what about a USB Device? It seems possible that the firmware for a USB Device could be rewritten to speak CopperLan.

Yes, you're right: a USB piece of gear can be made CopperLan compliant by rewriting its firmware.

On the http://www.copperduino.com website you will find example code (and HW setup) for a USB implementation. (joystick demo)

Just for the record, a couple of years ago we brought to our demo room at the Frankfurt show a Behringer keyboard/controller whose firmware was changed to CopperLan.

The requirements to switch the firmware from MIDI to CopperLan could be hampered by:
- the size of the code memory
- the size of the RAM
- the processing power (essentially impacting the latency and swiftness of the device)

We had a demo based on an Atmel's AT90USBkey board which uses an AT90USB1287 chip, a USB able variation of the well known AVR 8-bit family.

The advantage in these USB implementations is that, contrarily to embedded Ethernet, the actual CopperLan processing occurs in the host computer, the USB board being only in charge of its application job and controlling its CopperLan tasks by RPC (remote procedure call).

[Copperhead]

On a related note, the USB Specifications cover many common Classes of Devices, such that generic drivers can be installed. Custom Classes are also available, but these can be less useful because they require a new driver for every new manufacturer or new model of device released. Are there any plans to create a CopperLan Class for USB such that manufacturers could implement a common set of protocols over USB for CopperLan?

We tried going the Standard Class route but it was very long and full of traps (including some non-technical ones). We may try this approach once again when CopperLan gains more weight on the market.

In the meantime, since we arrived to the same conclusion as you, we opted for a hybrid solution:
We use a Custom Class for the USB IF, and a Custom Descriptor for unequivocal validation.

Without being as transparent as a Standard Driver for a known Class (e.g. flash key), our approach avoids the developer to provide a driver with its product:
- under MAC OS-X : no driver to install; the detection happens automatically
- under Windows, the developer should provide a .inf file (we provide an example, to tweak), and optionally, a .cat file to sign the driver if he wants to. These files are referencing to a pre-installed generic driver that is part of the CopperLan package.