基于p-net从零搭建PROFINET从站：STM32移植与GSDML实战

1. 为什么我要用 p-net 从零搭一个 PROFINET 从站

最早接触 PROFINET 是在一个产线改造项目上，当时现场有一台西门子 S7-1500 做主站，下面挂了一堆远程 IO 和几台伺服。项目验收前甲方临时加需求，要把一台自研的测厚仪接进这条 PROFINET 总线里，让 PLC 能直接读到厚度数据并参与联锁。那台测厚仪的主控是一块 STM32F407，跑的是裸机程序，串口和以太网都有，但没有任何现场总线协议栈。摆在面前的路无非三条：买一块现成的 PROFINET 通讯板卡、换主控用带协议栈的芯片、或者自己撸一个从站协议栈。

买板卡是最省事的，但成本高、交期长，而且那块测厚仪的板子已经定型，加板卡要改结构件。换主控更不现实，整个算法和标定流程都要重写。最后我选了第三条路，用 p-net 这个开源协议栈在 STM32 上把 PROFINET 从站跑起来。p-net 是 RT-Labs 开源的一个轻量级 PROFINET 设备协议栈，用 C 语言写的，代码量不大，移植性很好，支持 RT 和 IRT 的部分特性，最关键的是它不依赖操作系统，裸机或者 RTOS 都能跑。对于我这种只想让设备“能上总线、能收发循环数据”的需求来说，p-net 的体量刚刚好。

这篇文章我打算把整个从零搭建的过程完整复盘一遍，包括协议栈选型的考量、GSDML 文件怎么写、STM32 上的移植细节、跟西门子 PLC 联调时踩过的坑，以及最后怎么把通讯跑稳。如果你手里也有一块带以太网的 MCU，想让它接入 PROFINET 网络，或者你单纯想搞明白 PROFINET 从站到底是怎么工作的，这篇内容应该能帮你省下不少查资料和试错的时间。我会尽量把每个关键决策背后的原因讲清楚，参数怎么算、代码为什么这么改、现场遇到问题怎么排查，都会给到可直接参考的做法。

2. 协议栈选型与整体方案设计

2.1 为什么是 p-net 而不是其他方案

市面上能跑在 MCU 上的 PROFINET 从站方案其实不多。商业协议栈比如西门子的 Development Kit、HMS 的 Anybus 嵌入式方案，功能全、认证齐，但授权费不便宜，而且代码是黑盒，出了问题只能找原厂。开源这边，p-net 算是知名度最高的一个，GitHub 上维护得也比较活跃。我选它主要看中三点：第一，纯 C 实现，没有复杂的依赖，移植到 STM32 这种资源受限的平台比较现实；第二，它把 PROFINET 的底层状态机、循环数据交换、非循环读写、报警处理都实现了，我只需要对接硬件抽象层和 GSDML 配置；第三，它的 RT 通讯基于标准以太网 MAC 的实时通道，不需要特殊的硬件加速，普通 STM32 的 ETH 外设就能跑。

当然 p-net 也不是没有短板。它默认只支持 RT 通讯，IRT 需要硬件支持时间戳和队列调度，普通 MCU 基本跑不了。另外它的认证支持有限，如果你的设备要过 PROFINET 一致性认证，可能还得补不少东西。但对于大多数非认证类的设备接入场景，p-net 完全够用。我实测下来，在 STM32F407 上跑 1ms 的循环周期，CPU 占用大概在 15% 左右，留给应用层的时间很充裕。

2.2 整体架构怎么搭

整个从站的架构我分成四层来理解。最底下是硬件层，STM32F407 的 ETH 外设加一颗 LAN8720 PHY，跑 RMII 接口，100Mbps 全双工。往上是 p-net 的硬件抽象层，需要我实现几个关键函数：网卡的初始化、数据包的发送和接收、以及一个毫秒级的系统时钟。再往上是 p-net 协议栈本体，它负责处理 PROFINET 的帧解析、状态机切换、循环数据映射。最上面是应用层，我把测厚仪的厚度数据写进 p-net 的输入模块，同时从输出模块读取 PLC 下发的控制字。

