TinyOS在MSP430F2618上移植转

2万 · 2013-4-25 01:12

最新版本的TinyOS2.1.1，虽然增加了更多的平台支持，比如epic、shimmer，但是这些平台都有一个共同的局限性：采用的微控制器都是低端的MSP430系列，如MSP430F149、MSP430F1611。在一些应用场合，这些处理器已经不能达到性能要求，而基于ZigBee的开发平台，如TI推出的开发套件已经开始使用高性能的处理器，并且国内一些公司，如成都无线龙也都纷纷推出基于MSP430F2618和CC2520无线收发模块，这个模块自从它诞生就很好的支持了ZigBee,因为有TI的全力支持，并且相关的演示代码TI都已经准备好了。但是，目前还没有把TinyOS移植到MSP430F2618上的先例。网上很多人说，这个移植很简单，但是为什么现在还没有成功的案例呢？或许是有的，只是我没有找到而已。那么下面就先分析一下移植的关键点：

首先，通过比较MSPF2618与MSP430F1611的datasheet可以发现，这两款芯片的存储器映射就大不相同，下图是2618的存储器组织结构

值得注意的就是code memory的起始地址以及占用空间长度、中断向量表地址映射、RAM空间的地址映射。下图是1611存储器组织图

2万 · 2013-4-25 01:12

对比可以发现，两个地址空间有很大的不同。在TinyOS中设置存储器映射的文件是在/msp430/lib/script中，不过这些只是编译时的脚本文件，直接修改这些文件并不能解决问题，所以最终的办法就是升级你的mspgcc编译工具链，其安装升级方法可以参阅我的另一篇**Ubuntu 下TinyOS msp430 Toolchain mspgcc升级。还有就是两种MCU相关寄存器地址的映射，主要还是USCI端口的设置，2618提供4组USCIA0/1，USCIB0/1,比1611多了两组，还有就是2618的USC1A1/B1的中断使能以及状态寄存器不再是由特殊功能寄存器设置，并且没有了mode enable registers 1/2。USCI接口的移植可以说是最繁琐也是最核心的。其他寄存器的配置可以参考数据手册。当升级了mspgcc，MSP430相关库中也已经包含了相应的头文件，需要修改的就是.platform文件中-mmcu的设置，以及版本信息的设置。

2万 · 2013-4-25 01:12

对比MSP430F1611与MAP430F2618,可以看出两者最大的不同点在于后者提供了更丰富的外围接口，分为A,B两组，其中A组的功能有UART、IrDA ,B组提供SPI、I2C功能，另外A组也可以配合B组中提供的SCK作为SPI接口。在A,B组中又分为两个独立组，A0/1，B0/1。

2618中特殊功能寄存器也做了改动，去除了模块使能寄存器1、2（module enable register 1 and 2）ME1以及ME2，特殊功能器IE2，IFG2中仅包含A0和B0相应的接收/发送中断使能以及中断状态位，而A1和B1相应的中断使能以及中断状态则有寄存器UC1IE和UC1IFG相应位实现。所以，首先得修改McuSleepC.nc中出现的ME1，ME2，在getPowerState()中使用UCB0/1CTL1 和UCA0/1CTL1替代，即当USCI使用时钟源为UCSSEL_1(ACLK)时，返回当前的电源状态为LPM1。

修改HplMsp430GeneralIOC.nc中引脚配置，去除所有宏定义（否则编译时出现引脚未定义错误），重新配置接口（主要是USCI接口）。

修改msp430usart.h。根据2618中相应寄存器修改数据结构，定义数据类型msp430_ucactl0_t,msp430_ucactl1_t(Async_mode)和msp430_ucbctl0_t, msp430_ucbctl1_t (Sync_mode)，并增加相应的DEFINE_UNION_CAST宏，实现定义的结构体类型与整型之间相互转换。定义用于SPI接口配置的数据类型msp430_spi_config_t，其中包括16bit的波特率UBR，8bit的UCTL0以及8bit的UCTL1寄存器相应位的定义。定义用于UART接口配置的数据类型msp430_uart_config_t，其中包括16bit的波特率UBR，8bit的UMCTL ,8bit的UCTL0以及8bit的UCTL1寄存器相应位的定义。

