两种方式实现TinyOS对MSP430F2654系列的支持

第一种方式在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 <msp430x16x.h>改为#include <msp430x26x.h>

这样就可以保证编译的时候能够识别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移植也很重要。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wwzzdw.html