MSP430 support

Forum related to ERIKA Enterprise and RT-Druid version 2

Moderator: paolo.gai

Post Reply
srl100
Newbie
Posts: 15
Joined: Thu May 20, 2010 2:07 pm

MSP430 support

Post by srl100 » 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:

Code: Select all

-EE_CC = msp430-gcc-4.4.3
+EE_CC = msp430-gcc
2) The Makefile and build system seem to require the variant of MSP430 processor to be defined in an EEOPT, e.g.

Code: Select all

EEOPT += __MSP430_1611__
which is then picked up in various places:

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)
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:

Code: Select all

CFLAGS += -mmcu=msp430x2231
ASFLAGS += -mmcu=msp430x2231
LDFLAGS += -mmcu=msp430x2231
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.

Code: Select all

MCU_DATA = MSP_430 {
    MODEL = CUSTOM {
        MODEL = "-mmcu=msp430x2231";
    };
};
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.

paolo.gai
Administrator
Posts: 875
Joined: Thu Dec 07, 2006 12:11 pm

Re: MSP430 support

Post by paolo.gai » Tue Mar 08, 2011 12:20 pm

Hi!

This is a great news! I'm happy that you found the MSP430 port useful, and that you are working on the Launchpad board!

The main problem for us currently is that we do not have an MSP430 system at hand, so it is quite difficult to check if the commits are working. It would be nice if you could also check that your modifications works correctly on the MSP430 (for a subset of the other architectures we do have the regression tests in place to guarantee that everything will continue to compile at least).

about the various points:

- About point 1: I agree the compiler pointed by the scripts should not have any reference to the compiler version. but the toolchain pointed in the wiki probably has that name as executable. What is the best thing to do?

---

- about point 2: Consider that the MSP430 was done as an initial support, which works fine but is not complete.

for ee_context.S and ee_oo.S I agree they could be moved in the CFLAGS (and then in the OIL file).

for ee_uart.h the code dose not seems related to the compiler architecture. So probably the __MSP430_1611__ should be generated anyway when using the MCU

And I agree too that we could do an OIL support for the platform... Do you mind doing it like you did with esiRISC, and then sending it to Nicola for integration?

---

- about point 3: I agree!

---

Finally, we will need to:
- update a little the wiki to include the new board
- put a news
- maybe put some posts on the launchpad community website?

Ciao,

Paolo

srl100
Newbie
Posts: 15
Joined: Thu May 20, 2010 2:07 pm

Re: MSP430 support

Post by srl100 » Tue Mar 08, 2011 6:38 pm

I don't have an UTMOST board (and can't find too much information out there as to what one of them is) but will, of course, update the existing code and check that it still builds after my changes for LaunchPad support.

I will look at the OIL support after I've got the basic Makefile-based building working.

paolo.gai
Administrator
Posts: 875
Joined: Thu Dec 07, 2006 12:11 pm

Re: MSP430 support

Post by paolo.gai » Wed Mar 09, 2011 1:55 pm

Hi,

I have just had an e-mail exchange with Christian on the topic... Hopefully he'll post something on the forum about his current sattus.

If he will not answer in a efw days, I guess you cn go on with committing your patches, then we'll make sure that everything will work out...

PJ

srl100
Newbie
Posts: 15
Joined: Thu May 20, 2010 2:07 pm

Re: MSP430 support

Post by srl100 » Sun Jun 12, 2011 9:35 pm

Just to complete the thread, if anyone is still following this, the June 8th 2011 release of Erika Enterprise (http://erika.tuxfamily.org/erika-for-mu ... vices.html) includes support for the MSP430 Launchpad board.

The wiki (http://erika.tuxfamily.org/wiki/index.p ... =TI_MSP430) has more information on how to specify the processor type and desired peripherals, and RT-Druid now includes a simple program that demonstrates use of the LEDs, button, ADC, interrupts and tasks.

paolo.gai
Administrator
Posts: 875
Joined: Thu Dec 07, 2006 12:11 pm

Re: MSP430 support

Post by paolo.gai » Sun Jun 12, 2011 9:47 pm

Hi Steve, Thanks for the update on the wiki!

PJ

Post Reply