Contiki OS MICAz 平台开发

最近由于项目的需要，这几天开始研究基于Linux Ubuntu的Contiki微操作系统在micaz平台的开发环境搭建。由于这个系统的资料网上非常难找，基本上都是英文的资料，所以我想将自己在开发中的心得体会写下来，希望后来者能够少走点弯路。

大家学习的时候可以参考的网站


 

Contiki OS

Contiki是Contiki 是一个小型的，开源的，极易移植的多任务电脑操作系统。它专门设计以适用于一系列的内存首先的网络系统，包括从8位电脑到微型控制器的嵌入系统。Contiki只需几kilobyte的代码和几百字节的内存就能提供多任务环境和内建TCP/IP支持。作为基础的内核以及大部分的核心功能是Swedish Institute of Computer Science的网络内嵌系统小组的Adam Dunkels开发的。下载地址  

Contiki开发环境有两种方式，其一为InstantContiki，在Windows系统中用VMware虚拟机模拟contiki开发环境,另一种是在Unbuntu系统中直接下载Contiki操作系统。两种方式各有利弊，第一种方式适合初学者，因为所有Contiki编译开发所需要的开发包，库，组件都已经安装好，是一个已经调试好的开发环境，适合不熟悉Linux系统菜鸟和初学者，缺点为安装包很大（1.9G），以及对系统的硬件要求很高（因为系统用虚拟机运行）。第二种方式的优点是安装包很小（28M），对系统硬件要求低，运行更流畅。缺点就是需要自己安装所有需要的组件，库，需要熟识Linux的开发环境以及命令。我选择的是后者，当然在调试中遇到了很多麻烦，但都一一得到了解决，反而对Linux的操作和认识都由一定的提升。下载完Contiki操作系统后，需要更新相关的库，几个比较重要的库和软件为：avr-gcc, avrdude, uisp, automake等等就不一一累述，大家可以到新立得软件包中去找。

MICAz MRP2400 平台

MICAz是Crossbow technology公司出品的新一代微型传感器，MP2400（带宽2400MZ到2483.5MHZ）使用Chipcon出品的CC2420 RF射频芯片，支持IEEE 802.15.4 zigbee传输协议，集成Amtega128L 8位微处理器，支持51针I/O接口。

Contiki Rime Stack

#define RIMEADDR_CONF_SIZE              8

#define NETSTACK_CONF_NETWORK rime_driver
#define NETSTACK_CONF_MAC     csma_driver
#define NETSTACK_CONF_RDC     cxmac_driver
#define NETSTACK_CONF_FRAMER  framer_802154
#define NETSTACK_CONF_RADIO   cc2420_driver

 

• radio：射频部分的驱动，在 core/dev/cc2420.*，相应的平台有相应的radio驱动
• Framer: 802.15.4
• RDC: Radio的管理机制在core/net/mac下，cxmac.c 是一种机制，其他的可以通过设置编译到系统中
• MAC：MAC层的管理机制，同样通过配置或得，有csma_driver 可知这里选择的是csma机制。
• 适配层：6LowPAN适配层，对mac层的数据进行压缩报头等数据分析与重组。core/net/sicslowpan.c,由input函数进入此函数
• network: 对数据进行处理，由core/net/tcpip.c下的tcpip_input（），packet_input（），uip_input（）函数完成最后将数据交给uIP协议栈，最后由UIP_APPCALL（）将数据包分发给不同的应用程序。
• App：应用程序

从这个过程看，第一个radio中的驱动是紧密与硬件平台有关系的，只能对于相应的硬件平台选择适当的driver，而其他各层却不是与硬件层紧密相连的。但是一些实现需要硬件的支持，所以有些虽然不与硬件之间相关，但是由于硬件本身不支持，所以无法实现一些可以的算法。尤其是在RDC层，因为这个设计无线射频的功耗，也是Contiki之所以作为网络系统优秀的原因。

从RDC和MAC的文件在同一个文件夹下可知，他们之间应该是有紧密的联系。适配层和Network在同一个文件夹下可知，他们应该是有紧密的联系。

