Strange increment problem
Harley
Posts: 997
I'm trying to increment a variable, but it doesn't increment beyond 80h.
I'm using the variable "Lptest++". It increments well from 00h to 7Fh then goes to 80h and 'freezes' there.
Makes no difference whether I assign the variable to byte, word or long!!!
I figured it was a signed vs. unsigned when it was a byte. But word or long should allow the value to get up to FFh, no?
Have been tearing my hair out trying various ways to increment the variable.
Without presenting the code, what could limit a variable below 128 decimal?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I'm using the variable "Lptest++". It increments well from 00h to 7Fh then goes to 80h and 'freezes' there.
Makes no difference whether I assign the variable to byte, word or long!!!
I figured it was a signed vs. unsigned when it was a byte. But word or long should allow the value to get up to FFh, no?
Have been tearing my hair out trying various ways to increment the variable.
Without presenting the code, what could limit a variable below 128 decimal?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Comments
I think it increments as expected, but your further processing masks it down...
But there are many other possibilities...
I'm using TV_text to display many Spin variables and this variable displays OK between 00h and 80h then stops at 80h.
Also, the value is output serially to another board and is properly displayed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
VAR long status, stack[noparse][[/noparse]100], key long rxpin, txpin, c, rxbyte, rxcheck, txbyte,frame[noparse][[/noparse]406],CmdStatus, LEDreg long addrReg, dataReg, statReg, keyReg, regReg, dirReg, AdDaStReg, id, BP2, LpTimer ' long triggermask, triggerstate, Prop2Reg, LOPENreg, SBPtReg, IOENAreg, PMENAreg long tempStat, tempLow, tempHigh, tempDat, Lptest word DTstatReg, DTadHiReg, DTadLoReg, DTdatReg, DTmask, DisplayReg, DTbusFlg, cogState ' word Lptest ' byte key OBJ PICSer : "FullDuplexSerial" ' D/K comm PropSer : "FullDuplexSerial" ' Prop2 comm Display : "TV_text" ' debug w/monitor Fsynth : "Synth" ' for 5 MHz 'clock' for Prop#2 vp : "ViewportConduit_12" ' transfers data to/from PC qs1 : "QuickSample_12" ' measures INA and variables, 1 cog '************************************************************************************* '* Prop#1 Control section handles: D/K interface, Control command decoder, Prop#2 i/f '* and 5 MHz synth clock, p/o Pod i/f... '************************************************************************************* PUB Main PICSer.start(PIC_Rx, PIC_Tx, %0000, PIC_Baud) ' s/b Cog 0 PropSer.start(Prop_Rx, Prop_Tx, %0000, Prop_Baud) ' Cog 1 cognew(Control1,@stack) ' Cog 2 repeat until status == StatusIdle PRI Control1 '| i,r,k,keyok Fsynth.synth("A", 24, 5_000_000) ' output 5MHz for Prop2; Cog 3 status := StatusInit ' set system status to Initialize Display.start(12) ' Cog 4 Display.setcolors(@tv_palette) color(blue) ' color for Prop1 register heading gotoxy(6,0) Display.str(@titleP1) ' waitcnt(80000000 + cnt) 'wait 1 sec for Prop#2 gotoxy(17,0) ' 11 positions + offset of 6 = 17 display.dec(CHIPVER) ' now read Prop#2 version and source file date color(red) ' color for Prop2 register heading gotoxy(6,7) repeat ' query Prop2's attention PropSer.tx($80) waitcnt(800000 + cnt) 'wait 2 seconds for Prop#2 ' waitcnt(clkfreq << 1 + cnt) 'wait 2 seconds if (c := PropSer.rxcheck) <> -1 until c == $80 GetProp2info ' Display.str(string("Got Prop#2 $80")) ' PropSer.tx($82) gotoxy(11,7) color(white) dirReg := 1 DisplayRegs RegistersUpdate DTbusRdInit ' start cog for DTbus read/writes; Cog 5 vp.start(31,30,@rxpin,String("Control_2Prop1:50 ns/div:LSA:rxpin+,txpin+,c+,rxbyte+,rxcheck+,txbyte+,frame*+@0.7.0")) ' s/b Cog 6 gotoxy(0,6) Display.str(string("starting DT cog# ")) Display.dec(id) LpTest := $70 ' DIRA[noparse][[/noparse]8]~~ ' temp. 'pulser' (neg. ~8 microsec every ~80 microsec) ' Main Loop *********** deals with inputs from D/K, Prop#2 or Pod *********** repeat if (c := PICSer.rxcheck) <> -1 ' process a byte from D/K key := c KeyDecode RegistersUpdate UpdateDK_LED if (c := PropSer.rxcheck) <> -1 ' process byte from the 2nd Propeller if (c & $F0) == $90 ' THIS IS FOR TEST PURPOSES ONLY DURING 'DEBUG' PHASE case c $90 : gotoxy(0,10) Display.str(string("$90cnt.")) if (c := PropSer.rxcheck) <> -1 Display.hex(c,2) if (c & $F0) == $80 AddrBus PropSer.tx($82) ' send a 82h code to read Prop2 I/Os qs1.sampleINA(@frame) ' used with ViewPort rxpin++ txpin+=2 ' OUTA[noparse][[/noparse]8]~ ' pulse Lo for ~ 8 microsec ' OUTA[noparse][[/noparse]8]~~ ' return to Hi level for ~ 80 microsec period gotoxy(0,4) Display.str(string("cogState.")) Display.hex(cogState,1) gotoxy(11,4) Display.str(string("DTbusFlg.")) Display.hex(DTbusFlg,1) ' need a 'timer' to do a 'Control <-> D/K <-> Control' Looptest; maybe every 1 - 5 min if LpTimer == 0 ' test if zero LpTimer := $80 ' 125000 ' reload for 1 sec between Looptests ??? PICSer.tx(Lptest) gotoxy(3,11) Display.str(string("Lptest.")) Display.hex(Lptest,2) ' might need some 'delay' here waitcnt(80000000 + cnt) 'wait 1 sec for Prop#2 gotoxy(20,12) if (c := PropSer.rxcheck) <> -1 if c == Lptest Display.str(string("Pass ")) Display.hex(Lptest,2) Display.str(string(" ")) else Display.str(string(" ")) Display.hex(Lptest,2) Display.str(string(" FAIL")) Lptest++ ' if Lptest > $F0 ' Lptest := $80 LpTimer-- gotoxy(20,11) Display.str(string(" LpTmr.")) Display.hex(LpTimer,8) ' waitcnt(clkfreq << 1 + cnt) 'wait 2 secondsReiterating, 'Lptest' will not increment above 80 hex.· WHY??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I think you've got an else that needs one more tab in front of it:
if (c := PropSer.rxcheck) <> -1 if c == Lptest Display.str(string("Pass ")) Display.hex(Lptest,2) Display.str(string(" ")) else <-------------------------------------[b]this one[/b] Display.str(string(" ")) Display.hex(Lptest,2) Display.str(string(" FAIL"))-Phil
The Prop manual under IF, pgs 4-70, 71, shows ELSE and ELSEIF at same tabbed positions as the IF.
But that does NOT affect the displayed values for 'Lptest' several lines above that ELSE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
... is a part of ViewPort, judging from the following line of code:
qs1.sampleINA(@frame) ' used with ViewPortThe 'frame' variable is declared as an array in the first of the following two lines:
I've never used ViewPort myself, and so I don't know if the 'frame' array might be accidentally filled up beyond its bounds (i.e. beyond 406 longs), or not. But if it is, other variables could be overwritten. Now, I'd think you would have noticed it from your debug output, if Lptest itself were overwritten this way. But what if, say, LpTimer were overwritten by accident? That one is declared above on the second line. If indeed it is overwritten, then the following 'if':
if LpTimer == 0 ' test if zero... may never evaluate to true (or it may just take a long time), and Lptest will then no longer be incremented. It's a long shot, but from this code at a glance, it's the only thing I can think of right now. Of course, there are also some other methods being called from this code, of which there is no way for us to tell how they might affect the program.
(edit: Looks like Phil and I posted at the same time)
Post Edited (_Mark) : 9/15/2007 11:30:39 PM GMT
It depends on which if the else goes with. I just assumed from the structure of your code that it went with the if immediately preceding it, in which case another tab is called for. But I could be mistaken.
-Phil
The compiler barfs if I indent the ELSE.
Think I found MY error. The IF...ELSE... business in in the wrong place. It should have been up where the
repeat if (c := PICSer.rxcheck) <> -1 Key := cis, as a last portion. Haven't tested it but this should not be a value coming from 2nd Prop (PropSer.rxcheck)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Yes, you were right the first time. That ELSE was supposed to be under the second IF. Found I was looking at my code on-screen, vs what was in the forum posting.
I still have some inherent error in my code I've not yet found. Probably will hit me next time in the shower, as it sometimes happens. Got to do a lot more squinting the code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Squinting can be avoided to a great extent by factoring your code into logical procedures. As soon as I see a function that fills a screen I start to squint too. So factoring enhances readability and aids debugging. If I had more time to read your code I might be able to help you more, sorry
*Peter*
Did that by looking at all the instances (Find) of where the variable 'Lptest' was used. Oh, dear, found it was used in a method where another variable was set to Lptest value, and then Lptest was being assigned from that other variable somewhere else. Ensuring it lock up at a value after it had reached a certain value received back from another board.
That board's progamming was done years ago; it retransmits values above 80h to about F0h. So my Prop code doesn't see it until it reached 80h or greater. Hence the 'lockup'. (Sound of hand hitting forehead and the 'commercial's' line of 'I could of had a V8' (a vegetable drink).
Apologies for wasting anyone's time and forum bandwidth. I just 'couldn't see the forest for all the (other board's) trees'. Another educational lesson in debugging code.
I did refactor the code to help make it more readable; much of this program had been written many months ago and some portions then were not able yet to be debugged. Thanks for everyone's suggestions. Now, on to the next 'stupid' bug; the bug isn't stupid, but maybe the programmer is at times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Thanks for that nose. I'd not seen this problem before, as the 'loop test' feature was written but not debugged until now. Funny wee traps one can find at a debug stage. Hides itself, too.
This code was written over a long period of time before the complete hardware was available. Just waiting for all the hardware parts to be included with two Propellers. Most worked but some 'funnies' (NOT!!) included to wrack the brain. Some easy to find; some NOT.
Thanks to everyone who suggested clues to these problems I've run into. I did not post them as they were found. Only after days of wracking my brain and checking various parts to see why the code wasn't right did I post. Most responses moved me in directions which helped clean up some bugs, but the tricky stuff hung in there.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko