Wow. It's been so long since I posted a diary entry. This probably is due to two things. 1) Being excessively busy. I'm pretty sure now I actually died sometime last week and my body just hasn't realized due to high caffeine levels. 2) Forgetting my password.

Thesis and AKO
Much has happened with my thesis and AKO. I didn't graduate last semester. I'm planning to graduate this semester, though. Or at least I've deluded myself into believing that. I went down and registered for graduation on Tuesday.

New Processor
We (Chris McFarlen and I) have switched AKO from using PIC 16F877's to Atmel ATmega128's. There's not even any comparison between them. The ATmega is faster, has more program and data memory, better peripherals, and it costs less. And last but not least, we can code in C and compile with gcc! No more nasty PIC assembler! Only in the embedded world would getting to use a 30-year programming language get you excited.

The only bad thing about the ATmega128 is that it's only available in a 64-pin TQFP package (a surface mount package). But this isn't really an issue for two reasons. First, the Kanda development boards are really nice, so you can you do alot without designing and building your own boards. Second, the company we work at has board prototyping equipment we can use to build our own boards easily, without having to shell out a lot money to a board house.

Error Detection and Recovery
One of the assertions in my thesis is that for a network using I2C as the physical and data link layers, an error detection and recovery scheme is better than an error correcting scheme. This is due to the fact that with the receiver can request a bad packet be resent, and that I2C has a low probability of corrupting data during transmissions. That sounds reasonable, but there's no experimental evidence actually showing that I2C has a low error density (at least not that I can find). So I decided to show this my self. Run I2C over varying lengths of cable, show error density as a function of cable length, determine if errors are bursty in nature or obey a Poisson distribution, calculate lambda values as functions of cable length if they are a Poission process. That would make some great experimental data. Except I haven't gotten a single error in a full 24 hours of tests so far! I guess that proves it has low error density, but it's not very interesting data. I'm even pushing it way beyond spec. The spec lists the maximum run as 1 meter. Right now, I have it running over a 50 feet of flat satin cable, perhaps the noisiest cable in existance. I've even gathered the cable up into a big wad, but still no errors. Much more robust than I had anticipated...

Embedded GUI's
The company I work for has a new product in development, which at its core is an ARM based embedded Linux system. The device has a built in a 2-(or 4)bit grayscale QVGA LCD display, and can be hooked to an external VGA monitor by using a PCMCIA VGA card (yes, such things exist! Probably for products just like this). We need a GUI for it obviously. We wanted to use Qt/Embedded, since we use Qt for all our PC software development. Plus, Chris has the Qtopia Qt-based environment on his iPaq, and it's pretty nifty. But the Qt/Embedded runtime license is going to be too expensive, unless Trolltech wants to make some kind of deal with us, which doesn't seem to interest them. If we used Qt/Embedded, the runtime license fee would account for 10% of the cost to manufacture a unit!!! Seeing as a how a major factor in choosing Linux for embedded systems is no runtime license fees, shelling out this kind of money a license for just the GUI toolkit is outrageous. Trolltech should realize they'e losing a lot of business with the high license fee. This is a shame because Qt is an excellent piece of software.

Since it's looking like we won't be able to use Qt for this device, I've begun investigating alternatives. The most promising so far is PicoGUI. My quick search indicated that it was the most mature and featureful. I remember the main developer on the project, Micah Dowty, from back when I was active in the uClinux and uCsimm stuff. I remember when announced starting PicoGUI on one of those lists. I haven't really looked into it much yet, though. I doubt that it's as easy to program in as Qt (what could be?), but I'm more concerned with whether or not it's mature enough to be used in product.

I think there's a gtkfb or something, for doing embedded GTK+ stuff. But, both Chris and I dislike GTK+. And don't think that's because I'm a Qt person. I converted to Qt after using GTK for a couple years. So did Chris. As long as PicoGUI is in a usable state and not too dificult to program, I imagine we'll end up using it. Anyway, the gtkfb stuff is only in the unstable GTK tree, so it's not like it has a large maturity advantage.