Disadvantages of MSP430 relative to AVR and PIC?

At risk of starting a religious war...

Why should I *not* prefer the MSP430 to the AVR and PIC?

Tell me its weak points.

MC wrote:
> At risk of starting a religious war...
> 
> Why should I *not* prefer the MSP430 to the AVR and PIC?
> 
> Tell me its weak points.
> 
> 

It's easier if you tell us what you need.

Just to start the religious war rolling, if you want a gcc toolchain for 
the device you are best with the AVR (Atmel supports gcc directly, and 
the toolchain is regularly updated).  The msp430 port is based on an old 
version of gcc - it works well enough, but has limited support for newer 
devices.  The PIC requires fairly expensive commercial compilers for C 
support.

I used to prefer the msp430 devices - they are cheap, low power, have 
plenty of pins, have a very nice cpu core, and some nice peripherals. 
But the AVRs are now cheaper and lower power (for many parts), the cpu 
is good (although it's 8-bit, it's as fast as the msp430 at the same 
clock), and the peripheral support is good.

On Tue, 16 Dec 2008 19:04:17 -0500, "MC"
<for.address.look@www.ai.uga.edu.slash.mc> wrote:

>At risk of starting a religious war...
>
>Why should I *not* prefer the MSP430 to the AVR and PIC?
>
>Tell me its weak points.

Many AVRs are available in DIP form factors. Handy for breadboard or
stripboard layouts.

AVRs (all?) support parallel programming in addition to in-system serial
or fancier, later options. Nice to have if the fuse settings get totally
borked and you want to recover the chip.

However, it's probably good to have both families in your skill set,
along with a 32-bit processor or two.

-- 
Rich Webb     Norfolk, VA

On Dec 16, 4:04 pm, "MC" <for.address.l...@www.ai.uga.edu.slash.mc>
wrote:
> At risk of starting a religious war...
>
> Why should I *not* prefer the MSP430 to the AVR and PIC?
>
> Tell me its weak points.

AVR and PIC have more active user forums (avrfreaks)

No EEPROM

MSP430 more expensive

Can't program MSP430 FLASH down to 1.8Volts on some models

the newer 5xx series fixes the last two problems

On 2008-12-17, MC <for.address.look@www.ai.uga.edu.slash.mc> wrote:
> At risk of starting a religious war...
>
> Why should I *not* prefer the MSP430 to the AVR and PIC?

TI's JTAG implimentation and support suck compared to AVR's.

Dunno about PIC's.  I took one look at the assembly code
generated for a C function and ran the other way.

-- 

MC wrote:
> At risk of starting a religious war...
> 
> Why should I *not* prefer the MSP430 to the AVR and PIC?
> 
> Tell me its weak points.

- high price
- almost exclusively SMD cases (no problem really if pin pich > 0.5 mm)
- 3.3 V supply, IO not 5V tolerant
- low output current esp. when compared to AVR.

Other than that, MSP430 is significantly faster and more flexible than 
any 8-bit stuff.

I prefer MSP430 over AVR and anything over 8-bit PIC. AVRs are perfect 
for tiny devices with LED drive capability, including even not too big 
multiplexed displays.

David Brown <david.brown@hesbynett.removethisbit.no> writes:

> MC wrote:
>> At risk of starting a religious war...
>>
>> Why should I *not* prefer the MSP430 to the AVR and PIC?
>>
>> Tell me its weak points.
>>
>>
>
> It's easier if you tell us what you need.
>
> Just to start the religious war rolling, if you want a gcc toolchain
> for the device you are best with the AVR (Atmel supports gcc directly,
> and the toolchain is regularly updated).  The msp430 port is based on
> an old version of gcc - it works well enough, but has limited support
> for newer devices.  The PIC requires fairly expensive commercial
> compilers for C support.
>
> I used to prefer the msp430 devices - they are cheap, low power, have
> plenty of pins, have a very nice cpu core, and some nice
> peripherals. But the AVRs are now cheaper and lower power (for many
> parts), the cpu is good (although it's 8-bit, it's as fast as the
> msp430 at the same clock), and the peripheral support is good.

