[Tinyos-devel] ti msp430 cc

Thu Mar 12 00:26:29 PDT 2009

Just as a side note, in the Core WG, we are in very early stages of testing
the modified mspgcc toolchain for the MSP430X series:

http://apps.sourceforge.net/mediawiki/mspgcc/index.php?title=Linux_installation_(MSP430X)

Until now I have not seen any significant problems with the existing test
applications. It still remains to be checked which if any of the existing
mspgcc bugs (like the HW multiplier, etc. that we have workarounds in the
tinyos code base) have been fixed by the update. Once we build more
confidence with using the toolchain, we will package it and start with the
full migration.

Finally, please consider moving away from tinyos-1.x. I know that sometimes
it can be hard to port an existing 1.x project to 2.x, but the benefits of
moving to the new architecture are significant.

Vlado

On Wed, Mar 11, 2009 at 9:40 PM, Hugh Hartwig <hugh at halomonitoring.com>wrote:

>  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/mcs51/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<http://www.eecs.harvard.edu/%7Ewerner>
>
> 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
>
> _______________________________________________
> 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/20090312/2d102f3a/attachment.htm 