这个分层的好处是职责清晰。硬件抽象层我只关心怎么把以太网帧收进来发出去，协议栈层我基本不用动，应用层就纯粹是业务逻辑。调试的时候哪一层出问题，排查范围很明确。比如通讯不上，先看 PHY 有没有 link，再看 p-net 的状态机走到哪一步，最后才查应用数据映射对不对。

2.3 硬件选型的几个关键点

MCU 这块我选的是 STM32F407ZGT6，168MHz 主频，192KB RAM，1MB Flash。选它不是因为性能多强，而是它的 ETH 外设成熟，ST 的 HAL 库和例程多，踩坑成本低。RAM 方面，p-net 协议栈本身占大概 30KB 左右，加上网络缓冲区和应用数据，192KB 是够的，但如果你要开多个 AR（Application Relation）或者做大量非循环读写，建议上 256KB 以上的型号。

PHY 用的是 LAN8720A，RMII 模式，25MHz 晶振。这里有个细节要注意，LAN8720 的 REF_CLK 可以配置成输出 50MHz 给 STM32 的 ETH 用，也可以由 STM32 提供 25MHz 给 PHY。我选的是 PHY 输出 50MHz 的方案，这样 STM32 这边省一个晶振，但前提是 PHY 的晶振要焊 25MHz 的。如果晶振焊错了，PHY 的 link 灯可能亮，但数据收发会大量丢包，这个坑我踩过，查了两天才发现是晶振频率不对。

3. GSDML 文件编写与设备描述

3.1 GSDML 到底是个什么东西

GSDML 全称是 General Station Description Markup Language，翻译过来就是通用站描述标记语言。你可以把它理解成 PROFINET 设备的“身份证”加“说明书”。PLC 在组态的时候，需要导入这个文件，才能知道你的设备叫什么名字、支持哪些模块、每个模块有多少输入输出数据、通讯参数是什么。没有 GSDML 文件，PLC 根本不认识你，连组态都做不了。

GSDML 是基于 XML 的，结构不算复杂，但细节很多。一个最小的 GSDML 文件包含设备基本信息、模块定义、子模块定义、输入输出数据长度、以及一些通讯参数。我一开始觉得这东西应该很简单，结果第一次写的时候漏了一个<IOData>的Length属性，PLC 组态时直接报错，提示设备描述不完整。后来对着 p-net 自带的示例文件逐行比对，才把结构理顺。

3.2 手写一个最小可用的 GSDML

下面是我实际用的 GSDML 文件的核心部分，去掉了注释和无关的厂商信息，只保留能让 PLC 认到设备并建立通讯的最小集合。

<?xml version="1.0" encoding="UTF-8"?> <ISO15745Profile xmlns="http://www.profibus.com/GSDML/2003/11/DeviceProfile"> <ProfileHeader> <ProfileIdentification>PROFINET Device Profile</ProfileIdentification> <ProfileRevision>1.00</ProfileRevision> <ProfileName>Device Profile for PROFINET IO</ProfileName> </ProfileHeader> <ProfileBody> <DeviceIdentity VendorID="0x1234" DeviceID="0x0001"> <InfoText TextId="T_DeviceInfo"/> <VendorName Value="MyVendor"/> </DeviceIdentity> <DeviceFunction> <Family MainFamily="I/O"/> </DeviceFunction> <ApplicationProcess> <DeviceAccessPointList> <DeviceAccessPointItem ID="DAP_1" PhysicalSlots="0..3" ModuleIdentNumber="0x00000001" MinDeviceInterval="32" ImplementationType="RT_Class_1"> <ModuleInfo> <Name TextId="T_DAP_Name"/> <InfoText TextId="T_DAP_Info"/> </ModuleInfo> <IOConfigData MaxInputLength="64" MaxOutputLength="64"/> <UseableModules> <ModuleItemRef ModuleItemTarget="Mod_1" AllowedInSlots="1"/> </UseableModules> </DeviceAccessPointItem> </DeviceAccessPointList> <ModuleList> <ModuleItem ID="Mod_1" ModuleIdentNumber="0x00000002"> <ModuleInfo> <Name TextId="T_Mod1_Name"/> </ModuleInfo> <IOData> <Input Length="4"/> <Output Length="4"/> </IOData> </ModuleItem> </ModuleList> </ApplicationProcess> </ProfileBody> </ISO15745Profile>

