Searching \ for '[OT] AVR Seminar' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=avr+seminar
Search entire site for: 'AVR Seminar'.

Exact match. Not showing close matches.
PICList Thread
'[OT] AVR Seminar'
1998\05\18@062631 by STEENKAMP [M.ING E&E]

flavicon
picon face
Hi,

Last week I went to an Atmel AVR seminar for the first time.  It was
interesting to see their angle of approach : They are really serious
about competing head-on with the PIC.  All through the seminar, the
presenter was pointing out the PIC's inadequacies.  At one stage he had a
slide comparing a 16 bit subtraction on the PIC and the AVR.  I have
never seen such a long 16 bit subtraction routine on a PIC in my life!
It must have been at least 20 instructions!  The AVR routine was 2 or
three instructions.  To be fair, the AVR would still beat the PIC on a 16
bit subtract, even if they compared it to an optimized subtraction
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...

We did get an AVR develoment board - which is quite nice - and a 1200 to
start playing with.  They are also planning on adding loads of different
devices and peripheral options in the ?near? future.
What I do like about their core, anyway, is the true RISC architecture
(no more moving to W before doing a calculation), the support for >8 bit
arithmetic and the large number of test and branch instructions (no
more btfss - goto combinations).  One core limitation I see is the fixed
amount of registers (32).  On larger devices with RAM you would have to
start to do a lot of moving between the register file and the RAM.

If Atmel can compete in price (which is what matters, afterall), the AVR
might just give Microchip a run for their money!

