个楼主一个实例：
uCOS:时钟节拍代码追踪
uCos中的时钟节拍可以基于软中断实现或者基于时钟节拍任务（但是这个任务要给予很高的优先级）
对于STM32（Cortex-M3）来说这个就是SysTick中断0x0000003C
当中断发生时调用OS_CPU_SysTickHandler函数，
这样就提供了系统的时钟节拍
uCos中扩展的应用都是在HOOK函数中实现的，
程序关于Time的调用，
首先都是基于OSTime的，
其次由于在OSTimeTick函数中预留了OSTimeTickHook()函数
这样可以方便我们在OSTimeTickHook()函数中添加我们自己的代码实现在系统中的调用
由于OSTimeTickHook()函数在OSTimeTick函数中，
所以每次Tick时都会调用这个函数，所以也就给了我们可以添加每次时钟Tick都被系统
调用的机会。
由于OSTimeTickHook()函数中预留了App_TimeTickHook()函数提供给应用层的程序实现相应的扩充，
这样就可以在应用层APP中，扩展一些我们想要的功能，例如Ctimer函数。
同时函数指针的应用更大程度的扩展了，我们可以扩展函数的功能的范围。
在系统启动多任务后
的第一个任务TaskStart中（即调用过OSStart()函数后）调用OS_CPU_SysTickInit()完成对系统Tick的设定。
在设置Tick的时候，是由OS_CPU_SysTickClkFreq函数来获得硬件的时钟频率
通过除以OS_TICKS_PER_SEC得到一个定时中断时间，以后每隔一定的时间中断一次。
追踪的过程
App_TimeTickHook()(app.c)--OSTimeTickHook()(os_cpu_c.c)--OSTimeTick()(cpu_core.c) \
--OS_CPU_SysTickHandler()(os_cpu_c.c)--DCD OS_CPU_SysTickHandler(vectors.s)
在追寻代码路径的过程中，
沿着最容易看到的代码追踪到它的上一级代码，
直到它的最底层实现，
这样就可以把与这个相关的系统上的东西都可以了解了。
我们评判一个操作系统的实时性，看的就是系统对外部动作做出响应所消耗的总共时间。那咱先得看看一个完整的响应分为几部分。一般情况下一个系统的完整响应过程可以分为以下几个部分：
1.系统输入环节。该环节一般负责将外部的响应转换成嵌入式系统所能识别的信号。这个环节所消耗的时间与输入设备的精度和响应时间有关，简单来说就是模数转换的时间，与操作系统的实时性没有关系。
2.系统处理环节。该环节一般负责对输入环节给出的信号进行响应并进行相应的处理。这个环节所消耗的时间与操作系统的进程调度机制有关，包括对外设中断响应机制，操作系统的调度机制决定着该环节所需要的时间。
3.系统输出环节。与1类似，不过方向恰恰相反，也就是数模转换的时间，同样也与操作系统的实时性没有关系。
上面三个环节只是一个简单的分类，实际系统中可能环节根据应用需求有所增减。判断一个系统的实时性应该从上诉三个环节统筹判断。至于判断一个操作系统的实时性，最关键的是其进程调度机制。
举报成功
经过核实后将会做出处理
感谢您为社区和谐做出贡献
扫码参与新品0元试用
晒单、顶楼豪礼等你拿
