PIC vs. AVR

[Sauli Sarkka]

I keep hearing "you can do XXX and YYY with PICxxFxxxx" and so on, but hardly anyone seems to be using Atmel AVRs, such as the Mega or Tiny series. Is everyone really happy with coding in ASM or is there a free C environment available for PICs, such as AVR-GCC is for AVRs?

Why is PIC better than AVR? Why is AVR better than PIC? Please, explain..


-Sale

[Arthur P.]

Hey, don't forget the ARM7 and ARM9 processors ;)

I always like the discussions which have been going on since the 1970's that x is better than y. In the end all they do is count or compare 0's and 1's. Some designs have more ports of type a or b (input, output, analog to digital, digital to analog, pulse width modulation, etc). Some have more timers. But within each familly there's usually a couple which will do what you want it to do. More important than which is better are the questions:

a) What do you want it to do now and what do you want it to do in the near future (forget longer term; there'll be new processors to work with then)?
b) Is there an existing design which does what you want it to do and is there open source code for that design to start working with>
c) Are the parts easy to get in your area?
d) What's the maximum cost you want to incur for your design?
e) What processor do you have experience with already if any?

If for your design you can choose any of the main processor lines regarding designs and source code, then of course choose the fastest "supercomputer in a chip" with the most ports you can get for the same money.

[Acetronics]

Why is PIC better than AVR? Why is AVR better than PIC? Please, explain..


-Sale

Hi, Sauli

You speak finnish, I speak French, He speaks English, She speaks German ...

Which is Best ???

Each language has it's own subtilities ...

What means for you "nose to nose" with s/o else ???.

Here it doesn't mean something special ... :D

Alain

[clicky]

Spectrum 48 is better that Commodore 64
Amiga is better than Atari
Java than C#
AVR is better than Pic

LOL :D
(BTW Never had Commodore, Atari, never programmed in C# or coded for Pic O:) )

[Gary Warner]

I keep hearing that PIC's are some how not up to the challenges of today's embedded solutions, but I haven't seen them hold me back. If I had it to do all over again, the PIC might not be the choice I'd make, but having invested so much time in learning them, I don't see that much of a gain in starting all over again with a 'better' name-brand. Seems most of the time consuming problems in any PIC, AVR, ARM, etc. device is working with other devices (I2C, LCD, SPI, RS232, OneWire, etc.) and what they require to make things work right.

[rmteo]

Also, there are PIC's and then there are PIC's. Oftentimes, when PIC is mentioned, reference is made to low end devices with limited peripherals and performance characteristics. For example, here is some data on a high end PIC:

Program Memory (KB) - 256 Flash
RAM Bytes - 16,384
Digital Communication Peripherals , 2-UART, 2-SPI, 2-I2C
Capture/Compare/PWM Peripherals - 8/8
PWM resolution - 16-bit
Timers - 9 x 16-bit 4 x 32-bit
Number of I/O Pins - 85

DC – 40 MIPS (40 MIPS @ 3.0-3.6V, -40°C to +85°C), 80MHz clock
16-bit wide data path
24-bit wide instructions
Linear program memory addressing up to 4M instruction words
Linear data memory addressing up to 64 Kbytes
8-channel hardware DMA

118 interrupt vectors
Up to 61 available interrupt sources
7 programmable priority levels

Analog-to-Digital Converters - 10-bit, 1.1 Msps or 12-bit, 500 ksps conversion
Up to 32 input channels with auto-scanning

Timer/Counters, up to nine 16-bit timers
Can pair up to make four 32-bit timers
16-bit capture input functions
16-bit Glitchless PWM mode

[newhackerflyer]

:) :rolleyes: ;)

[Sauli Sarkka]

This wasn't supposed to be a definitive answer to the question of closing down one factory and putting all investments into another.. ;)

I was just looking at development costs, hardware costs, easy of development/programming, etc. from a hobbyist point of view..and I still didn't get an answer regarding a C (or BASIC for that matter) compiler for PIC. I ask, because I don't know and I personally think that coding in ASM isn't that much fun, if there's an option to use a higher language that is easier to use. I'm also assuming that more people are already familiar with BASIC or C than ASM.

That high-end PIC mentioned before sounds interesting. What's the model number?


-Sale

[rmteo]

There are "C" compilers (as well as BASIC and PASCAL) here:
http://www.mikroe.com/en/compilers/

Also some useful development boards.

Device mentioned above is a PIC24HJ256GP610. More info here:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en024693

[Sauli Sarkka]

249 bucks for a C-compiler? For a hobbyist, I'd say OUCH, but then again, it's just a tool and tools cost money. Is there anything on the freeware side of things as far as C and/or BASIC for PIC?

PIC24HJ256GP610 is pretty nice, but one feature that's not so great: a 4 mA max sink rate on digital I/O-pins, so driving something as simple as a regular LED needs an additional transistor and resistor. How about sourcing current from IO-pins? I didn't see a mention whether that's possible and if it is, how much current can be sourced from the pin. An 18-channel ADC is impressive for a 64-pin package, not to mention the 32-channel ADC on the TQFP 100 -packaged version.


-Sale

EDIT: typos

[quax]

....
Device mentioned above is a PIC24HJ256GP610. More info here:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en024693

We should talk about 8-bit standard devices. The PIC you mentioned is a new generation 16-bit device. The according new generation of AVR is the AT32UC3A0128 with 80 MIPS.

Don't 'compare apples with pears', as we say ;)

cul
quax

[mem]

When I got back into this hobby recently there were a bunch of projects that I wanted to build and I found lots of RC related code available for the PIC. The availability of a free C compiler and low cost of the chip clinched it and set out to design and build some stuff that was useful and fun.

But as my projects became more ambitious I found I became increasingly disenchanted with the arcane low level register and memory map stuff that was required by the PIC. It was starting to seem too much like work! So it stopped becoming fun and I stopped building stuff with it.

