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

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC vs AVR'
2009\06\05@045713 by William \Chops\ Westfield

face picon face

On Jun 5, 2009, at 12:31 AM, Tamas Rudnai wrote:

> AVR is more modern architecture let's say and is great, however,  
> that 4x
> faster marketing stuff is not really true. That's only the MIPS they  
> are
> talking about (for example to add two 8 bit numbers in two RAM  
> locations
> storing the results in a RAM location takes almost the same time

Um.  I don't know that I can let that stand.  Presumably you're  
talking about the rather inefficient avr add sequence:
       LDS  R0, VAR1        ;2 cycles (4 bytes)
       LDS  R1, VAR2        ;2 cycles (4 bytes)
       ADD  R0, R1        ;1 cycle  (2 bytes)
       STS  R0, VAR3   ;2 cycles (4 bytes)
Compared to the PIC sequence:
       MOVF VAR1,w        ;4 cycles (2 bytes)
       ADDWF VAR2,w        ;4 cycles (2 bytes)
       MOVWF VAR3        ;4 cycles (2 bytes)
Is that about right?
Even supposing that "7 cycles" is "almost the same time" as "12  
cycles", this is a pretty misleading comparison.  I'd claim (with my  
AVR hat on) that if this was time-critical code, then the VARs would  
be stored in AVR registers (which are not present on PICs) instead of  
RAM (which would make it much faster - probably 2 cycles), and if the  
PIC code was going to match the 64k address range of VARn it would  
need additional instructions to handle banking and get slower.

(With my PIC hat on, I'd point out that MANY of the AVR peripherals  
are off "extended IO address space" where setting a bit in the  
peripheral takes one of those 4-byte 2-cycle instructions to read it,  
another cycle to set a bit, and another 4bytes and 2 cycles to write  
it back (and that's assuming you don't need it to be atomic) while  
MANY of the PIC peripherals can have similar sets done with a single 2-
byte 4-cycle instruction.)

There's a fair bit of ugliness hiding behind the AVRs "pretty"  
architecture, but I think the AVR speed advantage at a given clock  
rate is pretty real.  For most things.

BillW

2009\06\05@055430 by Tamas Rudnai

face picon face
Hi Bill,

On Fri, Jun 5, 2009 at 9:57 AM, William "Chops" Westfield <spam_OUTwestfwTakeThisOuTspammac.com>wrote:

{Quote hidden}

Actually I was more thinking about this:

> talking about the rather inefficient avr add sequence:
      LDS  R0, VAR1   ;2 cycles (4 bytes)
      LDS  R1, VAR2   ;2 cycles (4 bytes)
      ADD  R0, R1     ;1 cycle  (2 bytes)
      STS  R0, VAR2   ;2 cycles (4 bytes)
> Compared to the PIC sequence:
      MOVF VAR1,w     ;4 cycles (2 bytes)
      ADDWF VAR2,f    ;4 cycles (2 bytes)

which is like more "cheating" and "unfair" comparison (7 clock cycles vs. 8
clock cycles). What I wanted to point out is that MIPS is not everything.


AVR hat on) that if this was time-critical code, then the VARs would
> be stored in AVR registers (which are not present on PICs) instead of
> RAM (which would make it much faster - probably 2 cycles), and if the
> PIC code was going to match the 64k address range of VARn it would
> need additional instructions to handle banking and get slower.
>

That's correct, AVR is a register architecture while PIC is (almost) an
accumulator based one. "Almost" as the ALU can put the results back to the
RAM location, hence the name of "Working Register" instead of "Accumulator".
To be honest in a complex calculation gcc will optimize the use of the AVR's
registers (as long as the variable was not marked as volatile) so as an
average it is faster than PIC (I would not say that is 4x times faster
though, and with a higher power consumption as a trade off). Similar if you
are using time critical apps on PIC you can organise variables to be stroed
on the same bank or place them on the access RAM so you can dramatically
reduce the need of bank switching.

Anyway, couple of things I like in AVR:

1. The vector based interrupts
2. Port bit toggling capabilities
3. Extended instruction set (bit even more sophisticated than 18F)
4. Free gcc compiler without any limitations

Few things I like on PIC:

