David Brown wrote: > We use both AVRs and MSP430s at my company. I don't think we have > had many new designs using AVRs since we started with MSP430s, unless > they are closely related to existing AVR-based designs, or have very > particular > needs (we used an AVR Tiny for an extremely low cost, low power card).
Same here, we have used both, but the MSP430 is so much better in nearly all respects, I wouldn't use it in any new design unless there was a compelling reason... And I don't think there ever will be one! Very important is the on-board peripherals - the MSP430 is generally much better than the AVR. This saves so much code, and makes the firmware architecture simpler. Recently in our main MSP430 application, we changed serial I/O from interrupt-driven to DMA-driven, with no trouble. [...] > There's no doubt about the cores, however - the MSP430 is very > C-friendly, while the AVR is at best IAR-C-friendly. [...] > Where it falls down is code that uses a lot of pointers, 16-bit or 32-bit > arithmetic, flash memory access, or using small functions. Yes, the AVR is very compiler-unfriendly. The MSP430 is the opposite. > * The avr-gcc people decided to use a __zero_reg__ (I don't think it > is an overall win), and put it in r0. Since r0 is unavoidably used by other > features (multipliers, and LPM instructions), it must be preserved in the > interrupt prologue, since the compiler code generator assumes it is always > valid. Similarly, it assumes that __tmp_reg__ is always available. Interesting, I also use R0 as a "zero-reg" in my assembly code, without it I had to load zero into a register so often that it was silly. The MSP430's constant generator means you don't need to waste a register. Just another compiler-friendly design feature. (Actually that's not just compiler-friendly, it's assembly-friendly too.) Grant Edwards wrote: >>> Everything is so much cleaner on the MSP430 except for the >>> MSP430's lack of a TX holding register empty flag and lack >>> of a TX shift register empty interrupt. At least Atmel got that >>> right in the AVR ATmega parts. >> >> The MSP430 does have a transmit complete flag, > > I know. I said it didn't have a TX holding register empty flag. I think the UTXIFGx flag in IFG1 is equivalent to a transmit holding register empty flag. The data sheet says it "is set when UxTXBUF is empty". If the transmit interrupt is enabled, it is the bit that generates the interrupt. > The AVR has both flag and interrupt for TX holding register > empty and for TX shift register empty. The MSP430 has an > interrupt for the former (but no flag), and a flag for the > latter (but no interrupt). It makes using the '430 UARTs a > pretty clumsy in some applications. Yes it's a bit odd. I think the UART has the weakest design of all the peripherals on the MSP430. When I implemented some RS-485 bus slave firmware on the AVR, I could trigger an interrupt when the last bit of the last byte of a message had been transmitted, and the handler could turn off the bus transmitter straight away. To get the same behaviour on the MSP430, the code has to wait in a loop polling the TXEPT flag until the last byte has gone out, then turn off the transmitter. [...] >> I think the huge interrupt function size is due to the >> prologue and epilogue code in the interrupt handler. >> Looking at the problem as an assembly language >> programmer, you can see most of it isn't needed for >> your simple example, but I doubt the compiler has >> that level of insight. > > Yes, it does. The compiler knows which registers are used in > the ISR and which ones aren't. That's why the '430 version > didn't push/pop any registers. Note that even the AVR version > doesn't save the entire register. Saving/restoring only the > minimum required set of registers in a prolog/epilog has been > SOP in compilers for decades. The gcc AVR code generator just > doesn't do it right. There was absolutely no reasons to > save/clear/restore the "zero" register, and it should have used > either r24 or r25 instead of the "temp" register when it was > saving/restore SREG. Simplistic design, I guess. If the compiler's code generator is based on the fundamental assumption that the zero register will always contains zero, then the prologue and epilogue code has to ensure this is true, even though in your case the code generator doesn't actually emit any code that relies on that assumption. This seems different from the case of tracking which registers are and aren't used by the code. Perhaps the assumption that the zero register will be zero is so deeply embedded into the code generator that the designers didn't consider the possibility that the interrupt code might not need it, and therefore that the prologue and epilogue code might not need to do anything with it. I think they should've chosen a different register! If they'd used R1, they could have set it to zero and never changed it. Then the interrupt handler could assume it was zero as well - no need to preserve it, nor to set it to zero. They can't make that assumption because R0 may be some other value temporarily, as the LPM instruction always loads to it, and they wouldn't want to have to disable interrupts around the LPM instruction sequence. I guess. >> I guess they're a good "first microcontroller" for beginners and >> students. They're available in DIP packages, you can build your >> own programmer, and the basic development tools are free. >> None of those things are true of the MSP430, though I'd readily >> admit that the MSP430 is a much nicer device in almost all >> respects. > > Until you hit the 60K code space limit or need an external bus, > I think the '430 is definitely the winner. I agree the MSP430 should beat the AVR hands down. But then again, I think even the AVR is nicer than the PIC, and the PIC seems to be quite popular, at least among tinkerers and experimenters who publish do-it-yourself projects on the web, which is where many people will get their first experience with a microcontroller. I think the package is a big factor. The MSP430 is just harder to work with, for a tinkerer. Perhaps if Texas Instruments released a DIP device with simple, free software tools, the MSP430 would become more popular in that market. >> I think the MSP430 is aimed more at the experienced >> developers, who don't mind paying for tools > > I found tools for the MSP430 to be far cheaper than for AVR. > A development board and JTAG interface from AVR runs about > $500. The same thing is $99 from TI or $50 from Olimex. I'm out of date on this one, I started with the AVR before the MSP430 even existed, but I didn't buy anything when I started with the AVR, and I haven't bought anything since, either. I use a reconfigurable cross-assembler, since I hate Atmel's one. I guess it depends on what you're doing with it. If you're a tinkerer, the AVR is simple to understand and quick to start tinkering with. If you're a professional, the MSP430 is clearly a far better choice. Kris k...@abbey.co.nz Kris Heidenstrom Embedded systems design engineer / programmer Abbey Systems Ltd Telemetry specialists Wellington New Zealand Voice +64 -4 -385-6611 Fax +64-4-385-6848
