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.
I’m looking forward to the binary I2C access mode…
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
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.
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?
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.
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.
What’s the function of the y=AUX, z=CS bits in the last 2 commands?
CS is the chip select pin, AUX is the Auxiliary pin, set high(1) or low(0).
Figured but didn’t seen the point of controlling these pins in this mode, more features is never a bad thing I guess.
Ya, you never know what crazy use you might have for a few extra pins.
I implemented the binary I2C mode in the nightly compile, and documented it here:
http://dangerousprototypes.com/2009/10/14/bus-pirate-binary-i2c-mode/
Also, get a free cable for your script :) :
http://dangerousprototypes.com/2009/10/14/free-probe-cables-for-your-binmode-scripts/