But a few months ago I read about a project (http://www.windmeadow.com/node/42) that interfaced a three axis accelerometer (a wii nunchuck) to an AVR with what looked like impossibly small amount of code using something called the Arduino environment. The hardware and software is all open source and after building an Arduino board (an Atmega168 with a USB interface and some connectors for IO), I had a prototype accelerometer driven joystick interfaced and working with my TX in a few days.

So I got hooked on this and have been an enthusiastic user ever since. If you want something that will get you up and running in C or C++ in next to no time I strongly recommend having a look at the Arduino site: http://www.arduino.cc/

[rmteo]

We should talk about 8-bit standard devices. The PIC you mentioned is a new generation 16-bit device. The according new generation of AVR is the AT32UC3A0128 with 80 MIPS.

Don't 'compare apples with pears', as we say ;)

cul
quax

It wasn't my intent to compare AVR's and PIC's - and which is better. Both can do the job. BTW, you are comparing a 32-bit AVR. A comparable PIC would be this:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2607
A 32-bit device with 122+ MIPS.

My point is that if you can get a 16-bit, 28 pin PIC for $2-3, then why not consider using it instead of an 8-bit device with far lesser capabilities.

[rmteo]

249 bucks for a C-compiler? For a hobbyist, I'd say OUCH, but then again, it's just a tool and tools cost money. Is there anything on the freeware side of things as far as C and/or BASIC for PIC?

-Sale

That is actually a very reasonable price for a C-compiler (the BASIC compiler is $149) when you compare it with others on the market. For hobby purposes, you can download a FREE demo version of any of their compilers (including nice manuals that run into hundreds of pages). The only limitation of the demo is that your code cannot exceed 2K. Looking at typical hobby projects, you may never reach that limit - so essentially you have your choice of a free C, BASIC or PASCAL compiler for just about any PIC device (PIC12/14/16, PIC18, PIC24/dsPIC).

They also have similar compilers for AVR and 8051 if you are so inclined.

[Sauli Sarkka]

The 2k limit is way too small..but with AVRs I use AVR-GCC. In Linux, I do things from the command line with the aid of Avrdude and in Windows, there's AVR Studio, that uses the same AVR-GCC -compiler. No limits on code size. Cost: $0.00 ;)

EDIT: While it's true, that comparing apples to oranges or pears tells us nothing, I was mostly looking at the 8-bit processors, that are more common in the hobby scene, but also widely used in commercial products.

Is it true, that 8-bit PICs need 4 clock cycles to execute a single instruction?

-Sale

[rmteo]

Is it true, that 8-bit PICs need 4 clock cycles to execute a single instruction?

-Sale

Yes, that is correct. However, there are 8-bit PIC's (PIC18FxxKxx) that operate at up to 64MHz, giving you 16MIPs.

The 16-bit PIC's need 2 clock cycles per instruction and operate at up to 80MHz giving 40MIPs.

Also, if you are just getting started, 2K instructions can do a lot. Another BASIC compiler with a free demo (only for PIC18 though) is here:
http://www.sfcompiler.co.uk/swordfish/
No limit on instructions - only RAM limited to 256 bytes.

[Sauli Sarkka]

How much current and at what voltage is needed when running, for example, a PIC18FxxKxx, at 64MHz?


-Sale

[rmteo]

At 64MHz, typical run current is 12mA at 3.0V (these are 3.3V devices). In sleep mode, current draw is 15uA - there are quite a few power management modes available in these newer devices.

[mike50]

The biggest difference for me, here in the USA, is that the AVRs that I want are usually unavailable. Just yesterday I wanted to buy some 20 MHz SMD ATTiny45's, but none of the distributors in the US has them. That seems to never happen with PICs.

Mike

[Capt. Quirk]

This wasn't supposed to be a definitive answer to the question of closing down one factory and putting all investments into another.. ;)

I was just looking at development costs, hardware costs, easy of development/programming, etc. from a hobbyist point of view..and I still didn't get an answer regarding a C (or BASIC for that matter) compiler for PIC. I ask, because I don't know and I personally think that coding in ASM isn't that much fun, if there's an option to use a higher language that is easier to use. I'm also assuming that more people are already familiar with BASIC or C than ASM.

That high-end PIC mentioned before sounds interesting. What's the model number?


-Sale

Do you even know how to program in "C", if not then BASIC would be a faster learn. Don't get caught up in specs, a "slow by the specs" BASIC STAMP will loop at the same rate as your MEGA MIPS MPU if the program is full of PAUSES in the program. The STAMPS powerful, because it's programming language allows you to finish a project faster, unless you are experinced.

All Parallax Compilers (Basic Stamp) are free. There is a PIC compatable called the SX, that is capable of 50MIPS, with a free basic compiler.

Parallax's top of the line mpu is their "Propellor", 8-32bit processors (8 tasks in parallel, instead of sequential like the PIC, AVR) on one chip and if you like #'s, it's rated at 160 MIPS. It has a C like compiller-Free.

If you need a free C compiler for a PIC, download the student version. It is a 60-day trial, but after the trial period is over, it continues to work. The only function you loose is is the ability to produce "Optimized Code" durring compiling.

[arocholl]

This question comes and goes a number of times already. There are no wrong answers on this thread, just the question is wrong.

Better for what?

Better for the hobbyst but for doing what?

If you don't qualify, nobody can help.

Nonetheless, in general terms, PIC is very good for hobbyst because of: free samples provided by Microchip (try to get that from Atmel, anytime), free compilers available for high end family (compiler is based on GNU C, only limitation of the "student" license is the optimizer gets disabled and you get larger code image in place), lot of KB available on the web.

[Sauli Sarkka]

I write code for AVRs in C, using AVR-GCC as the compiler and I was just wondering about the availability of development software for PICs, since they are similarly popular in the hobby scene.

That Parallax processor also sounds nice - but to say anything more would require one to look at the specs a little more closely.


-Sale

EDIT: typo

[Sauli Sarkka]

PIC is very good for hobbyst because of: free samples provided by Microchip (try to get that from Atmel, anytime), free compilers available for high end family (compiler is based on GNU C, only limitation of the "student" license is the optimizer gets disabled and you get larger code image in place), lot of KB available on the web.

True, that samples help hobbyists out a great deal. Atmel seems to be more critical in sending samples, but I actually got a handful of Atmega128s, some AT230RF86 chips a few weeks ago - as samples. However, the chips aren't going into just "hobbyist development", but for some larger projects at the university, so I assume that helped in getting the samples.

Free compilers are also available on Atmel's side, as far as the 8 to 32 bit systems go. As for ARMs, I don't recall what the exact situation with them is..but that's a completely different world.


-Sale

[arocholl]

I write code for AVRs in C, using AVR-GCC as the compiler and I was just wondering about the availability of development software for PICs, since they are similarly popular in the hobby scene.

That Parallax processor also sounds nice - but to say anything more would require one to look at the specs a little more closely.


I see, so if your question is more on the C development tools side: it is a common believe that AVR free GCC compiler is very good for hobbists. There is nothing equivalent in the PIC world (a completely free C compiler with all GCC features) except, C18 and C30 compilers from Microchip that have the "GNU part" completely free, whereas the optimizer is not free.

In the ASM world, both AVR and PIC provides similar tools for free.

For Atmel you also have more simple things, free, such as Wire+Arduino, such a thing doesn't exist for PIC either.

[quax]

This question comes and goes a number of times already. There are no wrong answers on this thread, just the question is wrong.

Better for what?

Better for the hobbyst but for doing what?
.....

Yes, in deed, Sauli Sarkka please tell us your aim, then we can argue.

cul
quax

[westfw]

[AVR has] Wire+Arduino, such a thing doesn't exist for PIC either.
Arduino is something of an answer to things like the parallax Basic Stamp, and
"PICAxe", and several other "easy" PIC development systems of various cost and ease of use. They aren't quite exactly the same, but they're somewhat comparable...

The PIC is not a very friendly processor for C. Several commercial C compilers for PIC have free "limited" versions that may or may not be acceptable. (you said 2k code was not enough, whereas the PICs I like best have less than 2k of room for code anyway...) And there are other languages, sometimes including completely free compilers (JAL comes to mind.)

I would say for writing large programs in C, you might as well stick with AVRs. That tends not to be the "application space" where people like to use PICs.

[thanhTran]

Last time I wrote something in C for PIC using free version of HiTech C compiler which offers 2KB limit. Even with my basic & simple prototype, I kept running out of code space. I redid the project in AVR with WinAVR, and I felt like it never ran out of code space even I included printf() in the Atmel code for UART printing and I kept expanding the functions of the project (altitute, amp, voltage logging via bluetooth). The PIC I used was 16F877, and the Atmel was Mega16L. Maybe the HiTec complier doens't do good job and offers only 2KB. The thing I like about PIC's is that their documents are much easier to understand, and it's easy to implement something from reading their datasheet. With Atmel, it just seems harder to get things done right. Maybe I've spent more time learning PIC than I've done with AVR. Lately, I felt like I want to learn ARM. Texas Instruments also has many interesting MSP430 and they have tons of application notes available at their website.

Just my experience

Thanh

[arocholl]

Arduino is something of an answer to things like the parallax Basic Stamp, and
"PICAxe", and several other "easy" PIC development systems of various cost and ease of use. They aren't quite exactly the same, but they're somewhat comparable...


You are right they are comparable in features and easy of use, although Parallax and BasicStamp are more powerful environment so far, as they are commercial platforms.

But they are not comparable in price: Arduino is free. For a hobbist that may be a big difference.

[Peter Seddon]

When I was debating which 'horse to back' AVR or PIC the things that swung me were:
All Mega and Tiny AVR's are in circuit programmable
I wanted to programme in Basic as I never got my head around all those curly brackets and so PICBasic or Bascom were the alternative Basic compilers. Bascom won because at that time it was much cheaper.

Do I regret my choice - no, not yet at least, and I have been using Mega16, 32 and 64 processors.

my tenpenn'th.

regards Peter

[AndyKunz]

Maybe the HiTec complier doens't do good job and offers only 2KB.

Remember, you are working with a demo version there.

The "real" version supports the full chip memory (I have 128K chips with only a few bytes spare) and has the best optimizer of all the various PIC C compilers. I've been using Hitech since before it was released and I still love it (vs. the CCS that I couldn't wait to get rid of after a couple months).

