PIC versus AVR

mc wrote:

> I don't want to start a religious war, but could a few knowledgeable people 
> give me their impressions of the relative advantages of PIC vs AVR?  Assume 
> that I will be using both, to some extent, for some time, and want to know 
> what their relative advantages are.  Throw in MSP430 too if you'd like.
> 
> I'm mostly using PICs right now but am stuck on the fact that MPLAB requires 
> you to have write permissions in C:\Program Files (which we can't allow in a 
> big student lab with roaming profiles), and also, if you follow the 
> simplest, default path toward creating an ASM project, you run into a 
> 62-character length limit on the full path to the file.  Does AVR Studio 
> cooperate fully with normal Windows security practices, or does it, too, 
> require you to loosen security on the computer in order to run it?

Are you forced to install in C:\Program Files, or do you mean, you must 
have write permissions to the EXE host directory ?
( which is slack of them, if true )

-jg

On 2006-08-04, Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:
> On 3 Aug 2006 19:24:13 -0700, the renowned "steve"
><bungalow_steve@yahoo.com> wrote:
>
>>
>>larwe wrote:
>>
>>> All three - Proprietary single-source architectures.
>>
>>there are multi-source architectures?
>
> 8051 & ARM, for example. 

Except they aren't really multi-source.  For example, you're
using an ARM single-chip solution from vendor A.  It's not like
there's a drop-in replacement part from Vendor B: the
peripherals are all different from one source to th next.
Since all the work is in dealing with the peripherals, I find
almost zero benefit in switching to a second source with the
same core but a different set of peripherals.

-- 
Grant Edwards                   grante             Yow!  Are you still an
                                  at               ALCOHOLIC?
                               visi.com            

Jim Granville wrote:
> steve wrote:
> > larwe wrote:
> >
> >
> >>All three - Proprietary single-source architectures.
> >
> >
> > there are multi-source architectures?
>
> Oh yes :  80C51, ARMx, MIPs, C166, x86.....
>
> -jg

By multi-source I mean drop in replacement, pin-for-pin electrically
compatible, no code changes, I don't believe there are any modern
multi-source micro's. Silabs,Analog Devices, Atmel all make 8051's but
they make no attempt to standarized memory maps, modules interfaces,
pinouts, or even the most basic electrical characteristics etc, they
are all unique customized micro's.

A common core is not too helpful as modern high level languages already
makes all cores "psuedo common" (except for timing).

I rather have common memory maps, peripheral interfaces, electrical
characteristics and common pinouts with different cores, this way I
could just recompile. Yes not a true multi-source part, but it does
allow me a "chance" of just replacing the old chip with the new one
without redesigning my board (assuming all the timing/emi etc look ok).
 But obviously the amount of cooperation between companies to do this
would be mind boggling.

steve

Hi,

You have the FREESCALE famillies too :
8 bits :
====
68HC908
9S08

16 bits :
=====
9S12
9S12X

The IDE CodeWarrior is free up to 16Ko of C code on 8 bits famillies and 32 
Ko of C code on 16 bits famillies.

Yvan



"mc" <look@www.ai.uga.edu.for.address> a &#4294967295;crit dans le message de news: 
WMxAg.42352$Nt.39355@bignews8.bellsouth.net...
>I don't want to start a religious war, but could a few knowledgeable people 
>give me their impressions of the relative advantages of PIC vs AVR?  Assume 
>that I will be using both, to some extent, for some time, and want to know 
>what their relative advantages are.  Throw in MSP430 too if you'd like.
>
> I'm mostly using PICs right now but am stuck on the fact that MPLAB 
> requires you to have write permissions in C:\Program Files (which we can't 
> allow in a big student lab with roaming profiles), and also, if you follow 
> the simplest, default path toward creating an ASM project, you run into a 
> 62-character length limit on the full path to the file.  Does AVR Studio 
> cooperate fully with normal Windows security practices, or does it, too, 
> require you to loosen security on the computer in order to run it?
>
> 

steve wrote:
> Jim Granville wrote:
> 
>>steve wrote:
>>
>>>larwe wrote:
>>>
>>>
>>>
>>>>All three - Proprietary single-source architectures.
>>>
>>>
>>>there are multi-source architectures?
>>
>>Oh yes :  80C51, ARMx, MIPs, C166, x86.....
>>
>>-jg
> 
> 
> By multi-source I mean drop in replacement, pin-for-pin electrically
> compatible, no code changes, 

Then perhaps you should have said that, and not 'architectures' ? ;)

> I don't believe there are any modern
> multi-source micro's. Silabs,Analog Devices, Atmel all make 8051's but
> they make no attempt to standarized memory maps, modules interfaces,
> pinouts, or even the most basic electrical characteristics etc, they
> are all unique customized micro's.

