Hi Nico, Yep I would agree, its a mess, any plan no how to fix it?
I have tried to document all the places in the past what needs changing to add a new processor to the list of supported devices, it would be excellent not to have make any changes to do this, or at least only keep it in one place. Could all the WEAK symbols be defined in io.h, then used by the linker, compiler etc to build all the code. No this to Sergey, I never understood why gcrt0.S was compiled for each processor as it contains no code, yes symbols are defined in different places, but that's the job of the linker to sort out. ----- Original Message ---- > From: N. Coesel <[email protected]> > To: GCC for MSP430 - http://mspgcc.sf.net <[email protected]> > Sent: Friday, 3 April, 2009 7:21:12 PM > Subject: 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. > > Nico Coesel > > ----- Original Message ----- > From: "Roberto Padovani" > To: "GCC for MSP430 - http://mspgcc.sf.net"; > > Sent: Friday, April 03, 2009 9:01 AM > Subject: [Mspgcc-users] changes of the memory mapping for family x5xx > > > > Hi all, > > > > in the new x5xx family a lot of the memory mapping of the peripherals > > has changed. > > In particular, the watchdog is now defined as: > > > > #define __MSP430_WDT_A_BASE__ 0x150 // msp430x54xx.h > > #define WDTCTL_ __MSP430_WDT_A_BASE__ + 0x0C /* Watchdog > > timer control register */ // wdt_a.h > > > > In the libgcc.S file there is: > > > > #if defined(L__low_level_init) > > /***************************************************************** > > * Initialize peripherial, particularly disable watchdog > > * can be overwriten > > *****************************************************************/ > > .section .init3, "ax", @progbits > > > > .global __low_level_init > > .weak __low_level_init > > > > .func __low_level_init > > > > __low_level_init: > > mov #0x5a80, &0x120 > > > > .endfunc > > #endif > > > > where the watchdog address 0x120 is hardcoded. This is correct for > > every MSP except for the newer x5xx family. > > Is there anyone knowing the internals of the GCC who can fix or > > suggest how to fix this ? > > Parametrizing would be best, maybe with two different __low_level_init > > functions that are linked against depending on the processor family. > > > > R# > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users Yahoo!7 recommends that you update your browser to the new Internet Explorer 8.Get it now.
