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
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.
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.
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/ ... bang-mode/ (http://dangerousprototypes.com/2009/10/09/bus-pirate-raw-bitbang-mode/)
http://dangerousprototypes.com/2009/10/ ... -spi-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.
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.
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 ... nk/scripts (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/scripts)
Audiohacked has an update for the binmode in his repository. Great example! I'll post it up tomorrow.
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.
Awesome, thanks. I added it to the scripts folder. I'm posting it now.
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.
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 x0Dx0A 2. 8, EVEN x0Dx0A 3. 8, ODD x0Dx0A 4. 9, NONE
Stop bits:x0Dx0A 1. 1 *defaultx0Dx0A 2. 2 x0Dx0A
Receive polarity:x0Dx0A 1. Idle 1 *defaultx0Dx0A 2. Idle 0x0Dx0A
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.
Don't know if you saw this, I added two self tests to the bitbang IO mode:
http://dangerousprototypes.com/2009/10/ ... nary-mode/ (http://dangerousprototypes.com/2009/10/16/self-test-in-binary-mode/)
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.
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
Maybe I should make sure I actually attach my patch.
Looks great. I just uploaded a nightly with some fixes and an updated firmware with UART bin mode.
I added the binmode docs here: http://dangerousprototypes.com/2009/10/ ... uart-mode/ (http://dangerousprototypes.com/2009/10/19/bus-pirate-binary-uart-mode/)
Thanks for helping to develop the specs.
Can I give you access to work on the python scripts in SVN? If that's ok, just give me an email that's registered with google and I'll add you t the project.
I wasn't going to do it yet, but it was so easy. Mode 4 from binmode:
binary1WIRE mode:
# 00000000 - reset to BBIO
# 00000001 – mode version string (1W01)
# 00000010 – 1wire reset
# 00000100 - read byte
# 00001000 - ROM search macro (0xf0)
# 00001001 - ALARM search macro (0xec)
# 0001xxxx – Bulk transfer, send 1-16 bytes (0=1byte!)
# 0100wxyz – Configure peripherals w=power, x=pullups, y=AUX, z=CS (
# 0101wxyz – read peripherals (planned, not implemented)
The search macros respond with groups of 8 byte 1-wire addresses. The end of data is signified by 8 0xff bytes.
My googlecode account is tied to xx; the same account as used on Issue 40.
Added, removed you email from the forum.
I already have a version of pyBusPiratelite (http://http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/scripts/pyBusPirateLite%3Fstate%3Dclosed) in the /scripts forum, but feel free to create your own directory where ever you want.
Hey,
thanks for your script Sean, unfortunately there are some bugs :) - and I fixed two of them.
1) In BitBang.py you have to compare data to chr(0x01) as data is a string and does not get converted to a number unfortunately
2) Don't use
is
for comparisions - use
==
instead.
The python manual says about is:
The operators ``is`` and ``is not`` test for object identity: ``x is
y`` is true if and only if *x* and *y* are the same object.
Unfortunately you use is quite often :/
I attached a patch against your git latest tree.
Do you need some help in the python section? I guess I could bring the code up to date :) (without killing my bootloader again :))) if yes - just contact me.
Or should I fork your git tree and you pull my changes?
Here is another patch, it updates the i2c constructor, so that is compatible/similar to the SPI one
And another one:
This patch makes BBmode more stable, especially for subsequent calls.
Without this patch, the script might get confused if the Buspirate answers to early with an BBI01
And I attached also my I2C-Testscript, which writes and reads an eeprom
Here is the BRG baud rate calculation equation:
BRG=((Fosc/2)/(4*baud))-1
Fosc=32MHz, so
BRG=((32000000/2)/(4*baud))-1
Updated version of the stable patch - works faster, thanks to ian
Thanks so much. Next time you can just fork and ask for a pull. I knew of the ``is`` problem, and oddly it had no problems and did work; but thanks for catching the bugs.
P.S. To me there's no reason to grab 2000 bytes after sending 0x0F, but its safer than my assumption in case Ian decides to add more.
There's also self.port.flushInput(); instead.
yeah the change to 2000 is made without a reason :) - rather a leftover from testing :)
But changing it to flushInput would be a good idea I think.
[quote author="audiohacked"]
Thanks so much. Next time you can just fork and ask for a pull
[/quote]
Should I do that for these patches too? Or only for the next batch :)
I've already pushed this patch set; so next time. Thanks Again!