Windows 10 ARM工控主板CAN总线实时性能测试

        在常规的Windows系统中支持CAN总线应用，需要外接CAN总线适配器，通常为USB转CAN模块或PCI接口CAN卡。实时性本身是CAN总线的显著特性之一，但由于Windows并非实时操作系统，应用程序容易受到系统CPU负载影响，导致调度周期不确实，这就限制了CAN总线在Windows系统中的应用。

        英创公司推出的名片尺寸Windows工控主板ESM8400，其核心是基于NXP的iMX8MP 4核ARM64 MPU，安装Windows 10 IoT企业版操作系统，Windows 10 IoT企业版就是完整版本的Windows 10，而且支持软实时特性。ESM8400自带两路CAN总线接口，结合Windows 10 IoT企业版的软实时特性，可以实现可靠的10ms(甚至更小)循环周期调度，这使得ESM8400可作为软实时IPC直接应用于对控制周期有严格时序要求的控制回路中，以触发状态机的行为，然后通过CAN总线调度较小的硬实时控制单元。

        本文将介绍基于安装Windows 10 IoT企业版的ESM8400 CAN总线实时应用的测试目标、测试方法，以及对测试数据进行统计与分析。对于开发实时应用程序的具体编程细节将在单独的一篇文档中进行说明。

1. 测试目标

        模拟工业自动化现场实际应用，在ESM8400应用程序中生成10ms的固定循环周期，在每个循环周期内调用CAN接口以250kBits/s波特率连续发送6帧数据。最终统计分析两个时间指标：

        1、10ms循环周期在各种软件配置、以及各种CPU负载情况下的实际最大时间是多少。

        2、在各种工况下连续发送6帧CAN数据的耗时情况，并统计最长耗时。

2.  测试方法

2.1 硬件环境

        ESM8400评估底板直接支持1路CAN总线接口，通过PCAN模块(USB转CAN)连接到计算机。测试时需要注意短接评估底板上的CAN总线匹配电阻跳线器。

2.2 PCAN-View

        PCAN-View是PCAN模块对应的Windows应用程序，PCAN-View可以记录接收的CAN数据，同时可记录每帧数据的时间戳，时间戳精度为0.1ms。时间戳由PCAN模块自身标记，不会受测试计算机软件系统调度问题所影响。所以利用接收到的CAN数据时间戳，可以对各项时间指标进行精确的统计。

 

2.3 测试程序

        ESM8400上运行的测试程序利用Windows系统的高精度定时器QPC实现10ms的循环定时，每个循环周期内连续发送6帧CAN数据，测试发送12W帧CAN数据(2W个循环)后程序退出。下面是测试程序的主要代码，关于ESM8400 CAN接口在Windows中的使用细节，将在另一编文档中进行说明。

CFlexCAN        can;     flexcan_frame_t frame;     volatile        BOOLEAN txComplete = TRUE;     LARGE_INTEGER   frequency;     LARGE_INTEGER   end, last;     // 设置本进程优先级     // SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS); // 将本进程设置为仅在CPU3, CPU4上运行     // SetProcessAffinityMask(GetCurrentProcess(), (1 << 3) | (1 << 2)); // 打开ESM8400 CAN1,波特率设置为250kBit/s     can.Open(1, 250000); // 获取QPC的频率     result = QueryPerformanceFrequency(&frequency); // 计算10毫秒对应的QPC计数，减去1是为了补偿可能的调度延迟     LARGE_INTEGER interval = { frequency.QuadPart / 100 - 1 };     QueryPerformanceCounter(&last);     end = last;     while(1){         // 等待直到达到或超过预定的10毫秒间隔         do {             QueryPerformanceCounter(&end);         } while ((end.QuadPart - last.QuadPart) < interval.QuadPart);         // 更新上一次循环结束的时间         last = end; // 连续发送6帧CAN数据，每帧的CAN ID从1到6         for (int i = 1; i < 7; i++) {             frame.mfs_1.id = i;             can.Write(&frame);             while (!can.txComplete) {};             can.txComplete = FALSE;             frame.mfp.mfp_w.dataWord1++; // 此处可进行其它操作，注意代码执行时间不要超过循环定时 // 每个循环发送6帧，发送超过12W帧(2W个循环)后退出程序         if (frame.mfp.mfp_w.dataWord1 > 120010)             break;     }

3.  进行测试

