RTX64 3.x下PMC-5565反射内存卡rfm2g驱动安装与测试全攻略

简介：面向嵌入式与实时操作系统开发者的硬件驱动参考包，聚焦VMIC GE公司PMC-5565板卡在RTX64 3.x环境下的驱动实现与验证。内容围绕rfm2g模块的RTdll封装展开，说明如何将板卡接口功能按RTX64编程规范集成进驱动，使上层软件无需关心底层硬件细节即可调用；同时提供RTX64下的测试程序与Windows环境互测程序，覆盖驱动正确性、稳定性及跨环境兼容性验证，适合从事军工、航空航天、工业实时计算的中高级开发人员参考。压缩包共54个文件、约713KB，以h头文件、c源码、vcxproj与sln工程文件、rtdll实时动态库、rtss实时程序及lib库为主，另含inf安装信息与说明文档，工程结构完整可直接对照编译。已有1231人学习下载，可帮助读者理解板卡驱动分层设计、RTdll封装思路与双环境测试方法，为同类硬件平台驱动开发提供可复用的参考。

1. 装 RTX64 3.x 驱动前，先把 PMC-5565 的板卡身份认清楚

手上有一块 GE 的 PMC-5565 反射内存卡，机器是工控机，系统要跑 RTX64 3.x 实时子系统，任务是把 rfm2g 驱动装起来、测试程序跑通。这套组合在实时仿真、半实物测试的场景里很常见，但装起来并不轻松：板卡是 PMC 接口，宿主可能是 CPCI 或 PCI 转接，RTX64 又是挂在 Windows 下面的实时内核，三层东西叠在一起，任何一层版本对不上，表现都是「设备管理器里看得见、rfm2g 就是打不开」。新手最容易在版本和总线枚举上翻车，熟手则更关心驱动签名、中断分配和内存映射窗口的取舍。这篇笔记按我实际装过的一台机器的顺序写，从环境核对到驱动安装、参数配置、测试程序验证，最后给出装坏了怎么救的排查路径，照着走能少走几晚弯路。

2. 环境核对与版本选型：RTX64 3.x 与 PMC-5565 的匹配关系

2.1 先确认三件事：宿主系统、RTX64 版本、板卡形态

装之前不要急着插卡。我一般先把下面这张表填满，填不满就先别动手，因为后面每一步都依赖它。

这里有个反直觉的点：RTX64 3.x 的驱动不是「装一次就通用」的。驱动包通常按 RTX64 的主版本编译，3.x 内部子版本升级有时会改内核接口，驱动加载会报版本不匹配。所以第一步是打开 RTX64 的版本信息，把主版本号和子版本号都记下来，再去对驱动包里的说明。宿主系统这边，RTX64 3.x 要求 64 位 Windows，32 位宿主直接放弃，没有绕过去的办法。

板卡形态也要提前确认。PMC-5565 是 PMC 封装，工控机上多半通过 PMC 转 CPCI 或 PMC 转 PCI 的载板插进去。载板不同，系统枚举出来的总线号和设备号就不同，后面配 rfm2g 的参数时要填这些值。我习惯在插卡前先记录一张「空载」的设备列表，插卡后再对比，多出来的那一项就是板卡，省得在一堆桥设备里猜。

2.2 版本选型的取舍：为什么不要盲目追新

RTX64 3.x 有几个子版本，驱动包也有对应的编译目标。常见做法是：驱动包说明里写支持哪个子版本区间，就装那个区间里的版本，不要为了「用最新」去升 RTX64。实时子系统的升级往往牵动整个工程的链接库，升完之后测试程序可能连编译都过不了，而板卡驱动本身的功能并不会因为子版本新一点就多出什么。

另一个取舍是测试程序用 32 位还是 64 位编译。RTX64 3.x 的实时进程是 64 位的，测试程序如果要在实时子系统里跑，必须按 64 位编译并链接 RTX64 的库；如果只是想在 Windows 侧做一次快速连通性检查，用厂商给的 Windows 版测试工具也行，但它验证不了实时侧。我的建议是两边都备一份：Windows 侧工具用来快速确认板卡和驱动在系统层面是活的，实时侧测试程序用来确认 rfm2g 在 RTX64 下真的能读写。

