Strange SPIN behavior: WaitCnt stalls changing an "unrelated" statement SOLVED

ErNa

I face this strange behavior:
In a loop the variable "Winkel" is increased by one.
` repeat

      WaitCnt (DelayTime)
      Delaytime += 35_000
      Winkel    := Winkel + 1

      Winkel :=  Winkel // 1536

`
So Winkel is robbing around from 0 to 1535. I want to control the increment and introduce a variable dWinkel

`
dWinkel := 5
repeat

      WaitCnt (DelayTime)
      Delaytime += 35_000
      Winkel    := Winkel + dWinkel

      Winkel :=  Winkel // 1536

Next I wish to grow dWinkel slowly, so I scale up by 100 and devide by 100
dWinkel := 500
repeat

      WaitCnt (DelayTime)
      Delaytime += 35_000
      Winkel    := Winkel + dWinkel/100

      Winkel :=  Winkel // 1536

`
And now nothing happens, the programm stalls. Give it another try:

`dWinkel := 5
repeat

      WaitCnt (DelayTime)
      Delaytime += 35_000
      ddWinkel  := dWinkel
      Winkel    := Winkel + ddWinkel

      Winkel :=  Winkel // 1536

`
Return to the original scale and use a second variable: It stalls again. I can not print the value but do not see, what could provoke this?

Wuerfel_21

Assuming that's not the whole loop in your actual program: If you WAITCNT for a time that has already passed, the program will wait until the CNT register overflows and eventually reaches the target value again (this takes almost a whole minute with 80 MHz clock). So if you put too much stuff in the loop, it will miss the time target. 35000 cycles is not a lot for the spin interpreter, so a couple of divides can put it over the edge (not sure how slow a divide is, but wouldn't doubt it to take on the order of 1000 cycles with all operand push/pops).

If it is the whole loop, I must as usual implore you to post a complete program file showcasing the issue.

ErNa

OK, I shut down my system to retire, but then I thought: could it be, that the loop can not be completed just by accident when I introduced a single instruction? YES! Increasing delay time to 40_000 solved the problem. I've moved the process from main to a separate cog before and had to introduce HUB instruction, which increase the run time so I reached the limit!!
That was an accident not to foresee.
Yes Wuerfel, you got it! It blocked even it I just changed an instruction like A = 5 to A = B So I actually was on the brink! But for now: good night!

JonnyMac

Another other great thing about the Propeller is that you can use it to time itself. I do this all the time

  t := cnt

  ' test code

  t := cnt-t-368

  term.dec(t)

If you do this you'll find it takes more time to move a variable to a variable than the value of a constant to a variable -- which make sense as the former requires and extra RAM read.

ErNa

Thanks for the quick reaction. I dig a pit and find myself in it later. Q&D programming just to test an algorithm, and forgot about the safety belt. When testing a delay I toggle a pin I can test with an scope, usually, but not this time, my fault. On the other hand: I can just create set values in one cog and use them in another cog without any interrupt problems, only the Prop can do it!