[Tinyos-devel] ti msp430 cc

Wed Mar 11 13:40:10 PDT 2009

As some of you may be aware, support for extended flash range used by
devices such as the MSP430F2618 are not fully supported by msp430-gdbproxy
and cannot easily be remedied.   My project has surpassed the capacity of
.text region, and I require support for the extended flash range.  My
solution is to migrate to Code Composer Essentials as the c compiler for the
msp430 as alluded to by this thread.  My project is written in tinyos-1.x
and is based on the telosb platform.

I have successfully modified blink (compiled for telosb from tinyos-1.x) to
build on CCE, to run on a tmote sky.  Now I am in the process of modifying
mangleAppc.pl which is used for 8051 development that converts app.c to
third-party compilers to “mangle” for CCE as well.  I am not proficient with
perl and regular expressions so I could use some help with this.
“mangleappc.pl” can be found here:
http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/diku/mcs5
1/support/make/mcs51/

Can anyone provide guidance on the best way to make these modifications and
how to do these in the magleappc.pl script?

First thing that must be done is convert interrupts to CCE syntax.  

Convert this:

__attribute((wakeup)) __attribute((interrupt(50))); 

To this for all interrupts:

__interrupt void sig_TIMERA0_VECTOR(void);

#pragma vector = TIMERA0_VECTOR 

The function prototype must also be modified.

Convert this:

__attribute((wakeup)) __attribute((interrupt(50))); 

To this for all interrupts:

__interrupt void sig_TIMERA0_VECTOR(void);

I was thinking of something like a translation for this for each interrupt
source: $string =~ tr/[a,e,i,o,u,y]/[A,E,I,O,U,Y]/;

Next, CCE already has registers defined by the linker cmd script so all
register definitions can be modified as follows:
volatile unsigned char P1OUT __asm ("0x0021");
changes to:
extern volatile unsigned char P1OUT ;// ("0x0021");

Register Definitions:

In tinyos there are some registers defined within components so they look
something like MSP430ClockM__TA0CTL.  This was done to circumvent nesc
compiler warnings for non-atomic access to shared variables.  Since this is
a cludge anyway, I have considered adding a compiler flag to the tinyos
project that could be used to define these globally instead.  This creates
many non-atomic warnings, but it would keep us from defining each register
definition in the linker command script for component that defines them.

Enums Greater than 65535:

Another problem I haven’t figured out yet is that enumerations default to 16
bit, but tinyos is littered with enums, many of which are initialized to
values larger than 16 bits.  These either need to be identified and changed
to #define instead, or perhaps CCE can be configured so this isn’t a
problem.  I haven’t found the latter yet.

NOP

In CCE inline assembly, the following inline assembly produces an error:
__asm volatile ("nop"); 

Since the “nop” doesn’t have any preceding spaces, it assumes this is a
label.  This produces an error stating that label nop is multiply defined.
One solution is just to have the script replace “nop” with “    nop”
instead.  Another alternative is to replace the entire line with
“__no_operation();” (minus quotes) instead.  Can someone provide a perl code
snipet for doing this? 

Enable Interrupts:

This line can be modified to “__disable_interrupts();”

Disable Interrupts:

This line can be modified to “__enable_interrupts();”

are_interrupts_enabled(void):

The inline assembly “     __asm volatile ("mov  r2, %0" : "=r"((uint16_t
)__x));__x;”  must be modified to use correct CCE inline assembly, or it can
be modified to use the CCE standard function call “__get_SR_register();”

TOSH_run_task(void):

The following infinite loop needs braces around TOSH_run_next_task();

  for (; ; ) 

    TOSH_run_next_task();

These are all of the issues I currently have.  There may be more once these
have been resolved. 

Thanks for your help,

Hugh

From: tinyos-devel-bounces at millennium.berkeley.edu
[mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Geoffrey
Werner-Allen
Sent: Tuesday, November 11, 2008 9:57 AM
Cc: tinyos-devel at millennium.berkeley.edu
Subject: Re: [Tinyos-devel] ti msp430 cc

Hi Martin, Steve:

We had heard at Sensys'08 that someone had written a script to strip the
GCC-specific stuff out of the nesc output C code so that it could be fed
through another compiler.  I've been warned multiple times about problems
with msp430-gcc and the project seems to dormant, so it might be prescient
to start thinking about how we can support other compilers.  I've heard some
of the commercial ones generate significantly better code.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner

On Tue, Nov 11, 2008 at 4:27 AM, Martín René <martinvilu at gmail.com> wrote:

Hello
For what i know, the code generation is fine tuned to the facilities
provided by the GCC compiler, and using a diferent compiler wouldn't get the
same results, thats one of the reasons of the difficulties porting to the
8051 plattform.
Hope that answers your question
Saludos!

Martín René Vilugrón
San Carlos de Bariloche
Patagonia Argentina

On Tue, Nov 11, 2008 at 1:05 AM, Stephen Dawson-Haggerty
<stevedh at eecs.berkeley.edu> wrote:

Hi All-- I've heard that using the TI msp430 c compilier both (a) is
possible and (b) generates smaller code.  I gather doing so requires a
script to convert app.c to pure ansi-c, though.  Anybody know more about
this?  I think a number of people would be interested in the answer...

Thanks.
Steve

_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090311/c7854ff7/attachment-0001.htm 