RE: [avr-gcc-list] assembly-c mix and interrupts

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of darkschine
> Sent: Sunday, November 29, 2009 11:12 PM
> To: address@hidden
> Subject: Re: [avr-gcc-list] assembly-c mix and interrupts
> 
> 
> In my opinion, the best algorithm for an interrupt would be:
> 
> ISR(vector){
>    data=getData();
>    processData(data)
> }
> 
> then unit testing can be carried out on processData() and 
> getData() leaving
> little testing required for the interrupt itself

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.