这个文件里几个关键点我解释一下。VendorID和DeviceID是厂商和设备标识，PLC 靠这两个值来匹配 GSDML 和实际设备，必须和协议栈里设置的一致。MinDeviceInterval是最小通讯周期，单位是 31.25 微秒，我设的 32 对应 1ms。MaxInputLength和MaxOutputLength是整个设备支持的最大输入输出字节数，我设的 64 字节，实际用多少由模块决定。ModuleItem里的Input Length="4"和Output Length="4"表示这个模块有 4 字节输入和 4 字节输出，对应我测厚仪的厚度值和 PLC 的控制字。

3.3 GSDML 编写最容易踩的坑

第一个坑是ModuleIdentNumber和SubmoduleIdentNumber的对应关系。p-net 在代码里配置模块的时候，需要填这些标识号，如果跟 GSDML 里对不上，PLC 组态时能过，但实际建立 AR 的时候会报“模块不匹配”。我建议在 GSDML 里给每个模块和子模块都分配一个唯一的、有规律的编号，比如模块从 0x00000002 开始递增，子模块从 0x00000001 开始递增，然后在代码里用宏定义统一管理，避免手写错。

第二个坑是IOData的长度单位。GSDML 里的Length单位是字节，但有些文档写的是位，容易搞混。我一开始把 4 字节写成了 4 位，结果 PLC 那边只收到半个字节的数据，排查了半天才发现是单位问题。记住，PROFINET 的循环数据是按字节对齐的，输入输出长度都按字节算。

第三个坑是 GSDML 的版本兼容性。不同版本的 TIA Portal 对 GSDML 的 schema 要求不一样，太新的 schema 在老版本 TIA 里可能导入失败。我一般用 GSDML V2.3 或者 V2.31，兼容性比较好。如果你用的是比较新的 TIA Portal，可以用 V2.4，但要注意有些属性名变了。

4. STM32 上的移植与硬件抽象层实现

4.1 硬件抽象层需要实现哪些函数

p-net 把跟硬件相关的操作都抽象成了几个函数，移植的时候我只需要实现这些函数，协议栈本体不用动。核心的函数有这么几个：

• pnet_eth_init()：初始化以太网外设和 PHY，配置 MAC 地址。
• pnet_eth_send()：把协议栈组好的帧通过网卡发出去。
• pnet_eth_recv()：从网卡收帧，交给协议栈处理。
• pnet_get_tick()：返回一个毫秒级的系统时间，协议栈用来做超时和状态机调度。

这几个函数里，pnet_eth_send()和pnet_eth_recv()是重点。发送的时候要注意，p-net 传下来的帧可能超过一个以太网帧的最大长度，需要分片处理，但 PROFINET 的 RT 帧一般不会超过 1500 字节，所以直接发就行。接收的时候，我是在 ETH 的中断里把帧拷到一个环形缓冲区，然后在主循环里轮询处理，避免在中断里做太多事情。

4.2 网卡初始化和 PHY 配置

STM32F407 的 ETH 外设配置我直接用 CubeMX 生成，关键参数是 RMII 模式、100Mbps 全双工、开启接收和发送中断。PHY 的配置通过 SMI 接口读写寄存器，LAN8720 的地址是 0x00，需要配置成 RMII 模式、开启自动协商。这里有个细节，LAN8720 的REF_CLK输出方向要配置对，如果 PHY 输出 50MHz 给 MCU，那么 PHY 的REF_CLK引脚要配置成输出，MCU 这边配置成输入。配置错了的话，PHY 可能能 link 上，但数据收发会大量 CRC 错误。

我实际用的 PHY 初始化代码如下，去掉了无关的寄存器操作，只保留关键步骤：

