Memos From the Cube

It’s been a great week for my parts collection, with a few packages arriving recently. I’ve only got a few minutes, but I’ll give an overview of what I’ve recieved in the last week.

First up, I forgot to post an image of the boards I recieved from Donald Delmar Davis - (yes, that crazy guy, although to be fair that post was in response to the ongoing discussion here). I don’t have a macro camera around, so this blurry shot will have to do — for better photos, check out Donald’s blog posts here and here. Actually, on the same site another member has built the Benito and shares similar sentiments to mine - it’s damn tiny! The blue boards are Dorkboards (bare bones ATMEGA168 mounts) and the yellow are the USB “Benito” multi purpose boards, currently standing as a USB to Serial converter, SPI programmer and a MIDI keyboard.

Next, a package from SOC Machines. Larry was kind enough to send me two of their USB 10 boards (no link, as their site doesn’t currently mention it) and a “Ferret” ATMEGA64 board. The latter has a coin cell holder on the bottom, so it can be deployed in remote locations. I’m still trying to figure out how to hook up my JTAG to the USB10s so I can program their onboard AT90USB162s, but I’ll get there in the end. These look like great boards, and once the documentation becomes half decent I can see plenty of people giving them a go.

Finally comes my package I received tonight, from AVROpendous Inc., more specifically from Matt. Matt was kind enough to send me a whole bunch of neat parts, including one of his AVROpendous (AT90USB162 powered) boards, many different kinds of LEDs, a LED matrix, microphone, female headers for my USBKEY, crystals, capacitors, buttons, a breadboard and a whole bunch of other stuff. The AVROpendous board didn’t seem to like the trip through the courier much — I need to resolder the USB connector as it currently won’t enumerate to a host unless I use my thumbnail to ensure good contact between the board and the micro USB connector — but it really is a fantastic and simple bit of engineering. I can certainly recommend it to all those looking at low cost USB experiments, as it is very simple to prototype with, and has onboard HWB and RESET buttons just like the USBKEY.

While my current tasks are to fix up the MyUSB demos to ensure proper standards compliance, I also plan on writing a Bluetooth stack, which will combine with MyUSB to drive low-cost USB bluetooth dongles. Bluetooth modules are very expensive per unit, so by combining a low cost dongle with a low cost USB AVR, many people should be able to benefit. However, with all these fun packages arriving, I might take a short break and see what I can come up with using all the components I’ve received. If you have any project ideas, share them via the comments.

MyUSB 1.5.3 is well under way, with a release due exactly “when it’s done”. I don’t believe in setting concrete release dates and then either kill myself trying to meet a arbitrary deadline, or release substandard code. Until there’s a reason to fix a release date (e.g., for projects funded/contracted out by others) I’ll continue to try to release when I feel the current code base is ready.

To that end, the focus of the next release is mainly standards compliance. With all the noise I’ve made in the past (both on my blog, elsewhere and to my friends — forgive me Alan!) about forcing a painful death to all those who deviate from the standards, I’ve since discovered through use of the USBIF compliance tool quite a few bugs in the MyUSB library and demos’ implementation of the USB and class standards. This next release will hopefully fix that, with all devices now passing the Chapter 9 request compliance tests, and the HID demos passing the HID class tests. Mass Storage has a little way to go, with code needed to handle the infamous “thirteen cases” of wonky requests to the device. Once all the demos pass the relevant standards tests, 1.5.3 will be released.

The next MyUSB release will contain two “new” demos, which are actually just modifications of the current demos. The first is “KeyboardMouse”, a dual HID interface demo implementing both Keyboard and Mouse features to show off multi-interface single class devices. The second is “DualCDC”, which uses Interface Association Descriptors I wrote about previously to implement two independant CDC virtual serial ports in the one compound USB device.

On that note, I want to thank everyone who has contacted me about the library so far - knowing people are using it motivates me to keep improving it. I really appreciate the emails I get when people passionately describe what widget they are working on based on MyUSB. The latest email I’ve received is from Matt about his new AVRopendous project, a darn cheap open source/hardware AVR development board with a twist. The twist is a literal one, with the board mouting 90 degrees (perpendicular) to a breadboard, for easy prototyping. Matt’s promised to send me a couple in the mail, so I’ll be writing more about them when I get my hands on them. Assuming they arrive in the next week, it’ll be the first non-AT90USB1287 powered device I have to test out the library on, so I can ensure future compatibility with the smaller USB AVR range.

