Memos From the Cube

I’m currently right in the middle of my mid-year exams, so I’m not heavily developing like I normally am — but I have managed to squeeze in a little bit of coding over the last week in between the studying and blind, crippling panic. As such, there’s no great triumphs to report just yet, only some small wins.

Firstly, I’ve spell-checked the LUFA codebase again, including (for the first time) the manual pages. I’m well known for atrocious, terrible, awful and all-round bad spelling, so this at least should make the manual text look a little more professional. I managed to misspell “mispell” in the changelog when reporting some other spelling corrections a long time ago, which just about caused my computer to implode in a fit of irony. On the plus side, since I spell checked the actual code a while back, the new changes are cosmetic only. Nothing worse than finding the API of a library has functions with misspelled names, something I’ve endured first hand with a terrible PHP mailing list library.

Secondly, for those who missed it the first time, there’s a new Mercurial mirror for the LUFA codebase, to compliment the existing Subversion and GIT repositories. They’re all synced to the same code on my machine, so which you use is up to you. Convenience is best!

Also, I am still working on getting RFCOMM up and running for my Bluetooth stack. I’m in the process of adding all the control-channel multiplexer commands needed to establish channels between devices, and on the whole I’m fairly happy. My Linux machine no longer reports any errors when trying to send data to my LUFA device via RFCOMM, although the actual data is queued forever as my code does not yet send the proper “go ahead” flags the sender requires before it will transmit.

Actually, working on Bluetooth has made me realize just how amazing it is that anything we use actually works at all. I shudder to think of the layers of code involved in such complicated schemes such as visiting a website on a PC through tethered bluetooth phone. The transport alone would involve at least L2CAP, HCI, TCP, IP, PPP, and HTTP, and that’s just for a “simple” request. The biggest accomplishment your computer will ever achieve is turning on — anything else it does is just a bonus. In the case of my cheap Toshiba laptop, that “extra” functionality is promptly turning off again when I try to use it due to overheating caused by me being cheap and buying a poorly designed laptop.

I’ve also been pondering the possibility of adding hub support to LUFA again, which was on my mind a while back ever since Atmel told me it wasn’t possible, before adding it to their own stack. Granted, it’s only possible in a limited manner, but even that would be enough for many applications. My last attempt caused me to get tangled up in some of the details, so I’ll be mocking up the APIs again first this time so I can get a handle on how it would work. Right now I’m thinking of having it as a separate Hub class driver, which would internally handle the device “context switches” needed to reconfigure the pipes and set the Host address.

My server logs indicate quite a number of people accessing this page (that aren’t bots), which I found rather astonishing — after all, I wouldn’t read this junk. However, since I know people are reading this, I get the opportunity to reach out to you all and invite you to prioritize my LUFA development. Let me know what order I should be tacking the following – and add your own requests if you wish!

1. Bluetooth Stack
2. USB-TMC Demos/Class Drivers
3. Hub Support
4. AVR32 Port
5. ARM Port
6. Better Documentation and Tutorials
7. Compiler Ports