Cognew + Watchdog timer

MacTuxLin

May I know if there is a way to launch a cog for a fixed time? I only know:

VAR
  byte globalFlag[8]

PUB Main | cogID, i

  repeat i from 1 to 8
    cogID := cognew(chkSensor(i), @cogStack) + 1

    waitcnt(cnt + clkfreq/5)
    cogstop(cogID~ -1)

    if globalFlag[i] > 1
      'Sensor OK
    else
      'Sensor Failed

Thanks.

Mike Green

The way that you showed where you launch a cog, then stop it some fixed time later is one way to do a timeout. The other way is to have the cog itself time itself out by periodically checking the system clock for a quit time. If you have a spare I/O pin, you can set up one of the cog counters in the new cog to count down and output on the I/O pin when the time period has elapsed. If you're monitoring some other I/O pin using WAITPEQ or WAITPNE, you can set up your mask for the cog to continue if the sensor worked or if the timeout elapsed (using either I/O pin), then check the counter to see if it's lapsed. The "best" solution depends on exactly what you're trying to do.

MagIO2

Mike is right - as always ..

You should explain what your goal is .. what's the purpose of the 'fixed runtime'-COG. How adequate does the runtime have to be? What is the speed requirement of the runtime-COG? Is it feasible to add some instructions to check the runtime by it's own or do you need 100% of computational power for it's main task? How much COGs do you need in the end and is there a COG that can do the COGSTOP at all?

The way you do it in your example is fine for certain scenarios. And as the Propeller is fully deterministic this way also allows 100% adequate timing if you add a to be specified (for example by measurement) constant to the WAITCNT which covers the startup-time of a COG and the setup-time of your program that the COG executes.

If timing requirements are tough and the startup/setup time is to long you could propably start the COG and let it run in a wait loop before you actually want it to do it's job.

You see ... we don't know enough about your problem to give real good advice.

MacTuxLin

Thank you Mike & Mag. Sorry, I should have explained my requirement more clearly.

Actually, I was thinking if there could be a way that a new cog could time itself out so as not to tax on Cog0 to run the above repeat loop in sequence as the total sensors might go up to 20+ or so. I was thinking to launch new Cog & if additional Cog available, launch another one, then another one and so on. At any one time, there could be 7 Cogs checking the sensors.

I needed the timeout because if there are no acknowledgement from the sensors, it will be considered as failed so that the Cog will not be waiting for the feedback indefinitely.

Mike: "The other way is to have the cog itself time itself out by periodically checking the system clock for a quit time."

It seems Mike might have answered my problem but may I know how do I get the new Cog to check the system clock (maybe by 100ms) if it is also waiting for a signal from the sensor? Is it using the Cog counter like what you have said? I did looked at WAITPEQ & WAITPNE but it is pausing the Cog with pin conditions which isn't what I need. If you could point me a little further in the direction I should be looking into, it be great.

Thanks.

JonnyMac

Could you do something like this?

pri checksensor(pntr) | t

  long[pntr] := false                                           ' assume inactive

  t := cnt
  repeat 20
    ' set long[pntr] to sensor state
    if (long[pntr] == true)
      quit
    waitcnt(t + (clkfreq / 200))

  cogstop(cogid)

You launch this into its own cog with the address of the variable for the sensor in question. It checks the sensor state every 5ms until the sensor responds or 100ms has elapsed. You can keep the timing accurate by using a synchronized waitcnt as shown (this is discussed in the manual). At the end the cog unloads itself.

Mike Green

It's called "polling" and the details of how you do it depends on the sensor and how it communicates with the Propeller. Basically, the Prop program checks the sensor, then it checks the system clock. If checking the sensor involves waiting for some signal, then a check of the system clock is built into the wait.

MacTuxLin

Yes!!! This is what I needed. Thank you very much Jon & Mike