Older blog entries for gwossum (starting at number 6)

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.

A couple of days after I signed up to defend my thesis semester, I became rather nervous since I don't have a specific topic yet.  I began to wonder what made me think I could get it finished by then.  I'd have to pick a topic, probably do some work, write the paper, start the whole review cycle, and so forth.  It suddenly didn't seem reasonable to defend this semester. 

Then my advisor gave me some papers he had read over the summer that he was really excited about.  They were over sensor networks, which is similar to whate I'm doing.  These papers weren't very good.  Most of the ideas presented in them didn't seem very practical or very clear.  I'm still puzzled by one paper on an address free network architecture.  None of the people had implementation of the systems they described, just statistical analysis showing how great it would be if you actually did implement it.  This bothered me, especially since some of the assumptions these papers made don't seem correct.

Thanks to these papers, I'm now confident I can write a good paper and defend it by December.  I have a physical, working implementation of my system, from which I can gather real data.  Based on what I've seen in the other papers, I can simply write on what I have.  I'd like to implement some more features in the protocol, like priority or self-configuration, but those should be easy to do in the time I have available.

Project AKO
Added support for the immediate success extension (ISE) of the AKONET into the send side of the AKOI2C and the receive side of the components.  This makes the data link of the AKONET a whole lot better.  Plus, it's implemented in a way that's fully backwards compatible with non-ISE components.  I need to add it going the other way (components to AKOI2C) now, but that requires a large bit of modifications to the AKOI2C code. 

I got an idea today that the AKOI2C should be implemented as a component.  This is a really cool idea.  The CIF would need some modifications to it to make it more flexible, though.  The way the CIF handles the receive buffer works great for components, but it probably needs to be handled differently for the AKOI2C, since it is connected to the main contoller.

I also think it would be nice for a AKOI2C command to send a packet on an AKONET.  It's not really necessary, but it would vastly simplify the device driver.  I don't want to drop raw I2C functionallity from the chip or device driver, though.  I see a /dev/ako in the future ^_^

A while back, I wrote a wrapper around MSVC's cl.exe and link.exe, to make them accept more Unixish command lines.  I created it for a cross-platform commercial application that was using autoconf/automake/libtool for the build process.  The problem was that libtool always wanted to give the Windows compiler Unix command line options.  I couldn't find a pre-existing wrapper utility (at least not on fm, sf, or google), and so cccl.  I finally released it to the public under the GPL a couple of weeks ago.  It's at http://cccl.sourceforge.net.  It's a stupid program, but it proved incredibly useful for me.

Project AKO
In the past couple of days, I've made some fixes to the AKOI2C firmware and device drivers, and Chris made a mod to the PC-AKO reset circuitry.  Thanks to these changes, the AKOI2C is now working exceptionally well.  I was banging on it as hard as I could for over 36 hours without even a hiccup.  I also fixed a bug in the component's I2C stack, so they actually send their initializations properly all the time now.  With the low level stuff seeming to work nicely now, I can move onto the higher level AKOLIB and AKOAPI.

On a non-technical side, I got most of the Project AKO stuff checked into CVS on Sourceforge.  There's still a couple of schmatics and board layouts missing, but all the firmware is there.  I also just finished rolling a release of it.  And I also created two mailing lists on Sourceforge for Project AKO development.  One is for general Project AKO development, and the other is specifically for the AKOI2C.

Internet Imperialists
Internet Imperialists was a web-based game I started way back in March of 1997.  I modelled it after Amit Patel's Solar Realms Elite (SRE) BBS door game.  I really enjoyed playing SRE back when I was in junior high and high school.  There's now two code bases of it, an older one in C using flat files for storage, and a newer in Perl using PostgreSQL for storage.  Unfortantely, I haven't actively developed it in about a year, due to a lack of time.  This is a shame, because it was mostly complete, and it was a fun little game.

I had hoped that at someone would take over the development from me, but that never happened.  I've gotten emails inquring about its status, but never from anyone who could take over developing.  I eventually threw it into the attic of my brain.  Then, last week, I got an email from someone who said he might actually be interested in developing it, but I haven't heard back from him.  But his email did server to pull Internet Imperialists down from the attic.  I figured, hey, maybe someone here would be interested in taking over development.  The webpage is at http://inetimperial.sourceforge.net.   If you'd be interested in doing some development, or have any questions, you can contact me at gwossum at acm dot org.

I just fixed the reset problem the AKOI2C has had ever since its beginning. It turned out to be an uninitialized state variable. On a POR, the register file gets cleared with 0's. But on an MCLR reset, the user registers in the register file are untouched. The uninitailized variable caused the AKOI2C to sometimes reset into an indeterminant state, which would cause the chip to lock up and quit responding. I'm annoyed it took me this long to find it.

Got the AKOI2C firmware, device drivers, schematics, and board layout into CVS over at SourceForge. Also released an AKOI2C tarball with the stuff in it. Go to http://ako.sourceforge.net/akoi2c.html to see it.

Nathan Brown's R'n'B
Played a strange show out in Denton last night (I play violin in a band called "Nathan Brown's R'n'B"). We showed up at Rubber Gloves in Denton, and they told us we were going on second. So we left to go get something to eat. We got back about 10:10 or so and the first band was setting up on stage. At about 10:35, they tell us we're going on first, and the other band has taken their stuff off the stage. So we tried to setup really fast, but it still took us untio 10:50 to get ready. The sound guy comes out and tells us we can play until 11:05, which doesn't make any sense because the delay is their fault. We play three songs, and then they tell us we have time for a "quick" song. So we played the longest song in our set. ^_^ We only got to play half the set, which is a shame because it was sounding really good. It was the first performance I had used my new effects processor, and the violin sounded really nice.

Finally got a web page up for Project AKO over at SourceForge, with lot's of pictures. No source code yet, though. It's going to take another day or so to get that in order to put up there.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!