The main problem I had with the AVR's (for "bigger" applications in
C), is the contortions you have to go through to access constant data
in flash. It has a "harvard" architecture, meaning you need a
different pointer type to access data stored in the "program"
space. This makes it hard to write general purpose functions which are
equally happy working on RAM and flash data. While in principle I
think the compilers could hide this, as far as I know they all have
similar clumsy work-arounds which end up infecting many of your
function and variable definitions. (This is for the case when you have
quite a lot of constant data, too much to make a ram copy. For example
CRC tables, menu structures & screen layouts, fonts.)

I haven't used the MSP430 - I went straight to 32 bit ARM for new
projects. But it has a von Neumann architecture (single address space
for code and data) so should be better here provided you don't run out
of address space.

Another thing is that with the AVR you will get tripped up more often
by non-atomic access, when doing multitasking or interrupt
handlers. The fact that the memory width is 8 bits means that you have
to allow for any variable being updated just one byte at a time. So
you must be very careful to follow the rules for atomic access,
otherwise your interrupt routine may see a half-updated pointer for
example.

A 16 bit CPU with 16 bit pointers will be more forgiving (and a 32 bit
one even more so).

The AVR is fine for smaller programs, or ones that don't have much of
a user interface. Or there may be other overriding features already
mentioned by others that are more important for your application.

-- 

John Devereux

John Devereux wrote:
> David Brown <david.brown@hesbynett.removethisbit.no> writes:
> 
>> MC wrote:
>>> At risk of starting a religious war...
>>>
>>> Why should I *not* prefer the MSP430 to the AVR and PIC?
>>>
>>> Tell me its weak points.
>>>
>>>
>> It's easier if you tell us what you need.
>>
>> Just to start the religious war rolling, if you want a gcc toolchain
>> for the device you are best with the AVR (Atmel supports gcc directly,
>> and the toolchain is regularly updated).  The msp430 port is based on
>> an old version of gcc - it works well enough, but has limited support
>> for newer devices.  The PIC requires fairly expensive commercial
>> compilers for C support.
>>
>> I used to prefer the msp430 devices - they are cheap, low power, have
>> plenty of pins, have a very nice cpu core, and some nice
>> peripherals. But the AVRs are now cheaper and lower power (for many
>> parts), the cpu is good (although it's 8-bit, it's as fast as the
>> msp430 at the same clock), and the peripheral support is good.
> 
> The main problem I had with the AVR's (for "bigger" applications in
> C), is the contortions you have to go through to access constant data
> in flash. It has a "harvard" architecture, meaning you need a
> different pointer type to access data stored in the "program"
> space. This makes it hard to write general purpose functions which are
> equally happy working on RAM and flash data. While in principle I
> think the compilers could hide this, as far as I know they all have
> similar clumsy work-arounds which end up infecting many of your
> function and variable definitions. (This is for the case when you have
> quite a lot of constant data, too much to make a ram copy. For example
> CRC tables, menu structures & screen layouts, fonts.)
> 

Yes, that's definitely a problem, and one of the weak points of the AVR 
core (the other main weaknesses are poor pointer register support, and 
no SP+offset addressing).

Normally the programmer has a fairly clear understanding of when data is 
constant and can be in flash, and when it is in RAM, and whether a given 
function is expecting to work on flash or RAM data.  But even then it is 
still a pain when you want to work with portable code.

> I haven't used the MSP430 - I went straight to 32 bit ARM for new
> projects. But it has a von Neumann architecture (single address space
> for code and data) so should be better here provided you don't run out
> of address space.
> 

The unified address space, and the orthogonal instruction set, are some 
of the best features of the msp430 core.

