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.

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.

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