Advice sought - Basic Stamp 2, Inputs not changing
BryanBentz
Posts: 2
I'm new at the Basic Stamp 2, but have a fair amount of electronics experience. I'm at the beginning of a project, and have a switch that has three positions (and three poles to solder wires to). I connect 5 volts to the center pole of a battery, and have measured (with a meter) that the two wires show either 0 or 5 volts based on switch position.
I've run these two wires to P0 and P1 (this is on a "Board of Education", that is Stamp 2 with a protoboard on a small card with a reset button, power (9v battery or connector, and other such convenient items). I have a simple program (part of a larger one, but this is the only part I'm running/testing):
' {$STAMP BS2}
' {$PBASIC 2.5}
DEBUG CR
DEBUG "Beginning Program Execution"
DEBUG CR
'Declare the inputs:
INPUT 0
INPUT 1
' Read the switch state and report:
DEBUG "Pin 0 is: ", DEC IN0
DEBUG CR
DEBUG "Pin 1 is: ", DEC IN1
DEBUG CR
END
This seems to work (once on startup), but then, regardless of how I change the switch, the inputs remain the same. When I change the switch I hit the "Reset" button on the board, and indeed the program restarts, but reports the same inputs. I'm running this from the Parallax development environment (v. 2.5.2), with the board connected to my PC via USB.
If I stop debugging in the development environment, then restart, the program is (again) downloaded to the chip, and at this point a new run seems to find the new inputs. If I clip a meter to the exposed wire at the switch *that* sometimes causes the program to notice new inputs (making me wonder if there is some issue with the input impedance of the pins, or the path to ground.
For my 5V source into the switch I'm using the Vdd connection on the board; similarly for ground I'm using the Vss connection on the board, so I don't think I've got floating grounds or such problems.
I would really like, on reset, the program above to detect the current input state, not keep the old one 'latched'; or, perhaps this is a well-known issue, and there is some way of deeply reinitializing the inputs. It has occurred to me that the board might in some way be defective - I've checked what I can with my meter to make sure connectivity is right, and I've tried different pairs of input pins.
I feel (and I'm hoping) that there is something obvious I'm just not seeing. Any help would be most appreciated. If it's not something like that, is there some known failure mechanism that might explain this?
I've run these two wires to P0 and P1 (this is on a "Board of Education", that is Stamp 2 with a protoboard on a small card with a reset button, power (9v battery or connector, and other such convenient items). I have a simple program (part of a larger one, but this is the only part I'm running/testing):
' {$STAMP BS2}
' {$PBASIC 2.5}
DEBUG CR
DEBUG "Beginning Program Execution"
DEBUG CR
'Declare the inputs:
INPUT 0
INPUT 1
' Read the switch state and report:
DEBUG "Pin 0 is: ", DEC IN0
DEBUG CR
DEBUG "Pin 1 is: ", DEC IN1
DEBUG CR
END
This seems to work (once on startup), but then, regardless of how I change the switch, the inputs remain the same. When I change the switch I hit the "Reset" button on the board, and indeed the program restarts, but reports the same inputs. I'm running this from the Parallax development environment (v. 2.5.2), with the board connected to my PC via USB.
If I stop debugging in the development environment, then restart, the program is (again) downloaded to the chip, and at this point a new run seems to find the new inputs. If I clip a meter to the exposed wire at the switch *that* sometimes causes the program to notice new inputs (making me wonder if there is some issue with the input impedance of the pins, or the path to ground.
For my 5V source into the switch I'm using the Vdd connection on the board; similarly for ground I'm using the Vss connection on the board, so I don't think I've got floating grounds or such problems.
I would really like, on reset, the program above to detect the current input state, not keep the old one 'latched'; or, perhaps this is a well-known issue, and there is some way of deeply reinitializing the inputs. It has occurred to me that the board might in some way be defective - I've checked what I can with my meter to make sure connectivity is right, and I've tried different pairs of input pins.
I feel (and I'm hoping) that there is something obvious I'm just not seeing. Any help would be most appreciated. If it's not something like that, is there some known failure mechanism that might explain this?
Comments
Your program executes one time and then stops (END). If you want to constantly monitor the input pins, you need a LOOP so it reads the input pins over and over.
See the DO..LOOP command in the Basic Stamp Syntax and Reference Manual Ver. 2.2 page175.
Hope that helps.
Jim
The board I'm using (and the one I have as a final target) has power regulation, and I'm using the output of that now - presumably it's reasonably stable. If not, I've got other problems..
Publison, your point is noted; I can now run the full program, which does quite a bit, and lets me see that things are ok.
One final question - if I reset the Stamp, the program begins to run (as I think it should). This *doesn't* seem to happen on initial power-up; or perhaps I just don't see it as I normally do, because my PC may just be seeing the USB connection to the board (I can test this by looking at the circuit outputs - I hope that it does indeed run). If not, is there anything that needs to be done to make sure the transition from 'powering up' to 'now running program' happens smoothly?