I had a rare day yesterday. Something actually worked.

I am working on my RC4 project, trying to wrap up the last few priority issues. Well, I was looking into an issue - that was more like just a question in my mind - and in the process discovered a number of issues.

Let's see...do I try to even explain it here? If I do, it probably won't make sense to anyone but me, but I'll try, anyway. I have what I am now calling the "Trigger Input" (formerly "Channel 5") that can be programmed to sample an incoming signal connected to it in order to control the engagement of Fail-Safe mode. When it is not programmed to be in that mode, it simply samples any signal that comes in and the pulse width can be read as a 16-bit value (13 bits, really). If signal is lost, a read always returns the value of the last signal received. But when it is programmed to control Fail-Safe, it returns zero whenever no signal is present (i.e. it does not return the value of the last signal before signal went away).

There's a lot more to the story than that, but this particular story began with the question, "why does this return zero in this mode?" There was a reason for it, but it was a reason I never documented (in my 238-page development journal).

The answer I won't even go into, since considerable familiarity with the code is necessary for a contextual foundation, but I wound up revisiting an issue (that I thought was unrelated) that I addressed three days earlier. It was a classic example of tugging on one string here to disturb other strings elsewhere.

I realized I had to implement another solution. It was clear now what I had to do without disrupting anything else. I formulated a solution in my head and started at it. Sometimes, the best and easiest way to represent a design is to implement it, so I dove right in - no preliminary design docs to get in the way. I don't know how long it took me to revise the code (I had to back out a previous "fix" while at the same time implement the new one), but it seemed like a long time, and I wound up in the end about breaking even on the instruction count, so I was pleased. Strangely, I was also very confident.

I wasted no time and I assembled the code (no errors, first time!), and immediately burned it into the PIC16F628 microcontroller chip (PIC2 in RC4). I plugged the chip into RC4, and it worked.

It just worked!

So, anyway, as much as I complain about technology and how it shreds my insides from time to time, I have to also devote some appreciation to the time when things actually go right. It's not often machines cooperate. Hmm... It's funny that I say that just after getting home from watching Spiderman II.

As of this writing, I counted 137 (documented) issues that have been closed, 13 priority issues still open, 27 low-priority (non-critical) open issues (that I won't even look at), 31 open issues on the back burner (many of which will never see the light of day), 8 situations to debug, and 14 situations I want to test. This is just regarding RC4, itself, and does not include the documentation issues or the control software I use to demo/control RC4.

And why am I doing this? I HAVE NO IDEA!