简介：面向嵌入式与实时系统开发者的PMC-5565板卡RTX64 3.x驱动及测试程序资料包，聚焦VMIC GE高性能板卡在Windows实时扩展环境下的驱动编写、rfm2g模块RTdll封装与测试验证问题。压缩包共54个文件，约713KB，以C与C++源码及头文件、VC工程与解决方案、实时动态库、实时子系统文件、可执行测试程序和说明文档为主，工程依赖关系较完整，便于按模块查阅驱动实现与测试组织。已有1231人学习，适合需要参考板卡驱动落地流程、实时库调用与调试思路的中高级开发者，也可为军工、航空航天和工业控制等实时场景的类似平台提供迁移参照。内容覆盖实时扩展环境下的驱动测试与Windows互测两条验证路径，涉及动态库加载调用、硬件接口封装、测试用例组织及跨环境兼容性检查，可为类似硬件平台驱动开发提供可复用的工程骨架与排错参照。

1. 一块 PMC-5565 卡住两天：装不上的往往不是驱动

板卡插上、驱动装上、设备管理器干干净净，可一进 RTX64 3.x 的实时进程里调 RFM2G 接口就返回打不开设备——这种现场我碰过不止一次。PMC-5565 这块反射内存卡本身不复杂，复杂的是它要同时落在两个环境里：一边是 RTX64 的设备树，一边是 RFM2G 自己的节点号与内存映射。装不好的典型后果不是蓝屏，而是测试程序跑出一片全 0，你还以为是光纤没插好，拆机箱拆到怀疑人生。这套环境在半实物仿真、多机实时同步、采集回放里很常见，适合手上已经有卡、正在配 RTX64 3.x 的开发者。下面按我实际装机的顺序走一遍，从清单、安装、配置一路写到坏了怎么救。

2. 装机前把账算清：PMC-5565 与 RTX64 3.x 的硬件清单和软件分层

装机最怕的不是难，是顺序错。我见过有人把 RTX64 装完才发现机箱里那块卡是 PMC 封装，主板根本没有对应插槽；也见过 RFM2G 驱动装了三四遍，最后发现是子系统位数和应用程序位数对不上。所以第 2 章不写安装动作，只做一件事：把这块卡和这套实时系统拆成「硬件一层、运行时一层、驱动与库一层」，每层先确认到位，后面每一步才有意义。这一章的三个小节，你照着核对完，后面基本不会返工。

2.1 PMC 封装不是插上就能用：载板、供电与光纤环

PMC-5565 是 PMC 封装的板卡，单宽、32 位 PCI 本地总线，它不能直接插在台式机的 PCI 或 PCIe 槽里，中间必须有一块 PCI/PCIe 转 PMC 的载板。这一步是新手最容易漏的：卡买回来发现没地方插，或者随手找了块载板，结果载板只引了 5V 供电，板卡要的是 3.3V，插上去灯都不亮。载板的桥片也有讲究，太老的 PCI 桥在新型主板上枚举不出来，设备管理器里连未知设备都不给一个。

反射内存这一侧同样是硬件细节决定成败。PMC-5565 上一般是 SFF 小封装的光纤收发器，多模 850nm 居多，环网要么首尾成环，要么中间接一台 hub；两端模块的波长和速率必须一致，一头 850nm 一头 1300nm，链路能亮但数据不通，这种坑我踩过。光纤的弯曲半径也别忽视，机柜里绕成死弯，短包能过、长包就丢。

我一般的做法是：先在纯 Windows 环境里把卡跑通，再装 RTX64。厂商包里通常带一个 Windows 版的测试程序，两个节点对着读写一轮，硬件、载板、光纤、节点号全都能排掉。等实时系统装上去再出问题，你就分不清是硬件坏还是驱动配错了——这一步花二十分钟，能省两天。

2.2 三个安装包的分工：Runtime、SDK、RFM2G 驱动包