(Don't worry, I have not been converted - I just keep my eyes open ;-)  )

Niki

1998\05\18@083159 by paulb

flavicon
face
N STEENKAMP [M.ING E&E] wrote:

> What I do like about their core, anyway, is the true RISC architecture

> ... and the large number of test and branch instructions

 Eh?

1998\05\18@085039 by g.daniel.invent.design

flavicon
face
N STEENKAMP [M.ING E&E] wrote:
>
> Hi,
>
> Last week I went to an Atmel AVR seminar for the first time.  It was
> interesting to see their angle of approach : They are really serious
> about competing head-on with the PIC.  All through the seminar, the
> presenter was pointing out the PIC's inadequacies.  At one stage he had a
> slide comparing a 16 bit subtraction on the PIC and the AVR.  I have
> never seen such a long 16 bit subtraction routine on a PIC in my life!
> It must have been at least 20 instructions!  The AVR routine was 2 or
> three instructions.  To be fair, the AVR would still beat the PIC on a 16
> bit subtract, even if they compared it to an optimized subtraction
> 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...
Speaking of marketing, was the subject of I/O manipulation speed ever
initiated by Atmel ?
>
> We did get an AVR develoment board - which is quite nice - and a 1200 to
> start playing with.  They are also planning on adding loads of different
> devices and peripheral options in the ?near? future.
> What I do like about their core, anyway, is the true RISC architecture
> (no more moving to W before doing a calculation)
Above can easily be done on pic with two instruction macro.

, the support for >8 bit
> arithmetic and the large number of test and branch instructions (no
> more btfss - goto combinations).
Above is also done on PIC using special instruction Mnemonics, the
difference is that where as Microchip market usually 35 instructions,
Atmel start with 16 bits(same as PIC17Cxx) and subdivide some
instructions types into the jump variants etc. Atmel call this part of
their instruction set, where as with Microchip you have to be in the
know (use the "special instruction mnemonics") or using the PIC17Cxx
devices to be aware of these similarities.

 One core limitation I see is the fixed
> amount of registers (32).  On larger devices with RAM you would have to
> start to do a lot of moving between the register file and the RAM.
>
> If Atmel can compete in price (which is what matters, afterall), the AVR
> might just give Microchip a run for their money!
>
> (Don't worry, I have not been converted - I just keep my eyes open ;-)  )
>
> Niki

1998\05\18@113948 by Marc Heuler

flavicon
face
Hi N (N STEENKAMP [M.ING E&E]), in <spam_OUT64497E6F56TakeThisOuTspamfirga.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 :-)

1998\05\18@121538 by STEENKAMP [M.ING E&E]

flavicon
picon face
Hi,


> N STEENKAMP [M.ING E&E] wrote:
> >
> > Hi,
> >
> > Last week I went to an Atmel AVR seminar for the first time.  It was
> > interesting to see their angle of approach : They are really serious
> > about competing head-on with the PIC.  All through the seminar, the
> > presenter was pointing out the PIC's inadequacies.  At one stage he had a
> > slide comparing a 16 bit subtraction on the PIC and the AVR.  I have
> > never seen such a long 16 bit subtraction routine on a PIC in my life!
> > It must have been at least 20 instructions!  The AVR routine was 2 or
> > three instructions.  To be fair, the AVR would still beat the PIC on a 16
> > bit subtract, even if they compared it to an optimized subtraction
> > 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...
> Speaking of marketing, was the subject of I/O manipulation speed ever
> initiated by Atmel ?

It was mentioned, yes.  Someone asked about it and the presenter
mentioned the SBI (Set bit in IO Reg) and CBI (Clear bit in IO Reg)
instructions.  These do take 2 clock cycle, though.  So there the PIC
beats the AVR.  Although, an AVR running at 1/2 the speed of a PIC would
be able to handle the same rate of IO change as the PIC, courtesy of the
1-clock-cycle-1-intruction-cycle mechanism.  I really wonder how they did
that!?!

> >
> > We did get an AVR develoment board - which is quite nice - and a 1200 to
> > start playing with.  They are also planning on adding loads of different
> > devices and peripheral options in the ?near? future.
> > What I do like about their core, anyway, is the true RISC architecture
> > (no more moving to W before doing a calculation)
> Above can easily be done on pic with two instruction macro.

Very true, but it is not only a matter of typing less.  The AVR
instruction only takes one instruction space (16 bits), while the PIC
macro still takes two intruction spaces.  The AVR code is thus more
compact.


{Quote hidden}

Same argument as above.


I must admit that I have no PIC17Cxx experience.  I am making my
observations relative to the 12 and 14 bit cores.

Niki

1998\05\18@160229 by David VanHorn

flavicon
face
>It was mentioned, yes.  Someone asked about it and the presenter
>mentioned the SBI (Set bit in IO Reg) and CBI (Clear bit in IO Reg)
>instructions.  These do take 2 clock cycle, though.  So there the PIC
>beats the AVR.  Although, an AVR running at 1/2 the speed of a PIC would
>be able to handle the same rate of IO change as the PIC, courtesy of the
>1-clock-cycle-1-intruction-cycle mechanism.  I really wonder how they did
>that!?!


My experience on high speed bit-banging on the PIC was that at 4 mhz, it
needed
a NOP between bit changes, which adds even more time to it (of course).
I was told that this was because of "high capacitance or load" but all I'm
driving is a single cmos gate at the end of 0.4" if track.

Scoping the lines confirmed that the output bits were occasionally failing
to
change state as ordered, adding the NOPS into the straightline output code
solved the "missing bits"

The AVR can truly execute sequential bit operations without intervening
nops,
at 8 or 12 mhz.

Don't get me wrong, I'm not a processor bigot, I just use whatever suits the
job.
I do think though, that proponents on both sides have attempted to hide
their
various warts.

1998\05\18@160235 by David VanHorn

flavicon
face
{Quote hidden}

Very true, but in the pic you have to manually vector the int, checking
first that
it is in fact enabled, then wether it has occured (at least in the 84.)

They all got warts, and the marketing guys want them all to look like
princes.

:)

1998\05\18@214227 by Marc Heuler

flavicon
face
> >                in      sreg_save,SREG
> >                in      tmp,REGISTER
> >                andi    tmp,0xXX
> >                out     REGISTER,tmp
> >                out     SREG,sreg_save
> >                sei

Hm, another thing to add maybe is that on the AVR you can bit manipulate
LOW registers.  One is EEDR, which is free when you don't use the EEPROM
currently. I could have written, too:

               in      tmp,REGISTER
               out     EEDR,tmp
               cbi     EEDR,intbit
               in      tmp,EEDR
               out     tmp,REGISTER
               sei

It'll take one more cycle, but 1 general purpose register less (sreg_save).



But in the actual implementation I did define several literals (all
possible combinations) and did directly load them.  It consumed more code
space total, but less execution time as well as no status bits.

While the PIC offers more options for sneaky code, the AVR isn't boring too.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...