Would this code work like I think it would
HEy all,
Because I dont have the proper hardware to test my program, I cant be sure if its gonna work like how I see it. Here is the block I am interested in:
By default opto_in is low. When ever opto_in goes high, the variable df is incremented by 1. But opto_in may remain high for 1 second or so. Because of the fast execution of the loop, df may be incremented multiple times, when I only want one incrementation per high state. So I've added a second DO LOOP in hopes of stopping this. After opto_in is high, df gets incremented, but the second DO LOOP will halt the program from going further until opto_in is back to its default low state.
Would the the code actually do this?
--thank you
Because I dont have the proper hardware to test my program, I cant be sure if its gonna work like how I see it. Here is the block I am interested in:
up: DEBUG "Going up...",CR PAUSE 600 DO move_UP = 0 IF opto_in = 1 THEN df = df + 1 DO LOOP UNTIL opto_in = 0 LOOP UNTIL (cf = df) move_UP = 1 cf = df GOTO initial
By default opto_in is low. When ever opto_in goes high, the variable df is incremented by 1. But opto_in may remain high for 1 second or so. Because of the fast execution of the loop, df may be incremented multiple times, when I only want one incrementation per high state. So I've added a second DO LOOP in hopes of stopping this. After opto_in is high, df gets incremented, but the second DO LOOP will halt the program from going further until opto_in is back to its default low state.
Would the the code actually do this?
--thank you
Comments
This is part of a code for an elevator project. The "cf" variable is for storing the current floor as this is needed for looping so that the program knows where the position of the elevator.
When I compiled the code, the compiler gave no error about multiple "do" and "loop until". So I'm guessing its alright.
PAR
How/where/when is opto_in set high and/or low?
PAR
initialize the Dbounce variable as a nibble -> Dbounce VAR BYTE
up:
DEBUG "Going up...",CR
PAUSE 600
Dbounce =Dbounce << 1 ' shift bits creates debounce delay
Dbounce = Dbounce |opto_in & %11111100· ' binary mask·must be have least 2 or more zeroes on on the right
IF Dbounce = 1 THEN
··· CF= CF+1
ENDIF
GOTO initial
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
up:
DEBUG "Going up...",CR
PAUSE 600
Dbounce =Dbounce << 1 ' shift bits creates debounce delay
Dbounce = Dbounce |opto_in & %00000011 ' binary mask·must be have least 2 or more·ones on on the right
IF Dbounce = 1 THEN
··· CF= CF+1
ENDIF
GOTO initial
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 11/12/2006 10:14:11 PM GMT
MoveUp is simply a variable name assigned to a pin which is initialized as an output. I noticed that you changed 11111100 to 00000011. Why did you do that? I'm still unsure what the two lines that have the Dbounce variable do. Can you explain?
Back to the original question? Would my original code work?
This line keeps shifting the bits tothe left through each cycle:
···· Dbounce =Dbounce << 1 ' shift bits creates debounce delay
This line assigns·the Opto_in Pin tothe first bit of the Dounce byte and masks off the upper bits:
··· Dbounce = Dbounce |opto_in & %00000011 ' binary mask·must be have least 2 or more·ones on on the right
If the Opto_in pin goes high it will only generate a value of 1 during the first cycle see examples below
first loop:
00000001
second loop:
00000011
Third loop and beyond (due to mask):
00000011
If the bit goes low it will never generate a value of 1
first loop:
00000010
second loop and beyond (due to mask):
00000000
Therefore the "IF Debounce=1 THEN·" can only be true the first loop that the Opto_in goes high.
increasing the zeroes in the mask buffers the code from an electrical stutter (bounce - if it were a·button)
Since the code doesn't stay in a loop the rest of the program can·perhaps have·a "fail safe" routine that can catch the failure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 11/12/2006 10:55:36 PM GMT