Date: Sat, 1 Apr 2006 22:06:42 -0600 (CST)
Subject: black magic makes bit banging work
X-UID: 157

The robot code is back on track. I discovered a workaround a few days ago 
and have been trying to ferret out why it works. It is still a mystery.

If the translation unit VehicleControl.cpp has

#include <bits/locale_facets.h>
#include <bits/locale_facets.tcc>

then the bit banged serial GPIO works. It appears to be stable as any one 
of the following

#include <iostream>
#include <istream>
#include <ostream>
#include <locale>

which include those two files also work. So I have a black magic solution.

Orthodox soft real time approaches mostly involve the POSIX.1b interfaces. 
This should especially be true in Linux as the kernel is now fully 
pre-emptible and implements all user-space threads as processes. The code 
on my robot is not doing any of this yet is able to have reliable timing 
resolution in the low microsecond range for bit banging.

I had theories that including the right library files caused static 
initialization that affected process scheduling. This is impossible as all 
code runs as a non-priviledged (not root) user. I also thought that 
perhaps device sync and buffering might be the culprit. But adding O_SYNC 
or using fdatasync() makes no difference. The only thing that works are 
including those two files.

To get to the bottom of this probably requires a lot of work. I don't have 
time to dig out the answer now. I can use my DSO as a 2 channel logic 
analyzer and watch activity on the GPIO pins. But correlating GPIO signal 
precisely with CPU activity and what is going on inside Linux might 
require ICE tools that are completely beyond me. My approach would have to 
be deductive with a lot of reaching in the dark and hoping I get lucky. 
That's basically how I work now.

On Friday, I was flipping through my control theory book and noticed the 
last chapter covers the z-transform. Fascinating. Instead of a discrete 
approximation to a continuous control solution, the approach from the 
start is discrete. Seeing this made it clear how deep the control aspect 
is. I don't have time to work out any real mathematics. The ideas are 
powerful. But I'll just have to hack stuff together, test, and see if it 
works.

I need to stabilize my code so will charge batteries and prepare the robot 
for a test tomorrow afternoon (should be dry then). My testing schedule is 
all to blazes at this point. My goal for the end of April is to 
demonstrate autonomous driving in about 2 to 3 KLOCs of code. I read that 
the CMU robots had about 1000 KLOCs. Stanford's robot had 100 KLOCs. I 
only need very limited performance so shouldn't need that much code to do 
it.