cc2530-基于contiki系统读取DHT11问题总结

由于工作需要，需要在cc2530上运行contiki系统，并读取DHT11的温湿度数据，然后传送到另一个cc2530上。

首先读取DHT11程序厂家有提供例程的，不过他们的例程是裸机例程和ZigBee例程，而不是contiki上面的例程。他们DHT11使用的引脚是P1_1

我把他们的例程移植到contiki上，有时候读取DHT11的数据会出现错误。检查了差不多一个星期，最后发现问题范围总是在引脚问题那里！我居然还去怀疑时序，contiki的时钟，任务调度的方法等等非关键的地方。

为什么说是引脚问题呢。

第一，我使用了两个厂家的开发板，一个厂家开发板读取温湿度的引脚是P1_1，另一个是P0_7。例程上面有一个宏定义的引脚值，方便用户修改，按理说我只需要修改那个引脚的宏定义就可以移植了。可是我却忽略了cc2530读取DHT11需要设置引脚的方向，而设置引脚的方向是在程序里面，没有宏定义出来，我一时也没看到，以至于我总是怀疑时序的问题，磨了差不多几年。最后终于发现需要修改引脚的方向。

第二，我在调试client程序的时候，读取出来的DHT11不知道为什么总是有一次失败，而且好像特别有规律。这个时候我又怀疑是不是时序的问题了。结果当然不是，还是引脚的问题。后来我换了引脚P0_7，这个问题就消失了，可惜当时没有注意到引脚P0_7和P1_1读取DHT11的差别。contiki初始化的时候，会把P1_1引脚初始化为一个LED灯，再UDP包的时候会使这个LED灯闪烁一下，而如果我把DHT11连接到P1_1上，这个电平的跳变就会影响到读取DHT11的数据。这就是为什么client程序读取DHT11总是会出错！

总之，如果DHT11读取数据不正常，不是引脚的原因，就是时序的原因，如果时序原因排除了。那一定是引脚的配置错误，其他程序对引脚使用产生了冲突等原因，而不会是在系统的时钟，任务的调度等范围。

对了，经过我的测试，contiki系统中clock_delay(1);这个函数的延时时间的0.78125us，也就是说，clock_delay(100000);大约是7.8125ms。而不是例程所写的8ms。

由于有人想要例程，这里附上下载链接：http://download.csdn.net/detail/u012163234/9492314