Memos From the Cube

Thanks to all who’ve been sending me word on where MyUSB is ending up. I really get a kick out of seeing it incorporated into some very interesting projects, and I’ve been adding links to the projects I know of on the MyUSB project page.

Congratulations to Sean D’Epagnier for getting his Magnetometer mouse sold on Sparkfun. Sean was kind enough to send me a free unit partially for my help getting the MyUSB powered portion of the device working, and partially so I could test out the device in the sothern hemisphere. I posted a small rundown of the device previously, but go check it out again if you missed it the first time. It’s quite a neat product, and works a little like a tethered Wii controler, in that roll, pitch and yaw of the device controls the cursor on the screen.

I was alerted yesterday to another project built with the MyUSB library, however unfortunately for me the site for it is written in German. A quick Google translation later and I now have the jist of the project - it’s a 868MHz wireless protocol analyzer powered by an onboard AT90USB162 AVR microcontroller. I haven’t the faintest idea what the 868MHz band is used for, so if you are more clued in than I, please leave a comment.  The dongle looks quite professional, and no-doubt is being heavily used by whoever it is that uses 868MHz communications. I look forward to being illuminated on its exact purpose.

I’m also pleased by the number of members who have signed on to the new MyUSB Support Google Group in the last week. There’s already been a bit of good discussion about the project (or topics related to MyUSB in some way) so I do suggest that all those interested come and join in — you might learn something!

Currently in my idle time at University between classes I’m investigating Ray Tracing, by writing a simple ray tracer in Java. Once I get my spheres lit by some proper lighting via rays traced from the primary ray/sphere intersection I’ll post some screenshots. For now, it’s just a lot of uninteresting multicoloured spheres.

Good progress with my new book (currently entitled “USB and the USB AVR Series Microcontrollers”), which is coming along nicely. I’ve had to learn a few new things about formatting in Microsoft Word - specifically the auto-table of contents, and the sectionalized footers.

A big thanks to my proof-readers, Ross McKenzie, Nard Awater and Darren McInnes. They’ve already provided plenty of useful feedback which is helping shape the text. If you want to have your own say on what you’d like to be in the book, send me and email or leave a comment.

Also please check out the great work by Julian Beard on his Wikimedia Gallery page - Julian has provided several Public Domain images for the book. Great work, they really are first-class images.

Not much to add on MyUSB development; I’ve added a fully-interrupt driven (including control requests) mouse demo to the project, as several people have been looking for one. No release scheduled in the immediate future, as I still need to find more improvements to make to justify a whole release.

EDIT: I’ve posted the current book outline to the thread on AVRFreaks, so that others can comment on it.

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’ve been pleasantly surprised to see a fantastic blog post about my old ButtLoad project on someone else’s site, complete with a few neat pictures and a trip report for the construction of a version modified using Nard Awater’s plans to make it USB enabled. I do recommend checking out the post, it’s a fun read. Great to hear ButtLoad’s being useful!

I’ve now modified the USB DFU bootloader included with MyUSB slightly, as I just realised that the different target AVRs are supposed to return different PID (Product ID) values in the USB descriptors so that FLIP can identify the chip model. That and other minor corrections will be in the 1.3.2 release. Thanks to everyone who’s been emailing me with questions, comments and bugs about the project.

Yesterday I thought I’d try something a little different, and see if a lecture style presentation would be a suitable replacement for traditional text tutorials. I whipped up a few slides on the basics of USB (download it here) and posted it to AVRFreaks for comments. The general consensus - which I agree with having tried it out - is that text tutorials are superior for complicated topics, although I believe the narrated lectures would work for getting basic concepts down.

Well, I’m floundering a little for things to do (other than watch Stargate, and work on a small commercial application, that is) so I had a go at improving DynAlloc, my auto-defragmenting memory allocation library - available from my site separately on the AVR Experiments page, or as a part of MyUSB. The new code is slightly smaller and more efficient than the old.

By making use of the avr-lib-c optimized memory functions memcpy and memset, the need for my own code to replicate the functions is abolished. The avr-lib-c versions are assembly optimized (and thus slightly smaller) but also provides the benefit of being a separately linked function which can be called from the user-code without having to use up more flash than the CALL instruction.

I also changed the way the library works; now the first hole large enough is used, rather than looking for increasingly larger holes. That drastically reduces the number of searches the code has to do, but increases the need for defragmenting. It’s a good tradeoff however - the time used for the defragments should be much smaller than the time wasted doing the repetetive searches for exact-sized holes.

New laptop is awesome. I love the way I can control everything with my voice, mouse/keyboard or mobile phone (via bluetooth). Found some oddities with Vista, but no show-stoppers so far — I’ve been surprised at how well all my AVR tools and software behaves with it.

I’m pleased by the downloads of MyUSB - there’s been 42 in the last 9 days alone. While not a mind-boggling amount, it is not bad for an obscure project and shows that at least *someone* is interested in it.

I’ve been working on developing a commercial application of the DB101 board, from Atmel. So far I’ve been happy with the speed at which I can develop applications for the DB101, however I’m not hitting the limits of the Atmel-provided monster library. Understanding and modifying such a large codebase to allow for the features I want (menu separators, non-static dialogs) is a real pain, but I’m making progress.

