PINA instead of INA

Alexander (Sandy) Hapgood · 2013-10-09 15:49

Wouldn't it make sense to rename INA and INB to PINA and PINB?

TEST MASK, INA doesn't seem intuitive to me when I'm monitoring the output state of a pin from another cog. Wouldn't TEST MASK, PINA be clearer?

Sandy

Beau Schwabe · 2013-10-09 16:02

You also have OUTA and OUTB to contend with as well as DIRA and DIRB.

It's assumed that an INput or an OUTput or DIRection are associated to an I/O pin so PINA, POUTA, or PDIRA are not used and may not convey the same meaning as you might think to others.

Heater. · 2013-10-09 16:03

INA sounds fine to me. If a cog is monitoring the output state of a pin from another cog then that must be an input to the cog doing the monitoring.

Alexander (Sandy) Hapgood · 2013-10-09 16:23

I was thinking more along the lines of OUTA, DIRA and PINA.

Phil Pilgrim (PhiPi) · 2013-10-09 19:39

PINA is just INA with a P added, so I don't see what the advantage would be. Besides, INA and OUTA have the desired complementary ring to them. Moreover, in the Prop2 there will be a PINA that refers to both INA and OUTA, depending upon how it's used. (But I hope Chip reserves the option to use INA and OUTA to disambiguate them for the more casual of code readers.)

-Phil

cgracey · 2013-10-09 19:47

I have been thinking about this, too. INA and INB are fine, but when you get to INC and IND it sounds like INCrement and INDirect. The closest we could stay to OUTx and DIRx without using INx would be INPx. INPA/INPB/INPC/INPD aren't that great, either.

cgracey · 2013-10-09 19:51

How about SIGA/SIGB/SIGC/SIGD?

Phil Pilgrim (PhiPi) · 2013-10-09 19:52

How about AIN ... DIN, AOUT ... DOUT, and ADIR ... DDIR?

-Phil

Oh, wait, is BIN reserved?

Roy Eltham · 2013-10-09 20:07

IN_x, OUT_x, DIR_x

Roy Eltham · 2013-10-09 20:12

or maybe

IN0, IN1, IN2, IN3
OUT0, OUT1, OUT2, OUT3
DIR0, DIR1, DIR2, DIR3

Phil Pilgrim (PhiPi) · 2013-10-09 20:15

Roy Eltham wrote:

or maybe

IN0, IN1, IN2, IN3
OUT0, OUT1, OUT2, OUT3
DIR0, DIR1, DIR2, DIR3

But then we'd have Spin expressions like OUT0[1] and OUT1[0]. 'Dunno: is there potential there for confusion?

-Phil

cgracey · 2013-10-09 20:19

Roy Eltham wrote: »

or maybe

IN0, IN1, IN2, IN3
OUT0, OUT1, OUT2, OUT3
DIR0, DIR1, DIR2, DIR3

That actually looks pretty nice.

Alexander (Sandy) Hapgood · 2013-10-09 20:19

How about

OUTA, OUTB, OUTC, OUTD
DIRA, DIRB, DIRC, DIRD
PINA, PINB, PINC, PIND

INx holds the current value of the pin regardless of whether it's an input or an output so why not call it what it is.

Pin 0 will always be the first thing that comes to my mind if you go with IN0, OUT0 and DIR0.

I'm just learning PASM so I need things to be as simple and intuitive as possible haha.

Sandy

cgracey · 2013-10-09 20:27

Alexander (Sandy) Hapgood wrote: »
How about
OUTA, OUTB, OUTC, OUTD
DIRA, DIRB, DIRC, DIRD
PINA, PINB, PINC, PIND

That looks best, I think. Any dissenters?

Phil Pilgrim (PhiPi) · 2013-10-09 20:32

cgracey wrote:

That looks best, I think. Any dissenters?

I guess that works as long as PINA, etc., refer to inputs only and not to the composite usage planned originally. IOW, mov pina, #1 should be flagged as an error, even though it actually refers to outa.

