Scrolling problems

Vern Roach

' {$STAMP BS2e.bse}
' {$PBASIC 2.5}
MSI_SensymSw·· PIN··· 6
RedButton····· PIN··· 7
BlkButton····· PIN··· 8
SLAPS········· VAR··· Word
Scroll_Choice:
· IF MSI_SensymSw = 1 THEN Scroll_SL_Hg
· IF MSI_SensymSw = 0 THEN Scroll_Choice
Scroll_SL_Hg:····· 'i.e., "SLAPS" (Sea Level Altimeter Pressure Setting)
· IF RedButton AND BlkButton = 0 THEN Scroll_Choice
· IF RedButton OR BlkButton = 1 THEN Continue_0
· 'GOTO Scroll_Choice
Continue_0:
· IF RedButton = 1 THEN Raise_Hg
· IF BlkButton = 1 THEN Lower_Hg
Raise_Hg:
· FOR SLAPS = SLAPS|2992 TO 3092
· DEBUG DEC SLAPS, CR
· DEBUG DEC ? RedButton, CR, CR
· PAUSE 500
· IF RedButton = 0 THEN Scroll_Choice
· NEXT
· GOTO Scroll_Choice
Lower_Hg:
· FOR SLAPS = SLAPS|2992 TO 2892
· DEBUG DEC SLAPS, CR
· DEBUG DEC ? BlkButton, CR, CR
· PAUSE 500
· IF BlkButton = 0 THEN Scroll_Choice
· NEXT
· GOTO Scroll_Choice

Gentlemen, I need some help.

The above·routine is·the part (of a larger program)·that allows·me to select (via scrolling) and input the current "sea level altimeter pressure setting" (from National Weather Service data given for various airports) into a· PBASIC calculation for a BS2e that begins with the output from a barometric pressure sensor being sent to an a to d converter ... ; this·removes·one source of error from the final altitude output, which is displayed on a video monitor using a video overlay module. You'll notice the GOTO Scroll_Choice instruction just under the Scroll_SL_Hg label. With an
" '·" beginning that line to effectively remove that instruction, the debug window scrolls with a constant 2992, saying RedButton = 0, when in fact it shouldn't be able to scroll at all under the RedButton = 0 condition, ie, without the red button being pressed. And·when that particular GOTO Scroll_Choice IS included AND the "SLAPS|" is removed at the two places above so that scrolling always begins with 2992, the debug window scrolls as planned (ie, instantaneously) with the black button, but requires 2 to 3 pushes to begin the process using the red button. An ohmmeter reveals nothing·wrong (intermittent) with the red button switch, suggesting that the problem is in the above code. And finally, when the "SLAPS|"·IS included at the two places above, and scrolling is initiated for example with the red button, it will scroll upwards to 3008 and stop of its own accord! Two or 3 pushes of the red button to get it going again and it has·begun with·3057 (!)·and then stops at 3072, again of its own accord!·What I've described so far can be readily repeated.·Several more pushes to get it going again has on some occasions sent the number over 4000, and·sometimes the scrolling has even reversed and headed downwards with the red button still solidly pressed, or upwards with the black button still solidly pressed!·Both pushbuttons·have·the recommended 10k pulldown resistor installed.

You fellows are sharp, but I have my worries regarding this set of questions!
Many thank yous for your assistance.

Vern Roach / 'O Flyer

metron9

' {$STAMP BS2e.bse}
' {$PBASIC 2.5}
MSI_SensymSw PIN 6
RedButton PIN 7
BlkButton PIN 8
SLAPS VAR Word
Scroll_Choice:
IF MSI_SensymSw = 1 THEN Scroll_SL_Hg
IF MSI_SensymSw = 0 THEN Scroll_Choice

{I would use If Then Else for above logic}


{Add a debounce key input here and assign red and black button variables 1's or 0's so your logic below uses a consistant buffered pin state.}

Scroll_SL_Hg: 'i.e., "SLAPS" (Sea Level Altimeter Pressure Setting)
IF RedButton AND BlkButton = 0 THEN Scroll_Choice
IF RedButton OR BlkButton = 1 THEN Continue_0

