两种方式实现TinyOS对MSP430F26&54系列的支持

第一种方式在Ubuntu 下TinyOS msp430 Toolchain mspgcc升级一文中已经作了详细分析，下面说说另一种方式实现TinyOS对MSP430高端系列单片机的支持。

我们已经知道TinyOS的编译过程，ncc编译器编译得到app.c文件，接着使用mspgcc编译工具对目标代码进行编译生成需要的.hex文件。但是，要注意的是在ncc编译过程中也会连接msp430库文件，所以就不可能在没有mspgcc的支持下得到app.c文件。那么，这里就出现了问题，如果没有按照上述所提到的第一种方式升级mspgcc，应该如何正确的编译得到所需的文件呢？答案就是使用挂羊头卖狗肉的方法，具体的就是.platform文件不用修改，通过拷贝IAR IDE下的msp430x26x.h（路径在/IAR Systems/Embedded Workbench 6.0 Evaluation/430/inc）到/usr/msp430/include下，并修改该目录下io.h文件中的

#elif defined(__MSP430_167__) || defined(__MSP430_168__) || defined(__MSP430_169__) || defined(__MSP430_1610__) || defined(__MSP430_1611__) || defined(__MSP430_1612__)

#include 改为#include

这样就可以保证编译的时候能够识别26系列中特有的寄存器定义。注意：不能通过修改.platform文件-mmcu=msp430x26.h然后效仿1611设置预编译条件，那样会提示错误，说什么该芯片不支持，然后列出一堆已经支持的系列号。

按照上面配置好之后，应该验证是否成功，验证的程序当然是基于26系列单片机的。可惜，编译的时候必定会有错误、警告，错误很好排查，最多就是找不到某些定义，而出现的警告确实让人头疼。主要的警告是关于某些中断向量无效，对比下两种MCU的数据手册，这很好理解，26的中断向量号已经超出了0xffff（如果是按照16系列向量起始地址的话）。但是，幸运的时，我们要采用的第二种方法并不关心这些问题，因为最终编译、连接生成目标文件并不是真正的连接这些库，这里只是为了骗过ncc编译器。

现在已经得到了app.c,下面我们的工作可以转换到Windows平台了。

首先，还是要搭建这个平台下的开发环境。这里，我们需要使用mspgcc for Win32工具链。资源在CSDN上就有，可以搜索mspgcc for Win32下载。压缩包中有两个版本，因为新版本中已经去除了make.exe和msp430-insight.exe，尤其是make.exe比较重要，这样我们通过makefile可以很方便的得到想要的生成文件。首先，安装旧版本，可以直接默认安装，然后在同一目录下安装新版本，安装时会有提示说当前应经安装，可以选择否，强行安装。安装完之后，设置一下环境变量，添加安装路径到PATH变量。这样就可以在命令行下运行命令了。Makefile的编写，下面给出一个模板，可以根据需要进行修改

NAME        = app

OBJECTS      = app.o

CPU          = msp430x2618

CFLAGS   = -mmcu=${CPU} -O2 -Wall -g

CC              = msp430-gcc

.PHONY: all FORCE clean download download-jtag download-bsl dist

all: ${NAME}.elf ${NAME}.a43 ${NAME}.lst

download: download-jtag

${NAME}.elf: ${OBJECTS}

    ${CC} -mmcu=${CPU} -o $@ ${OBJECTS}

${NAME}.a43: ${NAME}.elf

    msp430-objcopy -O ihex $^ $@

${NAME}.lst: ${NAME}.elf

    msp430-objdump -dSt $^ >$@

download-jtag: all

    msp430-jtag -e ${NAME}.elf

download-bsl: all

    msp430-bsl -e ${NAME}.elf

clean:

    rm -f ${NAME}.elf ${NAME}.a43 ${NAME}.lst ${OBJECTS}

dist:

    tar czf dist.tgz *.c *.h *.txt makefile

FORCE:

app.o: app.c

在文件所在目录下make，OK，可以看到所要的文件了。

比起第一种方法，该方法显然比较麻烦，其过程有可能并不那么顺利，那为什么还要用这种方法呢？原因很简单，TinyOS还不能在线仿真调试，这给编程带来了极大的困难。在用micaz平台时，我就使用了相似的方法，用WINAVR来在线调试，虽然只能在汇编形式下调试。另外，这种方法在TinyOS从CC2430向CC2530移植也很重要。在线调试的内容，整理好之后一并发上来。