这里使用这样的宏定义，其实是已经在各个模块中都初始化好的一组函数指针的集合的结构体的全局变量，这种方式将C语言实现成了类，只是这里边只包含了操作，但是没有包含数据。这样的方法，很是巧妙。而且有效地隐藏了信息，很好地做到了信息隐藏。

在低功耗网络中，无线收发设备必须时常休眠以节省电量。在Contiki中，负责这个工作的是RDC（Radio Duty Cycling）层。Contiki提供了一系列RDC机制。默认的就是ContikiMAC。MAC（Medium Access Control）层处于RDC的上层。MAC层负责避免数据在传输过程中的冲突以及重传数据包。Contiki提供了两种MAC层，一种是CSMA（Carrier Sense Multiple Access 载波侦听多路访问）机制以及NullMAC机制（只负责对数据的转接而不对数据进行任何的操作）。

•  MAC驱动

       Contiki提供了两种MAC驱动，CSMA（载波监听多路访问）NullMAC。默认为CSMA。MAC层接收来自RDC层的数据并通过RDC层来转发数据包。假如RDC层或者是radio层检测到数据碰撞，MAC层就要重发这个数据包。如有数据碰撞只有CSMA支持重发。

• RDC驱动

       Contiki有多种RDC驱动。最常用的就是ContikiMAC，X-MAC，CX-MAC，LPP以及NullRDC。默认的而是ContikiMAC，它具有很好的功率效率，但有些更偏向于802.15.4无线设备以及CC2420无线收发设备。X-MAC是一个较旧的机制，它不像ContikiMAC那样有高功率效率，但是有较严格的时序要求。CX-MAC（兼容的X-MAC）比X-MAC有更宽松的时序要求，因此能在更多的无线设备上工作。LPP（Low-Power Probing）是一个随接收器启动的RDC协议。NullRDC是一个空的RDC层，它从来不会关闭无线设备，因此可以用来测试或者与其它的RDC驱动比较使用。
       RDC驱动尽量保持无线设备休眠并且定期检查无线传输介质。当进行检测时，无线设备接收数据包。信道检查频率以HZ为单位，指定每秒信道检查的次数，默认为8HZ。典型的信道检查频率为2、4、8、16HZ。
通常传输的数据包必须重复发送直到接收器打开检测。这就增加了耗电量以及无线通信流量（traffic）进而影响与其它节点的通信。一些RDC驱动允许阶段优化即推迟选通（strobe）发送的数据包直到接收器将要唤醒。这需要两个节点之间良好的时间同步，如果以1%的时钟差那么唤醒时间将贯穿整个发送阶段窗口每100个周期，比如在信道检查频率为8HZ的时候是12秒。当传送包的时间间隔为几秒的时候这将让阶段优化失去作用，因为发送者必须在接收器唤醒之前提前准备好发送的数据。时钟漂移校正（clock drift correction）可能解决这个问题。这些Contiki RDC驱动被称作：

contikimac_driver
xmac_driver
cxmac_driver
lpp_driver
nullrdc_driver

The diagram above displays the flow of control within the Contiki OS during network input.  Data originates packaged with all layer headers via the hardware driver process.  In this case, the socketradio.c/h files specify how to pull information from the underlying OS IPC socket. The raw data is copied from the socket to the packetbuf memory buffer, which is typically reserved for MAC layer processing of data. The faint green arrow displays this movement of data from the socket to the memory buffer.  Control then shifts from the device driver process into the OS network stack.  The network stack is a series of preconfigured (during compilation) function calls that chain into each other up and down the stack.  For sicslowpan/sicslowmac, the network stack is composed of the sicslowpan driver (network layer), thenullmac driver (MAC layer), the sicslowmac driver (Radio Duty Cycle), the framer802154 driver (Framer), and a variable radio driver that was chosen to be the socketradio device driver in this case to socket communication with ns-3.