At the 40/44 pin package point, there are truckloads of 
socket-compatible 80C51's

Over a broader package range, 80C51's tend to have common 
Timer0/Timer1/Timer2/PCA/UART/Interrupts, and P0..P3 are a common 
denominator.

Remember tho, that one of the reasons the peripherals are different, is 
to target different applications.
Clearly, every 80C51 variant should not have 24 bit ADCs, for example ?

> A common core is not too helpful as modern high level languages already
> makes all cores "psuedo common" (except for timing).
> 
> I rather have common memory maps, peripheral interfaces, electrical
> characteristics and common pinouts with different cores, this way I
> could just recompile. Yes not a true multi-source part, but it does
> allow me a "chance" of just replacing the old chip with the new one
> without redesigning my board (assuming all the timing/emi etc look ok).
>  But obviously the amount of cooperation between companies to do this
> would be mind boggling.

  Yes, there is an argument for this approach - watch for what freescale 
is doing with their RS08 and Coldfire V1 push.

  It has the merit you mention, that "just recompile" is the holy grail.

  The downside is, if the peripherals were sub-standard on the 8 bit one,
then you have the same rusty bucket of bolts on the 32 bit one! - and 
the only reason to move is the core.
  The commercial danger is, one part will merely cannibalize the market 
of the other.

-jg

> Except they aren't really multi-source.  For example, you're
> using an ARM single-chip solution from vendor A.  It's not like
> there's a drop-in replacement part from Vendor B: the
> peripherals are all different from one source to th next.
> Since all the work is in dealing with the peripherals, I find
> almost zero benefit in switching to a second source with the
> same core but a different set of peripherals.


This will change with the ARM Cortex-M3.  Standard peripherals and standard 
memory may.  Of coarse a vendor can choose to ignore the standard if they so 
wish.

Regards,
Richard.

http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * 

>
> David Kelly wrote:
>
>
>> compiler. I looked a lot at the output of avr-gcc. It never wrote
>> assembly that I could improve enough to justify the effort to rewrite in
>> assembly. Once or twice I changed a C expression for better assembly
>
> Mmm, maybe. I'm currently evaluating avrgcc (with which I have a lot of
> experience) against IAR and Rowley (with which I have relatively little
> experience on AVR targets). There _are_ differences.

One big difference:

AVRGCC - single stack, does something odd when making function calls.

IAR, Rowley, ImageCraft - separate call and data stacks to prevent the 
necessity for the above odd thing.

Regards,
Richard.

http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * 

> Are you forced to install in C:\Program Files, or do you mean, you must 
> have write permissions to the EXE host directory ?
> ( which is slack of them, if true )


I have both MPLAB and AVRStudio installed in c:\devtools.

Regards,
Richard.

http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * 

FreeRTOS.org wrote:

>>Except they aren't really multi-source.  For example, you're
>>using an ARM single-chip solution from vendor A.  It's not like
>>there's a drop-in replacement part from Vendor B: the
>>peripherals are all different from one source to th next.
>>Since all the work is in dealing with the peripherals, I find
>>almost zero benefit in switching to a second source with the
>>same core but a different set of peripherals.
> 
> This will change with the ARM Cortex-M3.  Standard peripherals and standard 
> memory map.  Of course a vendor can choose to ignore the standard if they so 
> wish.

... and they may wish to do that, as the Cortex peripherals are rather 
'ordinary/below par' for a new 32 bit core offering :

  No Up/Down or quadrature modes, and only 16 bit capture ?
PWM edge resolution is only = Core clk speed, 4Mhz spi speed... ?

  They don't look like they were designed by a perpipheral expert.

  Will be interesting to see how the Freescale Coldfire V1 peripherals
match against that. Freescale has a lot more experience at peripheral 
design.

-jg

On 2006-08-04, FreeRTOS.org <nospam@thanks.com> wrote:
>> Except they aren't really multi-source.  For example, you're
>> using an ARM single-chip solution from vendor A.  It's not like
>> there's a drop-in replacement part from Vendor B: the
>> peripherals are all different from one source to th next.
>> Since all the work is in dealing with the peripherals, I find
>> almost zero benefit in switching to a second source with the
>> same core but a different set of peripherals.
>
> This will change with the ARM Cortex-M3.  Standard peripherals and standard 
> memory may.  Of coarse a vendor can choose to ignore the standard if they so 
> wish.

And they most certainly will.  Since the vendor of an ARM part
can't differentiate their product based on the core
architecture, they'll try to differentiate it based on
peripherals.  Nobody really _wants_ to be a second source.

-- 
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                               visi.com