Skip to main content
Topic: pyBusPirateLite Overhaul and My Continued support (Read 15372 times) previous topic - next topic

pyBusPirateLite Overhaul and My Continued support

Embarassing note:  I was up all last night and somehow released code with some syntax errors.  Also the analogue to digital converer is no longer working, and I am actually worried that I somehow broke by BP (hopefully just the A/D converter). 

--A post below has one without syntax errors--

Hello all, I am just getting into working with the bus pirate and learning python, and so far it is going absolutely fantastic.  I already have some experience with the Pic24F, and I am going to be doing other projects building on the bus pirate (but more on that later...)

Attached is an overhaul of the pyBusPirateLite library.  What I have done is to incorporate member variables that keep track of what mode your output/pin directions regardless of mode, so that you can (essentially) treat the bus pirate as if it were a microcontroller!  I'll go into the details a bit here.

(First off, let me mention that anyone who has already used the library should still be able to use it in their code -- except that they have to manually connect using the BBIO.connect() member function.  The reason for this is because I wanted to be able to retain the class variable regardless of connection status.  If you get an error when trying to use this code in your already made code, please tell me!  The code is supposed to be backward compatible, so that would be a bug.)

Essentially the code works much the same as it always did, and as mentioned you should be able to use it the same way if you want to.  The difference is some member functions that increase usability (such as set_pin functions in all modes, more user friendly peripheral functions, and set_port and read_port functions that let you do things as if they were a microcontroller, where the class takes care of keeping track of everything)

Probably a demonstration is the best way to define what I have done.

Lets say you wanted to wiggle three pins and then grab some i2c data (something you probably wouldn't want to do, but let's just say), then wiggle three pins, and then do something on spi.

The coding method would (roughly) as follows:




import stuff
#call microcontroller object, contains all
# pyBusPirateLite functions
bp_device = UC()   

#the only significant difference between the
# two versions
bp_device.connect("/dev/ttyUSB" + str(n), 115200)

bp_device.BBmode() #enter BB mode as before
bp_device.cfg_periph(power = 'on', pullups = 'on') 
# user friendly peripheral config

bp_device.clear_pin('cs')
bp_device.clear_pin('miso')
bp_device.clear_pin('aux')

bp_device.set_pin('cs')
bp_device.set_pin('miso')
bp_device.set_pin('aux')

#same as before
bp_device.enter_i2c()  

##do i2c stuff as you did before

bp_device.enter_bb()    #return to bit bang

# have to re-configure hardware resets
# after every change
bp_device.cfg_periph(power = 'on', pullups = 'on') 

bp_device.clear_pin('cs')
bp_device.clear_pin('miso')
bp_device.clear_pin('aux')

bp_device.set_pin('cs')
bp_device.set_pin('miso')
bp_device.set_pin('aux')

bp_device.enter_rawwire()   #enter raw wire
##do stuff in raw wire as you did before

## continue doing more stuff




In actuality, some difficulties crop up with doing things like this because the bus pirate always enters HiZ mode, so that could wiggle signals too.  Some things you have to figure out yourself (for instance you can use pullups and always exit in HiZ).  Hopefully this gives you some idea of the advantages of this library over the old one.


IN SUMMARY
- This module allows you to try out different modes and raises an exception if you are trying to do something in a mode you aren't supposed to (i.e. setting a baud rate when you are in i2c mode)

- lets you transition between modes seamlessly, automatically keeping track.

- provides some additional user-friendly functions (like setting and reading a port like a microcontroller and easier configuration)

- Those functions, where they apply, are polymorphic.  For instance, you can call cfg_periph in any mode, and the class will send the proper commands to the bus pirate.  No longer should you have to think about whether you should call cs_high or CS_High.  You can always call set_pin('cs'), no matter the mode (this is still in testing, but you can make it happen!).

- Allows for much faster development (if you are developing for microcontrollers), because it is much easier to port.


ALL I ASK:
Please, please please!!! post in this forum if you find any bugs.  Post any bugs HERE (do not email me).  I will keep the code updated with any fixes, and eventually put it out on the svn.  If you want to take a more active roll in expanding the code, then feel free to email me :D


