Same code in different Pins

[Josuetas]

Well this device is some kind of 16 ports 1Wire to Serial HUB, it sends serial
data to a pc with the info requested by the PC, maybe write the pages of a 1wire device (0-15 pages), read de Identification from a 1Wire, read some temperatures, you should be able to do anything to any device on the port.

Why?: well in this development I am using up to 16 i-buttons, actually they where read directly through the PC. And i am in Colombia, it is not easy at all to find DS parts, even more it is really expensive.

What kind of info? well mostly OW commands with data bytes, since each page is 32 bytes it would be interesting to receive and send everything in an array 32 bytes long. Exactly?... well $F0, $cc, some bytes... typical protocol bytes for 1wire

Pins used: PORTB (ALL), portA (0-3... i hate pin4 ), portC(2,3), portd (0,1)

Thats all.... its simpler than it seems i guess.... i might do other simple tasks, but i´m sure i dont need help with that.

I really want to learn this, i m sure you have a great tip behind this request.

Thanks Again

[skimask]

Well this device is some kind of 16 ports 1Wire to Serial HUB, it sends serial
data to a pc with the info requested by the PC, maybe write the pages of a 1wire device (0-15 pages), read de Identification from a 1Wire, read some temperatures, you should be able to do anything to any device on the port.

Why?: well in this development I am using up to 16 i-buttons, actually they where read directly through the PC. And i am in Colombia, it is not easy at all to find DS parts, even more it is really expensive.

What kind of info? well mostly OW commands with data bytes, since each page is 32 bytes it would be interesting to receive and send everything in an array 32 bytes long. Exactly?... well $F0, $cc, some bytes... typical protocol bytes for 1wire

Pins used: PORTB (ALL), portA (0-3... i hate pin4 ), portC(2,3), portd (0,1)

Thats all.... its simpler than it seems i guess.... i might do other simple tasks, but i´m sure i dont need help with that.

I really want to learn this, i m sure you have a great tip behind this request.

Thanks Again

How about using a 74138 (3-8 decoder) or 74154 (4-16 decoder), controlled by either 3 or 4 address lines, to apply a ground to the O.W. device desired (thereby powering it up) and using the same one-wire read/write pin in common to all of them? Surely setting porta.0-porta.3 for an address takes a lot less code space than multiple types of OW commands...

Might not be such a good idea since it'll only save you 3 pins out of your 'Pins used:' list.
And heck, I don't even know if it'll work...

[Josuetas]

How about using a 74138 (3-8 decoder) or 74154 (4-16 decoder), controlled by either 3 or 4 address lines, to apply a ground to the O.W. device desired (thereby powering it up) and using the same one-wire read/write pin in common to all of them? Surely setting porta.0-porta.3 for an address takes a lot less code space than multiple types of OW commands...

Might not be such a good idea since it'll only save you 3 pins out of your 'Pins used:' list.
And heck, I don't even know if it'll work...

This seems like an idea but it also appeals to me like a waste since i have the micro and i can aviod using more ics.

What is really interesting and almost a need is to discuss if it is posible to use several OW devices conected to the same wire with the OWOUT OWIN commands, i havent really got into the subject but.... how do you assign addreses(ids) to each device conected to the line? I would have to read the document about the OW protocol by maxim, it dont seems to be simple at all.

[Darrel Taylor]

Colombia!
Sorry for the misspelling, but I'm used to hearing a RED or GOLD after it. So it seemed different.

And since I've been sitting on this answer for 4 days now, ...Not "THAT slow" is still slower than UPS ground.
So here goes...

As a reminder ...

And it's a scary one. Yet oh so cool.

<hr>
So here's the SCaRy part ...
I'm going to ask you to modify a PBP macro file. AAAhhhhh!!!!

Ohhh, stop screaming, It's easy!

And, since it's easier to Do, than to explain, I'll start with the "HOW TO". Then comes the explanation.

<hr>
In your PBP folder, there is a file named PBPPIC14.MAC

WARNING! Before making any changes to this file, Make a backup copy first.
Don't blame me if it gets messed up and you have nothing to replace it with!

Now that the legal issues are over <hr>
Open the PBPPIC14.MAC file with NotePad.

Do a Search for OWPIN?W

You should see a section that looks like this...

OWPIN?T macro Regin, Bitin
        BIT?R1  Regin, Bitin
    endm
  endmod

OWPIN?W macro Win
        MOVE?WA Win
        L?CALL  PINR1
    endm
PINR1_USED = 1
  endmod

;****************************************************************
;* OWMODE?X   : Macro - Assign One-wire mode, check for reset   *

Comment out the OWPIN?W macro with semicolons, and replace it with a new routine.
It should look like this afterwards...(without the colors, of course)
Blue is the OLD, Red is the NEW.

OWPIN?T macro Regin, Bitin
        BIT?R1  Regin, Bitin
    endm
  endmod

;OWPIN?W macro Win
;        MOVE?WA Win
;        L?CALL  PINR1
;    endm
;PINR1_USED = 1
;  endmod

;-- changed for addressing any pin with a word variable --
;-- highbyte = Offset from PORTA, lowbyte = PIN --
OWPIN?W macro Win
        MOVE?CB PORTA, RR1
        MOVE?BA Win+1
        CHK?RP  RR1
        addwf   RR1, F
        MOVE?BB Win, R4
        L?CALL CONVBIT
        MOVE?AB RM1
    endm
CONVBIT_USED = 1
  endmod

;****************************************************************
;* OWMODE?X   : Macro - Assign One-wire mode, check for reset   *

That's It! .. Well, almost.<hr>
Now the OWIN/OUT commands will accept a WORD variable that can address ANY pin on the chip.
The next part is to figure out what that WORD is.

You want the HighByte to be an Offset from PORTA. (0 is PORTA, 1 is PORTB, 2 is PORTC, etc.)
The LowByte of the word is the BIT number (0-7).

I'm sure there's a hundred ways to go about it, but here's one possibility.
Create an array of WORDs, with each element specifying a different PIN.

OWpins   VAR  WORD[16]                    ; assign pins for OneWire commands.
  OWpins(0)  = $0000  ; PORTA is 0, bit 0 ; Assignments can be in any order
  OWpins(1)  = $0002  ;             bit 2 ; Shown sequentially here for clarity
  OWpins(2)  = $0100  ; PORTB is 1, bit 0
  OWpins(3)  = $0101  ;             bit 1
  OWpins(4)  = $0102  ;             bit 2
  OWpins(5)  = $0103  ;             bit 3
  OWpins(6)  = $0104  ;             bit 4
  OWpins(7)  = $0105  ;             bit 5
  OWpins(8)  = $0106  ;             bit 6
  OWpins(9)  = $0107  ;             bit 7
   ... 
  OWpins(15) = $0307  ; PORTD is 3, bit 7

Which then allows you to do the original request ...

<font color="#000000"><b>PIN  </b><font color="#008000"><b>VAR BYTE

FOR </b></font><b>PIN </b>= <b>0 </b><font color="#008000"><b>TO </b></font><b>15
    </b><font color="#008000"><b>OWOUT </b></font><b>OWpins</b>(<b>PIN</b>), <b>1</b>, [<font color="#FF0000">&quot;data here&quot;</font>]
<font color="#008000"><b>NEXT </b></font><b>PIN</b>

That really is IT.
<hr>
The Explanation.

When compiling.., PBP chooses the correct macro to use depending on what type of variable you pass to the statement.
If you pass a BYTE variable as the PIN, it assumes it's a "PIN Number" (0-15) and uses the macro OWPIN?B

If you pass a PORTB.0 type, it hard codes the pin and bit with the OWPIN?T macro.

These choices are made by the PBP(W).EXE compiler, and we have no way to change that.
However, the actual macro's that are called, are "Open Source", so we are free to change the way the commands behave, even though the compiler doesn't know about it.

Now it's probably not a good idea to go around changing the way things work on a general basis, but sometimes it can make a big difference.

And in the case of OWPIN? there's a macro that really should never be used. It's OWPIN?W
While it allows you to use a WORD variable for the "PIN Number", it's value is limited to 0-15, so a word variable doesn't make a whole lot of sense.

Since it's already built in to the compiler, and it'll never be used. If we re-write the macro that goes with it, we can use it to select any pin we want, and still have OWIN/OUT work exactly the same way it did before.

*** I was going to go further into the macros here, but, in case you already understand, I'll wait. **

The only problem, is that on the next Upgrade to PBP, any changes will be overwritten.
So you'll have to remember what you've changed. I usually make a .txt file in the same folder as the project, and make notes on any changes required for that program.
Or, like Joe S. did, you can just bookmark this thread for future reference.

<HR>
Now then, I can see the wheels turning in a couple people's minds. And you're right!

The same concept can work for any command that uses "PIN Numbers".
SERIN/OUT, PULSIN/OUT, FREQOUT, DTMF, BUTTON, ... ok, well just about all of them.
You simply need to change the appropriate macro for the specific command.

If you have PINs scattered all over the place, it's an easy way to address ANY of them in a sequential (or random) manor.
But, if your PINs can fit into 2 ports, the PORTL/H approach shown in the previous posts is preferred.

[skimask]

And since I've been sitting on this answer for 4 days now, ...Not "THAT slow" is still slower than UPS ground.
So here goes...

Brilliant! Absolutely BRILLIANT!
You really should fire that off to MeLabs...
Maybe end up making a SEROUT3/OWOUT2 or something along those lines.

[Darrel Taylor]

Woohoo!

Does that mean I can have a Guinness now?





Watch this one last.

<br>

[Josuetas]

Oh my God this is awesome, i am going to work on it right now!!! will post as soon as i am finished.

And ...

BRILLIANT!.... by the way. jeje

[Darrel Taylor]

I really want to learn this, i m sure you have a great tip behind this request.

Well of course I do.
And it's a scary one. Yet oh so cool.

But to make it work, I still need to know...

16F or 18F ?
<br>