Pin re-assignment bricks imp

Squirrel Code
1

Are there any rules on dynamic pin re-assignment? The following code bricks the imp and only a power cycle will bring it back to life. Is it because I’m doing the re-assignment of the pin the caused the event handler to run?

Thanks as always

/`/ Event handler for PIR
function swEvent()
{
// Idle for 50ms to allow switch to settle
imp.sleep(0.15);

// Get PIR state
local state = hardware.pin1.read();
     
// PIR movement
if(state == 1 && movement == 0){
    triggerCount++;
    server.log("tc:"+triggerCount);
       
    if(triggerCount == 5){
        movement =1;
        server.log("Movement - wait "+ reArmDelay +" secs - " + format("rssi: %d dBm", imp.rssi()) );
        local _httpOut="l|020|5|"+getDateTime()+"|Monitor-Movement|PIR";
        _wsOut.set(_httpOut);
        hardware.pin1.configure(DIGITAL_OUT);
        imp.wakeup(reArmDelay, reArm);
    }
}

} `

2

Shouldn’t be an issue but absolutely sounds like a bug. I’ll file it as such…

3

Well, hang on, what’s connected to pin1? (Feel free to reply privately if need be.) But if you’re in an event handler 'cos something’s driving pin1 high, and the imp then tries to drive it low, you’re going to have a bad time.

Peter

4

Peter, All I was trying to do was stop the event handler being called for 20/30secs without using a server.sleep.

Ok what I’ve don’t is just removed that event handler but still bricking the imp.
hardware.pin1.configure(DIGITAL_IN_PULLDOWN); in place of dig out

Thanks
Lawrence

5

Ah, a pin configured as DIGITAL_OUT is always driven. Using analog in instead is a much better idea.

Peter

6

Or you could configure it as DIGITAL_IN but without the callback.

Peter

7

Peter, ok that’s what I’ve done but still bricks the imp.
Could I confirm that whitest in shallow sleep e.g. imp.wakeup that a pin event handler will be called e.g it isn’t blocked?
Hope I’m making sense not too sure if I am these days!

8

In imp.wakeup(), a pin event handler will be called. In imp.sleep() or server.sleepfor(), it won’t.

Peter

9

Peter thanks I have my workaround imp.sleep
perhaps a little more meat in the wiki for imp.sleep

The method will block for this period.
Does that included blocking an InputPort setter?

One last thing will a run timer error always cause a reboot?
Thinking of updating my state digram to reflect this.

10

Yes it does include blocking an InputPort setter, and yes the wiki should say so. I’ll head off there now.

And all Squirrel runtime errors cause a reboot (or certainly should do), whether the Squirrel in question is being run on startup or in an event handler or timer callback.

Peter

11

Peter thanks again for your help & have a good weekend.
I’m heading for the mince pies and mulled wine :slight_smile: