wiki/ news/ 2012-05-15 - GPS carrier board almost ready, poking at the FC GPIO

Lots going on tonight: Richard P. found what looks like a good SPS with enable, Richard A. is done picking out sane parts for the LTC, James is working on the battery board, K and Andrew discussed the ADIS IMU adapter, etc. Theo couldn't make it, but hopes to come Friday.

GPS Carrier Board

Nathan is hammering away at the GPS carrier board. He got a first go of the board laid out.

GPS Carrier board layout

GPS Carrier Board with boards on top

Issues: - Mounting hole distances on the LNA - plated mounting holes for the LNA and the Crescent board - Find connector for USB, work on placement to avoid coax

Battery Box

Dave finished the new 4 cell battery box. The upshot is: thicker walls, no top (stronger), less material near the plate screws so we can screws, PCB for both the front etc. Now James has the info he needs to layout the battery board. We're sending it off to Pat to get FDM'd. Yay!

Flight computer GPIO

Working on the FC GPIOs


We tried to get the GPIO on the ADventech PCM-3363 PCI-104 Atom flight computer to work sanely. We more or less won, kind of. The GPIO is from a NXP PCA9555 16 bit SMBUS-to-GPIO chip. Of the 16 GPIO pins, only the lower 8 pins go to a connector on the PCM-3363 board. The upper 8 pins either don't go anywhere, or are connected to the "melt down the FC" device, so we shouldn't mess with those bits.

According to the PCA9555 datasheet, it should exist somewhere between 0x20 - 0x27. Running i2cdetect -y 0 we found a device at address 0x20. And yes indeed, that's the PCA9555 we're looking for. To manually set the PCA9555 registers, you can use the i2Cset/i2cget commands (BEFORE you load the driver, see below). Also:


Magic SMBus Command What it does
i2cget -y 0 0x20 0 Read the state of the pins (0x00 - 0xff).
i2cset -y 0 0x20 2 0xff Sets the output register to all high (0x00 sets the output register (not pins!) low).
i2cget -y 0 0x20 2 Read the output register.
i2cset -y 0 0x20 6 0x00 Sets the direction of the pins to all outputs (0xff makes them all inputs)
i2cget -y 0 0x20 6 Read the direction register.

Linux driver

Jamey built a new kernel that includes the GPIO-PCA953x driver (which includes support for the PCA9555 and a bunch of other similar chips).

The command echo pca9555 0x20 > /sys/bus/i2c/devices/i2c-0/new_device which makes the driver pretend it discovered a PCA9555 at address 0x20.

cd /sys/class/gpio
for pin in `seq 240 255`; do echo $pin > export; done
for pin in `seq 240 247`; do echo out > gpio$pin/direction; done
for pin in `seq 240 247`; do echo 1 > gpio$pin/value; done

Stupidity all around

So what did we discover?

  1. The PCA9555 on the FC has stiff pull-up resistors. Tying the floating pins to ground using a 1kohm resistor gave us ~ 886 mV, which means there's the equivalent of a 4.7 Kohm pull-up resistor. Aaarrrrggghhhhh why?
  2. Although the PCA9555 defaults to 0xff in the output register, when we turned the direction register to all outputs, we'd get all low. This means something (the BIOS?) is setting the output register to 0x00 before the GPIO driver even loads. Weird. Toggling the "active_low" bit didn't help this. Since the driver doesn't allow us to set the output register before turning the direction to outputs, this means no matter what we do, the GPIO pins toggle from "inputs with 4.7K pull-ups" to "outputs set at low".

1+2 above totally suck, because it means that we can't sanely control the GPIO - as soon as we set them to outputs, the values flip. Luckily, we have two different solutions:

  1. Before the GPIO driver loads, use the i2cset command to manually set the output register to 0xff. That way when we set the direction to output, we still get 0xff just like the "input with pullups" had before.
  2. Desolder the pull-up resistors on the back of the board near the PCA9555 and add pull-down resistors other places. Now, when we set the direction to outputs, it's already low so again, no flipping state.

Which solution we'll take is dependent on the active high / active low requirements for the SPS units we're switching on and off.