Author:DriverMonkey

Mail:[email protected]

Phone:13410905075

QQ:196568501

测试平台：AM335X

优化前状态：采样速度  105次/S

优化目标：速度为 130次/S 以上（注：根据ADC的采样率理论上可以达到 330次/S）

优化步骤：

              1）代码框架可分为四大模块（UI, 业务逻辑管理，设备管理，远程管理）共10个线程

                   模块间有项目依赖关系，不能一下全部停掉，先去掉一些辅助功能线程（如：按键扫描线程，远程命令处理线程等）。

                   接下来只剩下UI，业务逻辑处理，设备管理，远程管理，四个主线程。编译运行代码查看采样速度有无变化。运行结果

                   是无任何明显变化（任然在105次/s 左右波动）

               2）现在怀疑UI，设备管理，远程管理这三个模块运行效率太低导致采样速度提不上去导致。

                    分别屏蔽这三个线程，分别采集线程同时运行查看采样速度有无明显变化。

               运行结果是无任何明显变化（任然在105次/s 左右波动）

              3）现在只剩下采集线程（其他线程全部停止）发现采集速度同样上不去

                    接下来逐一屏蔽业务处理模块的子模块，再分别编译运行，查看运行结果，采样速度任然没有任何明显变化

              4）到这一步只剩下应用层代码通过SPI总线读ADC 这部分代码了

                   写一份fake 读ADC 的代码替换掉原来的代码，发现能满足现在的优化需求（fake 读ADC 代码的采样率 280次/S）

                   通过当前调试现象至少可以肯定ADC 采样率的瓶颈不在应用层。接下来调试思路，从应用层代码转向驱动层，和硬件原理图的设计

              5）运行只有业务逻辑层代码的程序去读ADC值，并查看系统状态。

                    通过TOP查看发现系统进程状态发现一个kworker 进程有异常，发现这个进程CPU占用率为20%~30%。

                    继续查找资料，发现kworker 进程实际上在内核中是一个处理队列的内核线程。

                    看到这个kworker进程给我的第一感觉可能是SPI读写驱动申请的。继续调试发现调用读取ADC SPI 接口有的时候需要花费 5ms 甚至                             10ms的时间才能返回。实际上我们次发送和接收才4个字节。那就不可能是SPI驱动引起的，那就可能是别的驱动引起的，而当前运行

                      APP只调用SPI一个驱动。

                    现在从系统状态入手。通过查看系统状态发现，一个驱动中断异常(每秒钟103次中断)中断，明显中断过于频繁。实际上这个驱动我们

                    系统名没有使用，找到对应代码重新编译内核。重新运行APP 采集速度直接到 258次/S

优化结果：                    

               采样速度达到 258次/S  完全满足优化目标

     

记一次在linux 平台上的优化调试,古老的榕树,5-wow.com