> On 2006-03-15, Chris Liechti <cliec...@gmx.net> wrote: > > Grant Edwards schrieb: > >> I've been looking at the code generated by avr-gcc 3.4.5, and > >> it sure looks like there's a lot of extra overhead involved in > >> ISRs. Let's write an ISR that just toggles a port pin every > >> time the interrupt happens. > > > > you're posting that to the mspgcc mailinglist, don't expect too deep > > insight in the AVR architecture from us ;-) > > Doh! That was obviously meant for the avrgcc mailing list. > > I just hope you guys know how good you got it not having to > fight with the AVR's brokeness. I'm doing parallel > implimentations of some prototype code on MSP430 and AVR. > > 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 code generated by gcc for small functions on the MSP430 is > a _fraction_ (like 1/4-1/5) of the size on the AVR. After the > functions get large enough that the prologue/epilogue don't > matter, AVR code is about 50% larger than MSP430 code. > > And AVR parts are _expensive_. I honestly don't see why > they're popular at all... > > -- > Grant Edwards grante Yow! I smell a RANCID > at CORN DOG! > visi.com >
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). The AVR has a definite advantage in the wider range of supply voltages, and the internal EEPROM is better (more write cycles) than the MSP430's parameter flash. There's no doubt about the cores, however - the MSP430 is very C-friendly, while the AVR is at best IAR-C-friendly. This means that the msp430 gcc port has a more natural feel to it - the avr gcc port is especially awkward with flash data (and they got their signal/interrupt keywords mixed up). Debugging is also easier with the msp430, using dirt-cheap Olimex debuggers rather than more expensive Atmel hardware. As far as code size or performance is concerned, the AVR and MSP430 are actually not far apart for real code - the AVR code size is a bit bigger, but is often faster. 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. The function call overhead of small functions is often reduced in practice by the optimiser inlining the functions - with the gcc 4.1 release with whole program optimisation, the compiler should figure out inlining and reduce prologues/epilogues even for cross-module funciton calls. Small interrupt functions like your example are probably the worst possible comparison from the AVR's viewpoint. Some of the issues are: * The msp430 automatically preserves the status register on interrupts - with the avr, it must be done by code. * 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. * There is (currently) no optimisation in the compiler to remove unnecessary parts of the interrupt prologue. I believe there are people looking at it, but I don't know any more. * The avr has no "eori" instruction, making the toggle code particularly cumbersome. mvh., David
