Weddington, Eric wrote:
>
> Many times in the embedded software world, you have to deal with
> trade-offs.
>
> Sure you could design an ISR that way and do the unit testing the way you
> describe. And I'm sure that it would make your unit testing easier. The
> trade-off though is that it makes the ISR very inefficient. It has been
> said on this mailing list as well as on the AVR Freaks website forums that
> calling functions in an ISR is a Bad Idea, if you want to keep your ISR
> short. And you *do* want to keep your ISR as short as possible.
>
> When an ISR calls a function, the compiler has no idea what registers the
> called function will use. So, to be conservative, the compiler will
> generate code to push/pop practically all registers, thus causing more
> code bloat and more time in the ISR prologue. That is your trade-off. If
> you think that ease of testing is better priority than a short ISR, then
> by all means go ahead. I know that most embedded software engineers on
> this list would rather have a short-as-possible ISR instead of that
> testing scheme. It's all a matter of priorities and trade-offs.
>
>
I see your point, I guess it all depends on the application.
The issue I am trying to draw attention to is that, in my case, the compiler
is not being conservative so the push/pop of volatile registers must be done
manually.
--
View this message in context:
http://old.nabble.com/assembly-c-mix-and-interrupts-tp26421328p26570372.html
Sent from the AVR - gcc mailing list archive at Nabble.com.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
