Blimey Erik, what took you so long :) I'll try it shortly and update here. Many thanks.

I added enable_irq() and disable_irq() methods on InterruptIn class, which does quickly what it says. Might use those Paul. The NULL pointer trick as Eric suggested, does it also, but it is more time consuming.

Regards, 0xc0170

Is that a relative new function? Never noticed it before. I see it does the same as what I put as third method, indeed faster, but still often a little bit on the overkill side of things ;). Most important, I think that it can use slightly more documentation that it has now. Mainly to mention its behavior is dependent on which uC is used, and that it can disable all InterruptIns.

@Paul, hey you never responded on my last mail :P (I did see your current consumption numbers in another topic though).

Erik, dcfSignalIn.rise(NULL); has done the trick, sleep/wake functions back to normal now. (mail on its way:)

Martin, disable _irq() has some issues I think, possibly only with the KL25z?, definite issue with low power timer interrupts in sleep modes. I have not worked with IRQ on any other MCU. I would have thought calling a Ticker ISR should not restart any other disabled IRQ's? unless it is intended purely as a global disable/enable function to quickly shut down/restart many IRQ's in one go.

Thanks again guys

You can start a new thread on this issue, but I believe it does not have any, have you checked the implementation? It's straightforward, just enable/disables interrupt which was registered using InterruptIn object, can't disable anything else. If your pin is on the PORT A, during the initialization of an object for that pin, it enables interrupts from PORTA (entire port, a limitation of Kinetis L). By invoking disable_irq method, it disables the same vector which was enabled.

void InterruptIn::enable_irq() {
    gpio_irq_enable(&gpio_irq);
}

void InterruptIn::disable_irq() {
    gpio_irq_disable(&gpio_irq);
}

KL25Z HAL implementation:

void gpio_irq_enable(gpio_irq_t *obj) {
    if (obj->port == PortA) {
        NVIC_EnableIRQ(PORTA_IRQn);
    } else if (obj->port == PortD) {
        NVIC_EnableIRQ(PORTD_IRQn);
    }
}

void gpio_irq_disable(gpio_irq_t *obj) {
    if (obj->port == PortA) {
        NVIC_DisableIRQ(PORTA_IRQn);
    } else if (obj->port == PortD) {
        NVIC_DisableIRQ(PORTD_IRQn);
    }
}

@Erik Yes, it's been there since November. Overkill? Methods above are intended for quickly disabling/enabling interrupts for the object which registered that interrupt. You can compare the NULL pointer for raise/fall, what the implementation does (as I recall, even global disable/enable interrupts, not to mention stepping over array of attached functions) ! What would be your suggestions to enable/disable an interrupt for InterruptIn class? If I commit to mbed src again, I will add brief description.

Regards, 0xc0170

Maybe Paul was confused with the global irq enable/disable functions.

Regarding these specific ones, imo the problem is that their behavior is highly dependent on the platform: On the LPC1768 they disable all InterruptIns, on the KL25 half of them, on the LPC11u24 only one (I assume). And in general I am all for higher performance, but does enabling/disabling interrupts require such speed? And even if it does, doesn't it kinda decrease the advantage of a relative target independent library if the behavior depends so much on your target?

Normally to disable one I just use attach NULL, technically it doesn't disable the interrupt vector, but if all its sources are disabled the interrupt will never be called.

Yes you are correct Erik, but not so much confused more along the lines not having the code knowledge that I can narrow down and pinpoint an individual IRQ to control it. I know exactly what I want to do but lack the knowledge as to how to write the code. The code example that you and Martin have shown above has expanded this IRQ control function to be more specific to the IRQ I am trying to control. So yes for the beginner/intermediate programmer like myself more documentation with examples is a good way to go. However the question is how much documentation and to what depth and how much spare time you guys have. If you take a look at the 'hello world' examples on mbed, these are geared up very much for entry level knowledge and some of the questions I see do come from beginners. So if I were to document an example on mbed I would bare that in mind and for instance give an example of how to initialise the IRQ, use it and then how to disable it and re-enable it again if required. With regards to speed or ultimately how many clock cycles to perform a task can be very important for certain processes, but I think this is more for high performance applications that would be leaning towards multi-cored CPU's with vastly more resources and at this level the target audience would be expert who would know the code examples above. Lastly it has to be recognised that you guys are not getting paid for this time and I as well as many others really appreciate your efforts :)