From the device driver, control moves up the stack starting at the radio duty cycle component as shown by the yellow arrow leading out of the device driver process.  The RDC invokes the framer whose responsibility is to parse the contents of the packetbuf buffer and assign values to globally accessible structural variables that indicate packet information such as header lengths.  Once packet inspection is complete, the framer returns control to the RDC, which then invokes the assigned radio duty cycle driver - sicslowmac.  Processing at this stage is focused on stripping the layer 2 header from the contents of the packetbuf buffer since all pertinent information has been recorded into separate variables by the framer.  The sicslowmac driver then calls up the stack to the configured nullmac driver.  Here, no operations occur involving any memory buffers. Control then forwards onto the network layer.  The sicslowpandriver is called via the network stack whose main responsibility in the upward stack direction is header decompression.  The sicslowpan driver reads the packetbuf buffer and compressed fields are decompressed into the sicslowpan_buf buffer.  Once decompression of the compressed header is complete, the payload is copied from the packetbuf buffer to the correct address following the uncompressed layer 3 header in the sicslowpan_buf buffer.  Finally, once the full packet is assembled, it is copied from the sicslowpan_buf buffer to the uip_buf buffer.

Control is then forwarded to the tcpip_process using a process_post_sych.  This schedules an event that is immediately processed and the tcpip_process is signaled with the TCP_POLL event.  Further layer 4 and subsequent layer 7 processing continues after the delivery of the data from the network stack to the expected uip_buf buffer.

Sending data follows a similar flow of control but in the reverse direction.  The application layer data is written to the payload of the uip_buf buffer and the layer 3 headers are filled in as well.  Passing control down the stack to thesicslowpan driver, compression of the layer 3 header is performed by reading the header within the uip_buf buffer and writing the compressed version to the packetbuf buffer.  The payload is also copied over by the sicslowpan driver.  Thenullmac driver forwards onto the sicslowmac driver which adds 802.15.4 framing before forwarding to the configured radio in the network stack for network output.  Sending layer 4-initiated data (i.e. TCP ACKs) occurs automatically on receipt of data and the application is never notified of this.  In this case, the registered sicslowpan output function is triggered by the tcpip_process to initiate data passing down the stack to the radio.










三． 介绍一个简单的lightprocess程序，驱动传感器上得红黄绿三色灯轮流点亮。

#include "contiki.h"

#include "contiki-conf.h"

#include "dev/leds.h"

#include "dev/leds.c"



PROCESS(lightprocess, "lightprocess");

AUTOSTART_PROCESSES(&lightprocess);



PROCESS_THREAD(lightprocess,ev,data)

{

PROCESS_EXITHANDLER(goto exit);

PROCESS_BEGIN();



while(1)

{

static struct etimer et;

etimer_set(&et,CLOCK_SECOND);

PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

leds_on(LEDS_RED);

leds_off(LEDS_GREEN);

leds_off(LEDS_YELLOW);



etimer_set(&et,CLOCK_SECOND);

PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

leds_on(LEDS_GREEN);

leds_off(LEDS_RED);

leds_off(LEDS_YELLOW);



etimer_set(&et,CLOCK_SECOND);

PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

leds_on(LEDS_YELLOW);

leds_off(LEDS_RED);

leds_off(LEDS_GREEN);

}

exit:

leds_off(LEDS_ALL);

PROCESS_END();

}

在Console台中进入Contiki文件夹，然后创建一个文件夹命名为my_app/lightprocess,并将代码保存为lightprocess.c



四． 编译



1.在my_app下创建一个Make file 文件，内容如下并保存。



CONTIKI=/home/linhu/contiki-2.5（这是我的路径，需要改成本地相应的路径）

include $(CONTIKI)/Makefile.include



2.在console台中my_app/lightprocess下键入：make TARGET=micaz savetarget



3.在console台中my_app/lightprocess下键入： make lightprocess



4.在console台中my_app/lightprocess下键入：sudo chmod 777 /dev/ttyUSB0

这条命令作用为设置串口模式。

5.在console台中my_app/lightprocess下键入：avrdude -c mib510 -p m128 -P /dev/ttyUSB0

烧写程序之前需要设置avrdude，-c 为设置烧写器， -p 为设置处理器， -P为设置串口。



6.在console台中my_app/lightprocess下键入：

  make TARGET=micaz.lightprocess.u



这里编译后出现no programmer has been found 问题,但不影响程序烧录,希望哪位大侠解答一下. 

  make TARGET=micaz lightprocess.upload PORT=/dev/ttyUSB0

烧写过程如图所示，显示为烧写成功。