1-Wire bus confusion

This follows on from the topic “IIC usage problem”, but it’s sufficiently different that I thought it worth starting a new topic.
I’m using an rpi with an IIC to 1-wire interface from Sheepwalk Electronics. It’s effectively a Maxtor DS2482-100.
Attached to that I have a couple of DS18B20 temperature probes. The testing below was done with a single probe connected, since i haven’t managed to read the addresses yet.
So far I’ve managed to get my head around sending commands to the interface, and sending data through it to the 1-wire bus. With an oscilliscope I can see the probes responding. However I’m failing to read anything back.
The probes seem to require the commands “1-wire reset”,“skiprom”,“convert”,“read scratchpad”, then the data should be available to read. Between each of these commands the status register of the interface needs to be checked until the 1-wire-busy signal clears. The scratchpad holds 9 bytes, and would seem just to need 9 byte-reads or 72 bit-reads.
After this I tried the 1-wire-readbyte command to the interface, the setreadptr command (selecting the data register) and a read to the address of the interface. This always returns 00.
All the commands to the interface (except setreadptr) leave the default register as the status register, meaning a setreadptr is needed before the data register can be read.
I tried the 1-wire-single-bit command in a loop. This, with the MSB of the parameter set, does a read, and returns the result in the status register, avoiding the need to change the read pointer. By repeating this command I can see on the oscilloscope that the probes do respond, but always with 0 as the bit. This suggests to me that I’m using the wrong sequence to set up the read, but I can’t figure out what it should be.
There are lots of examples on the web for doing this, but most use Linux libraries which completely hide the level of detail I need. The others use specific libraries for less common microprocessors. Even if I found the sources of the libraries, my knowledge of C is minimal, and making sense of it unlikely.
Has anyone used these probes at a low level, and could help please?

Some six years ago, I explored the workings of the 1 wire bus and had some limited success. I’ve put up a web page and a download of my efforts from that time (with a few minor updates made over last couple of days). The IIC to 1 wire chip I’m using is the DS2483 so there may be some minor differences (choice of IIC address being one I noticed).

The program I’ve uploaded needs AppBasic loaded, as that provides the framework for it to run but looking inside the app at the Basic files inside !RunImage will reveal a number of PROCs to carry out most 1 wire functions. Using this program, I’m able to read the temperature from 3 1 wire chips all connected to the same 1 wire bus.

Thank you. This sounds promising.

I notice that you hadn’t managed to get the address search working. I have now successfully translated the Maxtor example into BASIC. The main difficulties I had were not initially realising that the ROM_NO store was effectively a byte array – I implemented it as an integer array – and not noticing that shifting the mask left until it reached 0 needed trimming to a byte. I had to move the main search loop into a seperate proc in order to get the “break” to work.
The result is here [SearchAddress]http://www.adamshome.org.uk/one-wire/AddressSearch.html

Nice work, Alan. This is just the sort of code I was looking for.

Moving on to try and read the temperature. I found in one of the data sheet examples a hint that after the convert command is sent and executed, a 1-wire reset is needed before selecting the address again (or skipping for one device only).
After doing this a readscratchpad followed by a sequence of 9 readbyte commands followed by reads of the data register returned a pattern of 9 bytes. (Reading more just returned constant values of &96).
However the pattern doesn’t fit the content expected from the scratchpad.
The first two bytes (1 and 2), which should be the temperature, are different between the two probes, and vary slightly with time. However they seem to indicate a room temperature between 1 and 2 degrees C. As i’m working in shirt sleeves, this seems unlikely.
The remaining 7 bytes are the same from both probes. Bytes 3 and 4 return 2 and 6, and these should be the limits high then low for alarm setting. Byte 5, the configuration register should always return &F in the low nibble. It returns &16. bits 6 and 7 should be 1 after power-on.
Byte 6 7 and 8 are reserved. Byte 9 should be the crc of the previous values. It is not.
Writing new values into registers 3,4 and 5 using the writescratchpad command do not change the returned values.
All this suggests to me that while it is sending back exactly 9 bytes of data, it isn’t the scratchpad data. But I can’t see what else it could be.

