I am new to AVR micros (fair experience with PIC18F and PIC16F) and I have a few clarification questions for you when it comes to execution speeds. I am trying to learn AVR on my own, after having taken formal classes on PIC, so I am fuzzy on a few of the differences.

The way I understand it, PIC throughput can be calculated by taking 1/4 of the operating speed, since an instruction executes every 4 clock cycles. So if you are running a PIC at 12MHz from an external crystal it will be executing 3 MIPS, correct? And it will stay pretty much constant at 3 MIPS no matter what instructions are executing?

I am reading the AVR datasheet and to me it seems like they can run at much faster execution speeds, but not all the time. The way I understand it (which may be wrong), running an AVR with a 12MHz crystal will execute at "about" 12 MIPS. It seems to me that the reason AVRs can perform with better throughput is due to their optimized ALU. So in theory, if all the instructions were ALU instructions the AVR would execute at exactly 12 MIPS on a 12MHz clock. However, in reality the program is doing other stuff besides ALU operations so your real-world throughput will be somewhat less than the ideal 12 MIPS. Is this the right way of thinking about it or am I totally turned around? If this is correct, is there any possible way to estimate the average number of instructions per second the AVR is executing for timer counting? Or does it constantly fluctuate throughout program operation such that it is very hard to time correctly by counting cycles?

Sorry if I sound like a n00b but I have to start somewhere! Any insight/help/info/links/corrections are greatly appreciated! I have been googling and I'm hearing mixed things.

 

I think AVR divides the clock by a factor of 4 too. This is because I made a simple program to flash a LED without any delays between the instructions which turn on and off the output pin and the switching frequency was 2 MHz. I used the 8 MHz internal oscillator.

 

The AVR is 1 instruction per Clock on most instructions (see the Instruction Set Summary)

 

AVR is one instruction per cycle so running it on the same crystal will yield 4x the throughput of a PIC.

 

AVR is one instruction per cycle so running it on the same crystal will yield 4x the throughput of a PIC.

It never fluctuates then? It is a 1:1 ratio between oscillator speed and IPS no matter what operations are being performed? Thanks guys, this is helpful. I'm actually really excited to start designing with AVRs.

 

It never fluctuates then?

Some instructions are multi-clock instructions like RETI (Return From Interrupt) for instance is 4 clocks. But on average your throughput will be 1 MIPS per 1 MHz.

 

I think AVR divides the clock by a factor of 4 too. This is because I made a simple program to flash a LED without any delays between the instructions which turn on and off the output pin and the switching frequency was 2 MHz. I used the 8 MHz internal oscillator.

Do you have the assembly listing (or source) for this? SBI and CBI are 2-clock instructions

 

Do you have the assembly listing (or source) for this? SBI and CBI are 2-clock instructions

I don't have assembly.

What is SBI and CBI?

 

Ok I found what is SBI and CBI in the datasheet. Thanks for it Nanovate.

 

What are SBI and CBI? Just guessing they are "set bit I" and "clear bit I". If that is the case, the analogous PIC assembly instructions are BCF and BSF.

So, while PIC may divide the clock by 4 for its instruction cycle, most of its instructions, including bcf and bsf, take only a single cycle. Conditional instructions take 2 cycles.

How many other AVR operations take more than 1 clock cycle? Are there instructions that take more than two cycles?

John

 

The AVR have IN and OUT instructions which are single cycle and perform the same operation as SBI CBI.

How many other AVR operations take more than 1 clock cycle? Are there instructions that take more than two cycles?

Yes they are listed in the datasheet. But only the RETI and RET are 4 clocks. The rest are are mostly single and double clock instructions. There are a few branch instructions that are 3 clocks.

The larger 16-bit PICs like the PIC24 and dsPIC30 do not divide the clock down.

 

ahhh I see. So PICs just scale the clock in order to force every instruction to take 1 instruction cycle (except for a branch), whether they need all 4 clock cycles or not. And AVRs take the other route of letting each instruction take the minimum amount of clock cycles they need, and more complex instructions take more cycles. I can see the advantage of doing it the PIC way though, because counting instruction cycles would be easier that way (pretty much either 1 or 2 cycles). Counting cycles for timing reasons would be a bit more involved on an AVR but the advantage is you get much better throughput.

I think it's starting to make more sense. Thanks everyone!

 

The AVR is one clock cycle per instruction for all but a few of the more complex intructions.

hgmjr

 

AVR has around 130 instructions, PIC has 32... You need to use several instructions in PIC, to do some of the single cycle instructions on AVR... Then there are the registers...

Different strokes, for different folks. 32 instructions are easy to remember, but takes a little more work to get what you want. We rarely need the micro to run at full speed, or use all the hardware features. There really isn't much point trying to compare the two, both will handle similar tasks, and with a high level language, the programming isn't too different.

 

Don't take at face value the number of instructions for each MCU.

Many of the AVR's instructions are "particular case" of a more general instruction, which will assemble to the same binary code if correct parameter is specified for the more general instruction. So sometimes there can be at least two ways to assemble to the same binary code.

The instructions like (SEC CLC SEN CLN SEZ CLZ SEI CLI SES CLS SEV CLV SET CLT SEH CLH) are particular cases of two more general instructions of BSET and BCLR.

In PIC camp, they chose not to count these "pseudo" instructions like skpnz, bnc, .., which in effect just (btfsx STATUS,Z or C...) from their list of instructions(to show their set is small) while AVR gives the impression that their instruction set is rich and comprehensive.

 

There have been a number of "discussions" in the AVR Freaks forum (http://www.avrfreaks.net). (It sounds like drivers arguing the merits of a Ford vs. a Chevy.) I think the latest result was "It depends on what you want to do" and "General speed tests can be misleading."

Also, if a micro is not running fast enough, there will usually be a faster one available. Get familiar with both micros. Use the one you prefer.

--Rich

 

I think for most of what we do (simple controls, etc.), the hardware choice isn't that important: as Rich said, if one isn't fast enough, you can always find a faster one in the family.

what matters most for us is the availability of peer support (forums like this), and availability of quality tools at affordable prices.

I settled on PIC because they are most widely used by hobbyists, so there is a wide availability of places to ask questions and get sample code.

plus, you just cannot beat a free ide (microchips), or hi-tide/picc-lite from htsoft.

 

plus, you just cannot beat a free ide (microchips), or hi-tide/picc-lite from htsoft.

How about *free* C compiler support on the AVR line. MPLAB is good but if I don't have the money for a decent C compiler... And yes I know there are "student" and "trial" free versions of C compilers like picc-lite but they are limited and usually only support a small number of devices.

 

How about *free* C compiler support on the AVR line. MPLAB is good but if I don't have the money for a decent C compiler... And yes I know there are "student" and "trial" free versions of C compilers like picc-lite but they are limited and usually only support a small number of devices.

the latest picc-lite version i believe supports all devices but with limited code size (+ maybe other limitations. - see htsoft's website for sure).

for me, the lite version has been sufficient, most of the time. I direct also my mcu choices towards the versions that picc-lite and proteus support and I have had no problem with that approach.

then you can always use unlimited asm for free.

 

The AVR have IN and OUT instructions which are single cycle and perform the same operation as SBI CBI.

Yes, but to use IN and OUT instructions you need first to move a value to a register with the LDI instruction like:

LDI R16, 255
OUT DDRB, R16

Thus it takes two cycles too because LDI needs one cycle.