ALSO:
There seems to be a bug in either the hardware or the software, but I have narrowed it down to where I think it is the hardware of the bus pirate (although I don't see any problems in it).  To see the problem in action, run the pin_dir_test funciton in BitBang.py with a 5V pullup resistor connected to each output pin.  It appears that every time you change the direcion of the pin, it will reset it to an "output" state.  You can correct the problem by clearing the pin after changing its direction to output, but that is rather annoying and rather unwanted.

 

Re: pyBusPirateLite Overhaul and My Continued support

Reply #1
Oh, one more thing is that for some reason I can currently only communicate at about 500Hz.  If anyone knows the reason for this, please let me know.

Re: pyBusPirateLite Overhaul and My Continued support

Reply #2
Nice work, thanks for sharing your update. Do you want access to work in SVN? Just shoot me a google registered email:
http://dangerousprototypes.com/docs/Using_SVN
Quote
Oh, one more thing is that for some reason I can currently only communicate at about 500Hz.  If anyone knows the reason for this, please let me know.

I think it is due to the select() sleep function used to pause for bytes? That is just a guess though. It's not fast, but it should be faster than that :)

Quote
It appears that every time you change the direction of the pin, it will reset it to an "output" state.

Could be. I'm not quite sure I follow though. You change the direction (input/output) and it always resets to output? Or You change high/low and it always goes to output? Here's the code for that:
http://code.google.com/p/the-bus-pirate ... inIO.c#226

I don't see this behavior, but it cold be in there somewhere :)
Got a question? Please ask in the forum for the fastest answers.


Re: pyBusPirateLite Overhaul and My Continued support

Reply #4
Ok, here is code that should have no syntax errors (I don't know how that happened before)

I also added two member functions to BBIO called special_start_getting_adc_voltages and special_get_next_adc_voltage.  These utilize the commands used in several osciloscope programs (I am currently altering the one made by Tim Vaugen using them and it works).  These commands are undocumented at http://dangerousprototypes.com/2009/10/ ... bang-mode/ and I am creating a post about it there, because they confused me for quite a while.  Using this method, it can sample at around 5.3 kHz (similar to other oscilloscopes).

I'll look into your suggestions and see if I can't speed it up a little bit.  The slowness is rather annoying.  I still can't get regular commands to go faster than around 250 Hz.  I have some speedtest functions in common_functions if anyone is interested in testing.

Re: pyBusPirateLite Overhaul and My Continued support

Reply #5
[quote author="Sjaak"]
Possible solution for the slow communication: http://dangerousprototypes.com/forum/in ... pic=1634.0

I dunno if is already in the svn or not.
[/quote]

he reports a maximum speed of 250Hz as well.  I have tried changing the timeout with no results (my timeouts are different than the original pyBusPirateLite timeouts as well.  His initial problem of only being able to operate at 10Hz WAS because of the timeout).

It almost seems like a hardware problem... but I don't see how.  The usb <--> uart chip says it can operate up to a MHz, and the uart should be going at 115200 Baud (about .1 MHz I think...).  The communication should not be this slow.  I'm trying to look into it in the BP source code, because I would really like to be able to communicate at at least 5-10 kHz, and it shouldn't be that difficult.

Something that would be nice in the future (if we can figure out why it is currently operating so slow) is the ability to configure the UART from binmode to go .5 MHz, which you can do with the "custom Uart" in the new hardware (but only via normal serial terminal.)

Re: pyBusPirateLite Overhaul and My Continued support

Reply #6
The FT232 can go this fast, but most Bus Pirate PICs don't have an accurate enough internal clock to communicate reliably at over 115200bps.

Quote
uart should be going at 115200 Baud (about .1 MHz I think...)

Kind of. It is 100K bits/second. 9 bits to a UART byte (8N1) = 12800 characters per second. Since you have to send the command, and read the reply, you should be able to do around 6000 characters per second not including time for actual Bus Pirate processing and action.

I think the big issue is in sleeping while waiting for the UART. Ideally, you would set an interrupt and act only/when the UART receives a byte from the Bus Pirate. You can do this in C, visual basic, etc, but I don't know if you can do it in script languages like Python and Perl.
Got a question? Please ask in the forum for the fastest answers.

Re: pyBusPirateLite Overhaul and My Continued support

Reply #7
Yes, I now realize why the cap for the ADC is around 6000 samples/second.  I realized that baud was pretty much in bits, not bytes last night.

One thing that would be pretty awesome is if there were a "continuous digital output" mode.  That should be able to spit out data at around 12000 samples/second theoretically, and you could view 5 digital channels simultaneously.  Also, and I think people have mentioned this, we could have a mode that only sends the high byte of the ADC data.

I've been looking at the source code and I think I am going to build on it for my own purposes, and might just add these two things to the source code.

I'm going to keep trying to figure out why the regular operation is so slow.  My library lets me get the analogue data at around 6000 Hz

Re: pyBusPirateLite Overhaul and My Continued support

Reply #8
I've got some fixes coming up.

- Added a member function to setup pwm with arbitrary frequency and duty cycle (stole the code from the wiki)

- Added functions for continuous adc readings.

- fixed some minor bugs.

I also re-programmed an oscilloscope program to ship with it.  Once I get stuff more together, I'll ship it as a package.  The oscilloscope program will come with several "custom buttons" that someone could easily pick up and program small blocks of code in (i.e. like sending i2c data or reading a data pin), all without having to worry about the scope readings (they will automatically shut down).  In addition, the scope program will be a generally handy gui with a scope, pwm control, and the ability to switch the power source off/on.

The oscilloscope is made in PyQt4 with matplotlib as the output screen, so it is more extendable than the other ones I've seen.

I've gotten the scope working.  Just need to implement triggers and work out some bugs and it is ready.

PLEASE:
If anyone has old code they wrote in the original library, could they try and run it using this library instead?  It is supposed to work, hopefully it does.  If it doesn't, any help fixing it would be appreciated.

Edit: posted the new code.

Re: pyBusPirateLite Overhaul and My Continued support

Reply #9
Thanks for all the work you put into this.  A couple things I noticed in BitBang.py

- enter_raw_wire() should return a 1 on success.  Now it either returns None on success or 0 for failure.
- shouldn't bulk_trans be named bulk_transfer?

Re: Re: pyBusPirateLite Overhaul and My Continued support

Reply #10
This project has taken a backburner for the last couple of weeks, but I'm looking at the bus pirate again.  I think the library is pretty solid, but if anyone has any suggestions please post them here or email me.

Dekay: Thanks.  I must have changed that since the last code update, since it no longer does that.
- As for bulk_trans: the legacy code named it bulk_trans, and I didn't want to break anyone's code.  If it bothers you, you are always welcome to import it as bulk_transfer, or I may add a mapping (as I've done with some of the other poorly named functions)

Here is the new code

Re: pyBusPirateLite Overhaul and My Continued support

Reply #11
[quote author="cloudform511"]
PLEASE:
If anyone has old code they wrote in the original library, could they try and run it using this library instead?  It is supposed to work, hopefully it does.  If it doesn't, any help fixing it would be appreciated.

Edit: posted the new code.[/quote]

Hi,

I've just tried your new library. It fixes the problem with PWM in the original library - great.
I've tested is using a script I have for the HP03 pressure sensor. I notice 1 main difference - it takes much longer to run the script. This is because the enter_bb function waits up to 1 second to read a response from each x00. In my case there is about a 15 second delay before the BP is ready.
It seems that you have dropped the use of select in most cases, instead just sleeping for a fixed amount of time - is there a reason for this?

Also, have you implemented the I2C write then read command (0x08)?

Matt

Re: pyBusPirateLite Overhaul and My Continued support

Reply #12
I was having that problem as well, but it is only a problem the first time you connect it.  I will take a look at it and see if I get it to work the same as before.  Thanks for the feedback, I am really glad it seems to work with legacy code :D

Re: Re: pyBusPirateLite Overhaul and My Continued support

Reply #13
Also, I dropped select because it is not compatible with windows.  (the current library is windows compatible as far as I have tested it)

If 0x08 wasn't there, then I haven't implemented it.  If anyone wants to do that, they are welcome to and I will add their function to the code.  I might implement it eventually.

Re: pyBusPirateLite Overhaul and My Continued support

Reply #14
G'Day

I was wondering if anyone had any examples of using pyBusPirateLite with the Dallas 1-Wire protocol. I cannot find any examples, and I cannot work out how to use the library

Any pointers would be appreciated

Darryl VK2TDS