You get what you pay for ;)

Andy

[Malc C]

All Mega and Tiny AVR's are in circuit programmable


As are most flash based PICs :)

To be honest, we could argue (Discuss :rolleyes: ) the pro's and con's of each type until we are all old and grey, but the bottom line is that its all down to personal preference. This personal preference will be based on several factors which we would all place in different levels of importance as we are all different and live in different parts of the world (the example of availability of AVR's in some parts of the world for example might play a major factor in the choice of direction).

The fact is that there is no clear winner. At the end of the day for us hobbiest (or professionals for that mater) you will be able to do the same job with either device platform.

[clicky]

OK - but I bet that there are people with extensive knowledge in both or at least in each separately.

Could each side, please, state strengths of each type of product (PIC/AVR) and historically preferred fields of application of each?

Could same go with dev. envs/IDEs/compiler-assemblers, etc?

Let me, kind of, start: somehow(*) it looks like to me that some people (visibility from my side desided it nothing else - but ignorace O: ) - preferred AVR for ESCs (due to PWM? earlier PVM implementation, easier? no idea O: )

(*) see my hesitation to make bold clear statement? No? LOL

[Malc C]

Could each side, please, state strengths of each type of product (PIC/AVR) and historically preferred fields of application of each?

Could same go with dev. envs/IDEs/compiler-assemblers, etc?



Why !

This is like saying "how long is a length of string", and would require someone with extensive knowledge of *all* PICs and AVR (either that or spend days reading every datasheet and being able to understand them ;) and most of us don't have the time to do that for you )

You would be better off asking what would suit a particular project (eg data recorder, ESC etc,) and then discussing the pro's and cons between suggested PIC and AVR for aspects of that project.

[arocholl]

OK - but I bet that there are people with extensive knowledge in both or at least in each separately.

Could each side, please, state strengths of each type of product (PIC/AVR) and historically preferred fields of application of each?



Futile.

Better use that time to master one of them, either PIC or AVR. All the opinions will be biased.

[clicky]

Ah, I was, really, really hoping to get some superficial, light, not so serious 'it is good for this because...' rather than serious study!

Why AVR is used for ESCs rather than PICs? ;)

