Has Spin2 removed array style access to I/O pins?

Larry Martin

From Spin1 I am used to accessing individual pins on INA with square brackets. For example, INA[2] would evaluate as $0000_0000/FALSE or $0000_0004/TRUE depending on the pin state.

Porting my old code to P2, it looks like that no longer works. INA[2] evaluates to some hex value with all 4 bytes populated, regardless of the state of the P02 input. This happens in both Spin2 Tool and Pnut. Is it intentional? Should I change all my INA[x] to (INA & (1 << x)) (same for OUTA)?

I don't see anything about this in the "Spin2 Language Documentation" PDF, but admittedly have not read every word. JohnnyMac's helpful post "From Spin1 to Spin2" does not seem to cover this point.

Code:

  pLLIOHostDtr                 = 2

PUB LLIOSerialPassthrough() : RESULT
  RESULT := NOT ina[pLLIOHostDtr]

PUB HPS_IOReply()
  fourrdrs.tx(k4RdrHost, "O")
  fourrdrs.hex(k4RdrHost, ina, 8)
  fourrdrs.tx(k4RdrHost, ":")
  fourrdrs.tx(k4RdrHost, "D")
  fourrdrs.hex(k4RdrHost, dira, 8)
  fourrdrs.tx(k4RdrHost, ":")
  fourrdrs.hex(k4RdrHost, ina & $04, 2)
  fourrdrs.tx(k4RdrHost, ",")
  fourrdrs.hex(k4RdrHost, ina[2], 8)
  fourrdrs.tx(k4RdrHost, ",")
  fourrdrs.dec(k4RdrHost, pLLIOHostDtr)
  fourrdrs.tx(k4RdrHost, ",")
  fourrdrs.hex(k4RdrHost, ina[pLLIOHostDtr], 8)
  fourrdrs.tx(k4RdrHost, ":")
  fourrdrs.tx(k4RdrHost, "P")
  fourrdrs.hex(k4RdrHost, LLIOSerialPassthrough(), 2)
  fourrdrs.str(k4RdrHost, @_crlf)

Output with DTR SET:
O0FFFF0E8:DC0000003:00,F603AC10,2,F603AC10:P00
Output with DTR CLEAR:
O0FFFF0EC:DC0000003:04,F603AC10,2,F603AC10:P00

The bold text shows that the P2 correctly reads the input and that ina & $04 correctly derives its value. The $F603AC10 is the value incorrectly read by INA[2], which makes the old code fail.

Did you mean it to be this way, or is it a bug in these early versions of the tools: Propeller Tool 2.4.1 and pnut v35s?

Wuerfel_21

Bit access in Spin2 would be ina.[2] (and can be done with any variable).

But you really should use the pin functions, for they work across the INA/INB divide.

(Also, Proptool is at version 2.7.0 now)

Larry Martin

@Wuerfel_21 said:
Bit access in Spin2 would be ina.[2] (and can be done with any variable).

But you really should use the pin functions, for they work across the INA/INB divide.

(Also, Proptool is at version 2.7.0 now)

Thanks again, @Wuerful_21. Since you said "pin functions," I now see PINW through RQPIN in the Spin2 reference.

JonnyMac

I don't see anything about this in the "Spin2 Language Documentation" PDF,

As Ada pointed out, there are specific pin functions now. Look up:

• pinfloat
• pinread
• pinwrite
• pinhigh
• pinlow
• pintoggle

There is a difference dealing with a group of pins. instead of using the x..y syntax, you would use

base addpins count-1

For example, if you want to read a nibble from pin4..pin7 on the P2, you would use:

  x := pinread(4 addpins 3)

Larry Martin

@JonnyMac said:

I don't see anything about this in the "Spin2 Language Documentation" PDF,

As Ada pointed out, there are specific pin functions now. Look up:

• pinfloat
• pinread
• pinwrite
• pinhigh
• pinlow
• pintoggle
  
  There is a difference dealing with a group of pins. instead of using the x..y syntax, you would use

base addpins count-1

For example, if you want to read a nibble from pin4..pin7 on the P2, you would use:

  x := pinread(4 addpins 3)

This chip has a world of new functionality that I hope to explore in time. As someone getting started, though, a note somewhere that you have to change all INA[x] to INA.[x] in order to get the old functionality would have saved me a few hours. The old syntax INA[x] still compiles, so you can't rely on the compiler to flag it for you. I guess it returns the LONG that starts X*4 bytes from INA.