可编程计数器的时长捕获与数据安全设计

李红波，李 盛，王 洋，陈 恒

(西京学院理学院，陕西西安 710123)

0 引言

电子计数器是最为常见的测量时间间隔的电子测量仪器之一[1-3]，常被部署在可编程器件中，具有良好的应用效果[4-5]。尤其是嵌在MCU中的可编程计数器与捕获电路相结合来测量时间间隔，特别适用于信号脉宽、信号周期等测量的嵌入式应用系统中[6-7]。然而，计数器的固有二进制位数少(16位计数器最为常见)，捕获测时的最大时长有限，不能满足长时甚至超长时间间隔的测量。相比硬件扩展计数器位数的方法[8]，采用软件方法来扩展计数器的位数则更适合基于MCU的系统[9]，但是软件扩展中又存在计数器捕获中断和溢出中断协作不良问题，会导致捕获时长数据出现致命性错误。本文在分析计数器位数扩展的方法基础上，首次明确了安全问题的根源，指出计数器位数扩展中存在着新的工作态——竞争态，并利用工作态检测法和RTOS系统的多任务事件同步机制防范和解决中断事件的时序问题，纠正了数据错误问题。

1 可编程计数器的捕获测时原理

可编程计数器的捕获结构如图1(a)所示。计数器工作时，16位加1计数器CNT一直在统计内部时钟源fosc脉冲数，当捕获信号EXS先后到来时，或上升沿或下降沿，依次顺序触发，并记录事件时刻的CNT计数值到捕获寄存器CAPREG，通过相邻两次的捕获值做差来获得事件间隔的计数值，如图1(b)中，在时刻tn-1和tn先后出现了捕获事件ICPS，捕获值分别是CapRegn-1和CapRegn，那么间隔计数值就等于CapRegn减去CapRegn-1。由于计数器统计的数字信号为固定周期信号，所以通过间隔计数值乘以信号周期Tosc，可计算获得间隔时长。这种计数器因具有事件的及时捕获记录和时长检测功能，在数字传感和数字控制等嵌入式应用系统中被广泛使用，以满足各种对时间间隔的测量需求[10]。

(a)计数器捕获结构

(b)捕获测时原理图1 计数器捕获测量原理

2 可编程计数器的捕获测量方法

计数器的捕获测时功能是在捕获事件的中断服务程序中通过计算捕获计数值Yn和间隔时长Δtn完成的，具体见式(1)和式(2)。

Yn=Cn×65 536+CapRegn

(1)

Δtn=(Yn-Yn-1)×Tosc

(2)

式中：Yn为捕获计数值；Δtn为间隔时长；Tosc为时钟周期;Cn为软件计数器。

由于16位计数器的间隔计数值最大为65 536，最大的间隔时长为65 536×Tosc。所以，增设软件计数器就能计算超出1个计数器周期的时间间隔，如图1(b)中时刻tn+1和tn间的时长。为了满足长时测量需求，采用中断的软件接力方法是实现软件扩展位数的常用做法，即通过软件计数器Cn对硬件计数器溢出次数的统计来完成计数位数的扩展，常用于嵌入式微控制器系统中。

3 时长测量的数据共享安全模型

软件接力方法需要通过计数器的溢出事件来完成，时长捕获计算需要捕获事件来完成的。溢出事件负责处理软件计数器加1功能，捕获事件负责处理捕获计数值和时长计算。由图2模型知，两事件的中断服务程序都对Cn计数器进行了操作：溢出事件对Cn写操作，捕获事件对Cn读操作，出现了Cn计数器被两中断服务程序共享的新情况。根据操作系统原理，该共享协作问题可以看成经典的两线程读-写者同步问题[11]，需要通过正确的互斥方法和协作方法来解决同步读写问题，仅靠中断机制是不能解决的。

图2 捕获测量的读-写者模型

