PIC versus AVR

On 2006-08-04, FreeRTOS.org <nospam@thanks.com> wrote:
>>
>> 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.

And yet people claim the AVR was designed to be C-friendly.
I've looked at AVR code generaged by GCC and IAR.  The AVR is
not C-friendly.  It may not be actively hostile like the 8051
or PIC, but it's not C friendly.  

Any processor that falls over when you attempt to do any
pointer manipulation isn't C-friendly.

-- 
Grant Edwards                   grante             Yow!  Yow! Maybe I should
                                  at               have asked for my Neutron
                               visi.com            Bomb in PAISLEY--

> *chuckle*  That's me :)
>
>> AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>> broad range of devices. Much closer compatibility in the family than
>> amongst the different PIC flavors.
>
> So I had noticed.  It may be a bigger instruction set, but there are fewer 
> flavors of it...
>
>> MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> VERY easy to work with. Code compatibility between parts is superb.
>> However, relatively expensive and not many devices in the family.
>
> Ah!  Didn't realize it was Von Neumann.  Hmmm...  A lot of what I do is 
> precision timing of one kind or another, and the ability to count to 65535 
> might be useful.
>
>

With the right compiler you are in luck.
The IAR AVR C compiler allows you to do

#define    MHz    12
#define    delay_us(x)    __delay_cycles(x * MHz)

Which means you get an exact delay in C.

Probably available for some other compilers/architectures as well,but it is 
nice to know
you can have it at all...

The register intensive AVR architecture makes it easy for the compiler to do 
16/32 bit math.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

mc wrote:
> > Well, gee, I only just finished writing several thousand words on the
> > topic... here's the dime version:
>
> Previous postings here, or something else?  I'd be glad to read it if you've
> made a web site or something...

Both. There was a long thread in this NG recently, I think the title
was something like "about the MSP430", and we got into pros and cons of
these three architectures. Some very detailed stuff in there, IIRC from
Senor Kirwan.

> > AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>
> So I had noticed.  It may be a bigger instruction set, but there are fewer
> flavors of it...

I have a strong pro-AVR bias. I've had ongoing good luck with all my
AVR-based projects; things have "just worked". With the MSP430 there
are so many switchable options that I have trouble working out why
things don't work right.

> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
> > VERY easy to work with. Code compatibility between parts is superb.
> > However, relatively expensive and not many devices in the family.
>
> Ah!  Didn't realize it was Von Neumann.  Hmmm...  A lot of what I do is

It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
isn't EEPROM) area is mapped straight into the normal memory map, not
the usual address/data registers found in other parts. It's very easy
to use.

> precision timing of one kind or another, and the ability to count to 65535
> might be useful.

The MSP430 is quite rich in timer and capture/compare goodies. If you
want to play with it, invest in the $20 ez430 demo/development kit;
this is a full debugger with a small target board (2K flash). The
debugger only works with the most recent chips, since it uses TI's new
2-wire protocol. For older chips you'll need a flash emulation tool
[JTAG debugger]; Olimex sells those for US$20 in a parallel port
version, more for the USB version.

The 2K target is inside the 4K limit of the free C compiler provided
with the kit, so you can work in asm or C (or even C++) according to
your particular fetish.

Grant Edwards wrote:

> And yet people claim the AVR was designed to be C-friendly.

That was explicitly the design intent; it's not a claim, but a
published fact.

Note that the explicit design intent of the observation platform atop
the Empire State Building was for (dis)embarkation of lighter-than-air
aircraft.

On Friday, in article <44d2c440$1@clear.net.nz>
     no.spam@designtools.co.nz "Jim Granville" wrote:

>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 )

Unfortuntely most of the vendor apps are written by PC applications
programmers, who assume everybody is on a STANDALONE PC! Programmes that
force storing of project details into the installed programme directory
are the NORM not the exception. Very few have network deployment methods.

I would not surprised if the apps want to write all sorts of files in their
installed directory and not into a project directory.

As the original poster was talking about a univerity type lab which would be
on a university network, with all sorts of restrictions such as users cannot
install programmes and their work is over the network so their "My Documents"
is actually on a server, along with the user portion of registry. Often in
these situations the user has no write access directly to local drives! Nor
would I wnt to is some eductaion establishments.