还有一点容易被忽略：驱动安装前要确认宿主上有没有装过旧版本的 rfm2g 驱动。装过的话，设备里可能残留旧的服务项和注册表键，新驱动装上去会打架。常见做法是先在设备管理器里卸载旧设备并勾选删除驱动软件，再清理残留的服务注册，然后重启，最后装新驱动。这一步多花十分钟，能省掉后面几小时的「为什么版本明明对还是打不开」。

2.3 安装前的系统准备清单

动手前把下面这些做完，按顺序来：

1. 关闭宿主 Windows 的快速启动。快速启动会让驱动加载时序变得不可预测，实时子系统启动时偶尔找不到板卡。
2. 确认宿主已安装 RTX64 3.x 运行时，并且 RTX64 子系统能正常启动。先单独验证 RTX64 本身是好的，再叠加板卡驱动，出问题才好定位。
3. 准备驱动包和测试程序包，解压到不含中文和空格的路径，比如C:\rfm2g_drv。路径里有空格时，某些安装脚本传参会被截断，这是老坑。
4. 记录当前系统的设备列表和中断分配情况，插卡后对比用。
5. 如果宿主开了驱动签名强制，提前确认驱动包是否已签名；未签名的驱动在 64 位宿主上加载会被拦，需要按实验室的规范处理，不要临时关签名了事。

提示：第 2 步单独验证 RTX64 很关键。我见过有人把 RTX64 启动失败和板卡驱动失败混在一起排查，最后发现是实时子系统本身没起来，板卡根本还没轮到。

3. 安装 rfm2g 驱动：从插卡到设备识别

3.1 插卡与总线枚举：先让系统看见板卡

断电插卡，注意 PMC 连接器的方向，插反了轻则不通、重则伤针。上电进系统后，先看设备管理器里有没有多出未知设备。PMC-5565 在没装驱动时通常显示为未知的桥设备或内存控制器类设备，位置在载板对应的总线下面。

如果设备管理器里什么都没多出来，先别怀疑驱动，按这个顺序查：载板供电是否正常、PMC 连接器是否插到位、载板的 PCI/CPCI 插槽是否被系统识别。可以在命令行里用系统自带的设备枚举工具看总线列表，确认载板桥设备在、板卡在桥下面。这一步是纯硬件和总线层面的确认，和 rfm2g 无关。

设备出现后，记下它的总线号、设备号、功能号，以及系统分配给它的内存基址和中断号。这些值后面配 rfm2g 参数时要用。我一般会截图存档，因为重装系统或换插槽后这些值会变，有存档就能快速对照。

3.2 驱动安装的两种方式与参数说明

驱动安装常见两种方式：用厂商提供的安装脚本，或者手动指定 INF 安装。脚本方式省事，但参数要看清；手动方式可控，适合脚本装不上时排查。

脚本方式大致是这样调用的：

# 以管理员身份运行，进入驱动包目录 cd C:\rfm2g_drv # 安装脚本通常接受一个目标目录参数，路径不要带空格 install.bat C:\rfm2g_drv

这里的参数是驱动文件和服务的安装目标目录。脚本内部一般会做三件事：把驱动文件复制到目标目录、注册内核服务、把服务设为按需启动。执行完不要立刻插着卡重启，先看脚本输出有没有报错。脚本报「服务已存在」时，说明之前装过，要先卸载旧服务再装。

手动方式是在设备管理器里对未知设备选择「更新驱动程序」，指向驱动包目录，让系统按 INF 匹配。这种方式适合确认 INF 里的硬件 ID 和板卡枚举出来的是否一致。如果系统提示「找不到兼容的驱动程序」，多半是 INF 里的硬件 ID 和实际枚举不符，或者板卡形态（PMC 转接后）的 ID 和 INF 预期不同，这时候要回去核对载板和板卡型号。