否则，若Cn对共享变量处理不当，数据计算结果Yn往往随机性的出现65 536的错误问题，时长Δtn也相应会出现差整数倍计数器周期时长错误。如先读取Cn并完成结果计算，后Cn++，可能带来少计算1次65 536；若先写Cn++，后进行读取和结果计算，则可能带来多计算1次65 536。

4 65536数据安全问题的原因

该数据安全问题是与中断系统响应中断的顺序密切相关的。因为中断系统只会提交级别最高的中断源给CPU进行处理。但事实上，受指令延时和嵌套延时造成的CPU不能及时响应中断，使得实际响应情况变得复杂。如两中断事件不同时刻到来，但是仍然可能因为响应延时(程序嵌套或指令周期)被中断系统视为同时到来的。再如即使同时到来，系统仍然按照预先设定的中断次序进行响应，造成响应顺序出错，如图3所示。计数器溢出TF事件优先级高于捕获EXF事件优先级，不论TF和EXF中断发生的先后时间情况如何，因为响应延时，致使中断控制器判优时发现两者都进行了中断请求，于是根据判优规则，总是把高优先级的TF事件提交给CPU来先处理。事实上，当EXF事件先于TF事件发生时，CPU将先错误选择执行(SW=0)TF溢出服务程序计算Cn，后再执行(SW=1)EXF捕获服务程序计算捕获结果Yn和Δtn。由于执行顺序出现错误，导致本次Yn计算结果多计算出65 536的计数错误，从而造成Δtn多计算出1个计数器周期时长错误。可见，中断系统难以解决这种协作问题。

图3 中断控制器结构原理

5 工作态及检测

5.1 工作态

对于被视为同时到来的情况具体存在3种情况。第一，捕获事件先于溢出事件，但由于指令或嵌套延时，当CPU发出INTA信号回应中断请求信号INTR时，存在2个事件同时出现的状态，即被视为同时到来。第二，捕获事件滞后于溢出事件，但由于指令或嵌套延时，同样被视为同时到来。第三，捕获事件和溢出事件真正意义上的同时到来。这3种情况和单独到来的情况交织在一起，随机出现，仅靠中断系统难以辨认。由于这3种情况存在两事件复杂的仲裁竞争关系，为了和普通单个事件响应进行区分，把这种被视为同时到来事件的计数器状态称作竞争态，把上述3种情况分别称作超前竞争态(如图4中①)，滞后竞争态(如图4中③)和同时竞争态(如图4中②)。把单独事件的非同时到来情况称作常态(如图4中④)。

图4 计数器工作态

5.2 工作态检测方法

判明竞争态类型是解决问题的关键。为了获得3种竞争态区别特征，把计数器工作时序从边界0和65 535处切开成小段时序，对齐相应边界平铺层叠到二维平面上以便观察，然后在图中用点标注出竞争态发生时捕获寄存器值，不需要标注出常态下捕获事件发生时捕获寄存器值，如图5所示。计数区间具有较为明显的数据聚合分布特征。对于超前竞争态，捕获寄存器值小于等于65 535，且靠近于65 535值一侧分布，分布在超前区间[x2，65 535]；对于滞后竞争态，捕获寄存器值大于0，且靠近于0值一侧分布，分布在滞后区间(0，x1]；对于同时竞争态，捕获寄存器值为0，位于0点上。若考虑程序抢占嵌套，那么发生计数器溢出事件时，由于CPU被高优先级程序抢占，导致溢出中断响应在指令延时的基础上再推迟一个嵌套延时时长，从而滞后区向高位扩展，x1变大。若考虑程序抢占嵌套，那么发生捕获事件时，由于CPU被高优先级程序抢占，导致捕获中断响应在指令延时的基础上再推迟一个嵌套延时时长，则超前区向低位扩展，x2变小。嵌套延时的存在，使得超前竞争态的捕获值和滞后竞争态的捕获值有趋于中间值的趋势。事实上，基于嵌套和指令随机发生概率的均等原则，两侧嵌套延时和指令延时宽度均可取一致，那么有x1=x2。同时，考虑嵌套程序的延时最大化，取x1=x2=计数上限/2，对整个计数区间进行二分类。如16位计数器，取x1=x2=216/2=32 768作为阀值来划分整个计数区间，如图5所示。从而，计数器工作态的具体判别方法用决策树表示如图6所示。