I’ve also just updated the ButtLoad project source, to compile on the latest version of WinAVR. Unfortunately the most recent versions of AVR-GCC caused the size of the compiled binary to blow out past the allowable size, so I’ve added in the –relax linker option to change the CALL opcodes into the shorter RCALL opcodes where possible to save space. It now once again compiles (only) with the latest WinAVR, with the latest avr-libc. You can grab the modified code over at AVRFreaks.net.

Well, twenty four hours premature. But still - if you visit here tomorrow, you need to heap-sort your priorities!

I’m now convinced that the Mass Storage Host code is correct, with the addition of a new function to wait while the device is busy. It seems the correct method is a spinloop, looking for NAK signals on the BULK IN data pipe. Calling the new function before any read or write operations now causes them to work just fine, rather than the code locking up (while waiting for the data response from the device that won’t come) after more than one operation is executed within the time it takes the device to get ready for the next command.

Today and late last night I coded up something which I dreamed up while riding in the car - an auto-defragmenting, dynamic memory block allocation library. It’s operation is quite simple from an algorithmic standpoint, but the end result is a nice dynamic memory allocator with no fears of memory fragmentation after a long period of time. I’ve posted the initial version of the code over in a thread at AVRFreaks.

Happy holidays!

Yesterday I started my latest contract work, based on the new DB101 board from Atmel I reviewed here previously. It’s my first time programming the board; my interactions with it until now have been restricted to using the default firmware’s terminal mode as a micro-debugging terminal.

I have to say, Atmel’s done a good job with the code. The widget library has a few eccentricities that I had to track down and fix (you can select the title of a dialog with the cursor, for instance) and new features to add (non-selectable spacers when blank strings are passed to a choice menu) but it’s been pretty usable. My only gripe is that it doesn’t seem possible (or at least easy) to display icons or pictures simultaneously with forms — the two are incompatible using the Atmel widget/form/image libraries and will require some hacking on my part.

I’m back to working on the MyUSB Mass Storage Host code, the last demo I have planned for the library at the moment. I fixed some issues with the host samples and the library that was causing unforgivingly standards compliant devices issues (I’m looking at you, Toshiba USB memory stick!). That means I can now get the same behavior with two different memory sticks of mine, rather than seperate behaviors. It still doesn’t work mind, but I’m getting closer with each code edit and debug session.

Also changed in the library, is that the API for sending, checking and receiving data in both endpoints and pipes has been changed over. Previously it was all done by the In_Clear/Out_Clear/etc type macros, which worked for both control requests and normal IN/OUT requests, but wasted flash memory. Now they are seperate Setup_In_Clear/Setup_Out_Clear/etc and FIFOCON_Clear macros which means smaller code usage, and more technically-correct code.

Today marks some real progress with the Mass Storage code - it’s almost finished. With the latest code I can now format a 16MB flash disk, give it a name and drop very small files onto it (less than 64KB or so each). For some reason folders or any files larger than about 64KB aren’t reading (or writing) correctly, and have the data above the ~64KB mark all repeating garbage. I’ll have to look into that and try to suss out the source of the problem.

My previous problems with the formatting was down to a few mis-calculations in the MODE SENSE command, as well as a few bugs in the READ/WRITE command (one of which was a missing check for the endpoint recieved flag, resulting in writing and reading before the host was ready). Tests show that the host doesn’t seem to use the READ SENSE (10) command at all, so I’ve thrown all that code away in favor of just the MODE SENSE (6) command, which is definitely used and required.

With any luck the example will be finished by Friday, when I get my second semester University exam results.

After submitting my “atomic.h” header file (which dealt with the problem of atomic access blocks in a easy manner) to the avr-lib-c project about a year ago, It’s finally gone into the CVS repository. That gives me a nice warm feeling - I’ve now officially contributed to the project in some small way.

My new “interrupt.h” header file is also almost ready, pending any extra change requests. Having to make the header files for the project has reinforced my love for working solo on projects. The red tape to get a simple change into a public collaborative project is enormous; first any changes have to be discussed, then written, then documented, then reviewed, then any changes made before it is incorporated into the source mainline. It’s rather reminiscent of the “Vogons” and their over-the-top bureaucracy in Scott Adam’s “Hitchhiker’s Guide to the Galaxy” novel. Being the sole programmer for your own project gives you a lot of freedom to make the changes you want to make in a timely manner.

I’ve recently updated the MyUSB main source (again) as well as the Mouse Demo source to reflect the new advancements in the library. I’ve also solved the problem of being unable to easily determine which events are not hooked in the user application, by a quick Java application I wrote up this morning. That gives birth to a new “HelperApps” directory of MyUSB, which houses any Java applications I make to automate MyUSB library related tasks for building and for the end-user. Having to make a whole Java applet for a simple task is a little overkill, but is cross-platform, and gives a nice formatted list of the unhooked events by checking the MyUSB events header files, and the target application’s linker MAP file.

The helper application is yet to make it into the source on my site, while I fix up the bugs and get it suitable for general use.

SWATVAC week has now started, which is the week of holidays before my exams start. Next week I’ll be doing my exams proper, and I’m petrified.

UPDATE: My new Interrupt.h header file has now also made it into the CVS. Hurrah!