My thanks to everyone who has donated to me so far. University is a full time commitment, so the only work I can do is small contract jobs. Having people donate to show their appreciation helps me out quite a bit. Actually, I think that making the library MIT licensed was a great decision, as it helps get my name out in the wild for future jobs.

A few days ago, I recieved word that the Bluetooth organization has released their specifications publicly for free, rather than to members-only (which it used to be, as far as I can remember). I’ve downloaded the Bluetooth 2.0 and the Bluetooth USB transport standards, which I’ll hopefully be able to implement on top of MyUSB. Commercial Bluetooth modules are usually either raw HCI or fixed Serial class only, and are frightfully expensive, while HCI USB dongles are only $4 or so each. If I’m able to create a Bluetooth stack that runs on the USB AVRs, this will drive down the implementation cost to under $10 or so per unit and (as an added bonus) the resulting device will not need to undergo any wireless testing as the pre-tested and sealed dongle would be used as-is. Once I start on that, I’ll branch it off as a seperate project that ties into MyUSB and make it GPL, with alternative licensing avaliable for a small one-time fee.

As a final bit of news, last Fridat I purchased a legitemate license of Microsoft Office 2007 Ultimate (RRP ~AU$1300) for the princely sum of AU$79. I actually REALLY like the updated ribbon interface, as it makes every task easy to find and use, unlike previous versions. The special University student-only offer was first made avaliable last year over at It’s Not Cheating, but I missed it the first time. Checking back last week shows that it’s once again back on, so I bought a license key. If you are an Australian TAFE or University student, you are most likely elligable, so go grab it before they kill it off again!

Actually, if one was not clued on to these things, one would dismiss the site as a scam, due to the stupudly low price and the currently non-functional “Click here for proof” link. Microsoft’s really boned it by not fixing up the site so that it provides adequate verification, but last year when the site was first up it had all the proof one needs (including a page on the official Microsoft website about the offer and the site). The proof is still available on the Microsoft site - but now one has to search for it manually rather than clicking the link on the purchasing site. At any rate, other than the dumb form only showing US states and not Australian states, it all works like a charm and now I’m the proud owner of the latest version of Microsoft Office.

I found an interesting presentation today from the “Sketching in Hardware ‘08″ conference, something of which I’ve never heard before. I find the presentation interesting for many reasons, but one of them is definitely the mention of MyUSB - and there’s a nice looking USB board in the presentation too, which presumably uses MyUSB (since the library is mentioned). It’s nice to see even a little momentum being built up about MyUSB, as the more people using it the happer I become.

Since he seems to be bursting at the seams, I’ll also put another mention to Casainho’s Bicycle POV project over on Google Code. While the use of MyUSB is ancillary (used as a command and data transport from the host) the project itself is quite spectactular, and the latest pictures of the finished prototype boards are top-notch. All the best to Casainho, and I only ask that he take a picture of the final design showing a MyUSB/FourWalledCubicle themed picture ;).

Actually, It’s been an interesting week. On Sunday night I battled over timezones with another user, to help him get the MyUSB Mass Storage demo working on his custom AT90USB162 board. It turns out I’ve done the dumb thing of making the endpoints in the demo double banked (why do I keep doing this?!) which doesn’t work in that situation on the AT90USB162. Writing demos that work across the full USB AVR range is difficult when I only have an AT90USB1287 handy, but hopefully that will change in the near(ish) future and I’ll be able to fully test out the demos.

In lieu of payment for my assistance on Sunday, the user has agreed to send me a few of his custom boards. The boards themselves are (deliberately) simple - they’re actually business cards which will have my name, contact details, website and the like printed on them, with my resume and a few odds-and-ends located on the card’s dataflash, accessable when plugged into a computer over USB. It seems like a rather cool idea in my mind — a business card where the firmware of the board itself is an example of my skills — which is why I agreed to grab a few. Now all I need to do is figure out what to put on the card’s 1MB of space, other than my resume, picture and contact details. I’ll post pictures of the cards when they arrive, but the user should be posting his own information about them on AVRFreaks soon.

It also seems that the MassStore demo is broken on XP, but not for the usual reasons. The demo itself works fine as a disk — but Windows XP refuses to format the dataflashes if they’re not already formatted (which they are from the factory on Atmel’s demo boards). This is due to XP requiring the implementation of a few SCSI commands marked as non-mandatory, which nevertheless cause problems if not present. Fortunately I have backups of the old code in my local SVN and was able to re-implemented the needed SCSI commands, which are simple dummy handlers anyway.

