PDA

View Full Version : Using COGINIT to exit a WAITPEQ 'hang up'



Harley
03-21-2009, 07:50 AM
The Prop manual says, pg 4-35, COGINIT "...can be used to stop and restart an active cog in one step..."

If one has assembly code hung up waiting for a WAITPEQ to match I/O pins designated state, will COGINIT truely remove it from the WAITPEQ instruction? If so, how much time does it take to effect the 'stop and restart' action?

Has anyone used COGINIT to exit a WAITPEQ condition? If so what are any details other than the COGINIT to accomplish this? Thanks for any help on this.

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

Mike Green
03-21-2009, 08:06 AM
COGINIT (and COGNEW) is fairly slow because it reloads the cog's memory. It takes maybe 200us to do this.

COGSTOP is fast, but leaves the cog in a stopped state.

You're probably wanting to force WAITPEQ/PNE to stop waiting and there's really no way to do that other than to satisfy the wait condition. You're better off not using WAITPEQ/PNE and using some instruction like TEST in a tight loop. It would leave the cog running, but you can control the exit condition.

Harley
03-21-2009, 08:39 AM
Thanks Mike,

I'm looking for a comparison in as few clock cycles as possible. Maybe a TEST in a tight loop would accomplish what's needed that WAITPEQ can't exit.

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

BradC
03-21-2009, 08:43 AM
I use test quite often for this purpose




here: test mask,ina wz
IF_Z jmp #exit
djnz loop, #:here





I'd love to see it faster, but off the top of my head 12 cycles is about as quick as I can manage

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

ericball
03-21-2009, 09:15 AM
8 cycles:
pintest test mask,ina wz
IF_NZ DJNZ loop, #pintest

Phil Pilgrim (PhiPi)
03-21-2009, 09:20 AM
In many cases you don't need to respond within one clock, but just need to know exactly when the edge occurred, while allowing for a timeout. For such cases, I've presented a "Trick" on this page (http://forums.parallax.com/showthread.php?p=575479) (1/5/2009).

-Phil

ericball
03-21-2009, 07:39 PM
Yes, I was thinking last night that it would probably be a better idea to use the counters instead of a spin loop, especially if the input might be a very brief transient.

BradC
03-21-2009, 07:59 PM
There are times I pine for the "capture" mode of the HC11 counters.

Oh to be able to latch the value of cnt into a register on the change of state of a pin...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

Phil Pilgrim (PhiPi)
03-21-2009, 11:10 PM
Brad,

You could do that with the Prop, using one counter, if the input doesn't have rapid-fire transients. All you have to do is set the counter to count up (frqx := 1) under the current pin state and stop counting when it changes. Then set its phsx so that it will equal (and thus track) cnt. Once the pin changes, you will need to read read phsx before it changes back.

With an external, resettable, D-type flip flop (e.g. 74HC74), you could use this technique to capture any pulse, no matter how fleeting.

-Phil

Harley
03-23-2009, 05:24 AM
Thanks for all the comments.

I'm moving ahead with using the WAITPEQ. Plus using COGINIT and COGSTOP to escape the 'hang-up' for the 'no match' situation. The crude test steps I've used so far appear to make WAITPEQ far superior.

I have a 17-bit value to compare for a breakpoint, and can implement the COGSTOP and COGINIT from keypad commands presently in use to escape and restart. The delay to restart is no problem.

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