PICvsAVRS Again(SORRY!)

[3v0]

Hey 3v0 are you telling me that i can put a 80MHz crystal/oscillators on a 20Mhz pic and have 20MIPS?

I did not say that.
A 20MHz pic that requires 4 clocks per instructions will only run a 5MHz because it is not a 20MHz chip, but a 5MHz chip.

This is due to an old marketing game that predates Microchip as I said in my previous post. Marketing types think they can sell a few more uC's if they rate and advertise using the clock speed instead of the processor speed. This distorts the numbers which in the long run works against them. In my world that 20MHz 18F88 would be listed as 5MHz. But it is not my world.

I also think the word free should never be used when the 'free' item or service is tied to anything non-free. I prefer the phrase "at no additional cost". Free should be without exception or condition.

3v0

 

[AtomSoft]

I did not say that.

Just use a 4X clock source

 

[3v0]

Just use a 4X clock source

You were talking about a chip marked 20MHz. By using a 80MHz clock
you would be overclocking the chip by 4X.

I edited my previous post.

 

[AtomSoft]

ok thanks and sorry about the confusion there. I know all about the 20mhz(clock)/4(clocks) = 5mhz (processor) i just thought when you said 4x clock source you where referring to the CLOCK it self. That is a drawback somewhat but not too much.

 

[Ubergeek63]

Do you have data to back up your claims? Microchip hit the 5billion PICs sold last year, they are very very cheap in quantity.
If you want some serious power far beyond any 8bit MCU Microchip offer the very fast and powerful 16bit PIC24F and the math capable dsPICs many can hit 40MIPs. Some PICs include USB & Ethernet built in.
Inexpensive tools like the PICkit2 or ICD series can program & debug can be had for less than $50 for a PICkit2

Hit the 5B mark...so what?

Microchip Technology Posts Record Net Sales for Fiscal Second Quarter 2009: Financial News - Yahoo! Finance

Net sales projection for 2008 based on double the last six months: one billion 74 million for the whole company. If we assume that 1/4 of that is for PICs and they all cost a dollar, which slants things tremendously in Microchip's favor, we get an annual sales quantity for PICs of 286 million.

ARM - The Architecture for the Digital World

From the ARM site we get an estimated figure of 90 per second or an annual sales quantity of two billion eight hundred thirty-eight million, or about ten times the unit QTY of PICs assuming they all cost a dollar, which we all know to be a lie of sorts.

As for developement kits there is the Luminary one for $50: EKT-LM3S811

 

[Noggin]

I used AVR's for 8 years and I've been using PIC for about 6 months now. There are advantages to using AVR's and there are advantages to using PIC. Lets assume for now that we are limiting this discussion to 8 bit PICs as AVR is only an 8 bit architecture.

The AVR has a VERY nice FREE optimizing compiler, AVR-GCC. There is a VERY active forum at avrfreaks.net at which the writers of AVR-GCC have a pretty strong presence. This means if you happen to actually find a bug, you can get one of the compiler coders to comment on it within a day or so without even having to PM him. In my 8 years of using AVR-GCC I can only recall one bug from the compiler. It caused a compiler crash, not a bad hex file. Changing optimization eliminated the error, and I never did narrow down on the cause.

For PIC, there are no free optimizing compilers. There are free trials for optimizing compilers though. In my six months of using PIC, I've found the Hi-Tech compiler to be riddled with bugs, mostly incomplete or just plain wrong header files. On one part the ADC wouldn't work which I narrowed down to improper bank switching. Oh, and there is no bank switching in AVRs. You can access any register at any time.

lIts been brought up multiple times that the AVR is faster in general due to most instructions being one clock cycle. Some people have suggested using a faster crystal to improve the speed, but not only does that take additional pins, but there is a limit to how fast it can go. Something that cannot be overcome is the fact that most if not all 8bit PICs have ONE working register while the AVR has up to 32 working registers. What this means is that the PIC will be swapping stuff in and out of RAM constantly. So, not only does it take 4 clocks to execute an instruction, it takes multiple instructions to add two numbers. load register, move register to ram, load register, add ram to register as compared to load register, load register, add register to register. So thats 16 PIC cycles vs 3 AVR cycles (some AVR instructions take more than 1 cycle, but I think loading a register and adding takes only 1).

Taking that thought a step further.... if you have a part with a tiny amount of flash and need to write assembly, the AVR is MUCH easier to work with due to the abundance of working registers (newer PICs have more registers, but I THINK they are 16 bit PICs).

AVR tools are generally cheaper. A cheap AVR programmer is $30, the ICD2 for PIC is about $50-$60 (I think there are cheaper PIC programmers though). The JTAG ICE for AVR is about $300 while the comparable PIC part is about $550.