Come acros this problem often as the other half (SWMBO) runs a school network
with some 7 servers and over 250 workstations around the school. Scanners,
and digital cameras can be the worst culprits for wanting to create their
wonderful 'albums' and catalogues in the program directory. Then you can
get printers that want to create their own print spooler and need a directory
for it, usually under the program directory and you cannot change it.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

> with some 7 servers and over 250 workstations around the school. Scanners,

This is a private school then, right?

Regards,
Richard.

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

On 2006-08-04, larwe <zwsdotcom@gmail.com> wrote:
> Grant Edwards wrote:
>
>> And yet people claim the AVR was designed to be C-friendly.
>
> That was explicitly the design intent; it's not a claim, but a
> published fact.

Touch&#4294967295;.

I should have been whinging about the claim that the AVR _is_
C-friendly. :)

> Note that the explicit design intent of the observation platform atop
> the Empire State Building was for (dis)embarkation of lighter-than-air
> aircraft.

That sure would have been something worth seeing.

-- 
Grant Edwards                   grante             Yow!  Now I'm concentrating
                                  at               on a specific tank battle
                               visi.com            toward the end of World
                                                   War II!

On 4 Aug 2006 07:28:26 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

>mc wrote:
>> > Well, gee, I only just finished writing several thousand words on the
>> > topic... here's the dime version:
>>
>> Previous postings here, or something else?  I'd be glad to read it if you've
>> made a web site or something...
>
>Both. There was a long thread in this NG recently, I think the title
>was something like "about the MSP430", and we got into pros and cons of
>these three architectures. Some very detailed stuff in there, IIRC from
>Senor Kirwan.

;)

>> > AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>>
>> So I had noticed.  It may be a bigger instruction set, but there are fewer
>> flavors of it...
>
>I have a strong pro-AVR bias. I've had ongoing good luck with all my
>AVR-based projects; things have "just worked". With the MSP430 there
>are so many switchable options that I have trouble working out why
>things don't work right.
>
>> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> > VERY easy to work with. Code compatibility between parts is superb.
>> > However, relatively expensive and not many devices in the family.
>>
>> Ah!  Didn't realize it was Von Neumann.  Hmmm...  A lot of what I do is
>
>It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
>isn't EEPROM) area is mapped straight into the normal memory map, not
>the usual address/data registers found in other parts. It's very easy
>to use.
>
>> precision timing of one kind or another, and the ability to count to 65535
>> might be useful.
>
>The MSP430 is quite rich in timer and capture/compare goodies.

This is a serious strength of the MSP430.  If there is one thing and
only one thing permitted to be said about the MSP430 peripherals, it
would have to be the timers.  The B7 section available on some parts
has 7 capture/compares on it.  Unusual and... at times... very useful.

Jon

>If you
>want to play with it, invest in the $20 ez430 demo/development kit;
>this is a full debugger with a small target board (2K flash). The
>debugger only works with the most recent chips, since it uses TI's new
>2-wire protocol. For older chips you'll need a flash emulation tool
>[JTAG debugger]; Olimex sells those for US$20 in a parallel port
>version, more for the USB version.
>
>The 2K target is inside the 4K limit of the free C compiler provided
>with the kit, so you can work in asm or C (or even C++) according to
>your particular fetish.

>> 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.
>
> And yet people claim the AVR was designed to be C-friendly.
> I've looked at AVR code generaged by GCC and IAR.  The AVR is
> not C-friendly.  It may not be actively hostile like the 8051
> or PIC, but it's not C friendly.
>
> Any processor that falls over when you attempt to do any
> pointer manipulation isn't C-friendly.
>
> -- 

You are probably saying that an 8 bit architecture is inherently 
C-unfriendly.
If you start in the other end: How do you make an 8 bit architecture which 
is C-friendly
you may come to a different conclusion.

From this viewpoint it is "C-friendly" to use 2 instructions for 16 bit 
operations
and 4 instructions to do 32 bit operations.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:44d309c7$1@clear.net.nz...
> 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.

No, the standard M3 peripherals such as the interrupt controller/
timer/profiler/breakpoint unit are defined by ARM and cannot be
changed. Neither can the memory map. Due to this there is almost
no need in porting RTOSes, debuggers etc when moving between
different devices.

Other peripherals like UARTs are not standardised. The major MCU
manufacturers already have their own, so there is little chance of
standardisation.

> ... 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... ?

These are Luminary peripherals. The Cortex-M3 peripherals are
described in the TRM. You can add more peripherals but you
can't change/remove the standard ones.

Wilco