Same code in different Pins

[Darrel Taylor]

Assuming you have them on PORTB as shown. Just use Pin Numbers.

PIN  VAR BYTE

for PIN = 0 to 7
    owout PIN, 1, ["data here"]
next PIN

Numbers 0-7 are usually PORTB.0 thru PORTB.7, 8-15 can be PORTC, but it depends on the chip you are using.

[skimask]

Assuming you have them on PORTB as shown. Just use Pin Numbers.

PIN  VAR BYTE

for PIN = 0 to 7
    owout PIN, 1, ["data here"]
next PIN

Numbers 0-7 are usually PORTB.0 thru PORTB.7, 8-15 can be PORTC, but it depends on the chip you are using.

I've got no idea how this came to me...magic I suppose...
How about a variable that's 'locked' into a certain memory location (porta in this case), and it's set up as an array.
Since the ports are usually in sequential order in the memory map, it seems to me like a person should be able to access those bits as bits of a variable, like you would any other ram variable.
i.e.
PIN var byte[4] $F80 system '5 bytes to handle porta, portb, portc, portd, porte, in the case of a PIC18F4620

then you'd access the pins by pin.0[index]...

Wouldn't that work?

[Darrel Taylor]

Nope, won't work Skimask.

For instance, with this statement...

owout pin.0[index], 1, ["data here"]

PBP will do an Array Out from the indexed pin, then use that result as the "PIN number" which will be either a 0 or 1. So it will always use either PORTB.0 if the pin is low, or PORTB.1 if the Pin is high.
<br>

[skimask]

Nope, won't work.

For instance, with this statement...

owout pin.0[index], 1, ["data here"]

PBP will do an Array Out from the indexed pin, then use that result as the "PIN number" which will be either a 0 or 1. So it will always use either PORTB.0 if the pin is low, or PORTB.1 if the Pin is high.
<br>

---deleted---I don't follow you at the moment...

I got what you saying... pin.0[index] is actually a bit variable...0 or 1 correspoonding to port B
but if you say it's not going to work...then chances are good that it's not going to work...

[Darrel Taylor]

... pin.0[index] is actually a bit variable...0 or 1 correspoonding to port B

This is another one of those examples where arrays act differently depending on whether a Constant or a Variable is used as the index.

Using the same statement...

owout pin.0[index], 1, ["data here"]

If index is a Constant, it does what you thought, and will use the index to select the Pin as an offset from PORTA.0. So 8 would be PORTB.0. But then, you can't change it at run-time.

IF index is a variable, then it makes it an Array operation that will read the value of the indexed Pin (0 or 1), that value then becomes the "PIN Number".

When a statement works 2 different ways like that it's hard to grasp sometimes.
Not sure why meLabs did things that way.
<br>

[skimask]

This is another one of those examples where arrays act differently depending on whether a Constant or a Variable is used as the index.
Using the same statement...
owout pin.0[index], 1, ["data here"]
If index is a Constant, it does what you thought, and will use the index to select the Pin as an offset from PORTA.0. So 8 would be PORTB.0. But then, you can't change it at run-time.
IF index is a variable, then it makes it an Array operation that will read the value of the indexed Pin (0 or 1), that value then becomes the "PIN Number".
When a statement works 2 different ways like that it's hard to grasp sometimes.
Not sure why meLabs did things that way.
<br>

Might be the difference between a $250 compiler and a $2,500 compiler.
But I got what you were getting at.

I think the original post'ers only option is to do the SELECT CASE thing, combine all OWOUT's into one place, use a generic "data here" string type array variable and go with it.

[Darrel Taylor]

I think the original post'ers only option is to do the SELECT CASE thing,

Well, I think Josuetas' best option can be found in Post #4
<br>