> Another thing is that with the AVR you will get tripped up more often
> by non-atomic access, when doing multitasking or interrupt
> handlers. The fact that the memory width is 8 bits means that you have
> to allow for any variable being updated just one byte at a time. So
> you must be very careful to follow the rules for atomic access,
> otherwise your interrupt routine may see a half-updated pointer for
> example.
> 
> A 16 bit CPU with 16 bit pointers will be more forgiving (and a 32 bit
> one even more so).
> 

It's best to program such code correctly, rather than looking for the 
cpu's forgiveness!

It's a very common misconception that "volatile" gives you atomic 
access, and newbies often make such mistakes in their interrupt code. 
But that applies to *all* 8-bit architectures, not just the AVR (and 
applies equally when trying to update 32-bit data with a 16-bit cpu).

> The AVR is fine for smaller programs, or ones that don't have much of
> a user interface. Or there may be other overriding features already
> mentioned by others that are more important for your application.
> 

All small microcontrollers have their idiosyncrasies.  I think the AVR 
devices are the best overall choice at the moment for a wide range of 
applications.  By the time you are getting over the 128k code level, 
however, it is probably best to jump to a 32-bit device.

On 2008-12-17, David Brown <david@westcontrol.removethisbit.com> wrote:

>> Another thing is that with the AVR you will get tripped up more often
>> by non-atomic access, when doing multitasking or interrupt
>> handlers. The fact that the memory width is 8 bits means that you have
>> to allow for any variable being updated just one byte at a time. So
>> you must be very careful to follow the rules for atomic access,
>> otherwise your interrupt routine may see a half-updated pointer for
>> example.
>> 
>> A 16 bit CPU with 16 bit pointers will be more forgiving (and a 32 bit
>> one even more so).
>
> It's best to program such code correctly, rather than looking for the 
> cpu's forgiveness!

One presumes you use mutexes to protect shared 8-bit values in
a threaded environment just in case your firware needs to run
on a 4-bit machine?  ;)

Apart from the JTAG pain, I find the MSP430 to be an excellent
family.  The last project I did MSP430 was far lower power and
far cheaper than the equivalent AVR.  I find the low power
modes in the MSP much more useful since they wake up in
microseconds rather than milliseconds.

-- 
Grant Edwards                   grante             Yow! In 1962, you could buy
                                  at               a pair of SHARKSKIN SLACKS,
                               visi.com            with a "Continental Belt,"
                                                   for $10.99!!

On Tue, 16 Dec 2008 19:04:17 -0500, "MC"
<for.address.look@www.ai.uga.edu.slash.mc> wrote:

>At risk of starting a religious war...
>
>Why should I *not* prefer the MSP430 to the AVR and PIC?
>
>Tell me its weak points.

I have done several products using the MSP430, mostly the 'F149 and
'F449 parts.  Basically, except for a few special purpose
applications, I will not use the MSP430 on future products.  We had
NUMEROUS problems writing to the flash reliably.  The flash write
problems have finally been somewhat acknowledged by TI, but they
really have not solved the problems (maybe others parts in the MSP430
family have them fixed).

Those same parts are also VERY sensitive to any noise.  We do a pretty
good job of board design and keeping our circuits immune from noise,
but those parts were especially sensitive causing resets and, worst of
all, lockups where even the watchdog timer would not pull it out.

On the 'F44x parts, there were issues of sometimes not starting up
when using a 32KHz crystal.  What is required is to properly "tune"
the crystal used to the part.  We found the selection of capacitors
for the crystal is very critical to starting up. 

I would not recommend using the 'F44x or 'F1xx parts for any
applications but those that are battery powered and only applications
that do NOT write to on-chip flash.  If I was forced to use an MSP430
and I needed to write to non-volatile memory, I would use an external
serial EEPROM or FRAM.   In my career, I have used several micros, but
the MSP430 family has definitely given me the most problems.

Lou