PDA

View Full Version : Strange increment problem



Harley
09-16-2007, 03:47 AM
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

deSilva
09-16-2007, 03:52 AM
Please give the context in your code.

I think it increments as expected, but your further processing masks it down...
But there are many other possibilities...

Harley
09-16-2007, 04:50 AM
deSilva,

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

deSilva
09-16-2007, 05:09 AM
So I have no further idea what your bug could be http://forums.parallax.com/images/smilies/smile.gif

Harley
09-16-2007, 05:33 AM
·OK, deSilva, here's a portion of my code.· Hope it is enough to help.· Some things are temporarily commented out; will either be used or tossed out eventually.· And some lines are totally for debugging purposes temporarily.


VAR
long status, stack[100], key
long rxpin, txpin, c, rxbyte, rxcheck, txbyte,frame[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[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[8]~ ' pulse Lo for ~ 8 microsec
' OUTA[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 seconds


Reiterating, 'Lptest' will not increment above 80 hex.· WHY??


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Phil Pilgrim (PhiPi)
09-16-2007, 06:34 AM
Harley,

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 <-------------------------------------this one
Display.str(string(" "))
Display.hex(Lptest,2)
Display.str(string(" FAIL"))





-Phil

Harley
09-16-2007, 06:58 AM
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

_Mark
09-16-2007, 07:25 AM
I think he means perhaps that 'else' is currently aligned to the wrong 'if'. Don't know if that would affect Lptest, though. It looks like Lptest should have no problem counting beyond 80h. But since this is not the entire code, it may be difficult to tell. For example, I assume this:



qs1 : "QuickSample_12" ' measures INA and variables, 1 cog



... is a part of ViewPort, judging from the following line of code:



qs1.sampleINA(@frame) ' used with ViewPort



The 'frame' variable is declared as an array in the first of the following two lines:



long rxpin, txpin, c, rxbyte, rxcheck, txbyte,frame[406],CmdStatus, LEDreg
long addrReg, dataReg, statReg, keyReg, regReg, dirReg, AdDaStReg, id, BP2, LpTimer '



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

Phil Pilgrim (PhiPi)
09-16-2007, 07:25 AM
Harley,

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

Harley
09-16-2007, 08:25 AM
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 := c


is, as a last portion. Haven't tested it but this should not be a value coming from 2nd Prop (PropSer.rxcheck)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Harley
09-16-2007, 08:44 AM
Phil,

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

Peter Jakacki
09-16-2007, 11:21 AM
Hi Harley,
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 http://forums.parallax.com/images/smilies/smile.gif

*Peter*

mcstar
09-16-2007, 12:00 PM
Here's another vote for refactoring! Doing so helps debugging immensly. You can then do unit test and pull out functions that have issues. Might also help to break that up into other objects!

Harley
09-17-2007, 06:13 AM
OK, this 'stupid' problem is solved.

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

deSilva
09-17-2007, 03:06 PM
If you look into the second posting, it seems deSilva had a good nose http://forums.parallax.com/images/smilies/smile.gif

Harley
09-17-2007, 11:21 PM
deSilva said...
If you look into the second posting, it seems deSilva had a good nose

Yes, but the 'nose' didn't provide a clue as to where the problem was. The 'mask' is difficult to recognize at times.

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