RTX64 3.x 不是一个安装包打天下，它至少分成两块：Runtime 装在目标机上，负责 RTX64 Server 服务、Subsystem 和 Control Panel；SDK 给开发用，提供 Rtapi.h、Rtss.h 和 RTSS 侧链接库。很多人只装 Runtime，然后拿一个 RTSS 测试程序的源码过来编译，第一行 include 就报找不到头文件。

第三块是 RFM2G 驱动与测试程序包，里面通常有四类东西：给 RTX64 用的设备安装信息文件（INF）与驱动文件、rfm2g.h 头文件、Windows 侧与 RTSS 侧两套库、以及一个已经编译好的测试程序。RTSS 侧一般是 .lib 加 .rtdll 的形式，具体目录结构以你手上这个包的 readme 为准，别凭记忆写路径。

版本对齐上只有一条硬规则：RTX64 3.x 的位数必须和操作系统位数一致，RTSS 应用的位数必须和子系统位数一致。32 位应用拿去连 64 位子系统，编译能过，跑起来就是打不开设备。RFM2G 包也要选对应 RTX64 3.x 的版本，早年给 RTX 或更老实时扩展写的驱动，别往 3.x 上凑。

2.3 一张装机前核对表和三行确认命令

装之前我习惯把机器状态先摸一遍，尤其是虚拟化相关的特性——RTX64 要在系统里划走处理器和内存，机器上如果开着 Hyper-V、内核隔离这类功能，两边会抢资源，轻则子系统起不来，重则开机蓝屏。三条命令足够看清底子：

:: 1) 系统版本与位数：RTX64 3.x 的位数必须和它一致 wmic os get Caption,Version,OSArchitecture :: 2) 虚拟化相关特性：有输出说明相关功能开着，装之前先处理 systeminfo | findstr /i "Hyper-V" :: 3) 物理核数：决定能给 RTSS 分几个处理器，别把核全分光 wmic cpu get Name,NumberOfCores,NumberOfLogicalProcessors

第一条看 OSArchitecture，64 位系统就只能配 64 位的 RTX64 和 64 位的 RTSS 应用，别抱侥幸。第二条是个黑匣子式的判断：如果输出里出现「已检测到虚拟机监控程序」，说明系统上有虚拟化层在跑，常见做法是进「启用或关闭 Windows 功能」把 Hyper-V 关掉，同时关掉内核隔离里的内存完整性，再重启。第三条看物理核数，八核机器给 RTSS 分两到四个是常见配置，分满会导致 Windows 侧卡顿，后面调参数时会反复用到这个数字。

提示：安装路径别带空格和中文。后面写编译脚本、写服务启动参数时，路径里的空格会让你多写一堆引号，还容易出错。

3. RTX64 3.x 装到位：从 Runtime 到 Subsystem 起服务

安装动作本身不复杂，复杂的是「装完了到底算不算装好」。这一章拆成三步：先按顺序把包铺进去，再把 Subsystem 的三个关键参数调对，最后用一条命令确认子系统真的在跑，而不是 Control Panel 上显示个图标就算完。这三步任何一步跳过，后面装 RFM2G 驱动时出的问题都会表现得莫名其妙。

3.1 安装顺序与路径约定

顺序是 Runtime → 重启 → SDK → 装 RFM2G 包。Runtime 装完必须重启，因为它要注册服务、改启动项；不重启就装 SDK，后面 rtssrun 跑程序时会报一堆找不到设备的错。安装时默认目录形如C:\Program Files\<厂商目录>\RTX64\3.x，版本号占一级目录，下文统一用%RTX64_ROOT%指代它，你自己的机器上换成实际路径。

:: 先把安装根目录记成环境变量，后面所有命令都用它，少打错字 setx RTX64_ROOT "C:\Program Files\<厂商目录>\RTX64\3.x" /M :: 装完确认两件事：服务注册了没有，SDK 头文件到位了没有 sc query type= service state= all | findstr /i "rtx64" dir "%RTX64_ROOT%\include\Rtapi.h"

