Contiki开发1:Contiki与8位MCU

Contiki开发1:Contiki与8位MCU

1 8位MCU重生

10年前,我们怀着激动的心情努力学习ARM,铺天盖地的ARM教材和开发平台板宣示:8位单片机的时代已经过去,以至于开发8位MCU都不好意思说出口。现在,随着物联网时代的来临,8位MCU即将得到一次重生。

1.1 更低的价格

物联网时代,将会有上百亿甚至千亿的终端诞生,我们知道,大规模的硬件复制成本仍是一个重要的指标。8位MCU相比32位MCU,晶体管更少,引脚也少,价格自然要低,同时,它的处理能力足够满足要求不那么高的物联网终端。

1.2 更低的功耗

因为晶体管更少,同时主频较低,在运算量不那么大的应用中,8位MCU的低功耗会更突出。在一些电池供电,运算较少,通信不太频繁的物联网终端,它将再次得到青睐。

1.3 更小的体积

很多物联网设备将会微型化,如:一张胸卡,一个手环,都是一个物联网终端,狭小的空间当然要求MCU体积越小越好,而8位MCU正合适。

2 需要一个操作系统吗?

开发8位MCU的工程师都习惯了“循环+中断”的前后台系统,它简单,直观,同时有限的资源也让很多操作系统无用武之地。但凡工作在RTOS的工程师,都享受过操作系统带来的如下红利。

2.1 降低软件复杂度

人类的大脑难以处理复杂的逻辑,为此,智者们提出分而治之的艺术。同样,一个软件系统是一个复杂的逻辑实体,而操作系统提供“进程”,将软件分解成多个执行逻辑,让大脑专注于本进程处理的事件;操作系统提供“层次”,将内核,API,应用,得以区分,再次降低开发者的复杂度。可以说,操作系统提高了软件分解能力,也就降低了软件复杂度。

2.2 丰富稳定的组件

想要快速开辟和回收一块内存?进程之间需要发消息通信?中断服务程序需要唤醒进程?想使用一个无限挂载的软定时器……大部分程序员想要的组件,操作系统都提供,要知道,这些丰富的组件可是经过严格测试的。复用成熟稳定的组件是提高软件生产力的有效手段,这方面,操作系统功不可没。

2.3 提高CPU效率

当一个进程等待一次硬件I/O,如进程等待射频发送数据包完成,无事可干;而其他进程希望得到CPU运行权,不用担心,操作系统会完成调度,它会将“因等待而无事可干”的进程阻塞,而将CPU分配给“具备运行条件”的进程享用。

2.4 更好的移植性

有一天,产品因为某种原因需要更换MCU,有操作系统支撑的系统就轻松多了,因为应用软件调用的是操作系统的API,它很少与硬件层直接打交道;基本上,只要将操作系统移植到“新MCU平台”,软件系统就OK了。大部分MCU都提供常用操作系统移植代码,因此硬件平台的更改代价降低了。

3 Contiki的功与过

Contiki是少有能同时实现2个目标的操作系统:对内存要求极低,同时支持进程阻塞机制。8位单片机的RAM极为宝贵,几KB都是很大了,一般的RTOS(FreeRTOS或uc/os-ii等)无法运行,而Contikil可运行良好;有些操作系统,如OSAL也在极少的RAM上可以运行,但是这种基于“状态机”开发的机制,让代码很难理解,程序执行流在状态中来回判断和切换,让逻辑更复杂。

3.1 优点

3.1.1 节能内存

Contiki有一个巧妙的机制来实现进程的调度:当进程被阻塞时,OS记录该进程的下一C语言行号;当进程继续运行时,从记录的C语言行号继续运行。这种机制从2个方面极大节省内存:所有的进程共享一个栈,没有上下文机切换。甚至在小于1KB内存的MCU上,Contiki都可以良好地运行。

3.1.2 进程可以阻塞

在Contiki系统中可以实现如下语句,进程发送无线电数据包,然后阻塞自己,直到发送完毕。这种“优雅”的机制,非常符合程序员思维,同时降低了开发的复杂度。

SX1278Send(packetbuf_dataptr(),packetbuf_datalen());

PROCESS_YIELD_UNTIL(RF_Tx_Done ==s_tRFResult);

3.1.3 移植简单

如果仅使用Contiki的内核,只需要移植clock.c,即从MCU中找一个定时器来给etimer进程提供时钟源。如果使用Contiki的网络协议栈,需要按radio.c实现无线收发函数。

3.1.4 丰富的网络协议栈

针对无线通信,Contiki提供3种MAC协议,还有RIME通信原语和RPL路由协议;针对TCP/IP,Contiki提供uIP协议栈,它支持IPv4和IPv6。

3.2 缺陷

3.2.1 无法提供实时性

因为Contiki进程是不可剥夺的,没有优先级,因此它是非实时的。这对于“紧急事件”的处理带来不便。比如,当射频侦听到同步帧会有一个中断,接下来需要立即开启无线接收,否则会错过该无线电数据包:如果是RTOS,ISR给优先级最高的进程发消息,该进程立即开启无线接收;但Contiki中ISR不能poll进程来完成,因为没有任何保证该进程会“及时”打开无线接收。

当然,可以通过在ISR中打开无线接收,这就需要使用“状态机”,它会把逻辑弄复杂,同时会带来竞态的风险。

3.2.2 进程无法就地阻塞

在Contiki系统中,如果希望在一个普通函数中阻塞进程,这是无法实现的,只有一种叫protothread的函数才行。具体实现请参考:

http://blog.csdn.net/jiangjunjie_2005/article/details/50192985

3.2.3 进程无法区分中断消息源

当多个ISR向进程poll消息时,Contiki进程无法区分消息源,解决的办法请参考:http://blog.csdn.net/jiangjunjie_2005/article/details/51793973

3.2.4 进程带条件阻塞会丢消息

当一个Contiki进程带条件阻塞时,除该条件的消息外,其他消息将“不幸遗失”,这对于开发者是一个例外,解决的办法请参考:

http://blog.csdn.net/jiangjunjie_2005/article/details/51804481

4 实战平台

工程师最大的习惯是把看好的东西做出来!8位MCU和Contiki再讨论,也需要落地实践。后续的系列博文,我们都会基于以下平台实践Contiki的开发,并公开源代码和设计。

该平台的MCU选用ST公司的STM8L151C8T6,主频达到16MHz,RAM为4KB,ROM为64KB,低功耗十分出色,性能稳定。由锐米通信(www.rimelink.com)开发为DEMO产品,链接为:

https://item.taobao.com/item.htm?spm=2013.1.w4004-13955217960.6.51YIQT&id=531517677682

感谢ST深圳公司闫涛先生(todd.yan@st.com)的支持,沛城电子郑卫涛先生( zheng@paceic.com)的帮助,你们对ST处理器的专业和热情让我们工程师在采购渠道上更轻松。


评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值