{not sure how pbasic works above for bs2e but the normal logic of
if redbutton then do something would imply if redbutton=true so your logic = if redbutton=1 AND blkbutton=0 not if both red and black are 0
Looks like you are getting a debounce problem as sometimes when the red button is pressed the pin is not stable and redbutton reads 0 for a microsecond
thus going back to the scroll_choice and not going to continue.

i would use

if (redbutton+blackbutton)=0 then scrollchoice ' no buttons pressed

let code fall thru if continue lable is next instruction or goto continue as the fact is one of them is a 1 if both added together are not zero.


{with the goto commented out}

' GOTO Scroll_Choice

{code falls through to next instruction}

Continue_0:
IF RedButton = 1 THEN Raise_Hg
IF BlkButton = 1 THEN Lower_Hg

{and then goes right into Raise_Hg: lable if redbutton =0)

Raise_Hg:
FOR SLAPS = SLAPS|2992 TO 3092
DEBUG DEC SLAPS, CR
DEBUG DEC ? RedButton, CR, CR
PAUSE 500
IF RedButton = 0 THEN Scroll_Choice
NEXT
GOTO Scroll_Choice

Post Edited (metron9) : 11/11/2005 6:59:58 PM GMT

Vern Roach

' {$STAMP BS2e}
' {$PBASIC 2.5}

BtnWk VAR Byte
SLAPS VAR Word '(Sea Level Altimeter Pressure Setting)
MSI_SensymSw PIN 6
RedButton PIN 7
BlkButton PIN 8
BtnWk = 0
Scroll_SL_Hg:
IF IN6 = 1 THEN Continue_0
GOTO Scroll_SL_Hg
Continue_0:
BUTTON 7, 1, 255, 255, BtnWk, 1, Raise_Hg
BUTTON 8, 1, 255, 255, BtnWk, 1, Lower_Hg
GOTO Continue_0
Raise_Hg:
FOR SLAPS = 2992 TO 3092 'Fouls up with "SLAPS|2992"
DEBUG DEC SLAPS, CR
PAUSE 150
IF RedButton = 0 THEN Continue_1 '"BUTTON" command here won't work
NEXT
GOTO Continue_1
Lower_Hg:
FOR SLAPS = 2992 TO 2892 'Fouls up with "SLAPS|2992"
DEBUG DEC SLAPS, CR
PAUSE 150
IF BlkButton = 0 THEN Continue_2 '"BUTTON" command here won't work
NEXT
GOTO Continue_2
Continue_1:
DEBUG CR
GOTO Continue_0
Continue_2:
DEBUG CR
GOTO Continue_0

Hi metron9,

I'm sending you the above "BUTTON" version to show that I have tried using this command for its "debounce" features, but as the comments indicate the problem still persisted, and as I've described it. I WOULD LIKE to retain the "SLAPS|" parts to enable speedier scrolling and selection of a particular value, but remove them and the skipping of numbers as described toward the end of my narrative no longer occurs.

In the next few hrs I'll examine more carefully your reply and experiment with your other suggestions. The (redbutton + blackbutton) test seems like a good one.

Vern Roach

metron9

I am going to go home now, we gave everyone the day off as most are Vet's so I am going home to cook a Turkey. But as it roasts, I would be happy to writa a nice routine for you. I only have basic stamp2 so i will use commands that work with it, but I think it would port to any higher stamp.
'
Correct me if I am wrong but you want to do this.

Select a number from 2992 to 3092 using the red button
Default starting number is 2992 the first time red button is pressed (we need to keep the last button press in a buffer here to know this)
When red button pressed scroll through numbers up to maximum of 3092
When button released, the current number displayed has been selected

Select a number from 2992 to 2892 using the black button
Default number is 2992 the first time... (same as above)
scroll backwards to minimum value of 2892 (Note, by the way you need to use STEP -1 in your for next loop to count backwards)
When button released number displayed has been selected.

I expect I will have one loop, no for next loops and an additional feature, when both buttons are pressed it defaults to 2992
that way if you scroll up to say 3005 and you want 3004 you just hit the black button to drop to 3004 and if you are up at 3050 you can jump to 2992 by pressing both buttons.

metron9

Well I guess it was not as simple as I had it made out to be but this should work pretty good.

First the MSI_SensymSw has to go High
then input starte and times out after 5 seconds if no input
Press red to go scroll up, black to scroll down and both to recenter at 2992

Modify for your input siuation, I dont know if you make a request for data and then adjust SLAPS or what but a quick test on my BS2 it seems to work fine.

' {$STAMP BS2}
' {$PBASIC 2.5}


MSI_SensymSw   PIN    15
RedButton      PIN    14
BlkButton      PIN    13

CX VAR Byte
tmp VAR Byte
tmp1 VAR Byte
counter VAR Word

top CON 3092
center CON 2992
bottom CON 2892


slaps VAR Word
keypressed VAR Nib     '0=none, 1= red, 2= black, 3= both red and black
Red VAR Bit
Black VAR Bit

slaps=center


DIRH= %00000000  'Make 15,14 and 13 inputs

GOSUB updatescreen

mainp:

IF MSI_SensymSw = 1 THEN
 PAUSE 150               'if you are using a clock you can check a timer instead of pause
 GOSUB Scroll_SL_Hg
 hold:
 IF MSI_SensymSw =1 THEN hold  'Not sure how your data comes in but for testing I did this
ENDIF

gosub keyin
if keypressed >0 then gosub Scroll_SL_Hg


GOTO mainp
'-----------------------------------------------

keyin:                          '20 mS read time
keypressed=0
 tmp=0
 tmp1=0
 FOR cx = 1 TO 20
  IF redbutton=1 THEN tmp=tmp+1
  IF blkbutton=1 THEN tmp1=tmp1+1
  PAUSE 1
 NEXT
 IF tmp>10 THEN keypressed.BIT0=1
 IF tmp1>10 THEN keypressed.BIT1=1
RETURN
'----------------------------------------------

 Scroll_SL_Hg:
 DEBUG CLS,"Data received Update SLAPS..."
 counter=0
 Scrollloop:
 GOSUB keyin
 if keypressed=0 then counter=0 
 IF keypressed=3 THEN GOSUB scrollcenter
 IF keypressed=1 THEN GOSUB scrollup
 IF keypressed=2 THEN GOSUB scrolldown
 counter=counter+1
 IF counter<250 THEN GOTO scrollloop   'After 5 seconds of no keyboard input mininum go back to main loop
debug cls,  "SLAPS=",slaps,cr,"Waiting for trigger or press Red or Black button to scroll"
 RETURN
'-----------------------------------------------

scrollup:
IF slaps<top THEN
 slaps=slaps+1
ENDIF
GOSUB updatescreen
RETURN

scrolldown:
IF slaps>bottom THEN
 slaps=slaps-1
ENDIF
GOSUB updatescreen
RETURN

updatescreen:
 DEBUG  "SLAPS ",DEC slaps,CR
RETURN

scrollcenter:
  slaps=center
  GOSUB updatescreen
RETURN

I made an edit in the scroll_SL_HG routine
Because the keyin routine takes a miinimum or 20 mS I eliminated the pause 1 and changed the compare value to 250
that way 250 times 20 = 5000 mS before going back to main loop if no data was input
Added another message that it timed out and the current value of SLAPS is displayed
Added logic to stay in input mode if keys are pressed by zeroing the counter when a button has been pressed
Added logic to scroll when red or black key pressed even if no triger from MSI

Post Edited (metron9) : 11/12/2005 1:53:44 PM GMT

Vern Roach

metron9,

It'll be sometime tomorrow (Sat.) before I can "get my mind around" what you've given me and key it in for testing, but all I can say is I'm impressed by what you've come up with. In the last few hours I've come to realize (after reading the Stamp Manual more closely) that the FOR...NEXT command is much more complex
than I had assumed and maybe not all that adaptable to a scrolling loop routine with the "SLAPS|" inclusions. The "twos compliment" phenomenon was probably kicking in every once in a while to produce those skipped numbers that I had described. And the examples in the Manual have nothing like the StartValue to EndValue range that I was trying to work with.

Thank you much for your very generous help. I suspect I'll have more questions in the coming days pertaining to this same project.

Vern Roach / 'O Flyer

Bruce Bates

Vern -

Just as a matter of sheer curiosity, what were you hoping the "SLAPS|" approach would provide? Ordinarily I'd try to decrypt something that looks so odd, but I'm saddled with the flu at the moment, and can hardly think straight on ordinary matters <sigh>.

Regards,

Bruce Bates

Vern Roach

Bruce,

You probably know that means "SLAPS OR 2992". Upon first running thru the program SLAPS hasn't been initialized (given a value), so the Stamp chooses 2992 the first time thru. Subsequently the updated value for SLAPS takes precedent over 2992
when going thru the FOR...NEXT loop. ... The idea is that in scrolling if you overshoot the desired value its quick and easy to go back to that value rather than having to start at 2992.

Vern Roach

daniel

Vern,

You are right, if SLAPS is initialized to zero, then the loop index·will start with the value 2992.

However, since the | is the bit-wise or (see the help file),·on subsequent passes, your loop·index will probably not have the expected initial value.· It will have the numeric value represented by all of the set bits (those equal to binary 1), and will likely be neither 2992 nor the current value of SLAPS.

After reading the Help file about the bit-wise or, let us know if you have additional questions about it.

As expressed, your intent could be captured in code (only one of several ways) link this:

if SLAPS < 2992 then

SLAPS = 2992

ENDIF

I think this is what Bruce is getting at.

Daniel

·

Bruce Bates

Daniel -

Exactly so, and I'm NOT as sick as I thought

Just to expand on your response if I might, the Stamp never "chooses" anything in a bitwise OR operation. As you note so clearly, the bits in the target field are SET using the logic in the following truth table, from the MASK field supplied (0000 1011 1011 0000):

/code
0 | 0 = 0
0 | 1 = 1
1 | 0 = 1
1 | 1 = 1
code/

The fact that the initial value (first time through) will be 2992, is merely a product of the way the Stamp RAM memory is initialized to binary zeros, thus the variables defined within that RAM memory will also be binary zeros, and nothing more. No choice, no selection, no precedence or anything else. If the Stamp variables weren't initialized to zero, then the starting value too would be rather unpredicatable.

Whew! I couldn't believe in nearly 40 years of programming that there was a way of initializing a FOR ... NEXT loop that I'd not seen before. I was CERTAINLY willing to LEARN however. I've always said it's a good day whenever you learn something new!

Regards,

Bruce Bates

metron9

Hmmm, I was wondering what that " | " was doing on end of that variable and I use and,or,xor all the time but programming in Bascom-AVR mostly using "and" or "or" instead of "&" or "|" and I just thought it was a typo in the post as the logic problem was in the code structure itself


this code

IF RedButton = 1 THEN Raise_Hg
IF BlkButton = 1 THEN Lower_Hg
Raise_Hg:


Will fall through to the Raise_Hg: when Redbutton equals 0 and BlkButton equals 0 , what would be the use of the red button if it raises pressed or not pressed.

the code

FOR SLAPS = SLAPS|2992 TO 2892

won't even execute if SLAPS is 2992 in MOST BASICs I have used although it seems to in Pbasic, the default for next logic would increment the variable unless step -number was used so I assumed this logic did not work at all.

And I just learned something as well, It seems after reading the For.Next Pbasic language ref, the optional " - " operator has been removed thus the code

for x=100 to 1 step -1
debug dec x,cr
next

will execute once and print 100 to the screen and removing the step -1 it executes correctly subtracting 1
step 10 instead of step -10 would also work when using a different step value
but this should be changed or at least flagged as an error in Pbasic as it compiles and could be hard bug to track for most old basic programmers
I guess I have always used the step -x when I wanted to decrement a for next loop and never tried ommitting it.

I bet I even have some pbasic BS2 code that uses step-1 that did not work correctly and now I know why!

As usual, seems the more I dig, the dirtier I get...

Post Edited (metron9) : 11/13/2005 5:44:34 AM GMT

Vern Roach

Daniel and Bruce,

In my rush to try to get the requisite information and implement it, I had, among other things, failed to notice the distinction between the bitwise OR and logical OR! For the same reason I also omitted saying I had only about 6 months self-instruction
in PBASIC under my belt when explaining my programming... I know now why pseudonyms are used so frequently within this forum [noparse]:([/noparse]

Both your responses were very helpful.

Vern Roach

Bruce Bates

Vern -

I'm still not going to let you off quite that easily "Learn it once, and own it forever", is what I was taught!

Please look carefully at the tables below, extracted from the PBASIC Help File - they are IDENTICAL.

/code
Bitwise OR

The OR (|) operator returns the bitwise OR of two values.
Each bit of the values is subject to the following logic:

0 | 0 = 0
0 | 1 = 1
1 | 0 = 1
1 | 1 = 1

The bitwise OR (|) is primarily used for setting bits ON in a target variable. If in the language you are using the condition or result code is set, based on the input and mask values, decision making ("selection") is possible, but only as a result of the conditon code being set, and not as a direct function of the OR command itself. No such condition or result code is available in PBASIC.

- - - -

Logical OR

The OR operator (OR) returns the logical OR of two values or expressions. Note that in the BASIC Stamp, a non-zero value is considered True (T), zero is considered False (F). The values/expressions are subject to the following logic

F OR F = F
F OR T = T
T OR F = T
T OR T = T
code/

The logical OR (OR) is a conjunction, the same as it is in the English language. It provides a type of union among and between two or more stated variables such that their respective single values but in combined form, can be evaluated as a whole. Please do not confuse my use of the word "union" above, and the UNION logic function.

In neither case in PBASIC, is direct selection possible. Logical OR (OR) is often considered a primative operator, but in truth, the logical NOR (NOR) operator is actually the primative, since logical OR can be derived from logical NOR. Please also note that NOT all languages recognize that a non-zero value is considered True (T), and zero is considered False (F). Some languages consider that just the opposite is the case! It is this very idiosyncracy of PBASIC that causes the logic table inversion noted above.

This is only intended to be informative and not pedantic. I hope you find it helpful and not confusing.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 11/14/2005 5:45:31 AM GMT

Vern Roach

Hi Bruce,

In the two tables, if the number "1" is considered True and the number "0" considered False, then the tables ARE identical, are they not?

Vern Roach

Bruce Bates

Vern -

Corrected! Scrolling back and forth obviously didn't help my view of the table one bit.

Bruce

Vern Roach

Metron9,

In your "Yesterday 9:41PM" post you open and then quote three lines of my code and say "Will fall through to the Raise_Hg: when RedButton = 0 AND..." My thinking was that only four lines earlier was an instruction as to what to do if both buttons were zero - that if you are a line or two below that it's because at least one button was NOT zero and that a person probably couldn't get his finger off that button in the time it takes for a Stamp to execute another two or three lines of code...

Your scroll code works beautifully, and I'm most grateful to you. I spent two and a half hours or so yesterday adapting it to also go from +99 to -99 (%) in order to set the zero point for a fuel level sensor.

If you feel up to it in the next few days, a few sentences on the reasoning behind your 5000 ms (or thereabouts) timer in your scroll code would be enlightening. At this stage to me it looks like the software equivalent of a black box - one only has the sketchiest idea of how it works.

Take care,
Vern Roach

metron9

Reasoning behind your 5000 ms (or thereabouts) timer in your scroll code

Oh sorry , been a while since I read many posts, I was searching for the one I did about a clock RC timer someone could use. But since you asked.

I assumed your input was from some source that when reeceived you would be alerted and asked to input the SLAPS number. I just used 5 seconds or so as a timeout in the scroll routine so if you did not select a number the main program would continue to run and wait for yet another input. Like an interrupt handeler only much slower, I really don't have a clue what SLAPS is or what you are working with as far as input and output, but the scroll routine is well defined and thus easy to program, Interfaceing the code the way you want it to operate is up to you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think outside the BOX!