Memos From the Cube

In case anyone is wondering, now is mid-year University exam time, which is the main reason for my lack of updates here. Actually, truth be told, discovering the (modern) Battlestar Galactica series has been the main contributor towards my laziness.

After tomorrow I’ll be free from Univeristy for a whole month. That’s great, but I’m going into my usual axiety spiral; not knowing what exactly to do any one one moment, causing me to do nothing and stress about wasting my free time. If my new contract job eventually gets of the ground I’ll have both a source of income (finally - ramen noodles, sleeping on burlap sacks and begging are tiresome!) and a sink for my creative *cough* tallent.

Soon I think I’ll release MyUSB 1.5.1, a very minor update fixing a couple of bugs in the demos and other non-critical aspects of the library like typos and the like. The library is for all intents and purposes done, so barring an ephiphany all updates in the near future will be minor only - no more frenzied development of new APIs.

It’s probably about time I got back to writing my USB book, which I’ve neglected. Hang on, I think I hear the next Battlestar Galactica episode calling me…

Well unfortunately today my laptop’s Vista install decided that six months was far too long living and committed suicide. Eye-witness reports indicate that a bungled auto-update was leaving the scene shortly before the explosion which took out the OS foundations.

I managed to fix the installation with a quick OS repair, but ended up deciding to copy off my data, wipe the disk and start again. The first month or so of owning the laptop was a hard time for the OS, as my Toshiba laptop model’s “black screen of death” (since fixed with a BIOS update) caused many unscheduled system crashes which no doubt would have bamboozled some of the critical components in unknowable ways. That, and the crashes from my early USB experiments led to me decide to reinstall all over again.

Several hours later, and it’s like I never left - score one for external hard disks. I’m still fuming about the latest trend of using hidden “recovery partitions” rather than actual physical OS install disks, but to Toshiba’s credit the re-imaging of the disk did go along smoothly. The only casualty which I’ll be morning for many months yet was an obscure old game called Lands Of Lore which I had installed into a part of my computer outside my profile, causing me to loose the saved game files. That really sucks, as I’ve had the game for at least 10 years and my brother and I are yet to finish it, and the saved game was at the very last obstacle before the end of the game. Oh, how I lament my forgetfulness!

Oh well, at least everything else is back to normal and stable once again. Now for the 9 trillion OS updates…

It turns out that I ended up not being attacked by crazed axe-wielding maniacs - the people I met this morning to discuss the possible contract work turned out to be quite a nice bunch of people, and the meeting went smoothly (to my inexperienced eyes). I’m actually really looking forward to the project now, as it’s going to be a fantastic learning experience, including how to design a complete product with a team including meetings and in person/online collaboration.

Now that I’m back, I’ve released the second and final MyUSB 1.5.0 BETA to the project page for general consumption. This new beta contains a few tweaks, enhancements and bugfixes, readying the project for the final 1.5.0 release next week if all goes well.

The changelog for the new beta is:

• UnicodeString member of USB_Descriptor_String_t struct changed to an ordinary int array type, so that the GCC Unicode strings (prefixed with an L before the opening quotation mark) can be used instead of explicit arrays of ASCII characters
• Fixed Endpoint/Pipes being configured incorrectly if the maximum endpoint/pipe size for the selected USB AVR model was given as the bank size
• HID device demos now use a true raw array for the HID report descriptor rather than a struct wrapped array
• Added VERSION_BCD() macro, fixed reported HID and USB version numbers in demo descriptors
• Cleaned up GetDescriptor device chapter 9 handler function
• Added GET_REPORT class specific request to HID demos to make them complaint to the HID class

EDIT: BETA 2 reflects the final 1.5.0 API. Any changes between the current codebase and the final release next week will be either non-breaking additions or bugfixes, thus it is safe to base new or update old projects off the second BETA code.

As always, the project download and documentation links are available on the project page.