1. Very stable device and hard to destruct
2. Easy to get it in low, middle or high volume
3. Wide range of support including appnotes and piclist ;-)
4. MPLAB with MPSIM and debugger support (which has regression test
capabilities through stimulus files)

Tamas
--
http://www.mcuhobby.com

2009\06\05@140837 by Chris McSweeny

picon face
On Fri, Jun 5, 2009 at 10:54 AM, Tamas Rudnai <.....tamas.rudnaiKILLspamspam@spam@gmail.com> wrote:
> 4. MPLAB with MPSIM and debugger support (which has regression test
> capabilities through stimulus files)

What's wrong with AVRStudio?

2009\06\05@142042 by Tamas Rudnai

face picon face
On Fri, Jun 5, 2009 at 7:08 PM, Chris McSweeny <cpmcsweenyspamKILLspamgmail.com> wrote:

> > 4. MPLAB with MPSIM and debugger support (which has regression test
> > capabilities through stimulus files)
>
> What's wrong with AVRStudio?


1. Simulator is really slow - only good for single stepping really
2. Does it have stimulus file capabilities? (if yes remove no.2 :-) )

Tamas
--
http://www.mcuhobby.com

2009\06\05@150246 by Isaac Marino Bavaresco

flavicon
face
Tamas Rudnai escreveu:
> On Fri, Jun 5, 2009 at 7:08 PM, Chris McSweeny <.....cpmcsweenyKILLspamspam.....gmail.com> wrote:
>
>  
>>> 4. MPLAB with MPSIM and debugger support (which has regression test
>>> capabilities through stimulus files)
>>>      
>> What's wrong with AVRStudio?
>>    
>
>
> 1. Simulator is really slow - only good for single stepping really
> 2. Does it have stimulus file capabilities? (if yes remove no.2 :-) )
>
> Tamas

Also some (important) peripherals not simulated .
I once needed to simulate a fast PWM in an ATTiny25 and the simulator
didn't work.

Regards,
Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\05@163605 by Chris McSweeny

picon face
On Fri, Jun 5, 2009 at 7:19 PM, Tamas Rudnai <EraseMEtamas.rudnaispam_OUTspamTakeThisOuTgmail.com> wrote:
> On Fri, Jun 5, 2009 at 7:08 PM, Chris McSweeny <cpmcsweenyspamspam_OUTgmail.com> wrote:
>
>> > 4. MPLAB with MPSIM and debugger support (which has regression test
>> > capabilities through stimulus files)
>>
>> What's wrong with AVRStudio?
>
>
> 1. Simulator is really slow - only good for single stepping really
> 2. Does it have stimulus file capabilities? (if yes remove no.2 :-) )

Yes, though not as good as MPLAB. Have to admit I've not noticed any
speed issues - I've been doing far more than single stepping - just
had a test with my current project and 6s for 160,000 cycles on a
1.83GHz Core 2 Duo. Don't know how that compares to MPLAB (not got it
installed on this computer). My judgement on this may be clouded since
I ran/run MPLAB on older slower computers, but it's certainly not
unusable as you seem to suggest. This is of course with AVR Simulator
2 - which does perform much better than the original.

It does have problems with some peripherals - USI output doesn't work
properly, though that's not a huge issue. Don't know about Fast PWM -
I have a project using that, but what exactly are you wanting to see?
Given it goes faster than the system clock, it's not exactly possible
to see exactly what's happening (I'll note that you can't simulate
Fast PWM on 8-pin PICs either ;-))

Chris

2009\06\05@171634 by Tamas Rudnai

face picon face
On Fri, Jun 5, 2009 at 9:36 PM, Chris McSweeny <@spam@cpmcsweenyKILLspamspamgmail.com> wrote:

> Yes, though not as good as MPLAB. Have to admit I've not noticed any
> speed issues - I've been doing far more than single stepping - just
> had a test with my current project and 6s for 160,000 cycles on a
> 1.83GHz Core 2 Duo. Don't know how that compares to MPLAB (not got it
>

On my Linux box (core2 duo 2.20GHz) with VirtualBox and XP I just run it for
5.5s, the result is 27.6 million cycles...
And it still supports the VHDL style stimulus, however, in this test I did
not put any on it.

Some may can argue of the validity of using simulator but I used it quite
heavy especially when dealing with DSP algorithms (I can even single
stepping while still working on the same signal on the single moment of
time).

