Memos From the Cube

Many people have contacted me requesting I implement some class or other. I’ve tried to implement the majority of the standardized classes (or at least classes with well defined specifications) where possible, but sometimes I’ve deemed it just isn’t feasable. I thought I’d list the evaluated-but-not-implemented classes here, and get some feedback as to other classes to implement, or ways around the limitations I have found.

Printer Class (Device): Possible, but just not useful. This would require a complete printer output language such as PostScript to be implemented - a big job in itself. I can’t think of any real use for a printer device demo.

Printer Class (Host): Possible, but too many variations. The printer USB class is just a simple wrapper for the printer’s display language. Different printers implement one or more of many different display languages, and not all printers conform completely anyway. Mandating some requirements would work, but would limit the demo to only a small subset of all USB printers. I still might tackle this, if there’s enough interest.

Bluetooth Class (Device): No use, and too complicated. Enough said.

Bluetooth Class (Host): I’m still evaluating this one. There’s a lot of specification to go over but initial evaluation was not good; the host is required to support up to 64KB packets from the Bluetooth dongle - far more RAM than available. I do want to give this a go as I do see some real uses for it (Serial over Bluetooth for one) and I’ve been told that it’s possible to get away with much smaller packets.

Test And Measurement Class (Device): This is a standard USB class from the USB-IF, but most OSes don’t carry any prepackaged drivers or ways of utilizing a TaMC device. I’d need to find good existing (free) products for all major OSes before I do anything with this, as a demo with no host application is rather useless.

Test and Measurement Class (Host): It’d be neat to plug in a USB oscilloscope into the board and have it log information, but I haven’t got any TaMC devices to test this with.

SideShow (Device): Vista-only at present but hopefully will see more exposure in the future. Currently I’ve got a working implementation, but the need for a XML parser and the host ignoring the device’s limited capabilities means that this has been put on hold. Microsoft have indicated that changes to the SideShow system will be released in November which will make SideShow implementation on small microcontrollers much easier, so I’m holding all further development on this until then.

SideShow (Host): Again, no hardware to test this with. Might be neat for the future to have any sideshow device act as a nice GUI for projects.

CDC EEM/ECM (Device): There’s too many Ethernet-over-USB class choices. The current library implements Microsoft’s RNDIS class, which also works on current Linux kernels. I’ve heard CDC ethernet implementations are spotty across the board, so I’m not sure which other classes to go with. For now I’ve played it safe and used RNDIS which should work across all Windows versions in addition to newer *nix distributions.

CDC EEM/ECM (Host): Haven’t given much thought to this one. If my USB modem uses this class, I might have a go at writing up a host for it so I can make a public webserver from my RNDIS demo code.

Still Image (Device): Haven’t thought of a real need, but also might do this one in the future, interest permitting. If you want to see this or another class implemented, leave a comment or email me.

Video Class (Device): The Video class requires high bandwidth devices for fluid motion. I don’t think the AVRs with their Full Speed USB will be fast enough to make this worthwhile.

Video Class (Host): Same as the above. The USB AVRs just don’t have the USB speed to process video.