In a few hours I’ll be off to have a meeting to discuss a small contract job at a hospital. I’m decidedly nervous; while I’ve done for-pay work in the past, it has always been with either friends of my family, or via impersonal exchanges over the internet. Today I’m off to meet someone I’ve never met before in a place I’ve never been before to do something I’ve never done before (that’s contract EE work, for the dirty minded amongst you) and I’m a little apprehensive.

In the likely event that the person I’m meeting doesn’t turn out to be an axe-wielding serial killer (at least the meeting is in a hospital!) I’ll be back this afternoon to release the next MyUSB BETA version. The new BETA is mainly just bug fixes (or additions to some demos for more standards compliance), and should just about reflect the final version due next week once I’ve given people a chance to contact me about problems with the BETA.

I haven’t made up my mind about the descriptor element naming I posted about previously, but I’m leaning heaving towards having the compile time option to switch to standards names in the final release.

As a (hobbyist) engineer, I routinely find myself mad at Microsoft. Not because of their products (I personally find the new Office and Vista to be quite good), but because of their crud-tastic approach to engineering.

Microsoft seem happy to define their own specifications (and try to force/coerce others into adopting them), but seem totally unable to follow others. Sometimes even their own specifications are poorly implemented - like the recent OOXML debacle.

Recently I’ve been bitten by their lack of engineering abilities four times. Once, from trying to assist someone into combining Mass Storage and CDC classes into a single device. It turns out Windows won’t allow that because of the way it is built; compound devices are enumerated an interface at a time, and there’s no way to bind more than one interface in a compound device to a single OS supplied driver. At least there’s a hacky way around it, at the expense of compatibility with every other OS on the planet.

Second, through the CDC Ethernet. Admittedly there are two standards regarding this (one newer that the other, after the original was found lacking in several areas), but Microsoft went and screwed everyone over by inventing their own psudo-standard called RNDIS. Want Ethernet over USB? You’ll be writing custom drivers to get it working cross-platform.

Thirdly, their %$#@$ING STUPID XBOX Wireless design. This is a total WTF on several accounts:

1) The dongle has four fixed endpoint pairs, one for each possible paired controller. Why do that, rather than having a single endpoint pair and using some sort of index to distingush the controller to interface with?

2) The entire device and each interface is marked as a proprietary class. One would think that it’s got some super-secret, amazing protocol running underneath it to account for the custom class. Nope - one pair of the endpoints at least are just the USB HID class obfuscated to require custom drivers.

3) Despite being partly a HID device (just obfuscated so that it requires a damn custom driver), it lacks an actual HID report. It appears the returned data is supposed to be interpreted via a known, fixed layout.

They could have circumvented the whole thing by making it a compound device containing:

1) A single USB HID interface, with report descriptors indicating the button layout for the controller. Use report IDs to distinguish between different controllers. That would make the dongle enumerate on any modern OS as a bunch of standard gamepad controllers, no driver required. All the buttons, joysticks and LEDs could then be controlled via the standard HID API.

2) A single USB PID interface, to manage the force feedback. That would allow modern OSes to expose the force feedback capabilities to any modern game, no driver required.

And that’s it. No proprietary drivers, no obfuscation layers, and it would be cross-platform. Of course, any other features which are XBOX proprietary (such as memory cards, etc.) could use a legitimately proprietary additional interface in the device, but the other standard features would still be usable.

Why do they spend *extra* time to re-implement an existing standard, so that it requires more work (for them and others) to use when it has no benefit? Seems like a waste of time and money to me.

My apologies for the downtime yesterday. Haven’t a clue what caused it — looks like a problem with the server provider. Whatever the reason, everything is once again working as it should.

I’ve given my blog a little bit of a face lift via a new WordPress theme. I actually stumbled upon it while looking for a theme for the comical “Glacial Pace” blog my University friends are planning on starting up (based around my friend’s notoriously slow eating pace). While I can’t be certain, the new theme carries distinct similarities to the old, so it probably a newer version by the theme author. In any case, it spruces things up slightly without radically altering the design of the blog so I’ve switched to it.

