new cog apparently slowing the whole prop down.

DerTrueForce

I've been trying to use an incremental rotary encoder cog I've written, and when I spin off a new cog with that code in it, the whole propeller seems to run much slower.
I know this because I coded up turning a pin on for one second and off again, and put it into the main cog's code before and after the call that spins up the new cog. I also put it into the beginning of the decoder cog's code, with a different pin. I've got LEDs on those pins, and when I start it, the first one lights for about a second, turns off for about a second, and then both turn on for around 53 seconds.

It's as if the system's clock input is slowing down from 5MHz to around 100kHz, but I'm on a FLiP, so I don't think that's what is happening.

Has anyone else encountered this?
I've also uploaded the source files in question, because that will very probably help. SIDcogSynth is the main cog, and decodeQuadrature is the rotary encoder driver.

apcountryman

It takes the system counter approximately 53 seconds to overflow when operating at 80 MHz. In my experience seeing a program hang for approximately 53 seconds is usually caused by the window for a synchronized delay being missed, but it appears that your code does not contain any synchronized delays so something else must be causing this behavior (I haven't reviewed the other code).

Phil Pilgrim (PhiPi)

Here's your problem:

  result := cognew(decodeQuadrature(pinA, pinB), 0)

What you have listed as "0" should be the address of a VAR stack array of at least 30 longs. Since you've specified "0", the stack will interfere with the the stored value of clkfreq. That will cause your waitcnts to wait for the next overflow of cnt, which just happens to be about 53 seconds away.

-Phil

DerTrueForce

.....

That was it. I allocated 30 longs, and it now works. And it was right there in the docs, too. I must have confused it for the parameter argument of the ASM version of cognew.

Where can I put my face...

Thank you.