![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
n*HW, 1*driver |
Posted: Sun Dec 02, 2012 6:07 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sun Dec 02, 2012 6:37 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
|
Posted: Sun Dec 02, 2012 7:17 am |
|
|
Hi Jay,
thanks for pointing it out!
What exactly do you mean by:
Quote: | 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. |
Connecting completely different types?
Again, in Code, how do you differentiate between the pins in use?
cheers Mart |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sun Dec 02, 2012 10:05 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
|
Posted: Sun Dec 02, 2012 4:59 pm |
|
|
mkay!!!
then, HOW reUSE code? plz... |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sun Dec 02, 2012 6:54 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
|
Posted: Mon Dec 03, 2012 3:02 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Mon Dec 03, 2012 3:18 am |
|
|
The 'efficient' way, is a simple test. So:
Code: |
#define PRIMARY_PIN (TRUE)
#define PIN1 PIN_A0
#define PIN2 PIN_A1
//Then instead of 'output_high(PIN_A0)' for example
if (PRIMARY_PIN) output_high(PIN1);
else output_high(PIN2);
|
This generates the fastest/smallest code to switch between two pins, with just a single bit test, and jump, on top of the basic output instruction.
In the code, you just set PRIMARY_PIN TRUE/FALSE before calling the driver.
Anything involving 'dynamic' pin changing to lots of possibilities runs into just how much harder this is. The processor can perform an output_high, or output_low, with a single bit set/clear instruction. With fully 'dynamic' allocation, you instead have to use indirect addressing to find the actual register involved, and then bit masking on the register to handle the bit. Typically probably at least 10* as much work...
This is what the CCS dynamic pin code does.
There is no 'better' answer. It is down to the limitations of the processor.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Mon Dec 03, 2012 3:22 am |
|
|
temtronic wrote: |
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.
|
Not at all.
If you know the Addr's of the devices beforehand, you can have a user menu to enter them... or in the case of one-sy two-sy projects (like a multi-point temp sensor I made for an old RS/6000 server) - just embed them into ROM... (granted, this isn't changeable without recompiling).
I supported 4 1820 family sensors with a 12F672 without a hitch... _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Mon Dec 03, 2012 3:27 am |
|
|
temtronic wrote: | 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. |
If I'm reading this correctly that you are asserting that, say, temp sensors and a GPIO and an A/D and a memory storage device (all dallas one wire) cannot be on the same bus....
This is absolutely not true.
The dallas dev kits even come with example software that scan and show multiple devices on the same bus. (which I've had working on the bench myself)
Check out this really old weather station project...
http://archives.sensorsmag.com/articles/0698/wir0698/index.htm
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Mon Dec 03, 2012 6:56 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Mon Dec 03, 2012 12:04 pm |
|
|
temtronic wrote: | 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.
|
That's weird...
(and I'm assuming when you say "code library" you mean the CCS Forum library, not Dallas's code library -- if that's the case, anything found here might be well written, but absolutely filed under "buyer beware".)
It doesn't make sense for them to white paper a protocol and then resell devices that don't adhere to that protocol.
Not that I don't believe you that it happened to you -- but I'm skeptical having seen multiple devices of the same family and different families on the bus working at the same time.
heck, I have an LCD from CrystalFontz that uses DOW (Dallas One Wire) for their temp sensors and you can put lots of them on a single bus. (I forget what they claim their drive levels are.. but I have about 4-5 1820's on the same bus working right now in my Linux server!)
hmmmm....
I'm skeptical.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
|
Posted: Mon Dec 03, 2012 3:26 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Dec 04, 2012 4:59 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
aaaaamartin
Joined: 17 Apr 2005 Posts: 39 Location: Germany Stuttgart
|
|
Posted: Tue Dec 04, 2012 8:07 am |
|
|
Hi ckielstra,
Quote: | The same input(pin) function can also be called with a RAM variable |
Is this a "new" feature I am missing? - My compiler is terribly old, 5y+ or something.
Got licence? Christmas is near
Mart |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|