Python Bus Pirate Wrapper (CLI)

[curly.drew]

Does anyone think that a software wrapper for the Bus Pirate would be of any particular use? What I'm thinking of is python scripts to handle the serial communication and act as a middle man in communications with the Bus Pirate. So rather than using single character commands ("?") you'd type something like "BPUtils --help". As far as I can think there are a few benefits to doing this;


1. A command line wrapper could provide more verbose command interactions, help information etc.

   1.1 Commands would be more readable and memorable


2. Shell scripts could be simplified by the use of a wrapper

   2.1 Piping data to and from the Bus Pirate could be handled either in a static command → result format or as an opaque or transparent session. (Making the process easier for users new to scripting)


3. Common interface for access collisions regardless of platform (may be useful for further (cross platform) software)



4. Cross platform availability can be maintained
 while increasing ease of use.

As well as the above, utilities relevant from the computers stand point could be included, such as  an option to resolve connected Bus Pirates. I'm a Java developer who is new to python and has not used the Bus Pirate extensively, so any comments and criticism welcome.

Thanks,
Drew

[ian]

I think it's a great idea. It would really help with stuff like EEPROM writes and dumps that need file I/O. We can add a raw access trigger to the Bus Pirate firmware for things that need to move data quickly or in bulk.

[audiohacked]

Hi, I've started a python library for the bus pirate (found in my signature). If anyone has any suggestions for it, I'm all open.

[ian]

Just wanted to let you guys know about the new binary access mode that should make command line interfaces and other stuff much easier than parsing the ASCII output:

http://dangerousprototypes.com/2009/10/09/bus-pirate-raw-bitbang-mode/
http://dangerousprototypes.com/2009/10/08/bus-pirate-raw-spi-mode/

I'm writing a EEPROM dumper in PERL as an example, but I plan to make a basic Python example based on audiohacked's code.

[audiohacked]

Now I'm wondering why I never thought of writing the library in PERL, I frankly dislike python. Only reason I learned python was in case I wanted a Internship at Google.

[ian]

I've made Perl examples for raw bitbang and the binary SPI library (SPI eeprom dump to file). I added them to a new folder for scripts in the project SVN. I'd be happy to add a copy of anything you develop:

http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/scripts

[ian]

Audiohacked has an update for the binmode in his repository. Great example! I'll post it up tomorrow.

[audiohacked]

Here's what I have for the Lite version of my python library (attached). The test script is a translation of the spieeprom.pl script into python. If you want me to do any other languages, just leave me a message.

[ian]

Awesome, thanks. I added it to the scripts folder. I'm posting it now.

[audiohacked]

I've started on Binary Mode UART, and I'll post a svn patch as soon as you're finish writing the protocol specs.

I also see that we could standardize on opcodes for {set,read}_peripherials, {set,read}_configuration, and etc. There is a inconsistancy in opcodes between I2C/UART and SPI of mentioned commands.

[ian]

The difference was a typo. I've corrected it to mirror the SPI opcodes because it's 'finalized' and I2C is only in the nightly. The change will go in the next nightly compile.

Here's the UART notes/comments from the code (rawIO.c), also updated to fix the mistake:

Baud
A) standard settings
B) send 2 bytes for custom BRG

databits and parity (2bits)
1. 8, NONE *default \x0D\x0A 2. 8, EVEN \x0D\x0A 3. 8, ODD \x0D\x0A 4. 9, NONE
Stop bits:\x0D\x0A 1. 1 *default\x0D\x0A 2. 2 \x0D\x0A
Receive polarity:\x0D\x0A 1. Idle 1 *default\x0D\x0A 2. Idle 0\x0D\x0A
output type (hiz or regular
peripheral settings

# 00000000//reset to BBIO
# 00000001 – mode version string (ART1)
 # 00000010 – UART open
 # 00000011 – UART close
# 00000111 - UART speed manual config, 2 bytes (BRGH, BRGL)
# 00001111 - bridge mode (reset to exit)
# 0001xxxx – Bulk transfer, send 1-16 bytes (0=1byte!)
# 0100wxyz – Set peripheral w=power, x=pullups, y=AUX, z=CS
# 0101wxyz – read peripherals
# 0110xxxx - Set speed,0000=300,0001=1200,10=2400,4800,9600,19200,33250, 38400,57600,1010=115200,
# 0111xxxx - Read speed,
# 100wxxyz – config, w=output type, xx=databits and parity, y=stop bits, z=rx polarity (default :00000)
# 101wxxyz – read config

Any comments or thoughts? The only one that isn't the same here is the config command. It requires an extra bit.

See datasheet for BRG calculation, or online calculators. PIC speed is 32MHZ/16MIPS (2 cycles per instruction).

Note to self: It's important that the UART open command clears the overrun error bit.

[ian]

Don't know if you saw this, I added two self tests to the bitbang IO mode:
http://dangerousprototypes.com/2009/10/16/self-test-in-binary-mode/

[audiohacked]

I just added the self-tests to the library. I've also moved the bulk_trans, speed, and peripheral functions to the BitBang code; then that way I don't have to write the same code for each interface, and can overload as needed.

I'll take a look at UART BRG like you said.

[audiohacked]

I thought that I might as well post the patch that I'm working on; apply at the root of trunk tree.
My commit message is at the start of the patch.

If anyone has any questions, don't hesitate to ask.

~ Sean Nelson

[audiohacked]

Maybe I should make sure I actually attach my patch.