void phy_init(void) { // 软复位 PHY phy_write(PHY_ADDR, PHY_BCR, PHY_BCR_RESET); HAL_Delay(100); // 配置为 RMII 模式，开启自动协商 phy_write(PHY_ADDR, PHY_BCR, PHY_BCR_ANEN | PHY_BCR_ANRESTART); // 等待自动协商完成 uint16_t bsr; do { bsr = phy_read(PHY_ADDR, PHY_BSR); HAL_Delay(10); } while (!(bsr & PHY_BSR_ANEGCOMPLETE)); // 读取协商结果，确认是 100Mbps 全双工 uint16_t phy_sr = phy_read(PHY_ADDR, PHY_SR); if ((phy_sr & PHY_SPEED_STATUS) && (phy_sr & PHY_DUPLEX_STATUS)) { // 100Mbps 全双工，配置正确 } }

4.3 系统时钟和定时器配置

p-net 需要一个毫秒级的时钟来驱动状态机和超时处理。我用的是 SysTick，配置成 1ms 中断，在中断里对一个全局变量累加。pnet_get_tick()直接返回这个变量的值。这里要注意，SysTick 的中断优先级要设得比以太网中断低，避免以太网中断被频繁打断导致丢包。我一开始把 SysTick 优先级设得跟 ETH 一样，结果在高负载通讯时偶尔会丢帧，后来把 SysTick 优先级降到最低，问题就消失了。

另外，p-net 的循环数据发送周期是跟 PLC 的 AR 协商出来的，一般是 1ms 到 16ms。我是在主循环里调用pnet_handle_periodic()，这个函数内部会根据时间戳判断是否到了发送周期。主循环的轮询频率要足够高，建议至少 100us 调用一次，否则循环数据的抖动会比较大。我实测下来，主循环 50us 轮询一次，循环数据的抖动在 10us 以内，完全满足 RT 通讯的要求。

5. 与西门子 PLC 的联调实战

5.1 组态和连接建立的过程

PLC 这边我用的是 TIA Portal V16，S7-1500 的 CPU。先把写好的 GSDML 文件导入到硬件目录里，然后在网络视图里把设备拖出来，连接到 PROFINET 总线上。组态的时候要设置设备的 IP 地址和 PROFINET 设备名称，这两个参数必须跟从站代码里设置的一致。我一般把 IP 设成 192.168.0.100，设备名称设成 “thickness-gauge”，在 p-net 的初始化代码里对应设置。

组态完成后下载到 PLC，PLC 会开始发送连接请求。从站这边 p-net 的状态机会从PNET_STATE_INIT走到PNET_STATE_WAIT_FOR_CONNECT，收到连接请求后进入PNET_STATE_CONNECTED，然后建立 AR，最后进入PNET_STATE_DATA状态，开始循环数据交换。整个过程如果顺利的话，几秒钟就能完成。我实际调试的时候，第一次连接花了大概 10 秒，因为 PLC 在反复尝试，后来发现是设备名称大小写不匹配，改成完全一致后秒连。

5.2 循环数据映射和调试

循环数据的映射是联调的重点。在 p-net 里，输入数据是设备发给 PLC 的，输出数据是 PLC 发给设备的。我测厚仪的厚度值是 4 字节的浮点数，放在输入模块里；PLC 下发的控制字是 4 字节，放在输出模块里。映射的代码大概长这样：

// 输入数据：厚度值 float thickness = get_thickness(); memcpy(&input_data[0], &thickness, 4); // 输出数据：控制字 uint32_t control_word; memcpy(&control_word, &output_data[0], 4); if (control_word & 0x01) { // 执行标定 }

调试的时候，我是在 TIA Portal 的监控表里直接看输入输出数据。如果 PLC 收到的厚度值一直是 0，先检查pnet_input_set_data()有没有被调用，再看数据长度对不对。如果 PLC 下发的控制字设备收不到，检查pnet_output_get_data()的返回值，确认输出数据有没有更新。我遇到过一次输出数据不更新的问题，查了半天发现是 p-net 的输出模块配置里SubmoduleDataDirection设成了Input，改成Output就好了。

5.3 通讯地址怎么对应

热搜里有人问“西门子 PLC 与安川机器人 PROFINET 通讯地址怎么对应”，这个问题其实跟我的场景类似。PROFINET 的地址对应分两层：一层是设备名称和 IP 地址，这是网络层的标识；另一层是模块的输入输出数据偏移，这是应用层的映射。PLC 组态的时候，每个模块的输入输出会自动分配地址，比如我的输入模块占 IB0~IB3，输出模块占 QB0~QB3。在 PLC 程序里直接读写这些地址就行。从站这边不需要关心绝对地址，只需要把数据填到对应的模块缓冲区里，p-net 会自动打包成 PROFINET 帧发出去。

这里有个容易混淆的点：PROFINET 的循环数据是面向连接的，不是面向地址的。也就是说，PLC 和从站之间建立 AR 之后，数据是通过 AR 的通道传输的，跟 IP 地址没有直接关系。IP 地址只用于初始的连接建立和诊断。所以你在组态的时候，只要设备名称和 IP 对得上，模块的输入输出长度对得上，数据就能通。

6. 常见问题排查与稳定性优化

6.1 通讯不上怎么一步步排查

通讯不上是最常见的问题，我一般按下面的顺序排查：

这个表是我实际调试中总结出来的，按顺序走一遍，90% 的问题都能定位到。我遇到最诡异的一次是 PHY link 灯亮、能 ping 通、PLC 也能发现设备，但 AR 就是建不起来。后来抓包发现是 p-net 的 DCP 响应里DeviceID跟 GSDML 里的不一致，改过来就好了。

6.2 循环数据抖动大怎么办

循环数据抖动大通常有几个原因。一是主循环轮询频率不够，pnet_handle_periodic()调用间隔太长，导致发送时间不准。二是以太网中断优先级太高，把主循环打断了。三是网络里有其他大流量数据，占用了带宽。我的做法是把主循环轮询频率提到 50us，以太网中断优先级设成中等，同时在交换机上给 PROFINET 划一个独立的 VLAN，避免其他流量干扰。实测下来，抖动从原来的 200us 降到了 20us 以内。

6.3 长时间运行稳定性优化

设备跑久了偶尔会掉线，这个问题我遇到过两次。第一次是内存泄漏，p-net 在每次 AR 建立和断开的时候会分配和释放内存，如果应用层没有正确释放，跑几天内存就满了。解决办法是定期检查pnet_get_memory_usage()，确保内存使用量稳定。第二次是看门狗复位，STM32 的看门狗在以太网中断频繁触发的时候可能会误复位，我把看门狗的超时时间从 1 秒改成 5 秒，同时在喂狗前确认 ETH 中断没有卡死，问题就解决了。

另外，p-net 的状态机在异常情况下可能会卡在某个状态出不来，我加了一个软件看门狗，如果状态机超过 30 秒没有变化，就主动复位协议栈重新初始化。这个逻辑在实际运行中救过好几次场，尤其是现场电磁干扰大的时候，PHY 偶尔会 link 断开重连，软件看门狗能保证设备自动恢复。

7. 一些实操心得和后续扩展方向

整个项目从选型到跑通大概花了三周时间，其中大部分时间花在 GSDML 编写和联调排查上。如果让我重新做一遍，我会先把 p-net 的示例工程在 Linux 上跑通，理解它的状态机和数据流，然后再往 STM32 上移植。这样能省掉很多在硬件上盲目调试的时间。另外，GSDML 文件建议用官方的编辑器或者在线工具生成，手写虽然能加深理解，但容易漏属性，排查起来很痛苦。

后续如果要扩展，我打算加两个东西。一是非循环读写，让 PLC 能通过 RPC 读取设备的诊断信息和标定参数，这样就不用占用循环数据带宽了。二是报警处理，设备出现异常时主动向 PLC 发报警帧，让 PLC 能及时响应。p-net 对这两个功能都有支持，只是需要额外配置一些回调和数据结构。等我把这两个功能跑通，再找机会写一篇续集。

最后分享一个小技巧：调试 PROFINET 的时候，Wireshark 是必备工具。它自带 PROFINET 解析插件，能看到 AR 建立过程、循环数据帧、DCP 报文、报警帧的详细内容。我很多问题都是靠抓包定位的，比在代码里加打印高效得多。抓包的时候记得在交换机上做端口镜像，或者用支持镜像的交换机，不然看不到完整的通讯过程。