-Phil

cgracey · 2013-10-09 20:33

Phil Pilgrim (PhiPi) wrote: »

I guess that works as long as PINA, etc., refer to inputs only and not to the composite usage planned originally.

-Phil

It's in OUR minds here, but probably in nobody else's.

Phil Pilgrim (PhiPi) · 2013-10-09 20:38

You're too quick for me, Chip!

Does my addendum jibe with your thinking?

-Phil

Alexander (Sandy) Hapgood · 2013-10-09 21:08

What brought this on was the fact that OUTx and DIRx are local to the cog while INx is common to all cogs. The only practical way to determine the current state of a pin from any cog is to query INx.

For the P8X32A, INx registers are read-only so Phil's concerns should be adequately addressed if the P2 'PINx' registers are read-only as well.

Sandy

Phil Pilgrim (PhiPi) · 2013-10-09 21:25

Alexander (Sandy) Hapgood wrote:

Phil's concerns should be adequately addressed if the P2 'PINx' registers are read-only as well.

As I understand it, in the P2, INx and OUTx share the same address. Which physical register is accessed depends upon context, IOW (oversimplified) are you reading from it or writing to it? Initially, PINx was to be used to refer to both INx and OUTx. But that can potentially lead to confusion amongst casual PASM readers. Chip can correct me if I'm wrong, but he seems now to prefer a syntactical disambiguation in addition to the semantic disambiguation that was already in place. The advantage of the former is that it requires one to state explicitly what they mean and flags an error if the stated operation is inconsistent with the P2's capabilities. If that's the case, I'm all for it.

-Phil

Roy Eltham · 2013-10-09 22:02

Phil,
Recent changes has split IN and OUT to their own addresses on the P2. So there are 14 special registers now. The two index registers, 4x IN, 4x OUT, and 4X DIR.

Roy

potatohead · 2013-10-09 22:05

No dissent here.

Phil Pilgrim (PhiPi) · 2013-10-09 22:07

Roy,

Ah so. The original advantage of combining them was that it permitted them to be directly addressable without resorting to special instructions, given the limted address space for SFRs. Has this advantage now been negated?

-Phil

Ariba · 2013-10-10 10:05

Phil Pilgrim (PhiPi) wrote: »

Roy,

Ah so. The original advantage of combining them was that it permitted them to be directly addressable without resorting to special instructions, given the limted address space for SFRs. Has this advantage now been negated?

-Phil

Yes, because it turned out to be no advantage. It makes not much sense to spare the hardware OUTx registers and then you need to define your own software OUTx registers to keep track of the current output states. And this is necessary for pin access with tasks, or for Spin, or for C...

Andy

Phil Pilgrim (PhiPi) · 2013-10-10 11:55

Andy,

Early on, I analyzed nearly a thousand PASM programs for OUTx usage. In only two or three cases did I find OUTx used in the source field of an instruction, and those could easily have been modified to eliminate that usage. For that reason, it seemed reasonable to combine OUTx and INx to share addresses, since the context of their usage completely determined which physical register was being addressed. The direct advantage for the P2 was that they could then all fit in the 16-register SFR block and be accessed by normal instructions (e.g. and outa,mask). I guess it's not clear to me what changed.

-Phil

David Betz · 2013-10-10 12:20

Phil Pilgrim (PhiPi) wrote: »

Andy,

Early on, I analyzed nearly a thousand PASM programs for OUTx usage. In only two or three cases did I find OUTx used in the source field of an instruction, and those could easily have been modified to eliminate that usage. For that reason, it seemed reasonable to combine OUTx and INx to share addresses, since the context of their usage completely determined which physical register was being addressed. The direct advantage for the P2 was that they could then all fit in the 16-register SFR block and be accessed by normal instructions (e.g. and outa,mask). I guess it's not clear to me what changed.

-Phil

The problem is with high level code like this:

OUTA |= 0x100;

