| Author |
Message |
victorf
Joined: 01 Jan 2006
Location: Schenectady, New York
|
|
Posted: 22 February 2006, 13:33 PM Post subject: Strange PutPin operation |
|
|
OK, I have fought this long enough and need some help. Consider this subroutine, I call it with a PortNum of 1 expecting that the pin named S0 (Declared as a Public Const S0 as byte = 8 ) will be set low(0) and pin named S1 (Public Const S1 as byte = 9) will be set high (1)
| Code: |
Public Sub SelectMuxPort(byval PortNum as byte)
Debug.Print "Port Number is: ";CStr(PortNum)
Select Case PortNum
Case 0 'for Sensor Board
Call Putpin (S0, zxOutputLow) 'S0
Call Putpin (S1, zxOutputLow) 'S1
Case 1 'for LCD
Debug.Print "Case 1"
Call Putpin (S0, zxOutputLow) 'S0
Call Putpin (S1, zxOutputHigh) 'S1
Debug.Print "S0: "; CStr(GetPin(S0))
Debug.Print "S1: ";CStr(GetPin(S1))
Case 2 'for Printer
Call Putpin (S0, zxOutputHigh) 'S0
Call Putpin (S1, zxOutputLow) 'S1
Case 3 'for Unused
'Call Putpin (S0, zxOutputHigh) 'S0
'Call Putpin (S1, zxOutputHigh) 'S1
Case Else 'default to sensor board
Call Putpin (S0, zxOutputLow) 'S0
Call Putpin (S1, zxOutputLow) 'S1
End Select
End Sub 'SelectMuxPort
|
Here is the output from the Debug.Prints:
Verification complete.
ZBasic v1.1.2
Port Number is: 1
Case 1
S0: 1
S1: 1
If I change Call Putpin (S1, zxOutputHigh) to Call Putpin (S1, zxOutputLow)
the output becomes:
Verification complete.
ZBasic v1.1.2
Port Number is: 1
Case 1
S0: 0
S1: 0
Why is this happening 
I'M STUMPED 
Any enlightenment will be appreciated 
Vic |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 22 February 2006, 15:50 PM Post subject: |
|
|
You cannot use GetPin to read the value just output by PutPin. See the documentation for GetPin (http://www.zbasic.net/doc/ZBasicSysLib/ZBasicSysLib92.html) which describes that the pin is changed to an input pin. That is why in both output examples the inputs do not match the value used in PutPin.
If you really need to know this information then you should directly read the chip data register which in this case is Register.PinC.
BTW You can also name specific pins without needing to declare additional constants and use GetBit() to retrieve a specific bit value. Here is the modified code that meets your requirement: | Code: | Public Sub Main()
Call PutPin (C.4, zxOutputLow)
Call PutPin (C.3, zxOutputHigh)
Debug.Print "S0: "; CStr(GetBit(Register.PINC, 4))
Debug.Print "S1: "; CStr(GetBit(Register.PINC, 3))
End Sub |
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 22 February 2006, 16:55 PM Post subject: |
|
|
| If you prefer not to use Register.PINx, there are some I/O pin routines that may be useful at http://www.zbasic.net/forum/about45.html. In particular, PinState() returns the logic level of a pin given its pin number. |
|
| Back to top |
|
|
victorf
Joined: 01 Jan 2006
Location: Schenectady, New York
|
|
Posted: 22 February 2006, 18:31 PM Post subject: |
|
|
OK. I checked out some of your suggestions and implemented the following changes in my procedure for testing:
| Code: |
Call Putpin (C.4, zxOutputLow) 'S0 Low
Call Putpin (C.3, zxOutputHigh) 'S1 HIGH
Debug.Print "S0: ";CStr(GetBit(Register.PINC, 4))
Debug.Print "S1: ";CStr(GetBit(Register.PINC, 3))
|
With the following results:
.........................
Verification complete.
ZBasic v1.1.2
Port Number is: 1
Case 1
S0: 1
S1: 1
so I reiterate:
Why is this happening
I'M STUMPED
Vic
|
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 22 February 2006, 18:41 PM Post subject: |
|
|
| You need to do some problem isolation Vic. Does the short 6 line program I posted work? If it does then you have some other logic error in your program. If it doesn't then you may have a defective chip. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 22 February 2006, 18:50 PM Post subject: |
|
|
If you're trying to confirm that the output register (PORTx) contains the value that you set using PutPin(), the following code would work:
| Code: | Call Putpin (C.4, zxOutputLow)
Call Putpin (C.3, zxOutputHigh)
Debug.Print "S0: ";CStr(GetBit(Register.PORTC, 4))
Debug.Print "S1: ";CStr(GetBit(Register.PORTC, 3)) |
|
|
| Back to top |
|
|
victorf
Joined: 01 Jan 2006
Location: Schenectady, New York
|
|
Posted: 22 February 2006, 19:55 PM Post subject: |
|
|
I have commented out ALL statements in my test program and substituted the following code as suggested by mikep:
| Code: |
Call PutPin (C.4, zxOutputLow) 'S0
Call PutPin (C.3, zxOutputHigh) 'S1
Debug.Print "S0: "; CStr(GetBit(Register.PINC, 4))
Debug.Print "S1: "; CStr(GetBit(Register.PINC, 3))
|
These are the only statements executed in the program and I got the following results:
.......
Download complete.
Verifying download:
.......
Verification complete.
ZBasic v1.1.2
S0: 1
S1: 1
So it is reasonable to assume that there is something going on here that I have no control over.
These two pins are controlling a 4052 multiplexer and are used to steer data between one of four locations. The locations are numbered:
S0 = 0, S1 = 0 - Location 0
S0 = 0, S1 = 1 - location 1
S0 = 1, S1 = 0 - location 2
S0 = 1, S1 = 1 - location 3
I can verify the location 3 is selected when running the program above instead of location 1.
Enlightenment?
Vic |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 22 February 2006, 22:30 PM Post subject: |
|
|
I would suggest modifying the code snippet to use a different pair of pins. If the output drivers have been damaged for the pins that you have chosen, selecting a different pair will likely perform successfully. Also, I would perform the test with nothing connected to the pins externally. This will eliminate the possibility that external circuitry is interfering with the result.
I tried the test code below, similar to yours, and it produced the result that you expected.
| Code: | Sub Main()
Call Putpin (C.7, zxOutputLow)
Call Putpin (C.6, zxOutputHigh)
Debug.Print "S0: ";CStr(GetBit(Register.PINC, 7))
Debug.Print "S1: ";CStr(GetBit(Register.PINC, 6))
End Sub |
As a side note, the subroutine SelectMuxPort() can be made shorter and faster by eliminating the Select Case and processing the two bits of the channel value as shown in the example below.
| Code: | Public Const S0 as byte = 5
Public Const S1 as byte = 6
Sub Main()
Dim i as Byte
For i = 0 to 3
Call SelectMuxPort(i)
Debug.Print "S0: ";CStr(GetBit(Register.PINC, 7))
Debug.Print "S1: ";CStr(GetBit(Register.PINC, 6))
Next i
End Sub
Public Sub SelectMuxPort(byval PortNum as byte)
Debug.Print "Port Number is: ";CStr(PortNum)
Call Putpin (S0, IIf(CBool(PortNum And &H01), zxOutputHigh, zxOutputLow))
Call Putpin (S1, IIf(CBool(PortNum And &H02), zxOutputHigh, zxOutputLow))
End Sub 'SelectMuxPort |
|
|
| Back to top |
|
|
victorf
Joined: 01 Jan 2006
Location: Schenectady, New York
|
|
Posted: 23 February 2006, 11:52 AM Post subject: |
|
|
Some interesting developments 
I took the advice to try the code with different pin numbers and as you expected, everything worked. Then I disconnected the two pins in question from their connection to the 74HC4052 and tried the code again. Again everything worked. Removed the 4052 (which is on a seperate PCB) reconnected the pins as normal and the problem returned. This isolated the problem to the 4052 board. A careful inspection with a multimeter found the problem. I had a PCB error of the most embarrassing kind.  I had the two lines in question intersecting on the board causing the short. So much for my careful inspection before board fabrication (ExpressPCB). A knife and jumper wire solved this problem.
Back in business. I want to thank both responders for their patience and insights into my problem. I learned a lot. Software is not ALWAYS to blame for problems. Mea culpa!
I must admit I like the code Don supplied to replace my SelectMuxPort(). It is a lot "neater" than mine. Thanks again.
Vic |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 23 February 2006, 14:34 PM Post subject: |
|
|
| victorf wrote: | | Removed the 4052 (which is on a seperate PCB) reconnected the pins as normal and the problem returned. This isolated the problem to the 4052 board. |
Problem isolation, problem isolation, problem isolation.
Seems like it might take more work but actually usually saves time. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 23 February 2006, 16:33 PM Post subject: |
|
|
| Quote: | | ... I like the code Don supplied to replace my SelectMuxPort(). |
Another alternative is shown below. The generated code size for this rendition is slightly smaller still but but it has the disadvantage of using a more obscure technique - manipulating the port bits directly. This makes the code more difficult to understand, more dependent on the underlying hardware and likely more difficult to modify and maintain. Nevertheless, I offer it here to illustrate the technique so that you may employ it when the situation calls for it.
| Code: | Public Sub SelectMuxPort(byval PortNum as byte)
' Prepare constants for the bit mask and shift count
' necessary to manipulate the port bits directly.
Const bitMask as Byte = &Hc0
Const shiftCnt as Byte = 6
' set the Port register bits
Call SetBits(Register.PortC, bitMask, Shl(PortNum, shiftCnt))
' force the pins to be outputs
Call SetBits(Register.DDRC, bitMask, bitMask)
End Sub 'SelectMuxPort |
Note, also, that this method is limited to situations where the multiplexor select bits are assigned to adjacent bit positions on one port and that they must have the same relative significance order as the port bits themselves. |
|
| Back to top |
|
|
|
