Still, this shouldn't be hidden in the C library. Most other microcontroller platforms have a startup.S which is simply compiled together with the rest of the project. Startup.S takes care of any hardware dependant initialisation and jumps to main. For a developer it is very clear what the code does and there is no magic happening at hard to find places.
At 15:49 3-4-2009 +0200, you wrote: >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. > > >--------------------------------------------------------------------------- --- >_______________________________________________ >Mspgcc-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >
