Disadvantages of MSP430 relative to AVR and PIC?
in [Embedded]
|
Prev: 16C752 Problem
Next: MAX3421E to PIC18F4550
From: dalai lamah on 17 Dec 2008 18:50 Un bel giorno Mr. C digit�: > 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. 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: http://focus.ti.com/mcu/docs/mcusupporttechdocsc.tsp?sectionId=96&tabId=1502&abstractName=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...). >>> Those same parts are also VERY sensitive to any noise. >> >>That's strange, I've used them without any problem in various applications >>where they are *submersed* into noise! > > 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. 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
From: Mark Borgerson on 18 Dec 2008 11:03 In article <antik41666g2eobbtt7o9afo7e3945hbkr(a)4ax.com>, fakeemail(a)hotmail.com says... > >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. > > We were sure our flash frequency was correct. Not the problem for us. > > >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. > > 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. 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. > > >> Those same parts are also VERY sensitive to any noise. > > > >That's strange, I've used them without any problem in various applications > >where they are *submersed* into noise! > > 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. > Mark Borgerson
From: Mr. C on 19 Dec 2008 10:19 >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. I guess it's obviously been a while since I used it :-) Thanks for the correction. Lou
From: Vladimir Vassilevsky on 19 Dec 2008 10:51 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. 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 http://www.abvolt.com
From: larwe on 20 Dec 2008 03:05
On Dec 17, 5:45 am, John Devereux <j...(a)devereux.me.uk> wrote: > 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 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). |