Raspberry Pi: A supercharged Bus Pirate

[Scratch.HTF]

This idea is going to be part of my "ultimate" test bench.

Native hardware functions on the GPIO pins are I2C, SPI (two chip selects), UART and JTAG, although optional handshaking pins can be defined - USB emulation at Low Speed/Full Speed (1.5/12 Mbit respectively) is also possible.
A powerful function which can be implemented is the emulation of "devices" (I2C, SPI and UART) in Slave mode (e.g. a 24LC02 EEPROM at Address 0x50 (Read/_Write) emulated by the Raspberry Pi) of the above buses up to a certain clock rate, and it can also support emulation of multiple I2C "devices" on the same bus.
For interfacing to logic levels other than +3.3V (+1.65 to +5V), bidirectional voltage translators such as the TI TXS0108E can be used and are available as premade modules; this device is rated at 110 MHz for push pull and 1.2 MHz for open collector (suitable for I2C Fast Mode Plus at 1 Mbit) although pullup resistors are required on certain pins of the Raspberry Pi due to hardware characteristics.

[rs20]

The value of the Bus Pirate is in the firmware, not in the fact that the onboard MCU has a handful of handy peripherals. What software are you going to load on to your RPi to give it features approximating a Bus Pirate?

[xani]

First as rs20 mentioned you'd have to write some fancy software for it.

Then you have to take into consideration that using full fledged non-realtime-by-default OS like Linux might cause some problems, like what will happen if kernel sleeps your program in middle of transfer because it needs to handle ethernet/display/input/whatever ? You *can* make Linux more realtime but at the very least that's a kernel recompile and some tweaking.

Sending won't be too bad for serial busses (because basically that will just stop bus/clock for a while) but receiving data directly on rPi by polling (hardware SPI/i2c would probaby be just fine) might be hard to do reliably without dead zones caused by kernel doing some stuff.

rPi might be interesting *base* for such device but to make it reliable you'd either have to run some RTOS on it, or have a  "buffer" chip that handled realtime stuff (and at that point you basically just strapped a bus pirate onto rPi).

I find that devices like rPi are great as a bus pirate/programmer/JTAG *host*, just plug your pirate/programmer/debugger into rPi and ssh to it remotely via wifi. That way I can leave my project on bench when debugging code and without having to drag long cables from my main PC

[cdev]

That sounds interesting.

All those SOCs with their GPIO's are uniquely well suited to doing things like that and the real GPIOs they possess seem really to have no equivalents in desktop PCs that I know of.

This idea is going to be part of my "ultimate" test bench..

[CM800]

That sounds interesting.

All those SOCs with their GPIO's are uniquely well suited to doing things like that and the real GPIOs they possess seem really to have no equivalents in desktop PCs that I know of.

This idea is going to be part of my "ultimate" test bench..

I'd say a PCIe I/O card is basically the equivilent.

It's just a matter of peripherals on a bus and the interrupt priority.

[eugenenine]

A Beaglebone might be a easier start, their beagle script would let you throw together some some BP like functionality and control over the GPIO pis faster than compiling code on the pi's

[cdev]

Does anybody sell a PCI-e I/O card thats got an accessible API, thats affordable?

That sounds interesting.

All those SOCs with their GPIO's are uniquely well suited to doing things like that and the real GPIOs they possess seem really to have no equivalents in desktop PCs that I know of.

I'd say a PCIe I/O card is basically the equivilent.

It's just a matter of peripherals on a bus and the interrupt priority.

[Christopher]

Because you have the abstraction of linux, you cannot always set the peripherals up to the same granularity as you can on a PIC,

You're better off buying a Saele analyser and just making your end product with a PIC talking straight to the SPI/I2C IC IMO.

[CJay]

Couple of excellent bare metal Pi programming guides...

http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/

http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/