This post originated from an RSS feed registered with Python Buzz
by Aaron Brady.
Original Post: Controlling a PiGlow with the Bus Pirate
Feed Title: insom.me.uk
Feed URL: http://feeds2.feedburner.com/insommeuk
Feed Description: Posts related to using Python. Some tricks and tips, observations, hacks, and the Brand New Things.
(If it wasn’t apparent: my birthday is on 14th March, the same day as Pi
Day and other celebrations)
Missed off of that list of presents: this year I got a Bus Pirate
from Dangerous Prototypes.
The Bus Pirate is a single PCB diagnostic and development tool that speaks
several serial protocols: SPI, I2C, 1-Wire, low-voltage RS232 and it can also
perform some non-serial tasks, like reading an ADC or generating PWM signals.
Like many useful tools, it has a bit of a learning curve. There’s wiki pages
with lots of information but they are no substitute for just getting your
hands dirty and using the thing. In fact, there’s a 3EEPROM Explorer
Board for this very reason- it gives someone taking their Bus Pirate out
of the box something to poke while they learn the ropes.
I didn’t have one of these, but it turns out that doesn’t matter: enter the
PiGlow.
PiGlow provides 18 dimmable LEDs and is designed to be used with a Raspberry Pi.
It sits right on the GPIO header of the Pi. It doesn’t use actual GPIO pins
though, because the PiGlow is actually based on the
SN3218 I2C PWM LED driver.
If you’re following along, you’ll need a few more bits to get up and running. I
already had a breadboard-compatible breakout for the Raspberry Pi GPIO header
(not exactly a Cobbler, but similar), I needed an IDC10 ribbon and
an IDC10 breadboard breakout. If you had a Bus Pirate Cable or
even just female-to-male jumper wires, you could probably do without those two.
For the remaining hardware part, it’s just a case of connecting everything up.
I moved slowly here: because I’d added in adaptors and ribbons cables (not all
of which were keyed to avoid flipping them around) I had to check that the
numbering of pins didn’t get messed up from what I expected.
(This pin out diagram from Crockett
Engineering was extremely
useful for this step)
For example, the first thing I did was put an LED across where I expected the
3.3V and GND to be on my IDC10 breakout. Once you select a mode on the Bus
Pirate, using the V command turns on the power supply and will light up the
LED. This step-by-step testing paid off: the LED did not light, I had the pins
all backwards. For my set up, 9 was 3.3V and 10 was GND.
Once that was established, I checked the image on the Dangerous Prototypes
site for the SDL and SDA connections (3 and 4, respectively) and I also ran
the 5V (pin 8) over to pin 2 on the GPIO breakout.
I2C requires pull up resistors. As the Bus Pirate runs at both 3.3V and 5V, you
will need to provide an input to Vpu on the board. I connected pin 6 on my
breakout (Vpu) to pin 9 (3.3V).
(You can see my version of the wiring above: I have a lot more wires plugged
in. I hooked up all of the GND and 3.3V inputs before I realised which ones
were needed and which weren’t. You don’t need to.)
Raspberry Pi Pins
GND
14
5v
2
3.3v
1, 17
SDA
3
SCL
5
(Where 1 is the bottom left pin pictured above, 2 is the top left etc.)
Now, for software. I’m driving this from a Debian Jessie laptop, but as long
as you have USB serial port drivers, you could be driving it from anything.
Load picocom
sudo picocom --b 115200 /dev/ttyUSB0
picocom v1.7
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv
imap is :
omap is :
emap is : crcrlf,delbs,
Terminal ready
The Bus Pirate boots into high-impedence mode, with the power supply turned off.
Let’s select I2C, 100Khz (which is around the speed of the Raspberry Pi’s I2C).
I’ve connected 3.3V to Vpu, so we can safely turn on the PSU and enable the
built-in pull-up resistors:
I2C>W
Power supplies ON
I2C>P
Pull-up resistors ON
And search the available I2C address space:
I2C>(1)
Searching I2C address space. Found devices at:
0xA8(0x54 W)
This bit confused me for ages. The source code I had read referred to
0x54 as the address, but the Bus Pirate wants to use the raw address for all
writes, which is 0xA8. Writing to 0x54 just generates a lot of NACKs.
We want to write 0x0 0x1 to enable output:
I2C>[0xA8 0x0 0x1]
I2C START BIT
WRITE: 0xA8 ACK
WRITE: 0x00 ACK
WRITE: 0x01 ACK
I2C STOP BIT
And enable all of the LEDs:
I2C>[0xA8 0x13 0xFF] [0xA8 0x14 0xFF] [0xA8 0x15 0xFF]
I2C START BIT
WRITE: 0xA8 ACK
WRITE: 0x13 ACK
WRITE: 0xFF ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA8 ACK
WRITE: 0x14 ACK
WRITE: 0xFF ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA8 ACK
WRITE: 0x15 ACK
WRITE: 0xFF ACK
I2C STOP BIT