AVR or PIC

[Mike - K8LH]

I'm a PIC "nut" but I admit I'm fascinated by what I've heard about AVR recently. Anyone have a recommendation for an AVR chip to start out with? What about the Butterfly for $20 (with LCD display and navigation switches)?

Mike

 

[Mindaugasu]

I think butterfly is a good start as it is well documented and pretty cheap tool.

 

[Nick9494]

The butterfly based on ATmega169 is good for a evaluation board to intoduce the AVR. The 169 has all sorts of fruit (peripherals) built into it as well to help explore. Some of the connections to the AVR are available on headers so you can hook up external circuitry as well.

The overall IO space model is common to all AVR's with the relevant locations only having an effect in the divice with the hardware present. This means code written for one type of AVR will run on any other providing it has the required IO hardware.

If looking at DIP style packages suited to the hobbyist, then the ATmega8 or ATmega8535 depending on how much IO you are after are good starting points. The older AT90S series that may still be available are also good parts that have been superceeded by their "mega" equivalents. The diferences are usually upgrades to peripherals and a hardware multiplier.

N.

 

[mbramwel]

hi guys,

I was just reading through the debate with interest. I personally use both AVR and PIC chips.

A site worth checking out with a FREE compiler for both the PIC and AVR chips is: https://www.mikroe.com/

They have C, Basic, Pascal for both the PIC and AVR. The 'FREE" version of the compilers are full featured but will only compile code up to 2k in size. More than enough to write some nifty programs. They support LCD, serial, eeproms, PS2 and a bunch of other devices. Their manuals are in full color PDF format and available for download.

I have no interest in the above company, just a happy 'FREE" user.

 

[Nick9494]

If you are looking for a basic compiler for the AVR then check out "BASCOM - AVR" by Mark Alberts at MCS Electronics.

https://www.mcselec.com/index.php?option=com_docman&task=cat_view&gid=73&Itemid=54

I've been using this for about 3 years now and watched it grow into what it is today. Can do all sorts of complicated stuff very quickly.

N.

 

[mramos1]

Also see bastoc.com (rvkbasic download). That is the one I have used for years. Works very well. Free for 200 lines of code, and low cost for the unlimited version.

 

[ronp849]

I used Pics for some while, (pre flash version), and changed over to use the Atmel 8pin flash devices. Flash devices were not available from Microchip at that time and Atmel devices did not use the annoying bank switching system. I started with assembler using Atmel Studio, (equivilent to Mplab), and then used 'C' with Codevision CvAvr.

I have not touched a PIC since - Interested to read Pics still have bank switching.

CvAvr is not a freebe for commercial use but there is a downloadable evaluation version available for free. The use of the Wizard to generate all the initialisation code has saved hours of work over the various projects.

There is a free compiler called WinAvr but I have never used it so I cannot make any comment.

 

[russ_hensel]

**broken link removed**

 

[Noggin]

For years and years I used only AVR microcontrollers, which made me into more of an AVR fanboy than I was allowing myself to believe that I really was. I recently moved to Texas and took on a job where we use PIC's 99% of the time.

The first PIC I started on was a PIC12. My boss (and only coworker) was out of town for a week and I couldn't get the environment to work so I started out using assembly on this guy. I've written assembly for AVR and didn't particularly like it, but it wasn't that bad. Assembly for PIC is TERRIBLE. Jesus christ... ONE working register? Bank switching? That kind of crap is rediculous. I was trying to compare some 10 bit numbers from the ADC. The high byte and the low byte were in different banks...

1. Read low ADC byte
2. Move to RAM
3. Change banks
4. Read high ADC byte
5. Do half a dozen shifts into and out of ram to figure out if this ADC reading was higher or lower than the previous one

The AVR has 32 working registers so little need to shift into and out of RAM so you save time there. The AVR is 1 clock per instruction while the PIC is 4 clocks per instruction. The devices such as PIC10 and PIC12 don't have PLLs, so the AVR is significantly faster since it doesn't have to do constant bank switches and shifts into and out of RAM.

Some of the higher pics (not including the PIC24, dsPIC, and PIC32) address the speed problem by adding in a PLL, but I think even these guys still only have ONE WORKING REGISTER. That is a PAINFUL limitation in assembly. Even in C its a terrible headache as it causes problems trying to do simple things.

A project I did recently was a PIC12 based device. It has to measure the frequency of pulses coming in on the analog comparator and output the same frequency but with a 33% duty cycle. The frequency ranges anywhere from 100Hz to 20Khz. The problem is that by the time it calculates the timer value for the output at 20Khz its already over a 33% duty cycle. It can't keep up. In the end, I settled for running TMR0 at 1/4 the speed of TMR1. On every pulse, move TMR0 to TMR1 and clear TMR0. Assert output until TMR1 overflows. At low frequencies, this results in a 25% duty cycle, but at 20Khz I'm looking at like a 65% duty cycle. There is no time to to do any calcs. Its just too dang slow at 2 MIPS. I think an ATTiny would be a much better device for this.

Also, the lower end PICs only have ONE INTERRUPT VECTOR. That means when you get an interrupt, you have to start looking at every interrupt flag to determine which on you have. Sometimes you have to look past that to figure out if the UART interrupt was due to a received byte or a transmitted byte. AVR gets an interrupt, and you're on your way to the correct vector.

Now, for PIC24 and up, the AVRs in my experience are not quite able to keep up. There are just a few features that the PIC has that I don't think AVR has yet. You can move peripherals around to the pins where you want them, a pretty doggone configurable internal oscillator, internal current sources for things such as capacitive touch sense....

As for PIC32, its not even fair to compare them to the AVR. If you're using a PIC32 you're in a different class of MCU.

 

[Mike - K8LH]

If you'd like to pass along more detailed specs' for that 12F' project in a PM, I would be happy to try and help. I'm not saying that you haven't done it the best way possible but sometimes another perspective provides insight or inspiration on how to take advantage of structure, hardware, or software in ways you may not have thought of.

Mike

 

[Noggin]

I appreciate the offer, but I think I'll pass. We've since moved on to projects for more important customers. If the end customer is not happy with the device then I may come back and take you up on it though. However, the end product, in my opinion, is snake oil and will have unmeasurable results. But, he's a paying customer....

 

[mramos1]

Noggin, tell us how you really feel..

I actually found the same thing. The PIC is like an Intel 8086/16 and a Moto 16xxx chips back in the 80s. 64K memory range, segment registers on the intel. I was like you have to be kidding. Motorola was much better.

But the IBM PC and Windows won on volume somehow (don't start on Operating Systems ).

For the PIC, there's a lot more for the hobby types on the web and a lot of small companies use them, I see them in pool controller, etc. I see a lot more AVR in commercial and other things.

I agree AVR is a far faster in speed and easier to program in ASM. But that's for me. But I have more PIC in the place than Atmels right now

I think it is all personal preference. If you are not using ASM they both program about the same.

 

[fermat7]

AVR seems more easier to proram... very fast ... software for free... Keep working with..!!