[Gary Warner]

Ok, I'll bite.

I think PIC's are the BEST because I DON'T use anything else.

Is that "superficial, light, not so serious" enough?

Ignorance = bliss ;)

[quax]

....Why AVR is used for ESCs rather than PICs? ;)
Because 8-Bit AVRs are faster than 8-Bit PICs and have a better interrupt strategy.

This is also the reason, why more and more the C8051F330 of Silicon Laboratories, Inc. replaces the AVR in ESC applications.

cul
quax

[clicky]

8051! And I thought I finally got the right route away from old 8031 technology... Eh... LOL

[thanhTran]

Remember, you are working with a demo version there.
...
You get what you pay for ;)

Andy

WinAvr is free and is much better for what I need. The professional version of Hitec C would cost too much for hobbyist. I wouldn't buy it for hobby and wouldn't stick with PIC forever to buy HiTech C for it while there are better choices out there.

I think the PIC with its architecture requiring the use of working register "w" making it have bigger code size (more instructions for some simple tasks).

Thanh

[Crashaholic]

The biggest difference for me, here in the USA, is that the AVRs that I want are usually unavailable. Just yesterday I wanted to buy some 20 MHz SMD ATTiny45's, but none of the distributors in the US has them. That seems to never happen with PICs.

Mike

My experience has been different than yours. Have you tried Digi-key and Mouser? Between the two, I have never had a problem with availablilty. Digi and mouser both have the parts you are talking about in stock right now.

BTW, I am an AVR and SAM7 user myself. I like the Atmel parts. For the hobbyist, the IDE Atmel provides along with GCC (via WinAVR install) is awesome because it is fairly solid and free. The support over at AVRfreaks is a great resource too. One thing that I really like about the Atmel line is that you can move from the ATTiny's all the way to their ARM9's and the development path "feels" the same.

[BushmanLA]

I use PICs because that is what I got started with.

Here is what I like about them. I can't say if the AVR does any of these things better or worse, just that the PIC does them enough to make me happy.


1. Selection. There are a huge number of PIC's to choose from, and Microchip has done a fairly good job of making it easy to know them all once you know one of them. There is usually a PIC that will fit your needs, and then there are PICs that tend to be a good general use microprocessor.

2. Lots of on chip hardware. USART, I2C, AD converters, comparators, on chip oscillators, etc. etc. etc.

3. Speed. Pics are fast enough. Though it is my understanding that AVR's have the PIC beat when it comes to raw instruction throughput.

4. Robustness. PICs are pretty tough. I've abused them pretty bad and they often keep on ticking.

5. Support. Lots of support in the form of libraries from microchip and third party compilers. Lots of free samples. Lots of general examples from other people using PICs.

[pldaniels]

Just something for you to all note about the AVR's, specifically the tiny13, 25/45/85 set, do not use them with their internal RC oscillator if you're wanting clock jitter to be less than 0.5%. A while ago I lost about half my hair nailing down a jitter issue and it turned out to be the internal RC clock and it's something that occurred because Atmel went for a smaller die area + lower power consumption selection rather than 'clock stability'.