第一段用 setx 加 /M 写到系统变量，需要管理员权限，好处是后面开新窗口不用每次重设。第二段里 findstr 不区分大小写，各版本服务名可能略有差异，能看到 RTX64 字样就说明服务注册成功；第三段是 SDK 是否装好的直接证据，头文件在，编译才有戏。这两条都不通过，就别往下走了，先回头查安装包是不是缺了 SDK。

3.2 Subsystem 三个参数最该改：本地内存、RTSS 处理器数、HAL 定时器

打开 Control Panel 进 Subsystem 页，参数一大片，真正需要你动手的就三个。改之前先备份当前配置，这个面板改完是直接写进配置并影响下次启动的，改坏了子系统起不来，救起来很麻烦。

本地内存这一项最容易设错。做仿真的项目数据缓冲区大，有人一上来给 4GB，机器只有 8GB 物理内存，结果子系统启动失败，事件日志里只留一句语焉不详的错误。我的经验是：先按默认跑通全流程，量出测试程序实际占多少，再往上加，一次加 512MB，加完重启验证。

3.3 确认子系统真的在跑，而不是面板上显示在跑

Control Panel 上有个状态灯，但它只代表服务进程在，不代表子系统初始化成功。真正的验证是让一个 RTSS 程序跑起来。

:: 服务名以 3.1 里 sc query 的输出为准，这里按常见写法写 sc stop "RTX64 Server" sc start "RTX64 Server" :: 跑 SDK 自带的一个 RTSS 示例，能正常退出就说明子系统 OK "%RTX64_ROOT%\bin\rtssrun.exe" "%RTX64_ROOT%\examples\RtssHello.rtss"

先 stop 再 start 是为了让刚才改的 Subsystem 参数重新加载，直接 restart 有些版本不生效。rtssrun 是拉起 RTSS 可执行文件的入口，示例文件名各版本不一样，跑哪个不重要，能起来、能正常退出就行。如果这一步报错，去 Control Panel 的 Monitoring 页看处理器占用，再去 Windows 事件查看器翻 RTX64 相关条目，通常能定位到是内存不够还是处理器分配冲突。

4. 把 PMC-5565 挂进 RTX64 设备树：RFM2G 驱动安装与工程配置

到这一步，系统侧的地基打好了，接下来才是这块卡真正落地。记住一个判断标准：Windows 设备管理器里认到卡，只说明载板和板卡没坏；RTX64 的设备列表里能看到卡，才说明 RFM2G 驱动挂上了。这两件事经常被混为一谈，也是「设备管理器正常但程序打不开设备」的根源。

4.1 先让 Windows 侧认到卡，再用 INF 加进 RTX64

先在 Windows 侧确认硬件枚举成功，记下厂商 ID 和设备 ID，出问题时这两个号是你查手册的依据。

# 列出当前在位设备里名字带 PMC / Memory / RFM 的，找不到就直接翻"其他设备"里的未知设备 Get-PnpDevice -PresentOnly | Where-Object { $_.FriendlyName -match "PMC|Memory|RFM" } | Format-List FriendlyName, InstanceId, Status

这段用 PowerShell 跑，InstanceId 里就包含 VEN_ 和 DEV_ 两段，抄下来。如果 Status 显示 Error 或者压根找不到，先回第 2 章查载板和供电，别急着装驱动——驱动救不了一块没枚举成功的卡。

硬件确认后，打开 RTX64 Control Panel，进 Devices 页，添加设备，选 RFM2G 包里的 INF 文件，应用后重启 RTX64 Server 服务。有些包会附带一个 install 脚本，把 INF 复制到系统目录并注册，那就按包里的 readme 走，别自己手搓。加完之后在设备列表里应该能看到 PMC-5565 对应的条目，看不到就是 INF 没匹配上，回去核对 VEN/DEV。

4.2 节点号、内存偏移与环网拓扑

这三个参数是 RFM2G 配置的全部重点，也是测试程序读出一片 0 的高发区。

节点号唯一这条没有例外。两个节点都设成 0，环网照样亮，写进去的数据却互相覆盖，测试程序跑出来的结果毫无规律。我一般会在机柜上贴标签，把节点号和机器名对应起来，换卡时照着标签拨。软件设置节点号会写 EEPROM，拨码能解决的场合别用软件写，写坏了这块卡就得返厂。

内存偏移容易被忽略。板卡容量是 128MB 不等于你能从 0 写到 128MB，手册里会单独标出用户区起始偏移和保留区，中断控制一类的寄存器往往占用末尾一段。测试程序里那个偏移参数，一定要按手册改，别用 0 去猜。

4.3 工程配置：头文件、库与位数对齐

编译这一关的坑集中在路径和位数。用 CMake 的话，配置大致长这样：

# 路径按你机器上的实际安装位置改，别照抄 set(RTX64_ROOT "C:/Program Files/<厂商目录>/RTX64/3.x") set(RFM2G_ROOT "C:/rfm2g") add_executable(rfm_demo main.c) target_include_directories(rfm_demo PRIVATE "${RTX64_ROOT}/include" # Rtapi.h、Rtss.h "${RFM2G_ROOT}/include") # rfm2g.h target_link_directories(rfm_demo PRIVATE "${RTX64_ROOT}/lib/rtss/x64" "${RFM2G_ROOT}/lib/rtss/x64") # 目录结构以包内为准，别硬套 target_link_libraries(rfm_demo PRIVATE rfm2g Rtapi)

三处要留意。include 目录两套都要写，Rtapi 是 RTSS 的系统调用，rfm2g.h 是板卡接口，缺一个编译就断。link 目录里的x64是位数标记，如果你的子系统是 32 位，这里必须换成对应目录，混用会在链接期报一堆符号重定义或者运行期直接打不开设备。链接顺序上 rfm2g 在前、Rtapi 在后，某些链接器对顺序敏感，报未定义符号时先调这个。

接口怎么用，一段最小代码就够看清：

#include "rfm2g.h" RFM2GHANDLE handle = NULL; RFM2G_STATUS status; RFM2G_NODE node = 0; unsigned char buf[256]; status = Rfm2gOpen(&handle); /* 单卡时直接打开，多卡用按索引打开的接口 */ if (status != RFM2G_SUCCESS) { /* 别把 status 吞掉，打印出来是排错的唯一线索 */ printf("open failed: 0x%x\n", status); return -1; } Rfm2gGetNodeId(handle, &node); /* 确认拨码和现场规划一致 */ Rfm2gRead(handle, 0x1000, buf, sizeof(buf)); /* 偏移按手册用户区起点改，别用 0 */

Rfm2gOpen 的返回值必须打出来。这个接口失败时不抛异常、不写日志，只给你一个状态码，吞掉它就等于把黑匣子扔了。Rfm2gGetNodeId 拿到的值和你拨码盘上的数字对不上，说明 EEPROM 里存了旧值，先解决这个再谈读写。Rfm2gRead 的偏移参数是这一整段里最容易写错的，0x1000 只是个示例，实际填手册上的用户区起点。

5. 避坑记录：PMC-5565 在 RTX64 3.x 下的五个翻车现场

这一章全是血泪经验，每条按「现象、原因、解决」写，出问题时对号入座比翻手册快。

5.1 读写全是 0 或者全是 0xFF

现象：两个节点都跑测试程序，一端写、一端读，读回来一片 0；换成另一种模式读回一片 0xFF。

原因：两个可能。一是偏移写错，用了 0 或者用到了保留区，驱动不报错，读出来就是空。二是环网没成环，只有一端在发光，另一端收不到，硬件层面直接给全 1。

解决：先把偏移改成手册标注的用户区起点，再在单节点上做自发自收——写一段特征数据，立刻读回同一段比对，能对上说明偏移对了。然后接第二台，用交叉写验证环网。别一上来就双机联调，两个变量一起动，出问题没法定位。

5.2 Rfm2gOpen 打不开设备，但设备管理器一切正常

现象：Windows 里卡无感叹号，RTX64 服务也在跑，应用一调 Rfm2gOpen 就返回失败。

原因：INF 只装进了 Windows 侧，没加进 RTX64 的设备列表；或者更常见——RTSS 应用是 32 位的，子系统是 64 位的，位数不匹配。

解决：打开 Control Panel 的 Devices 页，看列表里有没有这块卡，没有就重新选 INF 添加并重启服务。有的话去查工程属性，把目标平台改成和子系统一致的位数，重新编译。这两步排完还不行，把 Rfm2gOpen 的返回码打出来，对照包里的错误码头文件查，比瞎猜快。

5.3 小数据量没事，一传几 MB 就丢事件甚至卡死

现象：几百字节读写正常，一次搬 4MB 数据之后，等待事件的线程再也收不到通知。

原因：把事件通道当数据通道用了。反射内存的数据走内存映射，事件只是通知，事件队列深度有限，写得太密就溢出；另外大块写之后立刻去读，中间没有同步点，读到半截数据很常见。

解决：数据只走内存，事件里只放一个标志位或者序号。等待事件务必带超时，超时后回退到轮询检查标志位。大块传输拆成固定大小的块，每块写完更新一个序号，接收端按序号判断完整性。

5.4 装完 RTX64 重启蓝屏，或者子系统起不来

现象：安装完成重启直接蓝屏；或者能进系统，但 Control Panel 里子系统一直是停止状态，手动启动也失败。

原因：机器上开着 Hyper-V、内核隔离这类虚拟化功能，和实时子系统抢处理器控制权；另一种是 Subsystem 预留内存设得比可用物理内存还大。

解决：先关虚拟化功能，管理员命令行执行bcdedit /set hypervisorlaunchtype off，同时在系统设置里关掉内核隔离的内存完整性，重启。然后把 Local Memory Size 调回 512MB 再试。这两步的顺序别反，先关虚拟化再调内存，否则你分不清是哪个改好的。

5.5 搬个机箱就认不到卡，或者跑几分钟掉线

现象：机器挪了个位置，开机后设备管理器里多出一个未知设备；或者能认到，跑几分钟就掉线重连。

原因：载板在机箱里松动、金手指氧化、供电不足，或者光纤被压出死弯、两端 SFF 模块型号不一致。这类问题看着像驱动，实际全是硬件。

解决：换一个插槽、拔下来擦金手指、检查载板供电线，光纤按最小弯曲半径重新理线，两端模块统一型号。判断方法很土但有效：拿厂商的 Windows 测试程序跑一轮，Windows 下都不通，就别在 RTX64 里折腾了。

6. 装完怎么验证：两节点回环跑通才算数

装完最后一步不是打开 Control Panel 看一眼绿灯，是让数据真的在两个节点之间跑一个来回。我固定跑三步，缺一步都不算装完。

自环这一步最容易被跳过，很多人觉得一块卡自己写自己读没意义。恰恰相反，它能把偏移错、容量标错、驱动没挂上这三类问题一次排干净，而且不需要第二台机器配合。自环过了再上双机，交叉写要双向都做一遍，只测一个方向会漏掉一端的光纤收发。

压测不用写复杂程序，一个递增的 32 位计数器就够：发送端每次写完把计数器加一，接收端比对，发现不连续就打印当前值和上一个值。跑半小时，中间别关程序，让数据一直在环上流动。这条我吃过亏——短时间测试全绿，交付之后跑两小时开始丢包，回头查是光纤模块温度上来之后误码。

还有个小技巧：验证时把 RTSS 侧的日志先落到内存里，跑完再一次性写文件。实时线程里直接写磁盘，I/O 一阻塞，时序全乱，测出来的问题根本不是你系统的问题。

从那以后我每次装完这套环境，不管多急，都会先把单节点自环和双节点计数器压测走一遍，再交给别人用。硬件类的坑不会自己消失，只会在你最不想它出现的时候出现。希望帮到你。

本文还有配套的精品资源，点击获取