最近这几天一直给tinyOS挂载外设，从最简单的LED、KEY，再到串口，这些都没什么大问题，无非就是先初始化tinyOS，再初始化硬件外设，接着启动tinyOS，然后tinyOS去寻找优先级最高的任务并运行。

但是我把MPU6050按照这步骤，发现MPU6050初始化和DMP初始化没什么问题，可就是死活读不出数据。一般在MPU6050裸机程序里，如果读不出数据，mpu_dmp_get_data()这个函数会有一个返回值，可以根据这个返回值定位MPU6050在获取数据时代码的什么位置出现了错误。可是我的这个错误就比较牛逼了，竟然没有返回值。

 不管怎么说，迎难而上！

开启单步调试模式！

在一步一步的调试下，发现问题了，由于移植的是正点原子的代码，代码卡死在了这个地方。

mpu_dmp_get_data()           –>               

dmp_read_fifo()                    –>

mpu_read_fifo_stream()       –>

mpu_reset_fifo()                                                

看到了吧，这里有个50ms的延时，对于实时操作系统来说，50ms的延时就好像是一万年，所以果断把这句代码删掉。我之后也对比过其他stm32厂商的MPU6050初始化代码，都没有这个50ms的延时，可见这是正点原子加进去的。

OK，去掉了这个50毫秒的延时，再来试一下程序，好了，这下有返回值了，但是没有数据出来。

看来还是有问题，继续单步调试，发现问题还是定位到mpu_reset_fifo()这个函数上，但是这个函数是MPU6050官方厂家InvenSense公司写的，没有问题啊，官方写的能有什么问题呢。

没办法，继续排查问题，这下只能查每个函数到底是干嘛的了。

去查了下MPU6050数据手册。发现FIFO这个东西是用来保存MPU6050姿态的数据，然后再去读FIFO，把姿态数据读出来，但是为什么代码要去复位FIFO呢？肯定是FIFO的数据存满并且溢出了。可是为什么会溢出呢？说明没有及时去读数据，导致数据越堆越多，就溢出了。就好比你不停的向水壶里灌水，灌进去又不去使用这个水，所以只能越灌越多最后导致溢出。

这下问题的根本原因找到了，可以去修改代码了。根本的解决方案就是MPU6050以及DMP初始化之后立马去读FIFO里面的数据。

先来说说没修改前的代码，代码在tinyOS初始化以及硬件初始化后，会有个1秒钟来测试MCU全速能运行多少代码，这是为了方便后面测量MCU使用量。

MPU6050出错就是因为这个1秒钟，所以把MPU6050的初始化以及DMP的初始化放在这个测试MCU的1秒钟之后，但是这个解决方案效果并不是很好，因为MPU6050初始化里有100毫秒的延时。

经过几番修改，最好的解决方案是利用软件定时器。在tinyOS初始化、硬件设备初始化以及启动tinyOS之后，在启动MCU全速运行1秒钟之前，开启这个软件定时器。在这个软件定时器里面扫描mpu_dmp_get_data()这个函数，这下问题就彻底解决了。

数据通过串口输出如下：