MSP430 support
Posted: Mon Mar 07, 2011 10:39 pm
Hi All.
I'm working on a basic MSP430 LaunchPad board support package (just the 2 LEDs, 1 button, temperature sensor on ADC and timer, probably) and have some questions regarding the current MSP430 support.
1) The compiler rules in pkg/cfg/arch/cc_msp430.mk seem to be tailored to a particular version of the compiler (msp430-gcc-4.4.3). The version I have installed is different to this (4.4.5). Would there be any objections if I changed the .mk file to drop the version extension for each of the tools, leaving it up to the developer to provide (soft) links if required?
e.g. In SVN diff format:
2) The Makefile and build system seem to require the variant of MSP430 processor to be defined in an EEOPT, e.g.
which is then picked up in various places:
I think that this means that for each new processor variant to be supported the build system must be updated.
Instead of this, could we define the processor variant in the Makefile's CFLAGS, ASFLAGS and LDFLAGS thus:
In the fullness of time this could be automatically generated using a custom MCU_DATA item in the .oil file, as is done for the eSi-RISC support,e.g.
3) The initialization routine in the current support is called EE_msp430_init(). All this seems to do is disable the watchdog, so wouldn't the name EE_watchdog_disable() be more appropriate (and useful in more situations)?
Apart from the above points (which I have worked round locally for now) the BSP is pretty much done and working with a demo application to periodically sample the temperature and show changes on the two LEDs (the "Hello World" of LaunchPad programming!) using ERIKA Enterprise tasks and ISRs.
I'm working on a basic MSP430 LaunchPad board support package (just the 2 LEDs, 1 button, temperature sensor on ADC and timer, probably) and have some questions regarding the current MSP430 support.
1) The compiler rules in pkg/cfg/arch/cc_msp430.mk seem to be tailored to a particular version of the compiler (msp430-gcc-4.4.3). The version I have installed is different to this (4.4.5). Would there be any objections if I changed the .mk file to drop the version extension for each of the tools, leaving it up to the developer to provide (soft) links if required?
e.g. In SVN diff format:
Code: Select all
-EE_CC = msp430-gcc-4.4.3
+EE_CC = msp430-gccCode: Select all
EEOPT += __MSP430_1611__Code: Select all
pkg/cpu/msp430/src/ee_context.S: #ifdef __MSP430_1611__
pkg/cpu/msp430/src/ee_oo.S: #ifdef __MSP430_1611__
pkg/mcu/msp430/inc/ee_uart.h:#ifdef __MSP430_1611__
pkg/mcu/msp430/cfg/cfg.mk:ifeq ($(call iseeopt, __MSP430_1611__), yes)Instead of this, could we define the processor variant in the Makefile's CFLAGS, ASFLAGS and LDFLAGS thus:
Code: Select all
CFLAGS += -mmcu=msp430x2231
ASFLAGS += -mmcu=msp430x2231
LDFLAGS += -mmcu=msp430x2231Code: Select all
MCU_DATA = MSP_430 {
MODEL = CUSTOM {
MODEL = "-mmcu=msp430x2231";
};
};Apart from the above points (which I have worked round locally for now) the BSP is pretty much done and working with a demo application to periodically sample the temperature and show changes on the two LEDs (the "Hello World" of LaunchPad programming!) using ERIKA Enterprise tasks and ISRs.