Bus Pirate firmware v2.5


Firmware v2.5 is a minor fix release. We cleaned up two small bugs in the binary SPI library, and removed an update to the smartcard library to make it more flexible. This should be the last rapid release to correct minor bugs –   sorry about that, we want a final release firmware with fully working binmode features to develop against.

Our Perl script to dump SPI EEPROMs is in the project SVN, look for a full tutorial in the next few days. We created a scripts folder for any Bus Pirate related software. We’d love to host a copy of your scripts, no matter how simple.

The next firmware release will probably include binary UART and binary I2C access modes.

Join the Conversation


  1. Would you like to help me hammer out the specs? Here’s what I have noted in the code so far. Nothing final, just some thoughts:

    rawI2C mode:
    # 00000000 //reset to BBIO
    # 00000001 – mode version string (I2C1)
    # 00000010 – I2C start bit
    # 00000011 – I2C stop bit
    # 00000100 – I2C read byte
    # 00000110 – ACK bit
    # 00000111 – NACK bit
    # 0001xxxx – Bulk transfer, send 1-16 bytes (0=1byte!)
    # 0100000x – Set I2C speed, 1=high
    # 0101000x – Read speed,
    # 0110wxyz – Configure peripherals w=power, x=pullups, y=AUX, z=CS
    # 0111wxyz – read peripherals w=power, x=pullups, y=AUX, z=CS

  2. Probably needs an additional command to get the last ACK bit status. Then you could choose to trust the datastream or check each byte for the ACK/NACK status.

  3. Might be useful to report the ACK/NACK of every sent byte instead of checking it every time or enable this as an option if you want the output stream to be the pure I2C output. Slave mode going to be supported?

  4. You’re right about ACK/NACK: first byte is data, second byte is 0 NACK, 1 ACK.

    Slave mode might best be supported in a separate mode because it’ll rely on the I2C hardware, and won’t work on some PIC revisions without a bit of manual coaxing.

  5. I’m working up the code now. The slave replies ACK/NACK to the host, so the return byte from a write is 0 ACK or 1 NACK, no need for a second byte or separate command.

  6. Figured but didn’t seen the point of controlling these pins in this mode, more features is never a bad thing I guess.

Leave a comment

Your email address will not be published. Required fields are marked *

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