Disadvantages of MSP430 relative to AVR and PIC?
in [Embedded]
|
Prev: 16C752 Problem
Next: MAX3421E to PIC18F4550
From: BlueDragon on 17 Dec 2008 04:16 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.
From: John Devereux on 17 Dec 2008 05:45 David Brown <david.brown(a)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
From: David Brown on 17 Dec 2008 06:55 John Devereux wrote: > David Brown <david.brown(a)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.
From: Grant Edwards on 17 Dec 2008 10:56 On 2008-12-17, David Brown <david(a)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!!
From: Mr. C on 17 Dec 2008 10:58
On Tue, 16 Dec 2008 19:04:17 -0500, "MC" <for.address.look(a)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 |