If you want a stable RC option, go with the 24/44/85 tiny's as they're better in that respect (as per Atmel's advice).

(Some people will suggest using a crystal for a stable clock - this is quite true but not an explicitly suitable option for something like a tiny13 based circuit on a small board for a few reasons).

Anyhow, that warning aside, I still use AVR's almost exclusively and gobble through about 100~200 a month.

Paul.

[vintage1]

I have no opinion here, except to say that it reminds me of the old days of 'is a 6502 better than an 8080, and is the 6809 The One True Solution?

To be honest, it depended on how you programmed them..I always liked lots of registers in Assembler..but they tended to get in the way of a simple C or Pascal compiler. Using stack based variables..At least one C compiler I used on an 8080 simply ignored most of the registers.

I can't believe that a modern PIC type chip has just about all you need to replicate a home computer of the 80's..Or how memeory and cycle intensive modern code is. When you think what 64K or RAM could do under CP/M..sigh..

[Crashaholic]

If you want a stable RC option, go with the 24/44/85 tiny's as they're better in that respect (as per Atmel's advice).

Very true. The overall accuracy of the AVR clocks is pretty bad out of the box as well. I will check the others out. Thanks for the tip.

[clicky]

I was, somehow, aware that this question is not really new one and hoping that someone will dig out a link to previous rcgroups discussion about it, but nothing yet...

This is what I have accidentally stumbled across :

http://www.rcgroups.com/forums/showthread.php?t=552589

Even title is better! :rolleyes:

[pldaniels]

Very true. The overall accuracy of the AVR clocks is pretty bad out of the box as well. I will check the others out. Thanks for the tip.

No problem - took me 4 weeks of gnashing and thrashing to finally get the details out of Atmel - the trouble is/was that they don't have any spec relating to a cycle-to-cycle jitter in the datasheets, so it means that it's dangerous to develop a product around them if you're depending on a particular level of stability.

My products were various servo-pulse generators and that > 0.5% (~5,000ppm) jitter meant that the servos would murmer, jump and twitch despite the best of my attempts.

[mike50]

No problem - took me 4 weeks of gnashing and thrashing to finally get the details out of Atmel - the trouble is/was that they don't have any spec relating to a cycle-to-cycle jitter in the datasheets, so it means that it's dangerous to develop a product around them if you're depending on a particular level of stability.

My products were various servo-pulse generators and that > 0.5% (~5,000ppm) jitter meant that the servos would murmer, jump and twitch despite the best of my attempts.
Are you saying that the clock changed by more than 0.5% over the time scale of servo jitters? (ie. less than 1 second?)

So if you had the AVR in a loop (with interrupts disabled) putting out a constant pulse of (lets say) nominally 1.5 ms, servos jitter?

I understand that there is much more opportunity for jitter on input, where it is uncertain when in the loop the input will change state, but for a constant output (only as variable as the CPU clock) the signal should be much more stable.

Mike

[arocholl]

My products were various servo-pulse generators and that > 0.5% (~5,000ppm) jitter meant that the servos would murmer, jump and twitch despite the best of my attempts.

I do not think a servo will jitter by a 0.5% change in the pulse width, this is not true in my experience. There may be a different reason, such as not limiting peak current with a 220ohm or so resistor in the signal connection to the servo, or if your code sent a pulse in the wrong place 0.5% of the times, which is a different story.

[Crashaholic]

Mike, I dont think he is saying that the clock drifted 0.5%. I think he is saying the cycle to cycle accuracy (jitter) had 0.5% uncertainty. Most likely due to a fairly poor implementation of the PLL. Since the servos look at pulse duration for position, and the MCU's clock is used to determine how long this pulse should be, there could be a bit of jitter on the output, causing the servos to jitter.

But tell me where I go wrong here...
Lets assume you are using a 1MHz clock. A 0.5% variabilty gives you 50ns variability for each pulse. "Center" output for the servo is 1.5ms. Are you saying that the 1.5ms +/- 0.00005ms caused the servos to jitter?

One of the worst things about the AVR's is the internal clock. The factory cal is only guaranteed to be accurate to 10% which is terrible and with a user cal is only guaranteed to within 1% (and that is at a fixed Vcc and temp). They drift quite a bit over temp and Vcc. I have even had some that I couldnt cal to the 1% that Atmel states.

[Sauli Sarkka]

It's true, that AVRs aren't swiss-precise with their internal clock. The easiest answer is an external clock - so far it hasn't proven to be a huge problem. Are PICs really that much more stable and accurate when it comes to internal clocking?

(These the types of questions and answers I was looking for. Specific details regarding hardware and architecture in general between the two systems - not a "my god is better than your god" -discussion.)


-Sale

[mike50]

Originally Posted by mike50
The biggest difference for me, here in the USA, is that the AVRs that I want are usually unavailable. Just yesterday I wanted to buy some 20 MHz SMD ATTiny45's, but none of the distributors in the US has them. That seems to never happen with PICs.

Mike

My experience has been different than yours. Have you tried Digi-key and Mouser? Between the two, I have never had a problem with availablilty. Digi and mouser both have the parts you are talking about in stock right now.

BTW, I am an AVR and SAM7 user myself. I like the Atmel parts. For the hobbyist, the IDE Atmel provides along with GCC (via WinAVR install) is awesome because it is fairly solid and free. The support over at AVRfreaks is a great resource too. One thing that I really like about the Atmel line is that you can move from the ATTiny's all the way to their ARM9's and the development path "feels" the same.

When I posted, on April 6 (ten days ago), neither Digikey nor Mouser had that part and both were giving delivery dates of May 30.

Mike

[mike50]

It's true, that AVRs aren't swiss-precise with their internal clock. The easiest answer is an external clock - so far it hasn't proven to be a huge problem. Are PICs really that much more stable and accurate when it comes to internal clocking?

(These the types of questions and answers I was looking for. Specific details regarding hardware and architecture in general between the two systems - not a "my god is better than your god" -discussion.)


-Sale
I have used low end PICs (using 4MHz internal clocks) to generate RC servo control pulses and they are rock solid. I am surprised that any of the AVR chips vary so much over a short time that they would produce servo control pulses that would get outside any of our servos deadband to produce jitter.

Mike

[quax]

I have used low end PICs (using 4MHz internal clocks) to generate RC servo control pulses and they are rock solid. I am surprised that any of the AVR chips vary so much over a short time that they would produce servo control pulses that would get outside any of our servos deadband to produce jitter.

Mike

What is "rock solid" and what is "vary so much"?

Without knowing the absolut difference from destination clock, it is impossible to compare these statements.

cul
quax

[mike50]

Mike, I dont think he is saying that the clock drifted 0.5%. I think he is saying the cycle to cycle accuracy (jitter) had 0.5% uncertainty. Most likely due to a fairly poor implementation of the PLL. Since the servos look at pulse duration for position, and the MCU's clock is used to determine how long this pulse should be, there could be a bit of jitter on the output, causing the servos to jitter.

But tell me where I go wrong here...
Lets assume you are using a 1MHz clock. A 0.5% variabilty gives you 50ns variability for each pulse. "Center" output for the servo is 1.5ms. Are you saying that the 1.5ms +/- 0.00005ms caused the servos to jitter?

To cause enough variation in 1.5ms to cause jitter (probably need to vary by at least 2 microseconds to get outside the deadband) it can't be due to a single cycle off by 0.5%. And random variation will all cancel out over thousands of cycles. It has to be drift. And to keep the clock from speeding up (or slowing down) forever, the drift has to be random, but over larger timescales (like maybe 10's of milliseconds)


One of the worst things about the AVR's is the internal clock. The factory cal is only guaranteed to be accurate to 10% which is terrible and with a user cal is only guaranteed to within 1% (and that is at a fixed Vcc and temp). They drift quite a bit over temp and Vcc. I have even had some that I couldnt cal to the 1% that Atmel states.
Microchip quotes 1% factory calibration at a fixed temperature. They drift with temperature too, but drift with temperature is slow. For many of the RC applications the absolute accuracy and drift with temperature are not really important. Especially if you are doing something like a mixer, reverser or slow down device. In those cases you are measuring an input from the receiver and producing an output based on that measurement. In that case the absolute accuracy is not relevant. If the clock drifts it affects the input as well as the output and they cancel out. But short term (measured in 10's to 100's of milliseconds) drift of the clock will cause jitter.

I've found that it is uncertainty of the input measurement that is usually the most significant problem. Output is as stable as the CPU clock, but input has that uncertainty and the much larger uncertainty of the number of cycles in the loop used to detect the change on the input. But you can use software averaging to correct for the input uncertainty.

Mike

[Crashaholic]

To cause enough variation in 1.5ms to cause jitter (probably need to vary by at least 2 microseconds to get outside the deadband) it can't be due to a single cycle off by 0.5%. And random variation will all cancel out over thousands of cycles. It has to be drift. And to keep the clock from speeding up (or slowing down) forever, the drift has to be random, but over larger timescales (like maybe 10's of milliseconds)