回到usart目录下，由于低版本MSP430系列仅采用两个分组1,2，而2618中使用了A,B分组，而每一个组中又包括两个分组1,2。分别增加HplMsp430UsartA0C.nc，HplMsp430UsartA0P.nc，HplMsp430UsartA1C.nc，HplMsp430UsartA1P.nc，HplMsp430UsartB0C.nc，HplMsp430UsartB0P.nc，HplMsp430UsartB1C.nc，HplMsp430UsartB1P.nc。上述文件使用的接口HplMsp430GeneralIO分别连接到不同的接口上实现不同的功能。在文件msp430regtypes.h中增加相应数据类型的定义，即定义寄存器的数据类型，然后在上述P文件中使用MSP430REG_NORACE。

由于A和B两组共用同一类中断，如A0/B0使用USCIAB0RX_VECTOR接收中断向量，那么在TOSH_SIGNAL(USCIAB0RX_VECTOR)中应判断触发此中断的是哪一组，在中断中通过判断此时中断标志位和中断使能位指向哪一组，当这两个条件都成立时，读相应的数据寄存器，并触发Interrupts接口的rxDone。删除与ME1/2相关的语句，修改相应的寄存器选项。

2万 · 2013-4-25 01:13

实现SPI功能。增加Msp430SpiA0C.nc，Msp430SpiA1C.nc，Msp430SpiB0C.nc，Msp430SpiB1C.nc这4个文件供外部接口使用SPI功能时连接使用。在使用SPI功能时可以使用DMA模式，增加Msp430SpiDmaA0/1P.nc，Msp430SpiDmaB0/1P.nc，Msp430SpiNoDmaA0/1P.nc，Msp430SpiNoDmaB0/1P.nc共8个文件，实现上述4个C文件向上层连接，最终由Msp430SpiDmaP.nc，Msp430SpiNoDmaP.nc两个文件实现接口提供的功能。而向下层连接是通过增加Msp430UsartB0C.nc，Msp430UsartB1C.nc，这两个文件连接Hpl层，并且连接到资源仲裁层，通过增加Msp430UsartShareB0P.nc，Msp430UsartShareB1P.nc实现。

与实现SPI功能相似，UART功能由下述方法实现。增加Msp430Uart0/1C.nc, Msp430Uart0/1P.nc，其中Msp430Uart0/1C.nc用于外部接口使用UART功能时连接。向上层连接通过Msp430Uart0/1P.nc连接到Msp430UartP.nc,该文件实现UART接口的功能。而向下层连接是通过增加Msp430UsartA0C.nc，Msp430UsartA1C.nc，这两个文件连接Hpl层，并且连接到资源仲裁层，通过增加Msp430UsartShareA0P.nc，Msp430UsartShareA1P.nc实现。

通过上述配置即可完成USCI的移植，通过编译过程中出现的错误再做相应的修改。

使用SPI时通过连接模块Msp430SpiA0C.nc，Msp430SpiA1C.nc，Msp430SpiB0C.nc，Msp430SpiB1C.nc，选择其中的一组，最后提供一个组件使得上述4个文件中的Msp430SpiConfigure接口连接到此组件，实现配置SPI功能。

使用UART时通过连接模块Msp430Uart0C.nc, Msp430Uart1C.nc,选择其中的一组，最后提供一个组件使得上述2个文件中的Msp430UartConfigure接口连接到此组件，实现配置UART功能。

