Disadvantages of MSP430 relative to AVR and PIC?
in [Embedded]
|
Prev: 16C752 Problem
Next: MAX3421E to PIC18F4550
From: John Devereux on 20 Dec 2008 05:23 larwe <zwsdotcom(a)gmail.com> writes: > 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). I *think* you are missing the fact that they hide it by copying the "constant" data to ram on startup. This is OK if you have plenty of RAM, or not much "constant" data. But not good for the cases I was talking about. My experience is mainly with gcc a few years ago, but at the time I looked briefly at other compilers and they seemed to do the same sort of thing. You could work around the problem using PDATA pointers or PROGMEM macros etc but the resulting pointers were incompatible with normal ones. So you could not use e.g. a printf(s), you had to write a separate printf_P(s). And so on, you would need a memcpy_P(void* s, PROGMEM* p) etc, for every function wanting to access the constant data. -- John Devereux
From: Dombo on 20 Dec 2008 08:54 linnix schreef: > On Dec 17, 2:18 pm, steve <bungalow_st...(a)yahoo.com> wrote: >> On Dec 17, 10:58 am, Mr. C <fakeem...(a)hotmail.com> wrote: >> >> >> >>> On Tue, 16 Dec 2008 19:04:17 -0500, "MC" >>> <for.address.l...(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 >> Flash is the Achilles heel of every micro I have used, especially with >> applications that write to it in the field. > > 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. So what else would you consider?
From: linnix on 20 Dec 2008 11:36 1: > 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). IAR hids it. GCC dose not. 2: > > > 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. > So what else would you consider? Costs and power drains. 3. > In quite many practical cases, the 5V I/O and supply are required. > MSP430 is 3.3V only. AVR (M1) is capable of both 5V (A1) and 3V (A2). Single power rail M1A1 works great for us. However, we are splitting the power anyway. The main reason is to get the 3V LDO regulator in the BOM, so no surprise for the customer later on. The secondary reason is to cut power consumptions by half. Most importantly, double standby battery time. The new microcontroller (M2) is 3V only. So, it will only work with A2. Our migration path is: M1A1 -> M1A2 -> M1A1 -> M2A2 By the way, they are not weapons and not for military uses.
From: steve on 20 Dec 2008 19:38 On Dec 17, 2:31 pm, Mr. C <fakeem...(a)hotmail.com> wrote: > >Flash is the Achilles heel of every micro I have used, especially with > >applications that write to it in the field. > > 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 A battery backed MSP430 is another option (and use SRAM)
From: RumpelStiltSkin on 21 Dec 2008 09:10
"larwe" <zwsdotcom(a)gmail.com> wrote in message news:2d6a39d8-caef-48b1-8d4b-b56bd1d0c4eb(a)z1g2000yqn.googlegroups.com... 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). IAR hides it best. GCC is a pain. You have special functions to access FLASH. (strcpy_p, etc...) |