Automated Qt GUI Testing
There really doesn't seem to be any good automated GUI testers out there.  This is especially true for the main toolkit I use, Qt.  But I just had an idea for relatively easy way to do it.  It will allow recording and logging of events in the GUI, which is great since users never tell you what they REALLY did to make your program crash.  You could then look at the logs to figure out how the user actually made the program crash/misbehave.  You could also replay the log to take the drudgery out of testing your fix.  Finally, you could create automated tests.  That parts harder, as you would really need a nice test case editor to put together tests.

I'm really excited about this and want to start coding it RIGHT NOW, which is bad because I'm really tired and I need to get up and go to work in the morning.  This weekend I'll start up the code, and release it to try to get other developers interested.  I can really see it in my head.  The last part of the project, the test case editor, is going to be really big.  But I think it'll be really nice.  The only thing is, where am I going to get the time to work on it?  Then again, why would I want to do it?  I'm an embedded systems guy with an interest in music.  An automated GUI tester would be a great thing, but it keeps my from doing embedded and music stuff.  The core library that makes it work is incredibly simple, though.  I can write that, and maybe get other developers interested in writing the test case editor.  That is the way open source works, after all.

Thesis
I just finished a paper on the scalability and performance of multimaster I2C in sensor networks, and submitted it to a conference.  I'm going to start working on a paper this week on error detection and recovery for I2C in sensor network applications.  That paper should come together fairly quickly, it's just a matter of writing it all down in a coherent fashion.  My thesis advisor says that if I take the information in these two papers, combine them, and elaborate a little bit, I'll have my thesis.  Unfortunately, the deadline to submit a final copy for 72-hour review is in less than 3 weeks.  (I didn't know what any of the deadlines were until 2 weeks ago.)  And I don't have a committee.  D'oh!

AKO
We got some samples of the LTC4300-1 hotswap buffer, and Chris got the smart hub layed out.  We should be able to build a smart hub pretty soon.

I got the transmit portion of the AKO stack done for ATmega uC's.  The receive portion is kindof a low priority, since I'm working on that paper which will get rolled into my thesis.  It turns out my problem all along was that the ATmega can detect/generate an "illegal TWI condition", which requires special handling to recover from.  The part of the data sheet which tells you that is hidden remarkably well.  Once I handled this special case, the code worked fine.  I like the AVR uC's a lot better than PIC's, but the PIC's have much better data sheets.

I need to start updating the AKO SourceForge stuff with all the new AKO stuff.  I just haven't had time with my thesis and working.  Must increase caffeine intake...

AKO Stuff
My analysis of I2C's error density has revealed some rather interesting and unanticipated results.  First, I2C does have an extremely low error density, even when you push it beyond the maximum capacitance the spec allows.  The errors also tend to be clustered, rather than obeying a nice, spread out, Poisson style distribution.  This indicates errors are mostly due to noise in the environment.  This was also expected.  Now the unexpected stuff.  Within an I2C frame, if any bytes are corrupted, the most likely scenario are that two bytes are corrupted.  I have no good explanation of this situation, other than perhaps the noise creating the errors is spanning across two bytes.  I also observed that occasionally frames are missing bytes.  This is most likely due to noise interferring with the ACK from the slave to the master, changing an ACK to a NACK, and causing the master to abort the transfer.

Now for the really weird stuff.  I was also observing the throughput of I2C over the different cable lengths.  In each experiment, everything was exactly same, except for the length of the cable.  As the cable length (and thus the cable capacitance) increased, the throughput decreased.  Dramatically.  A 100 ft cable only had 43% of the throughput of 2 ft cable.  The master was supposed to be transmitting with a 400 kHz SCL rate in all the setups.  Upon close examination of the I2C specification, I2C has a scheme on the SCL line to allow slow slaves to slow down the transfer rate to the maximum speed they support, or even pause the transfer if, for instance, they need to service an interrupt.  It also serves to synchronize the clocks between multiple masters on the bus before arbitration kicks them off.  This SCL handling scheme is referred to as clock stretching/clock synchronization, depending on whether slave or master nodes are triggering it.

In my scenario, the bus was triggering it.  With the pull-up resistors, the bus lines act as an RC circuit.  Thus signal transitions don't occur simultaneously, but obey RC charge and discharge curves.  As the line capacitance increases (without the pull-up resistors changing), the RC constant increases and the curves become more gradual.  This increased slew time on the bus lines appears like another master performing clock synchronization, or a slave performing clock stretching.  This results in the automagically slowing down the SCL clocking rate in response to the bus, rather than nodes attached to the bus.  Furthermore, I believe the SCL rate which is converged upon (and thus the throughput rate) is the maximum that the bus lines are capable of reliably supporting.  This auto-throttling effect is not documented anywhere that I can find, nor is it predicted by anything that I can find.

On less therotical AKO items, Chris and I discovered the LTC4300-1 2-Wire Hot Swappable Bus Buffer.  We believe this chip will alleviate all the flakiness we were having with our hot swap setup.  It will also allow us to create an active hub, as opposed to our current passive hub which merely connects all the ports onto the same backplane.  With the LTC4300, there shouldn't be any backplane disruptions when a port is connected.  Also, if any component connected to a port becomes faulty and pulls a bus line or lines low, a microcontroller on the hub can detect the probability of this situation, and begin disconnecting ports, until it has disconnected the offending port and returned the bus to a usable state.  It can also force a STOP condition on the bus if that is required to return it to an idle state after disconnecting the faulty port.  We're also going to put transistors on the power lines of all the ports, so that the uC can attempt to reset faulty components.  The one thing is that to make it really work right, we need to know at any given point in time if a device is plugged into a port on the hub.  The only way we've really figured out how to do this is with a sense line, which means 4-conductor flat satin cable won't cut it anymore.  However, I don't think we need to move onto a IEEE1394 style connector.  By using the LTC4300's on an active hub, I think that we can hot-swap fine just using 5/6-conductor flat satin cable with RJ type connectors.

We have samples of the LTC4300-1's on the way, and we have a prototype active hub designed, utilizing an ATmega103 as the uC.  I think we can get an active hub working pretty quickly.

Crashing Pagers
Yesterday, I was working on some routines to transmit alphanumeric messages to POCSAG pagers.  My routines had some serious "issues", it would appear.  I attempted to transmit "HELLO WORLD" to a pager.  Instead, the pager started dumping out a bunch of its internal canned messages, all garbled up. "CALL OFFICE NOW CALL OFFICE NOW COME BACK HOME NOW LOVE YOU SO MUCH TAKE CARE MEET YOU AT THE SAME PLACE HAVE A GOOD TRIP APPOINTMENT IS CANCELLED CALL BACK..." and on and on.  Eventually, the pager crashed and had to be reset.  I think I'm going to keep these routines around ;)

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.

Thesis
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 ^_^

cccl
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.