I completely understand that and that is why I asked the question. I didnt understand why the servo would be twitching since he was talking about clock jitter and not drift.

For many of the RC applications the absolute accuracy and drift with temperature are not really important.

Very true. Unfortunately, for some of the things I have worked on, it has been a killer and required using an extrenal clock. Example is an RS-232 servo controller. Where is center again ;)

[Sauli Sarkka]

Example is an RS-232 servo controller. Where is center again ;)

Join the club..not to mention baud rate issues.

Why else would they make 14.7456 MHz (and in other 1.832 MHz multiples) xtals..? ;)


-Sale

[mike50]

What is "rock solid" and what is "vary so much"?

Without knowing the absolut difference from destination clock, it is impossible to compare these statements.

cul
quax
When I said "rock solid" I meant that the servo being controlled by the pulse output from the PIC moves to the commanded position and then doesn't twitch, buzz, jitter or move in any way after that.

When I said "vary so much" I was commenting on pldaniels' statement that the ATTiny25/45/85 clock varied in such a way as to cause jittering of a servo.

Mike

[quax]

When I said "rock solid" I meant that the servo being controlled by the pulse output from the PIC moves to the commanded position and then doesn't twitch, buzz, jitter or move in any way after that.

When I said "vary so much" I was commenting on pldaniels' statement that the ATTiny25/45/85 clock varied in such a way as to cause jittering of a servo.

Mike

Again, it is also impossible to compare these statements. What software runs here and what software runs there. I'm quite sure, that servo jittering is a matter of software implementation. Let 10 people realize a servo control with the same controller and you will get 10 different results and half the realisations will produce servo jittering.

To say the truth: I'm quite sure, that that's the best controller, that you are familiar with. I solve all problems with AVR and you solve all problems with PIC - and that's ok. Both controllers are very good, there is no need for a hierarchy.

cul
quax

[mike50]

Again, it is also impossible to compare these statements. What software runs here and what software runs there. I'm quite sure, that servo jittering is a matter of software implementation.

Unlike some, I don't have any axes to grind here. My only objection to the AVR was my inability to buy them. I have certainly used them too.

pldaniels statement, that I was responding to, was that, regardless of software, the ATTiny25/45/85 clock was unstable enough to prevent ANY software implementation from providing jitter free operation. I was expressing my surprise that what he said could be true. If his statement is true, that the ATTiny25/45/85 internal clock is so unstable as to cause servo jitter, even with "perfect" software, then these statements are comparable. I know that it is possible to have absolutely no servo jitter using a 10F or 12F PIC's internal 4MHz or 8MHz oscillators. I would be surprised (as I said) if that couldn't be done with the ATTiny25/45/85 as well.


Let 10 people realize a servo control with the same controller and you will get 10 different results and half the realisations will produce servo jittering.

I understand your point, but that was not the issue being discussed. BTW, I believe that more than half will produce jittering, especially with high performance servos with tight deadbands.


To say the truth: I'm quite sure, that that's the best controller, that you are familiar with. I solve all problems with AVR and you solve all problems with PIC - and that's ok. Both controllers are very good, there is no need for a hierarchy.

I have no opinion on whether AVR or PIC is "better"...I've used them both effectively.

I will say that I prefer the PICs over AVR chips for making simply RC servo manipulation devices. This is because PICs read 2V on their inputs as 'one' for Vcc = 5V, while the AVR chips require 3V (0.6*Vcc) for Vcc = 5V.

The newer Futaba and JR receivers (and probably others) only have 3V pulses on their outputs (with 5V supply). That leaves no noise margin at all with AVR chips. You need an external buffer to amplify the receiver's signal before feeding it to the AVR to provide the necessary margin.

Mike

[Sauli Sarkka]

will say that I prefer the PICs over AVR chips for making simply RC servo manipulation devices. This is because PICs read 2V on their inputs as 'one' for Vcc = 5V, while the AVR chips require 3V (0.6*Vcc) for Vcc = 5V.

The newer Futaba and JR receivers (and probably others) only have 3V pulses on their outputs (with 5V supply). That leaves no noise margin at all with AVR chips. You need an external buffer to amplify the receiver's signal before feeding it to the AVR to provide the necessary margin.

Mike


BANG! Another one of those points I was wanting to hear, instead of "scr*w you, Atmel kicks Microchip's a$$!". :)

This discussion is going great IMHO, so let's keep things going. From an open-minded hobby-level project and application developer point of view, these small tidbits of information are genuinely interesting and useful.


