On Tue, Sep 25, 2012 at 1:07 PM, Esmil <[email protected]> wrote: > Hi, > > I have a small project with a few functions implemented in a separate > assembly file. When compiling I essentially do > > msp430-gcc -mmcu=msp430g2231 -O2 -pipe -g -std=gnu99 -Wall -Wextra > -Wno-variadic-macros -pedantic oneslave.S lcdslave.c -o lcdslave.elf > > (See https://github.com/esmil/msp3n1s/blob/master/examples/lcdslave/lcdslave.c > for the full source.) > > This all works fine, except now I'd really like to include msp430.h > from the msp430mcu package in my assembly file, so I can do stuff like > > #if defined(__MSP430_HAS_TA2__) > .. > #elif defined(__MSP430_HAS_TA3__) > ... > #endif > > The headers seem to be designed to work in both assembly and C code. > However, what it does is this > > #ifndef __STDC__ > /* assembly stuff */ > #else > /* C stuff */ > #endif > > (see fx. msp430g2231.h) > > The problem is that __STDC__ *is* defined when running the > preprocessor on my assembly file, so the C stuff ends up being defined > in my assembly code. A quick fix is of course to do > > #undef __STDC__ > #include <msp430.h> > > in the beginnig of the assembly file, but that gives a warning and > doesn't quit feel right. > I don't know the exact semantics of __STDC__ but it seems to me the > right solution is to do > > #ifdef __ASSEMBLER__ > /* assembly stuff */ > #else > /* C stuff > #endif > > as is already done in the iomacros.h header. However this means > running a sed-script on all the TI headers, and I don't know if the > policy is to keep those intact. > > Anyway what are your thoughts on this?
Yes, the policy is to keep the TI headers intact. Please file a tracker ticket at https://sourceforge.net/tracker/?group_id=42303&atid=432701 raising this issue, and I'll assign it to the TI engineer who supplies those files to change #ifndef __STDC__ to #ifdef __ASSEMBLER__. That fix would be in a future msp430mcu release and would be incorporated into the development release, but would not be back-ported to any LTS release. The workaround until this is fixed is, as you suggest, changing those files within your local installation. Alternatively, I don't see anything that's going to be a showstopper with what happens when <msp430.h> is included; it does do the "wrong" thing for a couple macros, which you could redefine as below in a backwards-compatible way, and includes <in430.h> but that header protects with __ASSEMBLER__ so should be safe. #include <msp430.h> #ifdef LPM0_bits #undef LPM0 #define LPM0 LPM0_bits #endif If there is something else going wrong, please identify it in your tracker report. If you go further with this plan, you may find situations where the headers define constants like ADC10BUSY with parentheses that are not acceptable to the assembler in certain expressions (they'll look like syntactically wrong indexed register expressions). Please file a separate tracker issue for that (one issue is fine, with one or more examples, and I'll make sure all relevant cases get handled). Peter > /Emil > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