If the compiler isn't smart enough to turn that into a single OR instruction you get something like this:

mov t1, outa
or t1, #$100
mov outa, t1

Ariba · 2013-10-10 12:25

Yes for single task PASM (that's what we have on Prop1) it may not be necessary.
But it's different for high level languages. Also in Spin1 if you do someting like: !OUTA[5] or OUTA[9..6] := %1011, the Spin interpreter reads the OUTx register and calculates the new bit states with shifting and masking. How will you do that without knowng the OUTA bit states. With the combined PINx registers there was no way to read the output-latches, so you need to hold a copy in a register and update the PINx and the pseudeo OUTx which complicates that instructions.

Andy

Edit: Okay David was faster..

Bill Henning · 2013-10-10 12:30

I am not sure that solves the problem for the compiler, unless reading OUTA actually reads the current pin states instead of what the cog is trying to output - in which case IN/OUT may as well be combined.

What if DIRA is not set up so that the bit you are trying to OR is not set as an output?

mov  t1,pinsa
or    t1,#$100
mov  pinsa,t1

would seem to do what you want, assuming dira is set up to output on $100

With a separate OUTA, you would likely read the "shadow register", or $100, and write out $100 to the pins - clobbering any other outputs active in the cog.

IMHO, the best solution is have the compiler generate

OR pinsa,#$100

(which still would not work if DIRA is not set up correctly)

Bill Henning · 2013-10-10 12:33

The question is:

- should we do the operation based on what the cog was trying to output

- or based on the current state of the pins, which may have been modified due to ORing other cogs outputs, or an external signal

Ariba wrote: »

Yes for single task PASM (that's what we have on Prop1) it may not be necessary.
But it's different for high level languages. Also in Spin1 if you do someting like: !OUTA[5] or OUTA[9..6] := %1011, the Spin interpreter reads the OUTx register and calculates the new bit states with shifting and masking. How will you do that without knowng the OUTA bit states. With the combined PINx registers there was no way to read the output-latches, so you need to hold a copy in a register and update the PINx and the pseudeo OUTx which complicates that instructions.

Andy

Edit: Okay David was faster..

David Betz · 2013-10-10 12:39

Bill Henning wrote: »
I am not sure that solves the problem for the compiler, unless reading OUTA actually reads the current pin states instead of what the cog is trying to output - in which case IN/OUT may as well be combined.

What if DIRA is not set up so that the bit you are trying to OR is not set as an output?
mov  t1,pinsa
or    t1,#$100
mov  pinsa,t1
would seem to do what you want, assuming dira is set up to output on $100

With a separate OUTA, you would likely read the "shadow register", or $100, and write out $100 to the pins - clobbering any other outputs active in the cog.

IMHO, the best solution is have the compiler generate

OR pinsa,#$100

(which still would not work if DIRA is not set up correctly)

I think usually you're usually just trying to update pins you already have setup as outputs using DIRx. The other pins are "don't care" and will probably be set to zero anyway so the code I posted will work.

Phil Pilgrim (PhiPi) · 2013-10-10 12:49

Ariba wrote:

With the combined PINx registers there was no way to read the output-latches, ...

'Could have been accomplished in the few cases that needed it with getoutx instructions.

-Phil

Ariba · 2013-10-10 12:53

Bill Henning wrote: »

The question is:

- should we do the operation based on what the cog was trying to output

- or based on the current state of the pins, which may have been modified due to ORing other cogs outputs, or an external signal

Definitly the first option.
With all the modes we can choose on the Prop2 pins (drive strength, open drain..) there are many possibilties that you read not the same state at the input as you have in the output latch.
Say task1 uses bit 5 of OUTA and task2 want to change bit 0..3 of OUTA. Task1 sets OUTA[5] to high, but the pin is an open drain and driven low by an external device. Now when Task2 does an AND OUTA,#%1111 for example the OUTA[5] gets cleared, so task2 messes with the bits of task1.

Andy

PINA instead of INA

Comments