-Sale

[mike50]

Of course, with the PICs not all input pins will read 2V as a one. You have to be careful because some of the pins have, so called, Schmitt Trigger inputs which require 4V (for Vcc=5V) to read as one. And some of the pins can be either depending on how they are configured.

As in many other areas, the AVR chips are more regular. All of the pins behave pretty much the same way.

Mike

[pldaniels]

Hi guys,

Didn't realise my jitter comments would stir so much.

First up, the idea that one jitter will be cancelled out by another and thus shouldn't manifest in a servo pulse variance, while a good theory, actually doesn't happen. Instead you find that you get jittering all the way up the time-scale. The jitter is the amount of variance in the clock on a per-cycle basis (as apposed to clock drift which is what Atmel does specify).

As for the suggestions that perhaps the circuit wasn't setup etc quite right, that isn't the case here (though it can manifest as well from a poorly setup circuit or things like interrupts).

Consider this, if a servo has a resolution of 200 "steps", then a 0.5% jitter will be enough to cause a servo to jump one step.

Anyhow, here's the response I got back from Atmel regarding the whole scenario


There is not much that can be done to this currently in the existing
MCUs. Older AVRs, like the Tiny26 has different rc osc topology, which is
much more stable, but that topology is several times larger in die area,
and consumes also maybe 10x the power if the current rc osc. Hence, the
choice has been for the current one, despite of the shortcoming with jitter.


All that said, I still use AVR's a lot - they're a wonderful architecture and it's quite easy to move up and down the scale (tiny's to mega's) as well as between chips. I merely bought up the jitter issue as it's something that could become relevant to a lot of people if they're in the R/C electronics field. :)

Paul.

[Crashaholic]

Consider this, if a servo has a resolution of 200 "steps", then a 0.5% jitter will be enough to cause a servo to jump one step.

The 0.5% variance in the cycle by cycle variance of the clock will not show up as 0.5% variance on a PWM output with such a long period when compared to the period of the clock. That is unless all of the clock cycles were at the +0.25 stage during one pulse width cycle and -.25 during the next. Highly unlikely.

[pldaniels]

The jittering is unpredictable by nature of course, a lot of the time it does indeed 'cancel out', though there are enough times when there's a sufficient 'run' of bias in one direction to cause a sufficient shift in the servo. Sometimes it takes a few seconds for it to happen, sometimes you'll get a run of jumps.

The trick is not to assume that the degree of the jitter is mirrored evenly around the desired value within a given finite timeframe. Over an infinite timeframe the jitter will of course statistically cancel out, however in shorter timescales (uS, mS and seconds) it's periodically manifests an offset from the desired central value.

I provided this information so as to save people from ripping their own hair out if they're using tiny13's or other similar tiny chips with the version 4.0 AVR clock engine.

This information isn't some "I think it could be" theory, rather this is something that has been shown in experiments, discussed with other Atmel AVR developers and confirmed by Atmel's own engineers.

Again, don't think that I am against AVR's... I personally highly prefer them against PICs but at the same time it's important to know the various limitations of the given architecture.

[pldaniels]

Highly unlikely.

But not improbable. ;)

What I suggest is that people go and get themselves a tiny13, rig it up, decouple it well, turn off all interrupts, turn off all 'optimisations' and run a simple pair of busy-wait loops to generate a 1500uS on and 18000uS off pulse train and watch the output on a scope or hook it up to a servo.

Or, if you just want to see the action, run a simple while loop with something like;

while (1) { PORTB ^= (1<<PB1); } // yes, this can be optimised - but it's left for clarity

[mike50]

What I suggest is that people go and get themselves a tiny13, rig it up, decouple it well, turn off all interrupts, turn off all 'optimisations' and run a simple pair of busy-wait loops to generate a 1500uS on and 18000uS off pulse train and watch the output on a scope or hook it up to a servo.

Or, if you just want to see the action, run a simple while loop with something like;
So, this implies that these ATTiny chips, running with the internal oscillators, really aren't as well suited for driving RC servos as PIC chips, whose internal oscillators are stable enough to avoid any jitter.

Mike

[pldaniels]

So, this implies that these ATTiny chips, running with the internal oscillators, really aren't as well suited for driving RC servos as PIC chips, whose internal oscillators are stable enough to avoid any jitter.

Mike

That's about the simplest summary, yes :)

The tiny24/44/84's are fine though as they have been manufactured with stability of the clock in mind. You can get tiny25/45's which are stable enough but you may have to go through a bit of a selection process to find the ones with sufficiently low jitter (something I have to do here for now).

I still use the tiny13's for a lot of products, however as a servo pulse generator, it's not strongly advised.

For things like ESC's, switches and other such items, they're perfectly good :)

Paul.

PS, here's a very short video showing the severity of the jitter on the tiny13, this is running the simple while(1) loop with nothing else enabled.

http://www.pldaniels.com/flying/videos/flash/playflash.html?video=jitter13

[Crashaholic]

What I suggest is that people go and get themselves a tiny13, rig it up, decouple it well, turn off all interrupts, turn off all 'optimisations' and run a simple pair of busy-wait loops to generate a 1500uS on and 18000uS off pulse train and watch the output on a scope or hook it up to a servo.

OK, now you have got me curious. What clock freq you want me to use 1 or 8 MHz? I will bring my scope home and test it out sometime soon. I have a stash of tiny45's I am using for lost model alarms.

[mike50]

Presumably the time scale on the video is a few microseconds per pulse and the jitter it shows is surely no more than a small fraction of a microsecond. It still seems surprising to me that this jitter would scale up to several microseconds in a span of a millisecond. But I don't doubt you've demonstrated that it does.

Mike

[pldaniels]

Crash,