图5 竞争态捕获值分布图

图6 计数器工作态决策树

6 事件协作设计

6.1 捕获事件与溢出事件的协作要求

捕获测时处理的基本原则和要求是：先发生的事件，CPU对其先处理；同时发生的事件，CPU先处理溢出事件，后再处理捕获事件。对于竞争态，协作顺序应按照如图7(a)～图7(c)所示进行处理。如图7(a)所示发生了超前态，说明捕获事件先于计数器溢出事件发生，则先处理捕获事件(计算结果yn和Δtn)，再处理溢出事件(软件计数器Cn自加1)；如图7(b)所示发生了滞后态，说明捕获事件滞后于计数器溢出事件发生，则先处理溢出事件，再处理捕获事件；如图7(c)所示发生了同时态，则先处理溢出事件，再处理捕获事件。按照正确流程进行顺序处理，实质上是对共享的软件计数器进行正确读写访问，这样捕获时长计算结果才能正确。

图7 同步协作要求

6.2 事件驱动的任务同步设计

利用RTOS实时操作系统的事件驱动方法将有助于安全方便地设计任务间同步和互斥，可以有效地利用操作系统对事件的支持解决多任务同步和管理多任务的需求。为了实现事件任务同步要求，设计了如图8所示的任务交互协作图。

图8 任务交互协作图

系统建立了3个任务：识别任务CheckT，捕获任务ICT和溢出任务OVT。识别任务用于状态检测，捕获任务用于实现捕获结果计算，而溢出任务用于软件计数器功能。当任一中断事件到来，先在中断服务程序中保存寄存器CapReg和IntReg数据，并发送事件Event BIT_0给识别任务CheckT；识别任务然后检测状态，生成状态识别码，再同时发送事件Event BIT_1和Event BIT_2；捕获任务和溢出任务根据状态识别码，再做出合理的执行顺序。状态识别码共4种，分别为：常态0，超前竞争态1，滞后竞争态2，同时竞争态3。具体执行顺序是按照图7的同步要求进行设计的。如若当前态为超前竞争态1时，溢出任务OVT转入等待状态，捕获任务ICT转入就绪运行态，当捕获任务执行完后，发送事件Event BIT_3给溢出任务，溢出任务退出等待继续执行，实现同步和协作。

7 实验验证

实验是在符合CMSIS软件接口标准架构系统[12]上，通过单芯片STM32(ARM Cortex-M3核心)硬件基础上搭载有开源实时操作系统FreeRTOS和用于系统运行参数采集工具Tracealyzer。软件方面，用户只须在配置文件中设置就能完成对FreeRTOS操作系统和Tracealyzer分析仪的自定义移植[13-14]。硬件方面，采用计数器TIM3的捕获通道CH1(PA6引脚)作为EXS输入端，上升沿捕获，TCLK设定70 MHz，使能计数器溢出中断和捕获中断。通过Tracealyzer软件工具，完成对“3.3 V，1 kHz”的方波信号进行实时捕获采集，并进行定性和定量分析。

7.1 安全时序验证与定性分析