最后，TinyOS2.1.1默认的时钟源选择的是DCO默认设置,其频率在1.1MHZ左右。在MoteClockC文件中取消对MoteClockP。Msp430ClockInit -> Msp430ClockC语句的注释，意义在于使用本平台下的时钟初始化函数。修改MoteClockP文件中setupDcoCalibrate函数，开启XT2时钟源，并将MCLK和SMCLK都设置为以XT2为时钟源。并根据需要修改initClock函数，可以直接注释掉前两句。

2万 · 2013-4-25 01:13

总体架构：分为3层结构，最底层位于相应的platforms中chips目录下，实现在特定平台上控制引脚连接，SPI接口连接，以及SPI配置。中间层实现了LCD基本操作，LCD初始化，提供给上层模块连接的接口，以及资源管理。最上层提供应用层模块连接的接口。

在本架构中，中间层和最高层提供相同的接口LCD16，该接口提供的实现方法有english_string，clear，single_color等，以及写完成事件writeDone。不同的是在最高层提供的接口LCD16中，并没有真正实现接口的功能，而仅仅是获得应用层传递的显示参数并设置相应的状态变量，在保存参数后，申请资源，当资源granted后，通过判断当前状态变量，调用中间层接口LCD16相应的实现。在中间层LCD16接口的实现完成后，通过提交任务的方式触发写完成事件writeDone（最好使用任务提交的方式，根据TinyOS官方的说法，这样可以防止消耗过多的堆栈），最高层响应此事件，释放先前申请的资源，并触发写完成事件writeDone，这样应用层便获得了此事件。

接口ST7735Power实现LCD启动流程。提供的行为有start，stop，lcdinit，以及事件startDone，lcdinitDone。启动流程：应用层调用最高层SplitControl.start后，由最高层call 中间层SplitControl.start，中间层完成相应操作后signal SplitControl.startDone，最高层收到此事件后call Power.start，做LCD初始化前准备（复位LCD），并signal Power.startDone，最高层在此事件中申请资源，当资源允许时，call Power.lcdinit，中间层在LCD初始化完成后signal Power.lcdinitDone，之后最高层释放资源，并signal SplitControl.startDone。至此LCD启动完成。

应用层使用LCD时必须use两个接口LCD16和SplitControl，在SplitControl.startDone后即可使用LCD16其他实现。

2万 · 2013-4-25 01:13

采用3层模型，最底层实现在特定平台中的引脚连接，以及SPI接口的连接。中间层提供Flash接口，该接口为带参数接口（主要是为了学习带参数接口的应用，FLASH的擦除可以体现此方法的优点），参数即为写FLASH的命令。最高层提供应用层模块的接口。

在本架构中，中间层和最高层提供相同的接口Flash，该接口提供的实现方法有erase，perase（提供块擦除和区域擦除），read，write。最高层接口的实现中并没有给出真正的FLASH操作代码，而仅仅是保存了应用层传递的参数，并且设置当前状态变量，申请SPI资源是操作的关键，因为FLASH的操作都是通过SPI接口进行的，当资源申请成功后，根据当前状态，调用中间层FLASH接口相应的实现函数，这样就把应用层的参数传递到中间层，这时开始真正的FLASH操作。

因为接口Flash是带参数的接口模型，那么就需要给出不同的实例，在配件HplFlashC和FlashC中提供了接口Flash的不同实例，包括Flash_program，Flash_read，Flash_chiperase，Flash_blocherase，Flash_sectorerase，而这些接口分别连接到HplFlashWireC和FlashWireC，而其中的接口参数分别为对应的FLASH操作命令。最高层Flash接口连接到中间层Flash接口上，而应用层使用的Flash接口则连接在最高层Flash接口上，这样就完成了整个配线过程。

执行流程：通过接口SplitControl的start启动，该操作完成FLASH控制线的配置，最高层SplitControl接口连接到中间层SplitControl接口上，实际的操作都是在中间层完成。当SplitControl的startDone 触发后，就可以执行接口Flash提供的函数。

应用中需要使用SplitControl接口和Flash接口，连接到模块FlashC上。