GetPin Resets pin state???

[spamiam]

I have a ZX24nu that I got from Mike Perks a few yr ago. I though I had blown some pins when it was not putting the pins high and low the way they should be. I am trying to develop a GPIB bus interface to USB. And I am trying to check the bus state periodically.

I have had trouble with some of the handshaking signals not seeming to work properly. So I wrote some code to read out the signal states when needed.

But when I use GetPin(), it appears to reset the SetPin() settings it once had. Here is the code:

Code: Select all

'Handshaking pins
#Define NDAC	12
'12	'Green
#Define DAV		14
'14	'Red
#Define NRFD	16
'16	'Yellow


Sub Main()

Call PutPin(NDAC,0)
call sleep (1.0)
Call PutPin(NDAC,1)
call Sleep(1.0)

Call PutPin(DAV,zxOutputLow)
Call PutPin(NRFD,zxOutputLow)
Call PutPin(NDAC,zxOutputLow)
Debug.print(Chr(10)+chr(13)+"testing all asserted")
Call GPIBSendState()
call sleep(5.0)

Call PutPin(DAV,zxOutputHigh)
Call PutPin(NRFD,zxOutputHigh)
Call PutPin(NDAC,zxOutputHigh)
Debug.print(Chr(10)+chr(13)+"testing all released")
Call GPIBSendState()
call sleep(5.0)

Call PutPin(DAV,zxInputTristate)
Call PutPin(NRFD,zxInputTristate)
Call PutPin(NDAC,zxInputTristate)
Debug.print(Chr(10)+chr(13)+"testing all cleared")
Call GPIBSendState()

end sub





'**************************************
'
'
'*************************************
sub GPIBSendState()
dim x as byte = 0
dim cnt as byte =0 

for x=1 to 10
if GetPin(DAV)=1 then cnt = cnt+1 
next x
Debug.print(Chr(10)+Chr(13) + "DAV:")
if (cnt = 0) then Debug.print("ASSERTED ")
if (cnt = 10) then  Debug.print("RELEASED ")
if &#40;&#40;cnt > 0&#41; and &#40;cnt < 10&#41;&#41; then Debug.print&#40;"CHANGING "&#41;
cnt = 0

for x=1 to 10
if GetPin&#40;NDAC&#41;=1 then cnt = cnt+1 
next x
Debug.print&#40;"  NDAC&#58;"&#41;
if &#40;cnt = 0&#41; then Debug.print&#40;"ASSERTED "&#41;
if &#40;cnt = 10&#41; then  Debug.print&#40;"RELEASED "&#41;
if &#40;&#40;cnt > 0&#41; and &#40;cnt < 10&#41;&#41; then Debug.print&#40;"CHANGING "&#41;
cnt = 0

for x=1 to 10
if GetPin&#40;NRFD&#41;=1 then cnt = cnt+1 
next x
Debug.print&#40;"  NRFD&#58;"&#41;
if &#40;cnt = 0&#41; then Debug.print&#40;"ASSERTED "&#41;
if &#40;cnt = 10&#41; then  Debug.print&#40;"RELEASED "&#41;
if &#40;&#40;cnt > 0&#41; and &#40;cnt < 10&#41;&#41; then Debug.print&#40;"CHANGING "&#41;
cnt = 0

end sub

If you comment out just the GetPin() statements in the sub GPIBSendState() the LEDs stay lit properly. If I use the code for the GetPin(), then the LEDs stay on for an extremely brief time- they just flash. What's going on? I have compiler 3.4.1 on this computer, so maybe that is the problem? A bug that has since been fixed?

[dkinzer]

But when I use GetPin(), it appears to reset the SetPin() settings it once had.

The GetPin() function is documented to make the pin an input and then read the state. If you'd like to read the pin state without changing the configuration you'll have to refer to the PINx register directly or use Register.Pin(). In both cases, the value returned is all eight bits of the port which will need to be masked to get the value of a single pin (the PortMask() function is useful for this purpose).

Code: Select all

Const pin as Byte = C.0
Dim b as Byte
b = Register.Pin(pin) And PortMask(pin)

The result of this code will be that the variable b will contain a value with at most one bit asserted. Testing for zero/non-zero will provide a Boolean indicating the state of the bit.

[spamiam]

The GetPin() function is documented to make the pin an input and then read the state.

Ah, that makes sense to switch it to input - why would you want to read a pin where you are outputting the state yourself?! Sorry for the stupid question. And I should have re-read the documentation!! Double sorry!

In the actual program, the pin is set to input with pull-up. I will change the code to try that version. And then see how it works.

I suspect that the issue I am having with the real program is on the other end of the handshaking lines. I am expecting a condition that does not seem to be signaled by the other device. But AFAIK, the other device should be signaling in a different manner from what I am seeing. I am probably doing something else wrong....

-Tony