This semester we’ve move on from blasphemous TI microcontrollers into the exciting world of CPLDs. That means I now have to learn the VHDL language, something I’m already hating. VHDL, in my experience, looks like the illegitemate inbred offspring of C, BASIC and Delphi. So many well established syntax patterns are broken in the language it makes my head hurt, and my body wish for a more C-like language for the chips.

Two days ago I received in the mail a nice shiny new toy, courtesy of Sean D’Epagnier over at www.digitalsurveyinstruments.com - a new magnetometer/pointer device. Powered by MyUSB, this little critter can serve either as a “3D mouse”, where the computer’s mouse pointer moves according to the rotation of the device, or as a magnetometer sensor which can collect readings for curiosity, amusement and (possibly) legitemate survey uses.

The design and quality of the device is top-notch, and it’s a blast to play with - although not without the occasional bug as the system is still in development. I’m quite excited to play with a real, proper design made from MyUSB, and all the more excited about just how damn neat the thing is.

Sean’s been busy working on both this and the larger, full magnetometer design, with mountains of firmware to dig through on his site along with schematics, documentation and a host-side communication program. Following the lead of other designers the unit can be put into CDC mode, enumerating as a virtual serial port for terminal-like control over the settings and status of the device through either Sean’s custom program, or through a standard serial terminal. This flexibility allows other software to interact with the device easily through standard serial APIs, which makes porting or creating compatible programs a much easier task than a custom USB interface with custom driver would afford.

I haven’t had much of a chance to really play with this thing yet other than use it to control my mouse and surf the web, so it’s going to be a fun couple of days.

Today was spent doing what seems to be my new favourite hobby - reinstalling Windows on my laptop once again. This time the reinstall was sparked by something screwing in the OS chewing threw mountains of memory for no discernable reason; a good half gigabyte chunk of RAM was totally MIA and unaccounted for. After having the Aero interface kill itself (out of memory) while trying to do nothing more than play a DVD on my system with 2GB RAM, I backed up my data and started the system reinstall.

This morning I was actually doing my second favourite hobby (neither this one nor the above I enjoy, for the record) - fixing bugs. An email from a MyUSB user indicated that the current Mass Storage demo fails to work, so off I went to investigate.

First, I narrowed down the release revision which showed the symptioms - 1.4.1 (good) to 1.5.0 (bad). No surpise there; the differences between the two are striking due to the addition of DoxyGen documentation comments, and many code changes to make the library more uniform and inline with the USB specification names and mandates. Next I did my second MyUSB bug-fixing trick, transplanting the working demo code onto the new library (fixing up any changes in the process to make it compatible). After that too failed to work, I was able to determine that the fault lay in the library code itself, rather than the demo application.

My JTAG showed that the code was failing to get out of a spinloop, waiting for the Mass Storage IN data endpoint to become ready to write to. Further probing showed this was due to the endpoint being permenantly stalled, preventing it from ever becomming data-ready. Honestly, I’m a FIRM beleiver that all AVR users need a JTAG - those who cannot see the utility have obviously not had access to one for any useful length of time. The units high cost is quickly offset by the hours saved debugging using more primative methods such as serial logging or (gasp) LED indicators.

What puzzled me was that the storage demo only stalled the data IN endpoint when the command sent from the host was unable to be processed. Not a rare occurrence; the demo only supports a limited (mandatory) subset of the SCSI command set, while the host tries to use the more obscure (but more efficient) commands where possible to speed up the transfers. However, the spinloop the code was getting stuck in was after the loop waiting for the host to un-stall the endpoint via a standard Clear Feature endpoint request.

That, coupled with my previous experiment telling me the fault lay in the library pointed to the problem — the Clear Feature standard request handler code was broken. A SVN diff showed the cause; between the two versions I had altered the code slightly, removing a critical endpoint mask from one of the parameters from the host. Adding it back in fixes the problem.

For those unable to wait for the next release, you can fix the code manually. In MyUSB/Drivers/USB/LowLevel/DevChapter9.c, the second line of SB_Device_ClearSetFeature() should be changed from:

uint16_t wIndex = Endpoint_Read_Word_LE();

Into:

uint16_t wIndex = (Endpoint_Read_Word_LE() & ENDPOINT_EPNUM_MASK);

To make the code work once again.

Yesterday I made up my semester 2 university timetable, and it’s a doozy! With five subjects each with homework, I can unhappily kiss most of my leisure time goodbye.

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.