Tamas
--
http://www.mcuhobby.com

2009\06\05@175536 by Tamas Rudnai

face picon face
On Fri, Jun 5, 2009 at 10:16 PM, Tamas Rudnai <KILLspamtamas.rudnaiKILLspamspamgmail.com>wrote:

> On Fri, Jun 5, 2009 at 9:36 PM, Chris McSweeny <RemoveMEcpmcsweenyTakeThisOuTspamgmail.com>wrote:
>
>> Yes, though not as good as MPLAB. Have to admit I've not noticed any
>> speed issues - I've been doing far more than single stepping - just
>> had a test with my current project and 6s for 160,000 cycles on a
>> 1.83GHz Core 2 Duo. Don't know how that compares to MPLAB (not got it
>>
>
> On my Linux box (core2 duo 2.20GHz) with VirtualBox and XP I just run it
> for 5.5s, the result is 27.6 million cycles...
> And it still supports the VHDL style stimulus, however, in this test I did
> not put any on it.
>
> Some may can argue of the validity of using simulator but I used it quite
> heavy especially when dealing with DSP algorithms (I can even single
> stepping while still working on the same signal on the single moment of
> time).


Just tried out the same test with AVRstudio4. With the Simulator 2 I have
got around 600k instead of your measurements of 160k. With Simulator 1 it is
around 5 million cycles!

Also just found out that Simulator 1 has a Stimuli file facility (got knows
how many times I asked it in different AVR forums without an answer!). I
think the problem was that I was looking for "Stimulus" instead of "Stimuli"
so noone could find it on the Help (incl. me). To be honest I did not even
looking at in the Simulator 1 as for some reason I thought Simulator 2 must
be faster + has more features but I was obviously wrong on this...

Anyway, the Stimuli file is not as good as MPSIM's one as is far from a
VHDL, also it can deal only with PORTs, however, much better than nothing.

Thanks
Tamas

2009\06\05@181200 by Chris McSweeny

picon face
On Fri, Jun 5, 2009 at 10:55 PM, Tamas Rudnai <spamBeGonetamas.rudnaispamBeGonespamgmail.com> wrote:
> Just tried out the same test with AVRstudio4. With the Simulator 2 I have
> got around 600k instead of your measurements of 160k. With Simulator 1 it is
> around 5 million cycles!

Probably depends what peripherals you're running - that's with two
clocks, and USI shift register running - the 160,000 cycles is to my
timed interrupt.

Chris

2009\06\05@182258 by Chris McSweeny

picon face
Since the original point of this thread was about whether an AVR was
really 4 times faster than a PIC (more specifically with 8-pin
devices, at which point the issue with setting bits in extended IO
devices becomes moot - they're all within range of the 1 cycle IN and
OUT), I thought I'd have a look at some real code, where of course
with a AVR I'm making use of the 32 registers. Really not that
interested in rehashing the PIC vs AVR wars.

real AVR code (from current project - this is time critical):
; add time to total
ldi temp, 0
add tot0, timeL
adc tot1, timeH
adc tot2, temp
adc tot3, temp

; compare with max
cp maxL, timeL
cpc maxH, timeH
brge check_min
movw maxL, timeL

check_min:
; compare with min
cp minL, timeL
cpc minH, timeH
brlo set_fall_edge
movw minL, timeL

All single cycle instrs apart from brge/brlo if branch is taken, hence
13 cycles total

PIC code conversion:
movf timeL, w
addwf tot0, f
movf timeH, w
btfsc STATUS, C
incfsz timeH, w
addwf tot1, f
btfsc STATUS, C
incfsz tot2, f
goto check_max
incf tot3, f

check_max
; compare with max

Actually I can't be bothered to do any more and work out what to do
with the carry on the multi-byte compare (though it doesn't get any
better for the PIC - that single cycle movw takes 4 instructions on a
PIC). In any case, that's 10 cycles on the PIC for something which
took 5 cycles on the AVR, so I was actually being generous to the PIC
- the AVR is 8 times as fast.

I'll point out this isn't an example I've cherry picked to prove a
point, it's part of my time critical section in the code for which I
was selecting between 8-pin devices, which was the original point
where I said I went for an AVR as it was 4 times as fast.

Chris

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