Mikko – check you have the latest version from the link. There was an error in the first version posted – the PROCsetreadptr function didn’t work as it used “?(data%+4)” instead of “?(data%+1)”.

Thanks, Alan. I’ll take a proper look at this tomorrow evening.

Alan, Did you try my program? You would have needed to change the IIC address to get it to talk to the DS2482-100. I tried running your program after changing the IIC address to suit the DS2483 but hit a problem – missing brackets on line 69 – fixed that and it runs but I’m not sure what it’s telling me.

A quick and dirty way to get the temperature returned from the scratchpad, if you only want positive values is to multiply the returned value by 0.0625

I haven’t tried yours yet, as I needed to get the addresses. For mine, it gets addresses that look reasonable, ending in 28H, which is the right family ID, and with a crc that validates.

I’ve since extended it to try and read the temperature. It does appear to read 9 bytes of data, since reading more than that gets a constant value, and the bytes are stable. The two probes produce similar patterns too. However the temperature readings don’t make any sense, and the last byte isn’t a valid crc. (I did wonder whether the bytes were bit-reversed…)

Unfortunately the application I have in mind is monitoring a freezer, so negative values will be important.

@Alan: I’m quite interested in that topic also regarding multiple temperature measurement possibilities. On the Sheepwalk Site I see that the DS2482-100 only has one connection…how could you connect several probes ?

I also see advanced hardware offers from them for all R-PI’s with a DS2482-800 for up to 8 channels. Would that device also work, may be with some code changes ?