The only benefit to using 8 bit PIC's over an AVR that I can think of right now is that the config bits for PIC are in the load file for PIC while the AVR's fuses have to be programed in a separate step. This makes production more reliable when a minimum wage person is performing the programming.

The 16 bit PICs are pretty nice though, but I HATE the documentation (and 32 bit documentation is worse). On some of them, you can move peripherals around to just about any pin you want, built in USB, high precision low current supplies, and in about a year some PICs will have a built in LCD driver with an RGB interface. There are no 16 bit AVR's for me to compare this to, but there are ARM based Atmel chips. However, I don't know much of anything about those parts, maybe they have some similar stuff, maybe not. All I know is that AVR in my book is far superior to an 8 bit PIC.

Edit: Now, its not exactly fair to exclude the 16 bit PICs as the price point is actually very nice and there are a lot of on board peripherials. You can get a lot of MCU for $4 and there are some good free libraries available for the PIC. The project I'm working on right now used to be based on a $4 PIC24 (16 bit PIC) and would drive a 256k color 320x240 LCD though it was a bit slow, but that slowness could be hidden. The graphics library was provided free from Microchip, I don't think Atmel has anything comparable for their AVRs.
If anyone can poke holes in what I've said, please do so.

 

[dknguyen]

How is the documentation so bad for 16-bit PICs vs 8-bit PICs (or AVRs for that matter?) I found little difference between the documentation for 16-bit and 8-bit PICs, and overall chose PICs because I like the documentation- it was certainly more straightforward when the first documentation I tried looking at was for a 68000.

However, if you are referring to needing the "Family Reference Manual" and the manual specific to the 16-bit PIC since they cover different things in varying levels of detail, I understand what you mean. YOu have to jump back and forth. If something seems to be missing then it's probably in the other manual.

 

[Wond3rboy]

Wow!!

Thanks every one!

 

[Noggin]

How is the documentation so bad for 16-bit PICs vs 8-bit PICs (or AVRs for that matter?) I found little difference between the documentation for 16-bit and 8-bit PICs, and overall chose PICs because I like the documentation- it was certainly more straightforward when the first documentation I tried looking at was for a 68000.

However, if you are referring to needing the "Family Reference Manual" and the manual specific to the 16-bit PIC since they cover different things in varying levels of detail, I understand what you mean. YOu have to jump back and forth. If something seems to be missing then it's probably in the other manual.

Yes, I wasn't clear on the documentation point. Needing the family reference manual is annoying to me, but the Atmel documentation in my experience gives a much more detailed description of what a bit in a register does. I was working with a PIC24HJ (or maybe a PIC24FJ) part and in one datasheet I came across the following problems:
1. Code examples that were wrong (bits were set up to not even turn on the peripherial as well as logic errors)
2. A bit description was "Enables IPMI" for I2C and I have no idea what IPMI is as it wasn't discussed in the PDF and the family reference manual didn't even have that bit listed as being in the register
3. The CTMU was described as being able to trigger an ADC conversion but it didn't say how to set it up and again the family reference manual didn't have the same bits in the registers here either

Now, I would be naive to claim that the Atmel documentation is perfect. It very well could be that when I started working with my first MCU I didn't know enough to know that the documentation was horrible and by the time I learned how to use one AVR I pretty much didn't need the documentation any more other than to see what peripherals were available. Same can be said for PIC though, learn to use one PIC of a family and you've got them all mastered of that family.

Edit: I should do my part as a user of PIC products and point out those mistakes, at least the code example, so that they can be corrected. Didn't think of that until just now.

 

[3v0]

Processor architecture and speed were much more important in the early days when many of our apps were pushing the hardware limits.

Most people program in C or other high level language. Currently I do so using the PIC18 family. There are several good compilers. I know the processor well enough to read the disassembly listing when there is a problem, but not anywhere close to fluent, nor do I want or need to be.

I do not care what the underlying processor is as long as it is fast enough. Peripherals, configuration, and even low power modes are more of a differential to me. Picking the uC that includes the right bits can simplify a design. That would account for the large number of variants Microchip has within each family.

You could fairly say that Microchip purchased my loyality (such as it is). Had someone given me free access to AVRs or Freescale uC's I might well be using them. That is providing the toolset was free and up snuff.

The one thing I am not addressing here is bang for the buck.

3v0

 

[Ubergeek63]

I do not care what the underlying processor is as long as it is fast enough. Peripherals, configuration, and even low power modes are more of a differential to me. Picking the uC that includes the right bits can simplify a design. That would account for the large number of variants Microchip has within each family.

It does... but it is not called for these days. If they would just throw in the kitchen sink the economies of scale would kick in...but then they could not justify what they are charging for them!