ds18b20 one code on multiple pins

[Danni]

Hello guys.

im trying to adapt my ds18b20 code so i can change pin number and use the same code on multiple pins.

Im using case to change pin number and it works until the line with !!!!!:

[temtronic]

can't be done..
from the CCS manual.....
Syntax:
output_bit (pin, value)



Parameters:
Pins are defined in the devices .h file. The actual number is a bit address. For example, port a (byte 5 ) bit 3 would have a value of 5*8+3 or 43 . This is defined as follows: #define PIN_A3 43 . The PIN could also be a variable. The variable must have a value equal to one of the constants (like PIN_A1) to work properly. The tristate register is updated unless the FAST_IO mode is set on port A. Note that doing I/O with a variable instead of a constant will take much longer time.

Value is a 1 or a 0.

Please note 'value' MUST be a '1' or a '0' NOT a 'variable' .

As for 1 ds18b20 per pin, I simple copied the 'driver' functions twice.

ie:

[Danni]

But when i need 8 or 10 sensors it's a loooong code.

i did copy the code on a pic i have with two sensors.

i have changed all the code but only need the line output_bit(DQ, shift_right(&val,1,0));

My reset code its:

[Ttelmah]

The reason the core function only supports constants, is that it is basically coding a PIC _hardware_ function.
This does not support variables.

Going back, the original output_high, and output_low functions had the same limitation.

However CCS added 'variable' based versions for these a (long) while ago.
Your 'output_low' code will work with a variable. Your _output_low code is not needed, but the pin number needs to be an int16.

However they did not code 'output_bit' this way.

Add this:

[PCM programmer]

Using variables for CCS pin numbers generates very long ASM code which
doesn't allow the correct timing intervals required for a one wire driver.

This is the code produced by the test program shown below.

[Ttelmah]

Very much agreed.
I actually thought I said this, but I must have left it out..... :(

It's a balancing act.

For just two or three pins, the switch solution will be smaller/faster. However for the large number of pins involved, I'd suspect both solutions will be comparable.

The key thing is that the 'simple' code, using variables, will probably actually be as large as doing the multiple solutions. And (more importantly possibly), there is the very real risk of the extra delays inside the routines, may well create timing problems.

I have to say that I'd probably code the routine as a multi-line #define macro, so that the code can be kept simple, and the timings right.

[Ttelmah]

Looking at it again, there is another solution that should be considered.

Since all the bits are on one port, the best way to do this, is to simply create a mask at the start of the routine for the bit required, and then do all the operations using byte wide operations. This will be nearly as fast as the standard code, and only a very few bytes larger.

Otherwise the solutions are honestly awful.....

[temtronic]

Since it's almost 100*F here (40*C), I thought I'd look at this again. The ds18b20p driver I use is about 922 bytes long for 2 devices, 1 per pin. So... simple math says 460 bytes per driver per pin. 8 devices on 8 pins is 8 * 460 =+-3680 bytes.
Two things to consider. 1) TIMING ! 'one wire' is time sensitive so you have to be accurate and repeatable with your code to get proper communications.
2) cost. It should be possible to get a PIC with LOTS of program space for maybe a few pennies more, same pinout, just more memory.
Yes, my individual driver per pin is not code efficient BUT it does work. You've mentioned using 8 or 10 devices and that implies that 'main() has a lot to do, so you should be using a 'big' PIC (one with lots of memory).
Now Mr. T's 'masking' has merit but when you say 8 or 10 sensors...hmm the mask might need to be 16 bits or 2 x 8 bit, IF you can use byte wide ports. MY way doesn't care which bits on what ports...
It's one of those sounds simple but gets very complicated in working out the details... remember this is bit banged so TIMING is the most important factor.

I know cost is always a factor but you need to consider your TIME. R&D is not free, even at $50 per hour, how many DAYS have you put into this and not got a workable solution? I'm guilty of using the 18F46K22 for some 'simple' tasks but I've never run out of memory or pins and always delivered the product before the due date. Just something to consider.

Jay

[gaugeguy]

Another thing to consider is that the DS18B20, like most of the 1-wire product line, is designed to be multi-drop. 8-10 of these can easily be connected on a single line. There is some added communication involved but very simple hardware using just one pin.

[temtronic]

One problem with the DS implementation of 'one wire' communications with multiple devices is that if there's a break in that wire, say between sensor #2 and #3, you'll lose sensors #3 thru 8 so the option of one pin, one sensor eliminates that possibilty.
There are other ways to effect 'single wire' communications that will still work even if there's a break in the wire though.

It'd be interesting to see if the driver code for 'multiple devices on one pin' IS actually smaller than a 'one device-one pin' driver.

Jay

[Ttelmah]

OK. off the cuff code here.

[gaugeguy]

As far as the broken wire concern, having one input at the system does not mean there cannot be 8 or 10 connections going out, one for each sensor.
That being said my first product using the 1-wire sensors did use a separate pin for each of 4 DS1820 sensors using a PIC16C58 to drive a 2x16 display.
The search ROM code to find the sensor ID's is a little long so it comes down to a trade off. There isn't one perfect solution for every situation.