Skip to main content ↑ ↓
Topic: pyBusPirateLite 1-Wire example (Read 4637 times) previous topic - next topic

pyBusPirateLite 1-Wire example

from "Re: pyBusPirateLite Overhaul and My Continued support" ( http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=1703&p=22027&hilit=pybuspiratelite#p22027 ).

I thought this deserved its own topic.

[quote author="vk2tds"]
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
[/quote]

I don't know of any examples, but my next project involves using the DS18B20, which is a 1-Wire temperature sensor, and I was hoping to use the BP and the Python library to get the hang of it (writing it, if necessary).

Which is all to say, I'll probably be working on this, and would be happy to share anything I come up with.  Would you post about any progress you're able to make, as well?

Re: pyBusPirateLite 1-Wire example

Reply #1 –
Thanks for that. I look forward to following your discoveries. I will also work on things and see how I go

Darryl

Re: pyBusPirateLite 1-Wire example

Reply #2 –
In onewire.py, it would seem that going into 1wire mode resets the power and pullups. Therefore, I have added the following code, although it is a real hack, just to turn on power.
Code: [Select]
       def _1wire_test(self): 
                self.check_mode('1wire')
                self.port.write("x48")
                self.timeout(0.1)
                return self.response(1)

Also, the function __group_response will not work in Python from what I can determine. I have created a hack that sort of works. Probably not the best but it does return something.

Code: [Select]
        def __group_response(self):
                self.check_mode('1wire')
                EOD = [0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff]
                #= was ==
                while 1:
                        print "read"
                        data = self.port.read(8)
                        if data == EOD:
                                break
                        if len(data) == 8:
                                print "%d %d %d %d %d %d %d %d" % (ord(data[0]), ord(data[1]), ord(data[2]), ord(d


Now, when this runs, I get the following.... This seems to be the ID's of the two devices I have connected. Still, with the two zeros at the end, things look a bit suspicious. I will need to check. No, it is fine, but the first character being returned does not seem to be the ID, and there is a number at the end that is missing from the ASCII command under the BP [command (240) ]

Code: [Select]
MacBook:pyBusPirateLite_v1 darryl$ ./test.py 
read
1 40 220 20 6 3 0 0
read
41 40 253 22 6 3 0 0
read
43 255 255 255 255 255 255 255
read
read

My test code is :-
Code: [Select]
#!/usr/bin/python

import UC

myBP = UC.UC()
myBP.connect ("/dev/tty.usbserial-A6005kqu")
myBP.enter_bb()
myBP.configure_peripherals( power = 'on', pullups = 'on')
myBP.set_dir(0x00)
myBP.enter_1wire()
myBP._1wire_reset()
myBP._1wire_test()
myBP.rom_search()

Hope this helps

Darryl

Re: pyBusPirateLite 1-Wire example

Reply #3 –
Hm, it looks like you might be using the version of pyBusPirateLite from that previous forum post.  I had quite a bit of trouble getting anywhere with it, it seems to have diverged quite a bit from the current SVN source.  Try starting with the version in the repository (currently rev598) or grab the download package of r597:  http://http://code.google.com/p/the-bus-pirate/downloads/detail?name=pyBusPirateLite-r597.zip&can=2&q=#makechanges

[quote author="vk2tds"]In onewire.py, it would seem that going into 1wire mode resets the power and pullups. Therefore, I have added the following code, although it is a real hack, just to turn on power.
Code: [Select]
       def _1wire_test(self): 
                self.check_mode('1wire')
                self.port.write("x48")
                self.timeout(0.1)
                return self.response(1)
[/quote]

It seems to be normal for the system to disable power and pullups at mode transitions, requiring the user to re-enable them.  The BBIO class (in SVN) that 1Wire inherits from provides a "cfg_pins" interface that you can use to set them.  The values for the various peripherals are defined here: http://http://dangerousprototypes.com/docs/1-Wire_%28binary%29

Code: [Select]
obj.cfg_pins(0x08 | 0x04) # where obj is an instance of the 1Wire class

If you look at the I2C package (in SVN), it defines an "I2CPins" class which specifies the different peripherals that you can pass to cfg_pins.  We probably ought to define something similar for the 1Wire class.  According to http://http://dangerousprototypes.com/docs/I2C_%28binary%29, the peripherals are the same.  I'll try and add that to SVN later.  In the meantime, you can copy it directly, and then call

Code: [Select]
obj.cfg_pins(1WirePins.POWER | 1WirePins.PULLUPS) # where obj is an instance of the 1Wire class

[quote author="vk2tds"]
Also, the function __group_response will not work in Python from what I can determine. I have created a hack that sort of works. Probably not the best but it does return something.

Code: [Select]
        def __group_response(self):
                self.check_mode('1wire')
                EOD = [0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff]
                #= was ==
                while 1:
                        print "read"
                        data = self.port.read(8)
                        if data == EOD:
                                break
                        if len(data) == 8:
                                print "%d %d %d %d %d %d %d %d" % (ord(data[0]), ord(data[1]), ord(data[2]), ord(d

[/quote]

Interesting, I'll have to look into this a bit more.

[quote author="vk2tds"]
Now, when this runs, I get the following.... This seems to be the ID's of the two devices I have connected. Still, with the two zeros at the end, things look a bit suspicious. I will need to check. No, it is fine, but the first character being returned does not seem to be the ID, and there is a number at the end that is missing from the ASCII command under the BP [command (240) ]

Code: [Select]
MacBook:pyBusPirateLite_v1 darryl$ ./test.py 
read
1 40 220 20 6 3 0 0
read
41 40 253 22 6 3 0 0
read
43 255 255 255 255 255 255 255
read
read

My test code is :-
Code: [Select]
#!/usr/bin/python

import UC

myBP = UC.UC()
myBP.connect ("/dev/tty.usbserial-A6005kqu")
myBP.enter_bb()
myBP.configure_peripherals( power = 'on', pullups = 'on')
myBP.set_dir(0x00)
myBP.enter_1wire()
myBP._1wire_reset()
myBP._1wire_test()
myBP.rom_search()

Hope this helps
[/quote]

Good work so far.  Have you considered using the Python console?  It can be handy for experimenting with commands "live".

Re: pyBusPirateLite 1-Wire example

Reply #4 –
Thanks for that. I thought I was going to get a chance to look at this today, but that seems unlikely, and I am now going away for a few days flying, and I probably will not be taking my Mac and will not have time to play either.

I have downloaded the other library, and it still has the issues with things like assignment within the While.

Darryl

Re: pyBusPirateLite 1-Wire example

Reply #5 –
So I looked into this a little more.  I'm working with a DS18B20 temperature sensor, and was able to communicate with it using the normal serial mode of the Bus Pirate.

It seems pretty clear to me that the one-wire library has not been heavily used or tested, and I'd like to overhaul it a bit.  Here are some of the features I'm interested in:

* renaming it to something that's not subject to the same naming constraints (how does OneWire sound?)
* add OneWirePins class definition
* add setup support for entering BBmode, entering OneWire mode, and (optionally) enabling power and pullups during init
* add Skip ROM macro support
* incorporate updated group responses (Python doesn't seem to support that kind of assignment expression in a while loop at all, this is my biggest clue that there wasn't much testing going on for this portion of the library)

I will be out of town for a while too, but I hope to have another look at this next week.

Can you tell me more about what you're trying to use it for?  Which devices are you using (and how many? your example seemed to indicate at least two).

Re: pyBusPirateLite 1-Wire example

Reply #6 –
Hi Schazamp

Thanks for the email. I am back from my flying trip...

I am hoping to use to the OneWire library with multiple DS18B20's running mostly with active power. I am hoping to do data collection of temperatures within my house as part of a house monitoring experiment. I am guessing that I will be using more than two and less than 50. Apart from that, I really am not sure.

That assignment in the While loop was my miggest indication that the library has not been tested much either. In fact, it tends to suggest that the library may have been converted from 'C', or at least by a 'C' programmer.

Let me know how I can help. My programming is more hacking rather than well designed code. I am an electrical engineer rather than a computer scientist.

Darryl

I think renaming it to OneWire would be a good idea.

Re: pyBusPirateLite 1-Wire example

Reply #7 –
Quote
It seems to be normal for the system to disable power and pullups at mode transitions, requiring the user to re-enable them.

This is true, everything is reset between modes like in the terminal interface.

Code: [Select]
read
1 40 220 20 6 3 0 0
read
41 40 253 22 6 3 0 0
read
43 255 255 255 255 255 255 255
read
read

I think that first 0x01 is an 'OK' reply for the ROM SEARCH command. Everything else seems to be off one byte. Do these match the address you see in user terminal mode with the (240) search macro?
Got a question? Please ask in the forum for the fastest answers.

Re: pyBusPirateLite 1-Wire example

Reply #8 –
If the first byte is the OK, then there is a byte missing at the end. Anyway, I decided to bite the bullet and buy an Arduino board, and write a client program that scans the One-Wire bus constantly downloading the temperature and shoving this out the serial/usb port. I had the code running in under an hour of the Arduino arriving, and I had never used it before. Very impressed. For my purposes, this suits my purposes.

On the computer side, I wrote a quick Twisted Python protocol for my code and it is working really well. The one thing that I did find was that I need to throw out any results when the number of devices found chance since occasionally when removing a device it will get the temperature of the device not being removed

Darryl