Date: Fri, 23 Sep 2005 06:07:38 -0500 (CDT)
Subject: inconsistent GPIO pinout
X-UID: 92
Content-Type: IMAGE/JPEG; name="img1843.jpg"
Content-Type: IMAGE/JPEG; name="img1846.jpg"

Using Jim Cromie's kernel patch, I got the GPIO pins working on the 
Soekris 4801 board. What was confusing for a while is the correspondence 
between minor device numbers and the pins in the mainboard header. 
Remember that in UNIX, everything is a file (except for network interfaces 
which are special devices). So each GPIO pin is accessed through a file 
created with a command like:

mknod -m 600 /dev/gpio-10 c 254 10

Then the following will generate a square shaped wave on Soekris function 
pin GPIO 11 (this is not a typo - see pinout table below).

echo o > /dev/gpio-10
echo O > /dev/gpio-10
while [ 1 ]
do
   echo 0 > /dev/gpio-10
   echo 1 > /dev/gpio-10
done

Here is the pinout. The inconsistent numbering for the PC87366 pins are 
errors in the documentation.

(According to Soekris 4801 manual)   (Discovered by experiment)
Soekris pin #  PC87366 pin #         Minor device #

GPIO 0         GPIO 20, 117          16
GPIO 1         GPIO 21, 118          17
GPIO 2         GPIO 22, 119          18
GPIO 3         GPIO 23, 120          19
GPIO 4         GPIO 24, 121          20
GPIO 5         GPIO 24, 122          21
GPIO 6         GPIO 26, 123          22
GPIO 7         GPIO 26, 124          23
GPIO 8         GPIO 4, 6             4
GPIO 9         GPIO 5, 7             5
GPIO 10        GPIO 13, 55           11
GPIO 11        GPIO 12, 54           10

The i2c/SMB bus interface calls do not appear to work at all. This is not 
surprising given the device driver issues illustrated by the inconsistent 
pinouts above. It's likely that the i2c drivers are driving the wrong 
pins.

The oscilloscope was invaluable. It probably saved me one or two days of 
work for this one problem. Being able to see signals in real time over the 
pins makes a huge difference. It could be done with a multimeter but only 
with much greater trouble.

Tonight (this morning), I needed to see a periodic waveform. So a 
conventional analogue oscilloscope would have worked fine. In some ways, 
it might have been better for dialing into the solution. I remember using 
analogue scopes. They were very intuitive when dialing in. Last week with 
the power problem due to shorted +5 and +3.3 logic lines, I needed to see 
a single-shot, non-periodic wave. An analogue storage oscilloscope would 
work but really digital has more flexibility. If you ever get a scope, 
make sure it has storage capability. You need both modes. Also, the color 
LCD does help. With multiple waveforms, it can become confusing as to 
which trace corresponds to which probe.

I'd never seen the motor control board mounted over the computer boards 
outside of the aluminum enclosure. So I never knew that some of the pins 
on the underside of the board are almost shorting out. There's literally 
about 2 mm of clearance between a grounding flange on the eth0 RJ-45 jack 
and the ground side of the opto-isolator for the OC2 oscillator pin on the 
microcontroller. This has not been a problem as so far, the motor control 
board has never been powered up when mounted. But under vibration, it's 
likely that the boards will flex and so there will be intermittent shorts. 
Worse, these shorts are between logic and power which by design must 
always be completely isolated. The solution is to use electrical tape 
and/or shrink tubing to prevent metal to metal contact.