taskDelay

最近工作中碰到了一个问题，在使用taskDelay的过程中发现，tick频率设为每秒1000的情况下，执行taskDelay(6000)居然延时了几十秒钟~由于taskDelay的最小单位为tick，而且真实延迟的时间根据调用时刻的不同而不同，于是有一种可能是因为taskDelay延时问题导致了误差。不过话又说回来，taskDelay一次导致的是最多一个tick的时间错误，在这种设置的情况下即使累计1000次也不过是1秒的误差，运行6000次也就是6秒误差（当然这不可能，VxWorks会自动调整），怎么会差出几秒呢？我认为，从taskDelay的机理上可以认为，如果出错那一定是系统调度出现错误。taskDelay的运作原理应该是这样的：首先系统时钟（主时钟）触发中断，然后挂接在中断的中断处理函数（通常是usrClock）。然后中断处理函数调用tickAnnounce驱动系统运作。在每一次tickAnnounce的时候，处于延时态的任务在计数器上减一（当然有可能是加一），直到延迟时间结束，然后任务转换到就绪队列。所以，如果taskDelay出现问题，那么整个系统的定时机制都会出现问题，也就是说机制相似的看门狗也会出现问题。很不幸，实践证明看门狗也有问题。那么，这个问题是如何引起的呢？再回过头来看看整个延迟机制，taskDelay的运作原动力就是中断，也就是说，一个中断对应于一个tick。那么就可以推断出，系统不知道因为什么丢掉了应该获得的中断。于是问题应该集中在中断的丢失上。引起中断丢失有很多原因：1、设置计数器时就出现了错误。由于某些原因可能在设置计数器的时候已经把应该设置的数值搞错了，这时出现的现象应该是每次错误出现都具有比例性质，也就是每次出现问题的时候，延时时间和真实经过的时间都满足某一比例。当然，如果数字随机，可就没办法了。2、某个位置出现了不正确的连接。不论是哪一个位置，地址线、数据线或者中断线，任何一个连接不正常都会导致系统工作不正常。这也就可以解释为什么现象也就在一开始的时候出现。实际上这种情况比较好验证，使设备工作在低温情况下，现象自然就会不断出现。注意这里一定要低温，一旦CPU工作起来那可是很烫滴~~~3、软硬件配合问题。其实问题不外乎这三种情况，纯硬件、纯软件、软硬件配合。拿到这个问题中，那可能就是软件对硬件的初始化错误。大概的原因是硬件在复位之后处于某种不稳定的状态，而软件并没有对这种不稳定状态进行处理。总的来说，似乎不应该怀疑VxWorks的定时功能。或许VxWorks会因为调度的原因导致一定的时间偏差，但是对于强实时系统来说这个偏差绝对不会到秒级。还是拭目以待最新的测试结果吧。