> -----Original Message----- > From: > avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of darkschine > Sent: Sunday, November 29, 2009 11:12 PM > To: avr-gcc-list@nongnu.org > 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. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
