There are always some hardware-dependent things you cannot leave unaddressed.
Unfortunately, clearing the RAM and copying the variable initialisation can take longer than the WDT will allow with its PUC settings. So it is absolutely necessary to somehow address this. When MSPs did have only 256 bytes of RAM, the WDT was not a problem, but when devices with up to 16KB were introduced, it proved impossible to 'just do the C stuff and ignore the hardware' in the startup code. 'other GCC flavors' usually don't have a WDT. And some have a WDT PUC-default of several hundred to thousands of milliseconds. Currently the WDT is disabled, but that's a bad thing too (see my other post). JMGross ----- Ursprüngliche Nachricht ----- Von: N. Coesel An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 03 Apr 2009 10:21:12 Betreff: Re: [Mspgcc-users] changes of the memory mapping for family x5xx I've typed this before and I'll repeat it again: this issue again proves that the close integration between processor families and the MSPGCC toolchain is a bad idea. Most questions on this mailing list are about problems due to this close integration. IMHO the toolchain should have modes for architectural differences like other GCC flavors have. This forces developers to 'tailor' the toolchain to the controller they are using and eliminates questions about 'unsupported' controllers. Also, initialisation of microcontroller pheripherals shouldn't be done inside a C library at all. The low level initialisation should setup the stack, clear the RAM and jump to main. Have the developer choose what gets initialized and how. That's how its done on other architectures and probably for a good reason.
