Date: Wed, 29 Mar 2006 03:10:20 -0600 (CST)
Subject: bit banging was a mistake
X-UID: 156

The original motor control board was a gross conceptual error that led to 
a crisis point in the project. The entire design was abandoned in favor of 
a completely different replacement.

I just had the feeling that the same thing is happening on the software 
side, again involving motor control. It's not as acute as there are 
options. I have a spare RS-232 to 5V TTL level converter board that can be 
pushed into service with one of the free external DB-9 serial ports. This 
would solve the bit banged serial communications in hardware and obviate 
the need for any delay loops in software to generate pulses.

In retrospect, a sizeable amount of time and effort has gone into working 
around software bit banging. A few dollars of hardware and the entire 
issue would go away entirely. But instead, it's been something of a 
technical challenge to get it working.

I find that more than threads can induce write() delays on a character 
device. If pipe() is called, subsequent bit banging serial code stops 
working. It means that the situation is more complicated than I had 
conceptualized. I need timing resolution in the low tens of microseconds 
in software. I thought I had a solution that worked. But I'm not using a 
RTOS. This is vanilla Linux. What is amazing is that the old remote 
driving code worked so well. I was very lucky the first time. A more 
elaborate approach, as what I have tried now, would not have worked at 
all.

I think that what's going on is locking inside the system libraries. A 
write() to the GPIO char device changes state. A read() from the GPIO char 
device should not. Locking is probably multiple-reader, one-writer (MROW) 
and occurs for both read() and write(). But the read() locking is much 
faster than that for write(). This is why reading continues to work when 
writing fails in a threaded server.

The issues in trying to write real time code on a non-RTOS OS are deeper 
than I had anticipated. It's not just kernel and system configuration. It 
is knowledge of how the system libraries work.

So now I need a crisis gameplan. I have until the end of April to 
demonstrate autonomous driving. And I've already burned through almost two 
weeks fooling around with low-level software.

1. Return to a known working configuration

    The process that commands the motor control board will only use INET
    domain sockets and have a single thread. It will be a pure stateless
    server. A completely independent process will drive it. From everything
    I know, this should work. It's close to a known working solution. The
    only difference is that there are two processes running on the same
    computer board. However, I've done this before and seen the bit banged
    serial communications to be stable.

2. But if it doesn't work, then I need to open up the electronics box and
    see what's going on with the oscilloscope. It may be possible to adjust
    the delay loop counts and get the pulses back to correct width.

3. If none of the above work, then the exterior DB-9 RS-232 port will have
    be level converted to 5V TTL and used. This is an ugly solution as
    wiring now must be jury rigged between the exterior and interior of the
    enclosure. I know that I tend to be messy. But the aesthetics are even
    worse than what I normally do.

The good thing is that the code is cleaned up a lot now. There are two 
classes that do seem to be correct: VehicleControl and Networking. So I 
can use these to implement the ideas above. I should know which way to 
proceed sometime today after work.