Why does start up take so long???

krazyideas

Hello,

Well I have 2 pules's going into the Propchip.
Now the PUB TimeingRelay runs fine and so does the PUB TVDisplay, but Pub ExicuteRelay will not start until about one minunte goes by. Why won't it start immediately like it is soppose to???

I thought that it had to do with useing the same variables (mes1,bmes2) so I made and set some varuaibles in PUB TimeingRelay just for PUB ExicuteRelay (mes3, mes4) , but it made no difference. I can't figure it out.

Any thoughts

Timothy D. Swieter

The comment about one minute is your clue. Look for the errors in calculating WaitCnt statements. It sounds like you are calculating a time to wait for, but the time passes before we start to wait therefore you have to wait for the counter to roll over which takes about 1 minute with a 80 MHz. system.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

Jetfire

From waitcnt in the manual:

In fact, the interpreter takes 381 cycles of final overhead when the command is written in the form waitcnt(offset + cnt). This means the value of offset must always be at least 381 to avoid unexpectedly long delays.

Because of this, mes3 and mes4 should be at least 400. The time it is waiting for has already past when waitcnt starts.

Timothy D. Swieter

If you simply want to pause for some time you can use something like the following code which is stolen and slightly revised from the Clock object in the library.

'***************************************
PRI pauseMSec(Duration)
'***************************************
'' Pause execution in milliseconds.
'' Duration = number of milliseconds to delay
  
  waitcnt(((clkfreq / 1_000 * Duration - 3932) #> 381) + cnt)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

krazyideas

Hello,

Mes3, mes4 ect are all larger then 10_000_000. Which is why I couldn't figure out why it would wait so long before it would start. I finaly beat my head on the wall hard enough that I figured mabe that wasn't the problem.

What the problem was was the waitpeq command. I was waiting for the same pin to go high before before both the programs would continue past. So I ran the same pules to another pin and had one waitpeq wait for pin 7 to go high and then I had the second one wait for pin 5 to go high and it worked how it was soppose to.

I was under the impression that all the cogs had access to all the states of all the pins all at the same time. Why if I have two cogs waiting for the same pin to go high before continueing would only one ( the first one) sense that pins high state and continue while the second one waits for the frist program to stop and then wait's another minuet and then starts???

I attached the working program.

Any Ideas why it worked like that but not the other way?

Mike Green

All cogs do have access to all the pins. You can have two cogs waiting for the same pin to go high and have them both continue when the pin goes high. The delay of about a minute suggests that a WAITCNT was missed since 2 ^32 clock pulses is about a minute at 80MHz. I suspect that "beforeon" was not initialized when the 2nd routine began execution.

krazyideas

Sure enough.
I put a waitcnt of one second before starting the loop so that beforeon had time to initialze and it works like a charm

Thanks so much