custom interrupt handlers

Only INT0 and INT1 can currently be attached/detached, IIUC.

First of all, here's a micro-optimization suggestion: in WiringInterrupts.c, both INT0_vect and INT1_vect could be simplified by always storing valid function pointers in the intFunc array. So instead of detachInterrupt() setting an entry to 0, it could set it to a dummy (empty) function. That would get rid of the if statements in INT?_vect - maybe there's no speed advantage, I don't know avr-gcc well enough, but if there is, I think it's worth the change because in interrupts, microseconds can matter...

But the main point of this post is really to vote in favor making the TIMER0_OVF_vect interrupt overridable, somehow. Perhaps an extra entry in that same intFunc array? Maybe also for other interrupts, such as USART_RX_vect? There are cases where you don't want the default behavior of the millisecond timer and/or the serial receive interrupt, and right now there is no easy way to override these while still including the standard Arduino library code. Even the simple mechanism of calling the actual interrupt code through a global function pointer (which can pointed to another function at run time) would be enough.

A usage scenario: I would like to implement a small timer/scheduling library, driven by 1024 microsecond ticks from timer 0 so that simple tasks can be scheduled to run in the future, without tying up timers 1 or 2 for this, given that timer 0 is already firing all the time.

-jcw

First of all, here's a micro-optimization suggestion: in WiringInterrupts.c, both INT0_vect and INT1_vect could be simplified by always storing valid function pointers in the intFunc array.

Funny you should mention this, as it was something I had thought of recently while looking at the code but hadn't got around to writing up. (Partly because I had no hard figures on the timing/size difference it would make.)

My interest is in making the AVRUSB code work with the most recent version of Arduino and/or when interrupts are used and the interrupt code in that is extremely timing sensitive. (The whole thing is hand-crafted, cycle-counted assembly.)

If you felt like coming up with a patch to implement this and provide some stats on timing/size differences I'd suggest you send it to the developer list.

--Phil.