加载数据到上位机的Tracealyzer应用软件中，通过可视化时序分析功能，调整视窗尺寸，可观察到图9(a)～图9(d)所示的4种捕获时序。根据图8和图9知，当计数器中断事件到来时，中断服务程序先通过Tmr_SVC定时器守护进程把事件先发给识别任务CheckT进行状态识别，之后根据识别码给捕获任务ICT和就绪溢出任务OVT发送同步事件信号。如图9(a)超前态时序图所示，虽然溢出任务OVT先获得运行，但是在执行时序中要求先执行捕获任务，于是出现了捕获任务ICT得到运行后，再次投入运行，从而完整地完成正确的执行时序。如图9(b)滞后态和同时态时序图所示，时序顺序是按照执行时序要求进行的，即先执行溢出任务OVT，后再执行捕获任务ICT，也完成了正确的执行时序。对于常态而言，由于不存在任务间的竞争协作，只有单个ICT任务执行，时序也是正常的。

图9 捕获时序图

7.2 计算结果与定量分析

编写程序，对1 kHz的高精度信号进行上升沿捕获测周期，分别采用传统方法和新方法统计常态和各个竞争态出现时刻的前一捕获点(B)、当前捕获点(C)和后一捕获点(N)的数据，包括捕获寄存器值CapReg、软件计数器Cn和工作状态。从中抽取12组代表性数据，并以十六进制数表示，具体如表1所示。根据数据和式(1)分别计算新方法和传统方法的数据，包括捕获计数Yn，周期计数值和计数误差，其中周期计数值为相邻2次的捕获计数Yn的差值，计数误差=周期计数值-标准值。标准值为70 000D=1 1170H，是1 kHz信号在70 MHz的参考时钟下的周期理想计数值。周期计数值是1 kHz信号在70 MHz的参考时钟下的周期实际计数值。通过计数误差值比对知，常态下，传统方法和新方法都存在计数误差为±1，是正常的计数误差，实际上捕获输入的时钟同步也会产生计数误差。竞争态下，传统方法的6组数据，包括软件计数器Cn、捕获计数Yn、周期计数值和计数误差均出现了明显的变化，而新方法的计数误差在允许的范围内，数据均正常。其中，超前态下，对比新方法，传统方法的软件计数器Cn增加了1，周期计数值和计数误差均增加了65 536，而Next捕获点周期计数值减少了65 536，计数误差变为-65 536；而滞后态下，相比新方法，传统方法的软件计数器减少了1，周期计数值和计数误差均减少65 536，计数误差变为-65 536，而Next捕获点周期计数值和计数误差均增加了65 536；同时态下，对比新方法，传统方法的软件计数器Cn减少了1，周期计数值和计数误差均减少65 536，而后一捕获点周期计数值和计数误差均增加了65 536。

表1 捕获测周期实验数据表

通过比较分析，传统方法在常态下捕获结果是正确的，但是在竞争态时会出现65 536的周期计数值结果错误，原因是因为在竞争态时传统方法存在软件计数器Cn数据更新错误，从而导致周期计数值以及被测信号周期都出现错误的问题。采用新方法后，发现新方法的周期计数值与新方法常态以及传统方法常态均一致，说明新方法，不论计数器工作在何种工作状态时，由于采用了协作机制和同步方法，软件计数器Cn和捕获计数Yn每次都能得到正确的结果，所以后期的周期计数值和信号周期均能得到正确的捕获结果。

8 结束语

实验证明了提出计数器在捕获测量时间间隔时存在2类4种工作态是正确可行的，并结合创新性的工作状态检测和基于RTOS的任务事件同步法，有效地完成计数器溢出事件和捕获事件的协作处理，得到了正确可靠的测量数据和捕获时长，使之在时长捕获或中低频信号数据捕获上有了安全保证。传统方法是仅通过中断系统机制来进行捕获测量的，忽略了竞争态的存在，难免出现传统捕获测时带来的数据错误隐患。同时，由于采用RTOS系统，使得该方法做到与硬件中断类型无关，可统一按照共享中断向量来处理，极大地简化了程序设计的难度和增强了移植性。另外，本方法提供了一种单芯片低成本片上系统方案，可方便移植到多种基于MCU或SOPC的嵌入式系统中，具有一定的普适性。