Disadvantages of MSP430 relative to AVR and PIC?

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.

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

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

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.

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

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

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.

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

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

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.

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

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

Un bel giorno Mr. C digitò:

MSP430 flash has basically two problems:

1) You need to make sure that the internal charge pump frequency falls into a certain range (which is also slightly different for the various families). This means that you have to select which clock source to use (ACLK, MCLK, etc..), calculate the right divider ratio and program the appropriate flash register. This is annoying, especially if you use the DCO and don't know exactly the operating frequency. 2) For reliable writes, you need at least a power supply of 2.7 V. In my opinion this is the main issue; I can accept that below a certain voltage the device can't work at its maximum frequency, but I expect at least that every internal device will work flawlessy over the entire voltage range.

Just as a side note, MSP430 datasheets report in the absolute maximum ratings a different storage temperature for programmed and unprogrammed devices (-40/+85 and -55/+150 respectively). This doesn't make much sense: a higher temperature could (and would) shorten the retention time of a programmed device, but it wouldn't permanently damage it (which is the meaning of the absolute maximum ratings): otherwise, it would permanently damage also the unprogrammed device. I submitted to EPIC this observation and they confirmed that this distinction is no longer valid, and will be removed in the future datasheet revisions; the storage temperature will be unified to -55/+150, whether the device is programmed or not.

That's strange, I've used them without any problem in various applications where they are *submersed* into noise!

--
emboliaschizoide.splinder.com

Flash is the Achilles heel of every micro I have used, especially with applications that write to it in the field.

We were sure our flash frequency was correct. Not the problem for us.

Yep, we had good programming voltage too. One observation we had is that once you programmed flash, there is no guarantee (without verification) that the contents are correct. So, to take care of that, you need to read back what you programmed and make sure it got programmed correctly.

Also, see their document slaa334.pdf, section 3.3, where it gives strange warnings like, "Each time a single bit, byte, or word is programmed, a complete row of 64-byte flash cells sees the high voltage necessary for programming. This high voltage generates some stress to the complete row of flash cells, and this stress must be time limited to avoid damage. The next erase cycle resets this stress time to zero, and the cumulative program time restarts again from the beginning. According to the data sheet, as shown in Table 3, this high-voltage stress must be limited to 10 ms between two erase cycles. See the data sheets for the correct values for each MSP430 derivative." Why would they have such a strange write-up if their flash was not fragile?

What is especially discouraging is when the same document (section

4.2) goes on to say, "As explained in the previous section, data retention time is very much dependent on the ambient temperature of the MSP430 application. One possible solution to enhance flash data retention is refreshing the flash contents from time to time with software." (!) In other words, make good in firmware what we somehow couldn't seem to get right in hardware.

The place the MSP430 really shines, and the thing TI promotes the most about it is its super low current drain. With a 16-bit core that includes multiply and divide instructions, you have a LOT of compute power, yet can achieve a very low current drain. For our battery-operated products that used the MSP430, it seemed to be great. (There, I said something good about the MSP430 :-) ) In almost ALL their example circuits, they show the MSP430 being battery powered. I think that is what the processor was primarily designed for. And I sometimes wonder if they didn't compromise other things to get there.

We found that battery operated applications fared much better than the power supply applications. I don't know why, but the MSP430 was definitely the most sensitive processor I have ever worked with. Just my experience.

Lou

I have pretty much decided that any application that requires storage to non-volatile memory will use some sort of off-chip serial memory like an EEPROM for limited writes, or an FRAM for unlimited writes. Defintely gives me peace of mind.

Lou

Flash is great for developments and avr is nice for prototypes. However, we are looking into two other non-flash uC for productions. Avr and msp are too expensive. Pic is too ugly.

Un bel giorno Mr. C digitò:

Well, you can't blame them for the adversities of the laws of physics. ;-)

The dependence of data retention time on temperature (mostly driven by thermal agitation) is pretty much the same for every flash cell; you can roughly assume that for every 10 °C temperature raise, the retention time will halve. This is explained in slaa334a that you've quoted, and even better in slaa392:

What changes from a flash to another, of course, is the "base line": for the MSP430 they have specified the typical retention time at the room temperature, not over the entire working/storage range. A data retention of

100 years at 25 °C corresponds to barely two years at 85 °C (working limit), and one week at 150 °C (storage limit). It makes you think. :)

The fact that MCU program flashes are lousy is not news; since this thread started as a MSP-AVR comparison, it's interesting to point out that Atmel doesn't even bother to specify the flash retention time in its ATtiny/ATmega datasheets (yes, I'm sure it's reported in some app note, but still...).

I thought you were referring to radiated noise. On conducted noise, actually, I had some problems too but only with the JTAG low-cost interface (MSP-FET430UIF). It seems very sensible to noise on the power source of the target, and in several devices I've been forced to put a blocking diode and a capacitor on the JTAG Vcc signal.

--
emboliaschizoide.splinder.com

I think they made a compromise you missed: None of the MSP430 variants that I have used include a divide instruction. They have integer multiply and MAC hardware, but no divide.

Mark Borgerson

I guess it's obviously been a while since I used it :-) Thanks for the correction.

Lou

In quite many practical cases, the 5V I/O and supply are required. MSP430 is 3.3V only.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Am I missing something here? The AVR compilers I've used seem to hide this fact from the developer quite successfully (as compared to, say, the PIC compilers, which are of course simply an exercise in futility).