Re: [Avr-libc-corelib] Interrupt Handlers

[David Brown]

Ruddick Lawrence wrote:
> A possible solution would be for each module that needs to put code in 
> an ISR to define a macro with that code. The user would then have the 
> responsibility of defining the ISR and calling the macro in it. This 
> would give users full control of the order, and the ability to add their 
> own code, with the drawback that it is one more thing to remember. The 
> existence of an ISR macro in a module would have to be VERY well 
> documented, including which ISR it should be put in (perhaps a standard 
> heading in module documentation so it was also clear when there weren't 
> any ISR macros in a module). However, if this method is used throughout 
> the library, users will get used to looking for it as part of learning 
> how to use a module.
>
> Ruddick

This sounds like a good plan, except for the "macro" bit - such code 
should be "static inline" functions.  Generally speaking, "code" macros 
should be static inline functions these days - they are clearer to write 
and to understand, and provide better error checking.

mvh.,

David



> On Wed, Sep 23, 2009 at 11:07 AM, Jan Waclawek <address@hidden 
> <mailto:address@hidden>> wrote:
>
>     On Wed, 23 Sep 2009 10:44:59 -0500
>     Mike Perks <address@hidden <mailto:address@hidden>> wrote:
>
>      > 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?
>
>      > Having a first come first served policy will not work.
>
>     Why not?
>
>      > 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.
>
>     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.
>
>     JW