Categories

Bus Pirate logic analyzer firmware

Posted on Monday, November 2nd, 2009 in Bus Pirate, Development by Ian

sump-dataii

We wanted to check the remote control output while we debugged the color changing pumpkin. Usually we’d use a Saleae Logic, but instead we made an experimental logic analyzer firmware for the Bus Pirate.

***BIG WARNING*** The Bus Pirate will never be a substitute for a ‘proper’ logic analyzer, the hardware isn’t designed for it. The Bus Pirate can’t store a lot of samples, it can’t feed live samples very fast, and speeds will be in the kHz, not MHz. This test firmware records 4096 samples at a fixed 10kHz sampling rate.

Despite the limitations of the Bus Pirate hardware, our logic analyzer worked well enough to examine decoded IR remote signals. It’s also well suited to debug environments where you can control the bus speed (and the Bus Pirate may already be connected for other reasons).

We’re releasing the logic analyzer as a separate firmware for v2go and v3 only, but once it’s improved we plan to integrate it into the trunk. Documentation below.

There’s still time to get a Bus Pirate v3, $30 including worldwide shipping.

Logic analyzer specs

This test firmware records 4096 samples at a fixed 10kHz sampling rate. Future releases could easily sample up to about 1MHz, but the test firmware doesn’t support sample rate adjustments. Sampling is triggered by any change on any pin.

The five major IO pins are included in analyzer output:

  • chan0 – CS
  • chan1 – MISO
  • chan2 – CLK
  • chan3 – MOSI
  • chan4 – AUX

The firmware works with the open source Java SUMP logic analyzer client. There’s a bunch of SUMP builds out there, you can read about a few of them in our SUMP roundup.

SUMP follows a simple protocol. We’ve only implemented the minimum command set: reset, run, ID. Other commands are received, but the contents are ignored. Sample speed, trigger pins and directions, etc could be handled with an update, your patches are welcome.

What you’ll need

Load the logic analyzer firmware into your Bus Pirate v2go or v3 using your normal Windows or Python (MAC OSX/LINUX) update method. You can return to the normal Bus Pirate firmware later using the same procedure.

Using the logic analyzer

SUMP-configii

Open SUMP. Press the rocket button. Configure SUMP as shown here.

Change the serial port to match the normal Bus Pirate serial port on your system. Uncheck channel groups 2, 3, and 4. We capture a fixed 4000 samples (actually 4096), but SUMP will also accept a smaller sample size and ignore the extra data. The speed setting is ignored, but it tells SUMP how to label the sample increments.

RC5toggle-bitii

Click ‘capture’ to arm the logic analyzer. The MODE LED lights to indicate that the analyzer is armed.

The first change on any pin triggers sampling. 4096 samples are captured at 10kHz, and the LED turns off. Samples are sent to SUMP, and then displayed.

Improving the logic analyzer

Here’s our tentative goals for the logic analyzer

  1. Adjustable speed up to 800kHz – 1MHz
  2. Pin trigger selection (with direction?)
  3. Integrate into trunk
  4. Presampling, rolling sample buffer, etc.
This entry was posted on Monday, November 2nd, 2009 at 1:14 pm and is filed under Bus Pirate, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

10 Responses to “Bus Pirate logic analyzer firmware”

  1. Ian says:

    New compile with more features for v2go and v3. Not tested. Added trigger adjust, speed (1mhz-10hz), sample size adjustment. Detects if channel groups 2,3,4 are unchecked and sends padding bytes.

    http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v2-nightly/BPv3/v2go-v3-SUMP-v0a.hex

  2. Luke Skaff says:

    If you ever decide to make a dedicated DIY open source FPGA based logic analyzer I would be the first to buy it

  3. Ian says:

    Coming soon ;) Like I said in the other post, I hope to design a $30 open source 70MHz-100MHz logic analyzer. Please don’t hold your breath though, it’s not even in prototyping yet.

  4. Luke Skaff says:

    I took a look at your post again, I feel the FDTI serial chip would be too slow. After the FPGA dumps a sample set to SRAM it would take awhile to transfer all that data to the computer at serial port speeds. You could use a USB controller to get some nice data rates going, there is already some open source hardware and software for a simple FPGA with USB 2.0 controller.
    http://www.fpgaz.com/usbp/

  5. Ian says:

    That’s a cool project, I haven’t seen it before. I’ll post it up.

    The main issue I have with adopting that setup is that it just subs a Cypress chip for the FTDI chip. The cypress chip it uses has more pins, is in a smaller package, and seems rarer and more expensive (at least at first glance). The FTDI chip is really well supported, cheap, and readily available. Serial com is already supported by my target client (SUMP) without mucking around adapiting a Java app to work with the Cypress chip.

    The FTDI chip would dump serial data at 1-3MBPS, it would only take a second to transfer a few 100K samples. 4096 samples at 115200 on the Bus Pirate happens without noticeable delay. Using the Cypress chip would probably up the cost by $15-25, and the development time by months, just to shave a fraction of a second off the transfer time.

    Great project, but it doesn’t really fit with the skillz I bring to the table – namely I don’t program for desktops, especially in Java, unless there’s no other choice.

  6. Luke Skaff says:

    Ian,
    A fun mental exercise for me, haha.. At 100Mhz 4096 samples would only be 40.96us of data for one channel, kind of small. I was thinking of a analyzer that could do 1000ms of data (at the minimum) over eight channels would be 8 million samples / bits. 8 Megabits over FTDI would be some time, the max speed of the FTDI is 921.6Kbs and protocol / stop, start, error bits overhead would be at least 10 seconds which is not too bad but if you add more channels and longer sample times transfer times could get very long quickly. There has got to be a cheap n dirty way of using USB 2.0

  7. Michal says:

    Heh, I just developed a very similar logic analyzer with AVR but haven’t found a good GUI for displaying the samples so for now it has a simple textual ‘timestamp:channels’ output. It was good enough for debugging my 1-Wire bitbanging driver but not sexy enough for general public ;-)

    Sadly I’ve got BP v1a and can’t give your one a go.

    Re sending samples from the probe – how about using the full speed USB controller that’s available in many PICs (eg in PIC24FJ64GB004). It’s a raw USB, not usb-serial, and can probably achieve a better throughput. On the other hand would need a host-side driver.

  8. Ian says:

    @Michal – I made a v1 compile. It includes the most recent updates to the code, which haven’t been tested (at all):
    http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v2-nightly/BPv1a

  9. Ian says:

    This went so well that I rolled it into a v3 preview firmware:
    http://dangerousprototypes.com/2009/11/03/bus-pirate-logic-analyzer-mode/

  10. Ian says:

    Had some error reports. I used portmon to look at the traffic, and after a few bytes sometimes there’s a read timeout. SUMP takes that to be an error, but really it’s latency from the USB->serial driver.

    Changing the minimum read timeout (msec) in the FTDI driver setting to at least 4000 (device manager->ports->COMx properties->port settings->advanced in Windows) cleared any remaining problems on my system. Another way is to decrease the latency timer, but that hurts performance a lot.

    Ideally, SUMP would have a simple text .ini file with settings for things like read timeout (one byte, really?), device types, and clock divider, so this stuff is easier to address. But that’s not how it’s built (yet)…

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • mike: 1oz is 35um 2 oz is 70um 3 oz is 105um 4oz is 140um Obviously, the thicker the copper, the more current you can carry...
  • Manoj: U mean to use 105um ?
  • mike: have you considered thicker copper. 1oz copper is the norm, but I have often used 2 oz for higher currents. Theres probably 3oz as well
  • Derek: Perhaps I am too late. Perhaps I am not.
  • King5E: me