标签：style class c a color width
Author:DriverMonkey
Mail:bookworepeng@Hotmail.com
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 平台上的优化调试,布布扣,bubuko.com
标签：style class c a color width
原文地址：http://blog.csdn.net/drivermonkey/article/details/26619469
