Strange SPIN behavior: WaitCnt stalls changing an "unrelated" statement SOLVED
![ErNa](https://forums.parallax.com/uploads/userpics/JZIZYQ9QGBSK/n4DWIGLPA5QSR.jpg)
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?
Comments
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.
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!
Another other great thing about the Propeller is that you can use it to time itself. I do this all the time
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.
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!