安装完成后，设备管理器里板卡应该显示为正常设备，没有黄色感叹号。此时驱动服务已注册，但还没验证能不能真正打开设备，下一步用 rfm2g 的工具做打开测试。

3.3 rfm2g 参数配置：内存窗口与中断的取舍

rfm2g 的参数一般放在配置文件里，常见项包括设备号、内存基址、内存窗口大小、中断号、以及是否启用中断。配置的核心是让驱动知道去访问哪一段物理内存、用哪个中断。

# rfm2g 配置文件示例，路径和取值按实际枚举结果填写 [Device0] BusNumber=3 SlotNumber=8 MemoryBase=0xD0000000 MemorySize=0x04000000 InterruptNumber=11 UseInterrupt=1

逐项说明：BusNumber和SlotNumber来自前面记录的总线枚举结果，填错会表现为设备打不开或读到全 0xFF；MemoryBase是系统分配给板卡的内存基址，必须和枚举值一致；MemorySize是映射窗口大小，一般不小于板卡实际反射内存容量，窗口开太小会导致访问越界；InterruptNumber是系统分配的中断号，UseInterrupt=1表示启用中断方式接收数据，如果测试程序只做轮询读写，可以先设 0 排除中断配置的干扰。

这里有个取舍：中断方式实时性好，但中断号配错或共享冲突时，表现是数据能写进去、接收端收不到通知，排查起来很绕。我的习惯是先用UseInterrupt=0把读写通路验证通，再打开中断验证通知机制，两步分开，出问题能立刻定位是哪一层。

配置改完要重启驱动服务或重启系统让参数生效。重启后先用 rfm2g 自带的查询工具看设备状态，确认驱动认到了配置里的基址和窗口大小，再进测试程序。

4. 测试程序跑通：Windows 侧与 RTX64 侧分开验证

4.1 Windows 侧快速连通性检查

Windows 侧先跑厂商给的测试工具或一个最小读写程序，目的是确认板卡和驱动在系统层面是活的。最小验证逻辑是：打开设备、读一个寄存器或内存位置、写一个已知值再读回、比对。

/* 最小读写验证，伪代码风格，接口名按驱动头文件实际定义替换 */ handle = rfm2g_open(0); /* 打开 0 号设备 */ if (handle == INVALID) { /* 打开失败，先查配置和驱动服务 */ } rfm2g_write(handle, offset, 0x5A5A5A5A); /* 写测试值 */ rfm2g_read(handle, offset, &value); /* 读回 */ /* 比对 value 与写入值，一致说明读写通路正常 */ rfm2g_close(handle);

打开失败是最常见的第一个坎，原因集中在配置里的总线号、基址和实际枚举不符，或者驱动服务没起来。写进去读不回，先怀疑内存窗口大小和基址，再怀疑板卡本身的反射内存是否被其他节点占用。这一步通了，说明 Windows 侧驱动和板卡是好的，可以进实时侧。

4.2 RTX64 侧测试程序编译与运行

实时侧测试程序要按 64 位编译，链接 RTX64 的实时库和 rfm2g 的实时侧接口。编译时注意头文件路径和库路径都指向 RTX64 3.x 对应的目录，不要混入 Windows 侧的库，混了会在链接期报符号冲突或运行期直接崩。

运行前确认 RTX64 子系统已启动，测试进程作为实时进程加载。实时进程里不要做阻塞式等待和动态内存频繁分配，读写循环用固定缓冲。验证逻辑和 Windows 侧一样：写已知值、读回比对，再叠加中断通知的验证。中断验证时，发送端写数据后触发中断，接收端在中断回调里读数据并置标志，主循环检查标志。标志一直不置，回去查中断号和UseInterrupt配置。

两侧都跑通后，做一次跨侧一致性检查：Windows 侧写、实时侧读，再反过来。这一步能暴露缓存一致性和映射窗口的问题，也是这套环境真正可用的标志。

5. 常见问题排查：装完打不开、读写出错的几条血泪记录

5.1 设备管理器正常但 rfm2g 打开失败

现象：设备管理器里板卡无感叹号，驱动服务也在运行，测试程序打开设备返回失败。原因多半是配置文件里的总线号、槽号或内存基址和实际枚举不一致，尤其是换过插槽或载板之后。解决：重新枚举总线，逐项核对配置文件，改完重启驱动服务再试。我一般会把枚举结果和配置项做成对照表，改一项对一项，不凭记忆填。

5.2 写进去读出来是全 0xFF 或全 0x00

现象：打开成功，写入后读回固定值。原因通常是内存窗口基址或大小配错，驱动映射到了错误的物理区间；也可能是板卡反射内存被其他节点占用或未初始化。解决：先核对基址和窗口大小，再把窗口调大到覆盖板卡实际容量，最后检查同一反射内存网络上的其他节点是否在写同一区域。全 0xFF 更像映射到了未分配区间，全 0x00 更像映射到了有效但未初始化的内存。

5.3 中断方式下数据能写但接收端收不到通知

现象：轮询方式读写正常，打开中断后接收端标志一直不置。原因常见于中断号配错、中断被其他设备共享、或UseInterrupt配置与实际中断注册不一致。解决：先退回轮询确认数据通路，再单独查中断分配，确认中断号与系统分配一致，检查是否有其他驱动占用同一中断。共享中断在实时场景下要谨慎，能独占就独占。

5.4 实时侧测试程序加载即崩或链接报符号冲突

现象：Windows 侧正常，实时侧程序一加载就崩，或编译链接时报符号重复。原因多是 32 位与 64 位库混用、头文件路径指向了 Windows 侧目录、或 RTX64 子版本与驱动包不匹配。解决：清理编译输出，确认所有路径指向 RTX64 3.x 对应目录，按 64 位重新编译；仍报版本相关错误时，核对 RTX64 子版本与驱动包说明的支持区间。

5.5 重装系统后驱动装不上，提示服务已存在

现象：新系统上装驱动，脚本报服务已存在或设备带感叹号。原因可能是旧驱动残留的服务项和注册表键没清干净，或者安装顺序不对（先装了驱动后插卡）。解决：卸载设备并删除驱动软件，清理残留服务注册，重启后再按「先确认 RTX64、再插卡、再装驱动」的顺序走一遍。顺序错了就重来，不要在半残状态上反复覆盖安装。

6. 装完怎么验证跑通：一套可复现的验收流程

验收不要只看「设备管理器没感叹号」，那只是驱动注册成功。我用的验收流程分四步，每步都有明确的通过标准，任何一步不过就停在那一步排查，不往下走。

第一步，系统层验收。设备管理器里板卡正常，驱动服务处于运行状态，rfm2g 查询工具能列出设备并显示配置里的基址和窗口大小。通过标准是查询输出与配置文件逐项一致。

第二步，Windows 侧读写验收。跑最小读写程序，写已知值读回比对一致，连续读写若干次不出现偶发错误。通过标准是比对全对，且重复运行结果稳定。

第三步，实时侧读写验收。RTX64 子系统启动，实时测试进程加载，同样的写读比对在实时侧通过。通过标准是实时侧结果与 Windows 侧一致，且进程不崩、不报超时。

第四步，跨侧与中断验收。Windows 写实时读、实时写 Windows 读，两个方向都通；再打开中断，确认通知能到达。通过标准是双向数据一致，中断标志按预期置位。

下面这张表可以当验收记录用，每步填结果，不通过就记下现象，回头对照第 5 章的排查条目。

这套流程的价值在于把「能打开」和「能稳定读写」分开。很多翻车就发生在只验证了第一步就以为装完了，结果上真实任务时数据偶发错位，回头查才发现窗口大小或中断配置有问题。从那以后我每次装这类板卡驱动，都强制把四步走完并留记录，换机器、换插槽时拿旧记录一对比，差异点就是问题点。希望帮到你。

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