CC2538之Contiki3.0实验：4-Sensor
东方淇
相信大家看完前面作者的瞎掰也迷茫了，没错，Contiki的学习靠自己的努力辛苦，多去阅读代码，正如套用有一本物联网的书籍讲的“你不会C语言，那你来这干嘛”;
在前面的基本介绍大家基本会Contiki的例程自我编写;Makefile编写，make编译，Process(pt/lc)等基础概念，知道Contiki没有那么复杂；只要你耐心去阅读他的代码，搞清楚他的逻辑；针对自己的平台通过串口打印一些比如sizeof() ，process等等占用大小，以决定大家项目的资源分配，了解event的注册返回原型（字节）未处理事件的个数限定;再阅读底层相关；如contiki-main <==>main.c；阅读启动文件，makefile文件已方便以后自己添加应用c库文件;其次慢慢的去了解对于Contiki的条件编译参数;了解Contiki编程的一些需要避开的地方；我们清楚的知道先不谈Contiki的event驱动机制抛开应用层的rime/uip，他的核心应该是pt(叫process也好，thread也好)；编程的注意事项也是因他而来，如switch不可出现在PROCESS中；PROCESS中慎用局部变量（无上下文保存/不同于函数的调用当ISR发生的时候，局部变量等是保存的，处理完ISR回来继续运行）可以用static修饰，Contiki的系统库很多这样做的，共享/临界资源的保护;有得必有失;至于Contiki的mt则根据自己的需求选择使用;
TinyOS大家不要理解成有thread模式；现在主流的应用基本都不需要thread,实际上也确实用不着；TinyOS的cthread，有些厂家也给出了代码，但是始终不温不火；因为对于应用这些根本用不上;
编程应该越简单越好，技巧用得越多带来的BUG可能越多，也越难让大家都读懂;
我们的分析是Contiki是在编译的时候给了process结构体初值，对于大家的实际应用可否使用动态的分配来实现呢；当然动态的分配并不是C的malloc和free；而是类似6lowpan的先弄一个静态数组，然后自己编写ip_malloc/ip_free;当然Contiki也有内存操作部分；TinyOS有Poll;quene;fragpoll等
现在让我们阅读一下contiki-main.c(cc2538cb/cc2538dk)部分，发现button_sensor_init();呵呵，使用过TI评估板或者国内各种山寨TI评估板的朋友很熟悉了；TI这个家伙的常规做法按键；我都不清楚焊接按键干什么；对于cc2538cb节点，大家肯定疑惑为什么不引出按键；我反问一句；已经引出了IO口；要实现按键本质是IO口的电平变化；拿一根导线/镊子又或者指甲剪/挖耳勺;将引出IO口短接到vdd(引出)或gnd(引出)不就可以了？ADC也是如此；测量电源和地；当然也可以让一个IO口PWM输出电平；短接让另一个IO口采集ADC值;
回到Contiki的Sensor；去找一找Contiki(2538)的按键部分；哇;看我们看到了什么;好高深的样子：
在contiki-3.0\platform\cc2538cb\dev下的button-sensor.c和smartrf-sensors.c出现了
SENSORS_SENSOR(button_select_sensor, BUTTON_SENSOR, NULL, config_select, NULL);
SENSORS_SENSOR(button_left_sensor, BUTTON_SENSOR, NULL, config_left, NULL);
SENSORS_SENSOR(button_right_sensor, BUTTON_SENSOR, NULL, config_right, NULL);
SENSORS_SENSOR(button_up_sensor, BUTTON_SENSOR, NULL, config_up, NULL);
SENSORS_SENSOR(button_down_sensor, BUTTON_SENSOR, NULL, config_down, NULL);
SENSORS(&button_select_sensor, &button_left_sensor, &button_right_sensor,
&button_up_sensor, &button_down_sensor, &als_sensor,
&cc2538_temp_sensor, &vdd3_sensor);这是什么东东;通过前面的代码阅读我已经宠辱不惊了，好吧，查看代码去；
core/lib/sensor.h
#ifndef SENSORS_H_
#define SENSORS_H_
#include "contiki.h"
/* some constants for the configure API */
#define SENSORS_HW_INIT 128 /* internal - used only for initialization */
#define SENSORS_ACTIVE 129 /* ACTIVE => 0 -> turn off, 1 -> turn on */
#define SENSORS_READY 130 /* read only */
#define SENSORS_ACTIVATE(sensor) (sensor).configure(SENSORS_ACTIVE, 1)
#define SENSORS_DEACTIVATE(sensor) (sensor).configure(SENSORS_ACTIVE, 0)
#define SENSORS_SENSOR(name, type, value, configure, status) \
const struct sensors_sensor name = { type, value, configure, status }
#define SENSORS_NUM (sizeof(sensors) / sizeof(struct sensors_sensor *))
#define SENSORS(...) \
const struct sensors_sensor *sensors[] = {__VA_ARGS__, NULL}; \
unsigned char sensors_flags[SENSORS_NUM]
struct sensors_sensor {
char * type;
int (* value) (int type);
int (* configure) (int type, int value);
int (* status) (int type);
};
const struct sensors_sensor *sensors_find(const char *type);
const struct sensors_sensor *sensors_next(const struct sensors_sensor *s);
const struct sensors_sensor *sensors_first(void);
void sensors_changed(const struct sensors_sensor *s);
extern process_event_t sensors_event;
PROCESS_NAME(sensors_process);
#endif /* SENSORS_H_ */ 发现分析方法和PROCESS那些并没有什么不同，慢慢也清楚了Contiki作者的编程风格；至于core/lib/sensor.c，我就完全不去分析了;
如果让我去写传感器的处理，我才懒得这样去写；只是Contiki已经出现的这个宏定义，咱们也可以理解是他的关键字；
看看而已；路过路过...看到sensor_sensor不禁想起了超级爱听的歌:"斑马斑马，你来自南方的红色啊...."
类似资料：