Re: [Avr-libc-corelib] Interrupt Handlers

[Mike Perks]

Jan

One of the issues that will need to handled (intentional pun) by the 
library is ISRs. There are several use cases to consider:

1. Library module wants to use an ISR
2. User wants to use an ISR
3. User wants to use an ISR but it is used by a library module
4. Two library APIs (presumably from different modules) both want to use 
the same ISR
    

Can you please provide examples?
  

For the case of a user wanting to use an ISR, then this usually ameliorated by the API in some fashion. For example transmit and receive buffers are used for serial comms.

One place everyone is interested in is RESET. On a reset interrupt how we do handle initialization of every one including the user code? Presumably the user has a init() routine (could be a callback) that than calls all of the other init routines. Another case is that the user sets up an RTC timeofday routine but also needs to know when each tick occurs so they can do their own processing at predefined intervals. It might be as simple as incrementing a counter. If you introduce an API such as WaitForInterrupt() or WaitForTick() then the user code is stalled unless you also introduce some kind of RTOS that allows other user code (separate task) to proceed while waiting for the interrupt.

Having a first come first served policy will not work. 
    

Why not?
  

Because some piece of code will never get the interrupt they are expecting. Worse case the compiler has a link error with two ISR routines.

We probably need 
to provide a way to have hooks such as a callback. The problem is that 
this could be too heavyweight for what is supposed to be a fast response.

I see no problem with having alternatives: lightweight, heavyweight, let the user choose what he wants.
  

The purpose of this append is to discuss how it might be done in code. Ruddick has an idea with his macro approach although I would prefer to see it with public inlined static functions. Another idea is with a weak reference callback, to at least give one part of the code a chance to hook in.

I repeat myself: I anticipate the user will copy files to his project and possibly modify. I can't even imagine how could a pre-build library be less than cumbersome.
  

The issue of whether we build libraries for each device or family of devices I think is still open. In either case we still have to test the code. However I do not see most people scrambling around trying to understand the library code so they can modify it to explicitly add some additional ISR code. I believe the whole point here is to have a standardized API with documentation that people can just use.

Mike Perks
Oak Micros (oakmicros.com).