Strange behavior with math (Resolved)

Greg LaPolla · 2009-07-05 17:24

I may be missing something here but this has been driving me crazy for 2 days.

I have 2 variables timer_val and timer_ela. I can perform simple math functions (add and subtract) on them, however if I perform anything on them together I get strange results like:

lets say timer_val is 60 and timer_ela is 3

timer_rem := timer_val - timer_ela

timer_rem will be equal to 60, but should be 57.

timer_rem := timer_val -1

timer_rem will be equal to 59

timer_rem := timer_ela + 1

timer_rem will be 4.

All these variables are declared as type long, does anyone have any insight on this ?

Greg

Post Edited (Greg LaPolla) : 7/6/2009 12:18:19 AM GMT

Ale · 2009-07-05 17:46

I do not believe you, post the code please, all of it (even how you get the values of the variables).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Phil Pilgrim (PhiPi) · 2009-07-05 18:26

Ale,

That's a rather blunt appraisal, but I have to concur.

-Phil

Greg LaPolla · 2009-07-05 18:58

The objects are attached.

timer_val is obtained by calling Resistance method in RcResistance.spin
timer_ela is obtained by calling the rdReg method in timer.spin using the TMR_MINS parameter

here is the code to get the resistance:


PUB Main

  repeat
    if ina[noparse][[/noparse]24] == 1
      timer_val := display.getTimer
      timer.reset
      display.setup
  
    timer_ela := timer.rdReg(timer#TMR_MINS)
    timer_rem := timer_val - timer_ela 

    display.update (timer_rem)
    waitcnt(clkfreq  + cnt)




PUB getTimer: R

  meter.Init(RC_PIN, HL_PIN, CAP_VAL, COR_FACTR)  ' Initialize RcResistance
  output.tx(output#CLS)
  waitcnt(clkfreq + cnt)
  repeat until ina[noparse][[/noparse]24] == 1                  ' Repeat loop
    R := meter.Resistance / 9                ' Get resistance
    waitcnt(clkfreq/10 + cnt)                ' Display refresh 10 Hz
    output.tx(output#HOME)
    output.Str(String("Timer = "))
    output.Str(num.decf(R,3))                 ' Update display
    output.tx(output#CLREOL)

basically what this is is a 10K 10 turn pot that is used th set the value of timer_val. if you press a momentary switch it allows to take a reading from the pot then press it again to return to the timer.

Ale · 2009-07-05 18:59

Sorry if I was harsh :-(. No code would work if that was true and we have plenty of working code that uses such a statement, so the error has to be somewhere else, i.e. variable load or variable reading or in some assumption that does not have ground.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Phil Pilgrim (PhiPi) · 2009-07-05 19:03

How do you know that timer_ela == 3? I don't see it being displayed anywhere.

-Phil

Ale · 2009-07-05 19:04

timer_val seems to be initialized just when ina[noparse][[/noparse]24] == 1, what happens when that condition is not met ?

Print the values of timer_val, timer_ela and timer_rem and you will find out how you get false results... then investigate the source.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Greg LaPolla · 2009-07-05 19:08

I have done all that. I know that the values are all correct. The issue is that

timer_rem := timer_val - timer_ela

will always be equal to timer_val.

Nick Mueller · 2009-07-05 19:28

Did you try it with a bigger stack for the timer-cog?

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Ale · 2009-07-05 19:30

Very good suggestion Nick ! I always forget about the strage problems that a small stack can produce !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Greg LaPolla · 2009-07-05 19:37

The timer object works as expected.

if I set timer_rem := timer_ela

The timer display on the screen will increment by 1 every minute

if I set timer_rem := timer_val

The timer display on the screen will show the reading from the pot.

If I set timer_rem := timer_ela + 1

The timer display on the screen will show the reading from the timer + 1

if I set timer_rem := timer_val + 1

The timer display on the screen will show the reading from the pot + 1

Hence my problem that timer_rem := timer_val - timer_ela will always be equal to timer_val.

Nick Mueller · 2009-07-05 20:04

> The timer display on the screen will increment by 1 every minute

So the difference is 3 minutes?
That sounds like an overroll in CNT.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Greg LaPolla · 2009-07-05 20:09

Forget about 3 it was just a for instance I set up.

everything works as expected withe the proper results except for this line:

timer_rem := timer_val - timer_ela

no matter what timer_ela is this equation will always be equal to timer_val.

Nick Mueller · 2009-07-05 20:18

Did you try it with the stack?
Did you try a print of the values directly before and after the assignment?
Did you try so filler-vars to avaoid overwrites?

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Phil Pilgrim (PhiPi) · 2009-07-05 20:29

Greg,

Making sure your stack is big enough is a good idea. Otherwise, the value for one of your operands in the subtract is simply not what you think it is. Spin math is airtight. If the compiler/interpreter were making an error of the kind you supect, it would've been discovered and corrected long before now.

One of the hardest lessons to learn when debugging is to search for what you did wrong, rather than convincing yourself that what you did was right. ("It should work!") After forty years of programming, I still have to check myself on this issue!

-Phil

Nick Mueller · 2009-07-05 20:33

> "It should work!"

It's OK if you say that *before* letting run the program. But if it fails, the only allowable question is "what did I do wrong", and the only allowable statement is "I don't get it", or "I'm an idiot" (after you found the bug).

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

StefanL38 · 2009-07-05 20:40

Hello Greg,

please use the archive function of the propellertool to zip ALL lines of code that you were using

you made several quick shots that didn't solved the problem.

So it is time to do a careful analyse for EVERY DAMMED SINGLE line of code.

we can go on guessing into the fog for weeks and month or take half a day to
I repeat myself
a careful analyse for EVERY DAMMED SINGLE line of code.

best regards

Stefan

Greg LaPolla · 2009-07-05 20:51

Phil,

Your absolutely right after almost 30 years I still fall into that hole too!

This one has me perplexed.

I have done as nick suggested looking at the values before and after and also trying filler vars, everything is correct.

I really don't think the stack is the issue. I am not performing any calculations in the cog running timer.

I even tried changing variable names to X, Y and Z just to make sure nothing was overwriting.

Greg

Nick Mueller · 2009-07-05 21:26

> I really don't think the stack is the issue.

Never make assumptions. Only verification helps.

> I even tried changing variable names to X, Y and Z just to make sure nothing was overwriting.

Do you think the variables are sorted alphabetically in RAM?

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Phil Pilgrim (PhiPi) · 2009-07-05 21:29

Don't forget that the stack is used to pass method parameters and to hold local variables. If you have lots of parameters or the method calls are nested, you could easily get a stack overflow in Spin cogs that you've started from the top level.

-Phil

CounterRotatingProps · 2009-07-05 21:41

Another approach:

isolate the code into the smallest chunks that will run the code block in question - eliminate everything else. If the problem goes away... well, obviously add in code piece by piece. (The lazy way to check 'every damn line of code' [noparse];)[/noparse]

- H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Erik Friesen · 2009-07-05 22:12

A stack size of 12 is suspect. Could you confirm that you have tried a larger stack? Say 25?

Can you add a serial port object, and serial.dec(timer_ela) ?? I suspect you will get a 0

Peter Verkaik · 2009-07-05 22:24

Greg said...everything works as expected withe the proper results except for this line:

timer_rem := timer_val - timer_ela

no matter what timer_ela is this equation will always be equal to timer_val.

Then apparently timer_ela is 0 prior to the line.
I'd say test that for sure, then find out why it became 0
if you expected some other value.

regards peter

Phil Pilgrim (PhiPi) · 2009-07-05 23:28

I agree with Erik: a stack size of twelve longs is almost certainly too small.

-Phil

Greg LaPolla · 2009-07-06 00:08

I have finally identified a problem. I am still chasing it. My program outputs to PST right now so I hooked up an lcd to dump data real time. So tEla will increment as expected until I press the button and trigger ina[noparse][[/noparse]24] == 1. At this point tEla stops counting. until the prop is reset. So now I need to look into debuging the timer object, as it appears to be the culprit. Stay tuned!

Greg

Greg LaPolla · 2009-07-06 00:17

So I found the issue, I did not fully RTFM. after issuing a timer.reset, you have to issue a timer.run.

Nick Mueller · 2009-07-06 09:08

> My program outputs to PST right now so I hooked up an lcd to dump data real time.

Sorry for granny-telling: The first thing you should have for µC-debugging is a serial connection on the µC and a terminal on the other end. As soon as you do have that, you have won. All else is simply a PITA to work with.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Strange behavior with math (Resolved)

Comments