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.
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
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
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:
NOTE THAT THE PCA9555 SETTINGS STICK PAST REBOOT. ONLY A POWEROFF WILL RESET THE VALUES.
|Magic SMBus Command||What it does|
||Read the state of the pins (0x00 - 0xff).|
||Sets the output register to all high (0x00 sets the output register (not pins!) low).|
||Read the output register.|
||Sets the direction of the pins to all outputs (0xff makes them all inputs)|
||Read the direction register.|
Jamey built a new kernel that includes the GPIO-PCA953x driver (which includes support for the PCA9555 and a bunch of other similar chips).
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?
- 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?
- 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:
- 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.
- 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.