Memos From the Cube

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.

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, better late than never in reporting news. As a follow up to my earlier post about ButtLoad’s incompatibility with the popular open source AVRDude programming software, the problem is now resolved. I’d like to publicly thank AVRFreaks user Luke (lfmorrison) for his help - it was he who both debugged the problem and created a solution.

As he hypothesized, the problem was indeed in ButtLoad’s handling of the SPI_MULTI command - I had an increment in the wrong part of a loop, causing it to miss the transferring of some of the SPI data.

That’s all for today. Next week is my mid-semester break, which means time to get some of my Uni assignments done - and time to work on MyUSB. I’ll be needing someone with other USB AVR flavours than the ATUSB1287 to assist in the porting of the library to the other family members eventually, so if you’re interested please email me. Porting of the library will be done after the completion of the Host/Device modes, and after the compile-time separation of the two modes.

It also looks like the MyUSB name is here to stay - gimpy and unoriginal, but I lack any creative inspiration for a better name, and by the lack of emails I surmise that everyone else is too. If the host mode is finished before a new name is chosen, I’ll have to stick with the current codename as the official name of the project.

Well, my adapters have arrived for my USBKEY. They’re so tiny - only seeing them “in the flesh” gives the full impact of just how tiny these things are.

Above is Tom’s photo of his USBKEY, with the adapters mounted. When I have some spare time I’ll be mounting them on my own board, which will make development considerably easier. Having access to a standard pin header for each port means easier interfacing with external devices, like the Trackpad I bought a few months ago (see earlier blog entries) and the as-yet unannounced new “toy” I received.

Actually, I can’t wait for the “toy” to be officially announced so I can blog about it, it really is quite neat. I’ll be writing some nice open source drivers for it in the future, that’s for sure!

I’ve managed to get a few Uni friends interested in my Space game framework, and we’re now all busy working on coding AI modules for it. Very hard, but forces some interesting new thinking patterns and coding styles.

On the projects side, two tid-bits of news worth noting. One, it seems that ButtLoad is incompatible with AVRDude’s signature check. That’s rather strange, as the signature check works fine in AVRStudio, but one of the forum members might have found a reason - the two programmers use different methods to determine the signature. Current analysis points to a bug in ButtLoad’s “SPI Multi” command handling, which is entirely possible due to me being unable to find any programming software that made use of it to test it out. Expect an update on this issue here in the future.

Second item of note is a small update on MyUSB. Development is still underway as always, if a little slow while I wrap my head around a few Host and USB related concepts. I’ve started to move around some of the device code and filenames, to make it consistent with the new Host code.

MyUSB needs a proper name about now, before it gets too embedded. If you can think of a more interesting (and unique) name for the project I’d love to hear from you.

Well, ButtLoad 3.0’s finally out the door. It’s been a heck of a long ride for this project, and it’s certainly helped develop my coding, troubleshooting and design skills. I’m quite amazed that people all over the world use ButtLoad on a regular basis!

ButtLoad 3.0 took a very long time to finish, partly due to the major changes but also due to apathy and frustration at being unable to debug the thing. User’s can’t possibly fathom the amount of hair and sanity I’ve lost over the past few months getting the thing in a working and publishable state. The new non-consecutive HEX file support is actually the second generation, with the first being the reason for the delay; my original implementation was fast and clever, but too clever for me to debug it. What was that old quote again? Ah yes:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan

How true, especially in the embedded world where clever code is required to fit in with the minimal resources avaliable.

In any case, it’s now done and ready for public consumption. Please do notify me of any bugs you find - which there will undoubtedly be plenty! - in the AVRFreaks thread about the project.

ButtLoad’s now pretty close to what I had in mind when I first started the project, thus I feel comfortable with stopping its development for the moment (save for bug-fixes) while I pursue other projects.