I/O Definition Question

[Tim-M]

I have a Prop-1 programming mystery that I'm sure is an oversight on my part, but I can't see the forrest for the trees.  Here is the testing or draft programming in question...


'   {$STAMP BS1}                           ' In the form of an EFX-TEK Prop-1.
'   {$PBASIC 1.0}

' -----[ I/O Definitions ]-------------------------------------------------

' Pins used for this project are 0, 1, 5, 6, and 7 for a total of five I/O
' used.

'OUTPUTS:

SYMBOL  HandBtns = PIN0            ' Output for URBAN Hand Buttons DPDT relay
                                                     ' control.
SYMBOL  CableSw  = PIN1            ' Output for URBAN Cable Foot Switch relay
                                                     ' control.

' -----------------------------------

'INPUTS: The corresponding ULN output driver IC pins 1-3 and 16-18 have
' been removed to prevent input interference.

SYMBOL SelectorSw = 5               ' Input for automatic mode selector switch.
                                                    ' Read with the POT command and selector switch
                                                    ' circuit.
SYMBOL ResetSwitches = PIN6    ' Input for N.C. contact loop through the
                                                    ' URBAN E-Stop and Head-Reset buttons.
                                                    ' SETUP = ON-BOARD PULL-UP, Active = low.
SYMBOL StartStop = PIN7            ' Input for automatic control start/stop
                                                    ' foot pedal.
                                                    ' SETUP = ON-BOARD PULL-UP, Active = low.

' -----[ Constants ]-------------------------------------------------------

SYMBOL Closed    = 0                  ' For reset-loop input. See setup note above.
SYMBOL Open      = 1                  ' Also for reset-loop input.

SYMBOL Off         = 0                   ' For active-low outputs.
SYMBOL On         = 1

' -----[ Variables ]-------------------------------------------------------

SYMBOL SelectorValue  = B2      ' Selector switch value that is read with POT
                                                  ' command.

SYMBOL TimingLoop   = W2       ' Program use... For/Next loops.
SYMBOL TimingLength = W3      ' Program use... For/Next loops.

' -----[ Initialization ]--------------------------------------------------

'FOR DIRS, READ FROM RIGHT TO LEFT -- PIN 0 IS FAR RIGHT!!
' 0 = Input
' 1 = Output
' Unused pins are set as outputs.

Initialize:
  DIRS = %00011111                  ' Set I/O pin directions.
  PINS = %00000000                  ' Set all pins Low.


' -----[ Program Code ]----------------------------------------------------

StartCheck:
  IF StartStop = Closed AND ResetSwitches = Closed THEN Start
GOTO StartCheck

Start:
  POT SelectorSw, 255, SelectorValue
DEBUG SelectorValue

All this code does is read the selector switch on pin 5 with the POT command, when the two conditions are true in StartCheck.

The mystery is this:
As pin 5 is defined above, SYMBOL SelectorSw = 5, the program works well  and Debug shows a value for the selector switch as expected.  That value changes with the switch position also as expected.  All is good.

However, if I define pin 5 with SYMBOL SelectorSw = PIN5, then the value Debug shows is always zero, no matter what the switch position.  A syntax check comes back as good for either definition of pin 5.

I'm stumpted, can anyone shed some light here?

[livinlowe]

I know that with the serin or serout command you have to use just a number, perhaps its the same with the pot command? I can't check it right as I'm away from a computer with the PBasic editor.


Upon looking at the program that Jon gave you in the Prop-1 discussion forum, this appears to be the case.

[Tim-M]

Yep, that's my guess too.

It may have made more sense to post this in the Prop-1 forum, closer to the other discussion about the selector switch/POT command, but since it is programming I put it here.

I didn't find anything about this issue in the documentation and I think we all would like to understand what's going on.

Thanks for the help.

[JonnyMac]

Comments:

1) If your button inputs are active-high (if you can decide, then you should use active-high) then there is no need to modify the ULN for those channels; in fact, the ULN acts like a weak pull-down and this is helpful for active-high inputs.  The ULN will not affect outputs.

2) Put the potentiometer on P7 so that you can swap out the ULN2803 for a ULN2003 -- makes things easy.

3) ON is a PBASIC2 keyword and should not be used as a constant name; even though this won't affect the Prop-1 it's a bad habit to develop as you will likely migrate some programs to the Prop-2 where this becomes an issue.  Use IsOn as the constant name to prevent future conflicts.

4) The real mystery.... PIN5 is actually a bit sized variable; you can write to it (0 or 1) or read from it (you get 0 or 1).  You cannot use PIN5 in the POT command.  Your code, in essence, is doing this:

  POT PIN5, 100, rawValue

The first thing the controller does is look at the value on PIN5; if it's a low then it tries to run a POT command on P0; if it's high it tries to run the POT command on P1.  This is one of the trickier aspects of using the language and I'm trying to find a good way to explain and demonstrate it in my book.

[Tim-M]

Thanks for the help and feedback everyone.

1) Due to electrical noise in the environment, I thought input pull-ups and providing ground for a low-trigger via the switches would be the best choice.  The comments where the inputs are defined are correct, but I see now that I didn't go back to revise the notes in the constants area as I had intended.  Thanks for catching this, I'll get that revised.

2) That's a good idea.  I didn't have any ULN2003's at the time, so I clipped pins on the ULN2803 and forged ahead.

3) Thanks for this tip.  You're right that even though it won't affect Prop-1 projects, it would be best to avoid things like this for future Prop-2/BS2 work.

4) Thank you for explaining this.  With a little more understanding it makes alot more sense.

I appreciate your help and advice again Jon, we all learn more each time!