实际工程的运行要比上篇文章提到的例程复杂的多
ISYSTEM调试实践11-Profiler Timeline和软件运行时间分析
由于复杂的应用层模型和底层任务，假定应用层模型的运行周期是10ms，任务函数的执行时间往往超过1ms，这时候就必须要考虑函数执行本身的时间。
例如下图，taska\taskb\taskc\taskapp是10ms执行一次，task5ms任务是5ms执行一次。
由于10ms周期里，四个任务执行了6.95ms，等于占用了其他函数的周期，导致5ms的任务不能按时执行。
虽然说由于考虑程序执行时间以后，函数调用被影响无法避免，但是我们还是希望尽可能减少这种结果的发生，将影响程度降到最低。
所以该5ms的任务统计情况详见下图。它的period也就是调用周期异常，最大15ms，相当于周期性抖动（JIT）等于达到了200%，这是不能被接受的。而且最小仅仅位652us,等于是无效操作，毕竟这个任务既然要求5ms，太快的执行是没有意义的
比如ccpDaq这个函数也是5ms执行一次，被调用的情况和上一个类似，周期完全被打乱。
优化的方法就是找到哪些函数占用了大量的时间。
方法一：
例如这个函数执行一次需要2.5ms，时间长是因为大量调用了延时函数，可以根据需要减少周期。
经过对延时适当的降低，平均运行时间降到了1.05ms
方法二：
将需要时间才能执行完成的函数拆开，分批次执行，错开时间，给那些调用周期更短的任务执行。
左图是优化后
将上文提到10ms执行一次的aska\taskb\taskc\taskapp分开到两次执行，而将5ms执行一次的task5ms采样任务插入到中间任务，可以大大降低5ms任务的抖动时间。
这里抖动时间将为100%。
方法三：
ADC_GetConvertValue,这个函数在1.023这个统计周期内被调用了25808次，累计花了190ms，ADC读取作为被大量调用的函数，也需要进行优化，这里建议一般改为DMA读取，并且增加ADC的工作频率
改为DMA以后，平均call time降为463ns
方法四：
将不需要频繁执行的函数降低调用频率。
这个要根据项目实际情况。