Based on the few comments to my last entry plus research of my own, I’m thinking of leaving the Ethernet-Over-USB project for a little while. I’ve re-opened my unreleased “StillImageHost” demo code, which will eventually allow PIMA-compatible USB cameras (that’s anything which enumerates as a camera device rather than a Mass Storage device under Windows) to be controlled via the USB AVRs. I’ve already got a few of the commands working, so expect more progress on that soon.

Well the Network ‘08 dinner turned out to be a blast, with lots of interesting people to talk to. Turns out that the guy who invited me, Michael, is a really nice and dynamic guy in person - not that I suspected anything to the contrary. Despite the whole thing looking like some sort of weird pyramid scheme at first glance, the venue was quite nice and I was able to learn a little about the current state of the job market for engineers.

Five minutes ago I managed to get my MIDI demo working. I eventually settled on the “MIDI-OX” software (free for non-commercial use) although any MIDI application capable of MIDI-IN is suitable. After much swearing over the normal MIDI specification I realized that I’d missed a crucial part of the USB-MIDI supplement specification; since the USB protocol can carry many, many MIDI streams, each standard MIDI message has to be prefixed by a byte indicating the virtual cable number and message type. All now works well, and the new demo will join the new HID parser in the next MyUSB library release.

Reading the AVRFreaks.net forums too often can have an unintended side effect - more work. No, I’m not talking about the work of helping others, but rather the work induced by the thoughts implanted by others. A thread about MIDI had me thinking for a little too long, and so I decided to investigate the USB-MIDI class specification.

A little reading later and I’ve found that it should be relatively simple, due to the fact that the USB-MIDI class is built on top of the existing Audio class, which I’ve already experimented with. The only tasks that need to be done it seems is to add in the MIDI IN and OUT terminals to the descriptors, and then the actual MIDI note writing to the appropriate endpoint.

I think it’ll be my next addition to the library - a simple MIDI device which playes notes depending on the joystick position. My only problem is the host-side application; can anyone recommend a freeware application which can play notes sent to the host via MIDI?

I’ll be at the The IET Networking Dinner event tomorrow night, so if any of you are also attending, I’ll see you there!

I’ve caved. I’ve started to write my own book on USB communications, focusing on the Atmel USB AVR line of microcontrollers. No idea how it’ll turn out, but it should be fun either way. The end result should be easy enough for competent AVR programmers to use - since the USBXXX AVRs cover the physical USB layer transparently, the book can skip over all that to reduce confusion. I’ve posted a thread on AVRFreaks about the book outline, so post in there if you want your voice heard!

I got an email from a Stefan Salewski PHD (read: much smarter guy than I) who informed me about his own GPL USBXXX driver. Check it out here. It lacks a lot of the features that MyUSB has, but produces much tighter code due to being a bare-bones approach.

Yesterday I received my brand new RZRAVEN boards, courtesy of Atmel. Unfortunately, like so many others, my units came with broken speakers; good thing Atmel says they’ll be working on ways to prevent such problems when the kits start shipping. No firmware available for the boards yet, so I’m restricted to playing with the default firmware. I’ve already added the RZUSBSTICK board to the MyUSB library, which was a very easy task due to the lack of peripherals on the board and the fact that it’s based on the AT90USB1287 AVR.

I’m working on MyUSB 1.3.1, which will be a minor point release to fix a few minor issues in the 1.3.0 release. The demos will be patched so that more of them work on the AT90USBXXX2 AVRs - the 1.3.0 release has several demos which either use more USB FIFO memory than available or used endpoints which don’t support double banking on the smaller reduced device USB AVRs. Also added are some some new Endpoint and Pipe stream read/write functions, which provide a safe API for the exchange of a set amount of bytes stored in a buffer.

I’ll include the unfinished bootloader, just in case anyone else feels like debugging the remaining flash write code and gets it working.

I’m happy to say that my two month old Toshiba Satellite A200/02H now works flawlessly. After one trip to the repair center and a new motherboard later, I was still having the same random “black screen of death” problems which plague the Satellite series laptops. However, a few days ago Toshiba posted a fix in the form of a BIOS update which resolves the issue. Huzzah!