Try at either frequency. I've used 8MHz and 1MHz. The tiny45's should be fairly/moderately stable, but if you can get a new tiny13 (recent batch), compare it to the 45 and you'll probably notice quite a difference.

There is some variance of the severity between chips, that is how we got caught out in testing here.


Paul.

[mike50]

When comparing the 8-pin ATTiny AVR chips with the 8-pin PIC chips, I think that the PIC12F683 has much better hardware features for the purpose of measuring RC servo pulses as input and for generating RC servo pulses as output than any of the 8-pin ATTiny chips.

The 12F683 has a 16-bit timer that can be gated by the output of the analog comparator to capture the input pulse time completely in hardware with a resolution of one instruction cycle (which is 0.5 microseconds using the 8MHz internal clock). The analog comparator has a variable voltage reference that allows setting the noise margin to whatever you want.

It has a Timer Compare unit which allows generating the output pulse, also with 0.5 microsecond resolution, using the 16-bit timer and the 16-bit match register. The start of the timer raises the voltage on the output pin and the match condition lowers the voltage on the output pin.

Using these facilities gives very good (0.5 microsecond) resolution with no dependency on software timing at all.

The ATTiny chips only have 8-bit timers and they cannot be gated by the input signal. You would either need a software loop to detect the change on the input, with resolution no better than the period of the loop, or by using interrupt on change to detect the start and end of the input pulse, with uncertainty in the interrupt latency (due, at a minimum, to the requirement that the current instruction complete before the interrupt is taken and that the interrupted code will contain instructions of different timings).

If the output is done with a software loop, it wouldn't have the uncertainty, but I don't think 0.5 microsecond resolution could be achieved (with the 8MHz internal clock).

Mike

[pldaniels]

Mike,

Actually, the tiny 24/44 has a 16 bit timer - it's what I'm moving my production over to.

The tinys like the 24/44 and 25/45 do have input-capture as well.

But yes, in terms of 8-pin tiny's Atmel really does need to make a 16-bit timer equipped one.

Paul.

Paul

[mike50]

Mike,

Actually, the tiny 24/44 has a 16 bit timer - it's what I'm moving my production over to.

The tinys like the 24/44 and 25/45 do have input-capture as well.

But yes, in terms of 8-pin tiny's Atmel really does need to make a 16-bit timer equipped one.

Paul.

Paul
I can't figure out how to do a hardware input-capture on the ATTiny25/45. I can see how to clock the timer externally, but I don't see a way to gate it. Although it is probably moot as, with only an 8-bit timer, it wouldn't have enough resolution for RC servo pulses anyway.

Mike

[pldaniels]

There is a way on the 25/45 - you'll notice they have two 8 bit timers, so you can synchronize them with the second one running at clk/256, then you use a pin-change interrupt to reset/read the clock value as a 16-bit composite value.

Yes, I agree, it's a hack ;) Which as I said before is why I'm going with the tiny24's which have the 16 bit timer + input-capture, so your servo pulse width is captured without having to do anything fancy.

Paul.

[mike50]

There is a way on the 25/45 - you'll notice they have two 8 bit timers, so you can synchronize them with the second one running at clk/256, then you use a pin-change interrupt to reset/read the clock value as a 16-bit composite value.
I see how the two timers could be used, but you still have the loss of resolution due to the uncertainty of the latency for the pin-change interrupt. I think that a two timer "hack" could be used to generate the output pulse with good resolution.


Yes, I agree, it's a hack ;) Which as I said before is why I'm going with the tiny24's which have the 16 bit timer + input-capture, so your servo pulse width is captured without having to do anything fancy.
Yes, the input-capture and output-compare units on the tiny24/44 work very nicely for this application.

Mike

[Crashaholic]

But yes, in terms of 8-pin tiny's Atmel really does need to make a 16-bit timer equipped one.

Yes! Seems that they are excluding themsevles from part of the market when the fix (new part) probably wouldnt cost them that much money. Atmel is kind of funny like that though. On their SAM7X series of controllers, many of the peripherals are all out of whack. I am sure that a few minor tweaks to the silicon would fix most of the problems yet they never release a rev B of anything. They just kind of move on.

[Ralph Weaver]

Since most of the development tools are pretty inexpensive, I just choose what ever processor makes the most sense for my project. I'm not a big fan of the PIC because of their architecture, but they get the job done. I really like the Freescale and the Renesas R8C and M16C.

I used the Renesas M32 one a project at work a few years ago and really like it. Once we did a small job where board space was not an issue so we laid it out to take either a PIC, AVR or Freescale. The volume was high and the software was simple so we just populated with the cheapest CPU at the time.

[pldaniels]

Ralph,

Always a good idea if you can do that, I love having board space to roam on... alas most/all the projects I've done to date have been rather the opposite :)

[Ralph Weaver]

That is the norm.

I am still surprised that more people don't look into the Freescale and Renesas and others as well. There are a lot of good alternatives to PIC and AVR. Maybe not quite so much support in the hobby world, but some of these have free professional grade development tools.

[AndyKunz]

I'm not a big fan of the PIC because of their architecture...

That's funny because ARM9 and ARM11 are more PIC-like than the previous generations, but ARM9/11 are "state of the art."

Andy

[pldaniels]

When it comes to the hobby side, it's understandable that a lot of people stay with a limited range of architectures, namely constrained by factors such as;
* availability at local stores
* community knowledge/support
* cost of development kits
* lack of compelling force to explore other architectures

As a commercial developer, the cost of developments isn't quite as hard to bare but it's still significant at times (getting a free chip alone doesn't really go very far when you find that all the supporting glue logic or software costs a fortune).

Avoiding diversification to prevent an excessive buildup of required on-hand stock and tools is another push.

Personally, I like to keep two or three architectures at hand, much like with software languages (for my other business). Beyond 3 things start getting difficult to manage and you can often find that there's a long lag in development as you 'ramp up' again using a system that you've not used for a few months.