Hi N (N STEENKAMP [M.ING E&E]), in <64497E6F56@firga.sun.ac.za> on May 18 you wr
ote:

> routine, but not by such a large margin.  And of course he did not
> mention the inefficient table read until he was asked about it.  Those are
> the ways of marketing...

The AVR is inefficient with register access:

        In one project I wanted quick interrupt latency for lo-pri ints, so
        I disabled the specific int at the start of its ISR, and enabled
        global ints. This way the stack can't overflow, but latency is
        short.

        It takes lots of instructions to disable an int, when it's register
        is "high".

        After all I needed

                in      sreg_save,SREG
                in      tmp,REGISTER
                andi    tmp,0xXX
                out     REGISTER,tmp
                out     SREG,sreg_save
                sei

        The ISR itself does not change any status bits at all.

        Not only I have to read the register with a command, even worse, I
        also can't bit-manipulate it without changing the status flags!

        That's because the "sbr" and "cbr" commands exist only in the
        assembler - the silicon sees ANDI and ORI (see binary opcode).


Also, the AVR doesn't offer an FSR.  It is very inefficient to indirect
read/write registers.  On the PIC, I can setup FSR and then use its
destination just like any register!  Very nice.


But the AVR has its nice sides, too.  Today I finished another board with
AVR (typical PIC application but AVR won for better price/speed).  The next
one is in work, but featuring both PIC and AVR :-)