3.1 测试项目

        将测试程序分别设置为Normal和Realtime优先级类，在CPU空闲和CPU负载75%的情况下，测试程序运行于Windows 10标准模式和软实时环境进行了6个项目的对比测试。

测试项目	CPU负载	Windows 10 系统模式	进程优先级类
1	空闲	标准模式	Normal
2	75%	标准模式	Normal
3	75%	标准模式	RealTime
4	空闲	软实时模式， 3个标准CPU + 1个实时CPU	RealTime
5	75%	软实时模式， 3个标准CPU + 1个实时CPU	RealTime
6	75%	软实时模式， 2个标准CPU + 2个实时CPU	RealTime

对于测试项目的进一步说明：

        1、ESM8400的处理器i.MX8MP有4个CPU核心，在Windows标准模式下，测试程序由系统自动调度在某个CPU上运行。在3+1软实时模式下，应用程序通过SetProcessAffinityMask函数设置当前进程在CPU4(实时核心)上运行，在2+2软实时模式下，通过SetProcessAffinityMask函数设置当前进程在CPU3和CPU4上运行。

        2、测试程序进程优先级类由SetPriorityClass系统API配置为NORMAL_PRIORITY_CLASS或REALTIME_PRIORITY_CLASS。

        3、测试时利用CPU Stress程序为系统增加75%的高优先级 (HIGH_PRIORITY_CLASS)负载。

        4、在启用的Windows 10 软实时的情况下，可以看到在CPU Stress中增加的75%负载，Windows系统分别施加到了CPU1~CPU3上，不占用CPU4资源，这就是Windows IoT企业版的软实时特性之一——CPU隔离技术的体现。(下图中为1个实时核心 + 3个标准核心)

3.2 数据统计与分析

        每个测试项目执行2W次循序，得到12W帧、带精度为0.1ms时间戳的CAN数据，将6个测试超过72W帧数据导入Excel。

 

        如前面的测试程序所示，每个循环发送的第1帧CAN数据的ID为1，最后第6帧CAN ID为6，这里利用每一个ID为1的CAN帧时间戳、统计10ms循环的实际最大时间，利用ID为1和6的CAN帧时间戳计算连续发送6帧CAN数据的实际耗时。统计结果如下：

1. 各工况下CAN数据发送的耗时情况

        CAN总线在250kBit/s波特率下，理论上每秒最多能传输约2300个CAN标准帧，传输6个标准帧的最短时间理论上需要约2.6ms。分别统计发送6帧数据耗时在3ms内、3ms~6ms之间、6ms~9ms之间以及耗时超过9ms的次数。

  

从上面的统计结果可以看到：

• Win10标准模式下，如果不对应用进程优先级作任何设置，即使CPU空闲，也有一次发送时间超过9ms，当CPU负载增加时，CAN的发送时间变得很不确实，接近1000次发送时间超过9ms。
• 在Win10标准模式下，无论CPU负载如何，发送耗时都小于等于6ms。唯一在CPU负载75%时，有一次耗时处于6ms~9ms之间，根据原始数据查得这次耗时为6.1ms。
• 在分配2个实时核心的情况下，发送实时性要好于1个实时核心。这是因为测试程序实际上有两个线程：一个主循环线程；一个完成端口线程，用于为发送结果提供异步通知。
• 在Windows标准模式下，将应用程序设置为实时进程，得到了最好的实时性能，这将在稍后的测试总结中进一步说明。

2. 最大时间统计

        通过统计发送6帧数据的最长耗时，以及统计10ms周期的实际最大时间更能直观的反应系统在各个工况下的性能表现，和可预测性。

4.  测试总结

        在Windows标准模式下，如果不对应用进程优先级做特别设置，程序的调度响应时间将很不确定，在本次测试中，原本10ms的循环定时周期实际上最长测得为160ms。

        在Windows标准模式下，提高进程优先级可显著提高响应的实时性，但需要注意的是在标准模式下， Windows线程可以被调度到任意CPU上，Windows的音频驱动、SysMain、DPS等后台服务可能会在某一时间对关键应用程序造成影响，这会增加系统的不可预测性。

        在ESM8400上启用Windows的软实时特性，对多核CPU进行隔离应用，将关键应用进程固定在实时CPU上运行，能得到可预测的实时性能，具备在对控制周期有严格时序要求的使用场景中应用的能力。