n*HW, 1*driver

[aaaaamartin]

Hi,

I was wondering, how does one use driver code with multiple pieces of the same hardware connected at once.

e.g. the DS1822 code found here, which uses the CCS IO_Functions quite a lot:

http://www.ccsinfo.com/forum/viewtopic.php?t=19520

My HW is set up to use a DS on PORTC.0 and PORTC.1

Given the fact the driver references ONE_WIRE_PIN.

How can I manage two or more devices then?

I already stumbled into the limitations of passing a Pin as an argument.
The workarrounds for these use way too much time in my opinion, so not an option when diong 15us'isch kind of things.

The DS1822 is just an example, albeit not the best. - I know I can connect multiple of these to a single line.


Thanks Mart

[temtronic]

All those 'one-wire-devices' have a unique serial number. Either in the 'code library' here or in the 'forum', search and you will find code that accesses multiple devices on the same pin.
There is a 'cost' though. The new code has to first scan the line to see 'who is there', then you have to create a table of device, ID, use, etc. in NV memory.
Then your main program can then send/receive data from the devices. This extra code will take up space but allows multiple devices on one pin.
The 'easy' way is to just use one other pin, like you did, so did I !
Also be aware that the temperature devices do NOT have the same 'protocol' or timing format, so you can't mix them on the same bus.

And using one wire only has a potential problem. Any fault on that wire and ALL devices are 'lost'.

hth
jay

[aaaaamartin]

Hi Jay,

thanks for pointing it out!

What exactly do you mean by:

[temtronic]

Dallas Semiconductor has THREE different protocols for those devices. Think of having 3 RS485 devices on the same bus. One needs 8-n-1-9600, 2nd uses 7-e-1-2400 and the 3rd 9-n-1,2400. While all 3 devices are 'rs485', they require different signalling timings (protocols).
It's in the DS datasheets, though WHY they did it is beyond me.
It might be technically possible to have different 'protocols' on one bus, but it would be a nightmare. 'Bus conflicts', bad readings, etc.

I found it a LOT easier to have a pin dedicated to each temperature sensor, simpler code and simpler wiring. I tend to use 40 pin PICs as I always 'need' to add 'something' later and the cost of the part is tiny compared to R&D $$$...


hth
jay

[aaaaamartin]

mkay!!!

then, HOW reUSE code? plz...

[temtronic]

Simply put you can't.
Each different series of Dallas temperature sensors need it's own driver. While you can have several of the SAME type or series on one wire, you cannot mix them on one wire.
Think of rims for cars. Some are 4 bolt, some 5, some have 8. While all can 'attach' onto cars, you can't mix them up! 4 bolt rims go with 4 bolt cars.....etc.

It would not be common practice to have several different types of sensors. Usually you design for say DS18B22 series and stay with it. That way you have a common 'driver' and can have 1,2,5,25 of the same sensors (DS18B22 in this case) on one wire.

I do have to ask, why you need to use different sensors, but if you must, then you need to have each type on it's own PIC I/O pin.


hth
jay

[aaaaamartin]

Hi Jay,

sorry for causing confusion. My initial question meant something completely different. So I'll try to sum up:

It's not about specific hardware.
It's about a general approach of reusing driver code,
when there are (lots of) pin constants in it.
Sure can I adapt the code (by simply changing a #define or sth.).
But when in need to use the same code for let's say 3 or 4 devices connected to different pins, that pin must somehow become an argument to that driver-code.

Now my example kicks back in.

I have two DS1822. I don't want to do arbitration on the bus or something. Just simply talking to each one on it's own exclusive pin.

However that code targets a pin given as a constant.

I could as well come up with an example for a LED driver code, where one could blink or stay on etc.

Generally spoken, how to code drivers with pin-config given at runtime?

Thanks Martin

[Ttelmah]

The 'efficient' way, is a simple test. So:

[bkamen]

[bkamen]

[temtronic]

I haven't used the other devices from Dallas but the temperature sensors.
When I did the R&D 2+ years ago I found out that reading the datasheets is very,very important.
They are not compatible on the same wire! There's even drivers here in the code library that support my findings.(pretty sure,been awhile).
I don't recall the specifics, only that I'm NOT the only one that wasted a lot of time on the 'problem'.
At the time it didn't make much sense to not be 100% compatible with the 'one-wire' product line.The 'solution' was to choose one product and stay with it.

hth
jay

[bkamen]

[aaaaamartin]

Fun fun fun,

actually, the intention of the thread was to discuss decoupling of I/O operations from Pin-Constants.

@Ttelmah: Thanks for your suggestion.
@bkamen: Yeah, that is what protocols are for...
@all: Thanks anyway

Don't have the time right now to further discuss this.

Will try to implement some custom I/O Functions next weekend.

So long

Mart

[ckielstra]

Mart,

Just a short note on flexibility:
A driver that is very flexible with pin usage could be created but this comes at a cost and, depending on your project, not everyone is willing to pay that price.

Look at the CCS input(pin) function. You can call this function with a constant (#defined) value and it will compile to a single assembly instruction (when using FAST_IO mode). The same input(pin) function can also be called with a RAM variable, which is what you want, but then the number of instructions increases to about 10. For some time critical or memory limited projects this is unacceptable.

However, when you want to manage, for example, 10 identical sensors on different I/O pins then it would be a waste of code space to include the same driver 10 times. In this situation I would take the existing single pin driver and replace all #defined I/O calls by an I/O call using a RAM variable.

There is no golden rule on when to use either of these techniques. For 1 sensor use the I/O calls with a constant value, for 10 or more I/O configurations use the variable version. For anything in between you'll need to test both methods and decide. Perhaps the third variant as described by Ttelmah is a good solution when 2 or 3 pin configurations have to be mixed.

[aaaaamartin]

Hi ckielstra,