Re: AVR interrupt response time

From: Pygmi (bronco_castor_at_hotmail.com)
Date: 01/13/05 

Date: Thu, 13 Jan 2005 18:16:08 GMT

"Ulf Samuelsson" <ulf@NOSPAMatmel.com> wrote in message
news:34lvauF4e3rq9U1@individual.net...
> > When I compiled the code and ran it, I noticed that it took about 2.5 us
> to start executing my code?!?!
> > (I used ATMega8 as I don't have any M32 at the moment, but I guess it
> isn't relevant??)
> > I checked the list file and one reason is the LENGHTY prologue added by
> gcc into interrupt
> > handler (17 instructions!!!), saving LOT of registers...
>
>
> You can try a better compiler than WinAVR!
>

Actually I made a quick test today. Empty handler and
then I wrote the code using inline assembly. Prologue of
17 instruction dropped down to 4 and time from external
trigger from >2.5 us down to 1.2 us or so (at 14.75 MHz).

I was also able to snip few instruction out of my own code.
So, I think there is hope. It is possible to get all done within
2.5 us. But not with handlers written using C/gcc combination.
Maybe with C/IAR or some other compiler. And of course
by writing those critical parts in assembly.

I do understand also that this only half way there. I need to
design & write the other code in such away, that this one
critical handler is serviced with minimum delay...
But it is possible....maybe.

If there just was a AVR running with 25-30 MHz clock.

>
> // IAR C interrupt handler
> #pragma vector=12
> __interrupt void handler()
> {
> BYTE i = PORTB;
> PORTB = 0xF0;
> PORTB = 0x0F;
> PORTB = i;
> }
>
>
> Generated code
>
> 51 __interrupt void handler()
> \ handler:
> 52 {
> \ 00000000 931A ST -Y,R17
> \ 00000002 930A ST -Y,R16
> 53 BYTE i = PORTB;
> \ 00000004 B318 IN R17,0x18
> 54 PORTB = 0xF0;
> \ 00000006 EF00 LDI R16,240
> \ 00000008 BB08 OUT 0x18,R16
> 55 PORTB = 0x0F;
> \ 0000000A E00F LDI R16,15
> \ 0000000C BB08 OUT 0x18,R16
> 56 PORTB = i;
> \ 0000000E BB18 OUT 0x18,R17
> 57 }
> \ 00000010 9109 LD R16,Y+
> \ 00000012 9119 LD R17,Y+
> \ 00000014 9518 RETI
> 58
>
> Two registers used, two registers pushed.
> As you see, there is no reason to even push the PSR in this case since the
> flags do not get updated.
>

I must admit that this seems very reasonable.

> If you need fast interrupt response, and need to do a lot,
> then consider to divide the handler into two parts.

Not a bad idea. In general. But in this case I want fast service
(i.e. end result) after external interrupt. So dividing would make
it even worse.

> First part (minimal) does minimal fast processing and at the end, it sets
an
> external interrupt
> which continues the processing after the fast interrupt has exited.
>
> __no_init __register BYTE SavePortB @4; Put i in Register r4
> #pragma vector=TIMER
> __interrupt void fast_handler(void)
> {
> SavePortB = PORTB;
> set_ext_interrupt_pending();
> }
>
> #pragma vector=EXT_INT_HANDLER
> __interrupt void slow_handler(void)
> {
> // Continue slow processing after fast handler has exited.
> PORTB = 0xF0;
> PORTB = 0x0F;
> PORTB = i;
> }
>
> Since the processing is minimal in the fast handler, very few registers
> should be pushed by a good compiler.
>
>
> There is a 4kB restricted C compiler for tests.
> You have to personally contact IAR to get it. It is not on their web page.
> This does not generate assembly code , only object code.
>
>

I have seen you recommending IAR earlier. Unfortunately I have some
bad memories working with IAR compiler.
...ok several years back with Hitachi H8
...so maybe not very relevant today
...buts at that time we were consdering to go to gcc to get rid of all
the bugs in IAR libs. But all this happened in last century.

So, maybe I should give it a try one of thes days.

>
> --
> Best Regards
> Ulf at atmel dot com
> These comments are intended to be my own opinion and they
> may, or may not be shared by my employer, Atmel Sweden.
>

Thanks
Pygmi

Relevant Pages

  • Re: Free FAT16 Filesystem
    ... being an honourable reason. ... Dave, I made every effort 3 weeks ago to have you understand that if you ... >>Murray did not mention Keil in his correspondence to you. ... >>both your compiler AND under Keil's, ...
    (comp.arch.embedded)
  • Re: "Sorting" assignment
    ... issue on some ancient compiler doesn't make a lot of sense. ... to his on a few commonly used platforms and compilers, ...  Be sure and call the swap ... reason to find algorithms which operate independent of it. ...
    (comp.programming)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... >convention that has served Fortran for 50 years, is itself, no good ... >reason for change. ... >done, using implicit typing. ... The IBM 1130 compiler could do ...
    (comp.lang.fortran)
  • Re: Generating a simple hand-coded like recursive descent parser
    ... I see no reason to use that to bootstrap a compiler. ... a smarter algorithm using a fusionned DFA for the ... There's no specific algorith to build the AST. ...
    (comp.compilers)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... >> The compiler can never guarantee my code is correct, ... And in Lisp, the absence of an explicit handler is not necessarily a ... environments where an unhandled exception leads to abrupt termination ...
    (comp.lang.lisp)