A few updates to the previously uploaded program.
Added code to detect for presence of DS2482-100 (un-tested)
Added code read the full temperature range (previous version couldn’t do below zero deg C

Also uploaded a little BASIC program to read a single 1-wire IC’s 64bit ROM address and if it’s a DS18B20 read it’s temperature. For this to work there must be only a single 1-wire IC on the bus, any more and a collision will result. It works with a DS2483 and should also be able to work with a DS2482-100 (un-tested)

Get them here

@Kuemmel: A number of 1 wire IC’s can be connected to a single 1-wire bus with each being addressed via the IC’s unique 64 bit address. They are daisy chained like a set of tree lights.

Robin: I don’t have AoppBasic, so I’ve had to fudge it a bit. I have taken the DS2482 part of your software, added part of the INIT program and added in the addresses my program found, and now I can read the temperatures. I now intend to investigate the differences between this working hybrid program and my non-working original.
I’ll also have a look at your updated version.

Kuemmel: As Robin says you can connect a large number of 1-wire devices to a single bus, which is whay it’s called a bus. The limit will be wire lengths and capacitance, and to get over that you might want to use a multichannel master like the DS2482-800. you would also need this if you had sensors radiating out for some distance from the master. There is a short limit on the length of branches – something like 10 feet I think.

The code would need minor modifications for that. The address scan searches for all the device addresses on a bus. You would need to run that once for each bus, and store all the results. Then select the bus and an appropriate 1-wire address for each measurement.

I now have a complete program for finding the 1-wire addresses and reading temperatures from each device. (It assumes they are all temperature probes – check the lowest byte of the address is &28 to find out, and it assumes the interface DS2482 is on addresses &37 and &36, i.e. AD0 and AD1 are both 1.)

[]http://www.adamshome.org.uk/rpi/ReadTemperature.html

The key I discovered was that after issuing a 1-wire-reset, and checkign the 1-wire-bit in the status register, it needs an additional small time delay before doing the next command. This done by adding a PROCwait(0.02) into the FNOWreset. (using 0.01 produces a delay of between 0 and 10 mSecs, resulting in random failures. 0.02 is the shortest reliable value.)

I found this because when it didn’t work I added some code to log which functions were called. With logging on, it didn’t fail. Turning off the logging and it failed again.

I’ve left the logging code in the example, turned off, in case it proves useful.

Robin: your Ds2483_ReadROM example looped endlessly on my hardware. The status check after PROCreadrom is the cause – it assumes the read pointer is set to the status register, but at that point it is the data register. Removing the check works.

Alan: I can’t get your program to produce a useful result either! Having changed the IIC address it reports ‘Found 1 devices’ whether I have 1 or 3 devices connected and no sign of a temperature readout.

Removing PROCcheck_status from my program (or replacing my PROCcheck_status with your PROCwait causes a failure here.

How do you power your DS18B20s 5volts or parasitic? I’m using 5volts power. The only other thing I can think of atm is a difference in the operation of the DS2482 and DS2483 (the DS2483 does have an extra register but I can’t see how that would affect things)

The Pi uses 3.3V logic on pins 3 and 5. This suggests your temperature sensor should be powered at 3.3V not 5V.

Chris:The DS2483 uses the normal 3.3v for Iic but 5v (or parasitic) to communicate With 1-wire devices

Robin: That’s puzzling. The problem I had reading temperatures was that it wss sensitive to timing. Maybe the 2493 is more sensitive to timing, and hence failing to find more than 1 device. I would try putting a short delay after the triple before looking at the return.

I’m also using 5-volt power, because without it, it needs a pullup after the convert command, and then the 1-wire-busy can’t be used to check for completion.

The 18B20 power supply spec. is between 3v and 5.5v, so 5v power is fine. In the course of this I discovered that all 4 of my rpi power supplies fail to reach 4.7 volts, although the rpi’s are fine. I also tried a couple of USB mains-powered chargers, including an Apple one, and found the same thing. I was using a TTL monostable to get a good trigger pulse for the oscilloscope, and that wouldn’t work off any of them.

So I extended the code into a desktop program that reads and records the temperatures. It’s been running fine for about a week.
Today I added a third probe – now the address search finds the same two devices several times over – it seems it has trouble detecting when it has reached the last device. Any combination of two out of the three works, it’s when I have three together it fails.
No time to investigate now however, and it will fulfil its original purpose with 2 probes, so I ought to leave this on the back burner. Maybe…

(I did have a look at the DS2483. It seems to be a DS2482 with the one-wire timing adjustable. I wonder whether its default timing is not the same as the DS2482’s fixed timing? I did find some timing issues, so it’s definitely an area to be suspicious about.)

Any combination of two out of the three works, it’s when I have three together it fails.

That brings back memories of where I gave up 6 odd years ago. As for any real world use you would need to maintain a table of 1-wire addresses by location of device e.g. ‘ABCD1234ABCD1234, Dining Room’ I read the address of each 1-wire device in turn using Read ROM and then created the table.

I’ve also been looking for differences between the DS2483 and DS2482. Not come to any significant conclusion yet…

more work on it yesterday. I’ve narrowed the problem down to the search loop. With 3 or more devices connected it gets the first two addresses correctly, then loops endlessly getting the same two, never detecting last device. I now have a printout in binary of the three addresses and I’ll work the algorithm by hand to see whether I can see why “last_zero”, which controls the next search, goes 9,21,9, whereas I would expect it to be a descending number. When it’s 0, the loop should end. I’m expecting it to be one of the 3 or 4 points where search_direction gets decided.

Solved! I was initialising the results ROM array each time I started a new search loop. It turns out that it needs the previous value to still be in there in order to handle more than 2 devices on the bus. It’s now working with 7 devices.
The program can be found [Here]http://www.adamshome.org.uk/one-wire/ReadTemperature.html

Alan, I got your latest program working successfully. Had to change to the IIC address for the DS2483 and turn on logging to get it to run. With logging turned off it appears to start and quit immediately.

My next move is to try and adjust the DS2483 timings to align with the DS2482 default and try again with logging off.