Shop OBEX P1 Docs P2 Docs Learn Events
Using COGINIT to exit a WAITPEQ 'hang up' — Parallax Forums

Using COGINIT to exit a WAITPEQ 'hang up'

HarleyHarley Posts: 997
edited 2009-03-22 22:24 in Propeller 1
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

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-03-21 01:06
    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.
  • HarleyHarley Posts: 997
    edited 2009-03-21 01:39
    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
  • BradCBradC Posts: 2,601
    edited 2009-03-21 01:43
    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.
  • ericballericball Posts: 774
    edited 2009-03-21 02:15
    8 cycles:
    pintest test mask,ina wz
    IF_NZ DJNZ loop, #pintest
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-21 02:20
    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 (1/5/2009).

    -Phil
  • ericballericball Posts: 774
    edited 2009-03-21 12:39
    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.
  • BradCBradC Posts: 2,601
    edited 2009-03-21 12:59
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-21 16:10
    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
  • HarleyHarley Posts: 997
    edited 2009-03-22 22:24
    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
Sign In or Register to comment.