跳转至

PTM 并行任务机

简介

PTM 是 Parallel Task Machine(并行任务机) 的缩写,是 SF32LB57x 硬件资料中列出的架构模块。它是一种可编程外设任务引擎,适合处理这样一类任务:对普通固件循环而言时序要求过高,对固定功能外设而言过于定制,而规模又小,不值得让主 Cortex-M33 持续参与。

在产品中,PTM 可承担需要确定性时序的外设任务,例如时钟周期敏感的 IO 时序控制、自定义协议处理、传感器数据采集、类 PWM 波形生成、快速响应触发事件,以及由外部事件触发的简单寄存器或存储器操作。

可以这样理解:CPU 负责配置和监控任务;PTM 则在靠近 IO、FIFO/DMA、事件和 AHB 总线的位置,执行重复且对时序敏感的操作。因此,PTM 不只是 GPIO 波形辅助模块,也是用于外设自动化的小型可编程任务机。

当标准外设无法实现所需时序或协议,而让主 CPU 持续执行轮询循环会增加延迟(latency)、功耗或固件复杂度时,请阅读本文。本文面向设计硬件与固件边界的工程师,不介绍 GPIO 或定时器的常规用法。

为什么需要 PTM

在 MCU 项目中,应用逻辑和外设时序常常难以兼顾。CPU 的算力足以处理业务,但以下底层需求若完全由普通固件实现,往往会增加复杂度:

  • 位操作或周期精度要求较高的 IO 时序;
  • 无法直接套用 UART、SPI、I2C 或 CAN 的自定义串行协议;
  • 需要快速触发响应的传感器轮询或采样流程;
  • 超出标准定时器输出模式的类 PWM 控制波形;
  • 与外设事件绑定的小型数据搬运或寄存器控制流程;
  • 不希望每一步都唤醒主 CPU 的多外设协同任务。

这类任务若完全依赖中断处理,可能增加中断负载并使响应延迟更难控制;若采用忙等循环,又会长期占用 CPU、增加功耗;若增加外部逻辑器件,则会提高板级复杂度。PTM 正是为覆盖这几种方案之间的空白而设:由固件配置,以硬件方式执行紧凑、确定性的外设任务。

PTM 在 SF32LB57x 架构中的位置

PTM 可视为连接 SF32LB57x SoC 的 IO、事件、FIFO/DMA 和 AHB 总线资源的小型可编程引擎。应将其视为 SF32LB57x 已文档化的架构能力:若要把基于 PTM 的设计假设沿用到其他 SF32 系列,必须先核实目标器件的文档。

图:PTM 任务执行流程
应用程序/固件
        │
        ▼
CPU 配置 PTM 任务
        │
        ▼
PTM 执行确定性的外设任务序列
        │
        ├── IO 读写
        ├── FIFO/DMA 数据搬运
        ├── AHB 存储器或寄存器访问
        ├── 等待事件/固定延时
        └── CPU 中断或内部事件通知

PTM 执行精简的自定义指令流,交互对象不局限于引脚。它可以读写 IO、等待事件、通过 FIFO/DMA 搬运数据、访问 AHB 上的存储器和外设寄存器,并在需要上层固件处理时通知 CPU。

因此,标准功能仍应交给标准外设;当项目遇到非标准协议或边缘时序需求时,PTM 可提供确定性的实现路径。

核心能力

SF32LB57x 硬件设计指南列出 1 个 PTM 模块、16 路通道;引脚复用表列出了 PTM1_CH0 至 PTM1_CH15。结合 SDK 定义,PTM 的主要能力包括:

  • 可独立控制的 PTM 执行资源;
  • 精简自定义指令集;
  • 可从内部 TCM(紧耦合存储器)或系统总线取指执行;
  • 总线地址读写;
  • 数据运算;
  • 条件跳转和循环;
  • IO 读写;
  • 等待触发;
  • 固定延时;
  • 从 PTM TCM 执行时具备周期级时序控制能力;
  • 1 个 PTM 模块共支持 16 路 IO 通道;
  • 支持带 DMA 接口的 FIFO;
  • 可通过 AHB 总线访问存储器和外设寄存器;
  • 可产生 CPU 中断;
  • 可通过内部事件协调任务;
  • SDK 为带索引的 PTM 资源定义了复位、启动、暂停和单步执行等控制方式。

这些能力共同构成了确定性的外设自动化模块,而不仅是简单的引脚时序发生器。

执行资源配置:SDK v2.5.1 寄存器定义列出了索引为 0–7 的控制/寄存器组,指令定义也使用相应索引命名 TCM 资源。现有资料没有说明这些 SDK 索引与物理处理核数量之间的对应关系,因此不能将索引数量直接解读为芯片中的 PTM 核数量;具体可用资源应以目标器件文档和对应 SDK 实现为准。

执行模型

PTM 执行自定义格式的指令。指令集保持精简,但覆盖了构建外设任务序列所需的关键操作:

  • 流程控制:条件判断、跳转、循环、等待和延时;
  • IO 控制:读取或写入映射到 PTM 的 IO 通道;
  • 数据处理:基本算术和位操作;
  • 总线访问:通过 AHB 总线读写存储器和外设寄存器;
  • 同步:等待触发、产生中断,以及通过内部事件进行协同。

当任务从 PTM TCM 执行时,可以获得周期级时序控制。这对自定义协议和 IO 序列尤为重要:CPU 无需响应每一个边沿、每个时隙或每一段短暂的外设动作。

适合交给 PTM 的任务通常规模小、流程明确且具有确定性。若任务包含高层业务逻辑、复杂分支或产品策略判断,则更适合由 CPU 执行。

IO、FIFO 与 DMA

SF32LB57x 的 PTM 模块共提供 16 路 IO 通道,适合实现自定义接口时序、监测多个管脚,或生成多路关联信号。

PTM 支持带 DMA 接口的 FIFO。实际的自定义协议往往不只是翻转引脚电平,还需要在存储器和 IO 相关逻辑之间搬运数据。借助 FIFO 和 DMA,无需 CPU 逐个字节或字地介入。

常见实现方式包括:

  • 通过自定义接口移位发送或接收数据;
  • 捕获或生成重复 IO 模式;
  • 将数据搬运与外设事件协调起来;
  • 缓冲小型协议事务;
  • 由 DMA 向任务提供数据或读取结果,减少 CPU 在高频数据路径中的参与。

事件与中断

PTM 采用事件驱动的工作方式。它可以等待事件或固定延时,并通过内部事件衔接任务流程;现有器件资料没有说明 PTM 的物理核数量,也没有说明 SDK 资源索引与硬件核之间的映射关系。一部分事件路径可通过中断通知 CPU,使固件只在任务到达关键节点时介入。

其系统级价值在于,将高频、底层的时序工作留在 PTM 中执行,同时把清晰的事件边界交给固件。CPU 无需持续轮询,也不必为每一个时序窗口处理一次中断;它负责配置任务、等待关键事件并处理结果。

典型 PTM 应用

在 SF32LB57x 设计中,当外设行为超出固定功能模块的能力,同时对时序又过于敏感、不适合用普通固件循环实现时,PTM 的价值最明显。典型应用包括:

  • 自定义接口协议;
  • 自定义 PWM 或脉冲生成;
  • 自动传感器采集;
  • 快速触发响应流程;
  • 多模块联动调度;
  • 批量存储器或寄存器操作;
  • 围绕外部器件的小型确定性控制循环;
  • 在传感器、显示、执行器或配套 IC 与主应用固件之间适配协议时序。

使用边界

如果标准外设已经能够完整实现所需功能,通常不应优先使用 PTM。UART、SPI、I2C、CAN、SDIO、I2S、PDM、定时器和 DMA 仍是标准通信和控制场景的首选。PTM 最适合解决标准外设能力边界之外的非标准时序需求。

PTM 与 CPU 功耗

PTM 可以减少 CPU 因处理短小、确定性的外设任务而频繁唤醒的次数。CPU 配置 PTM 任务后,可减少持续参与,并在 PTM 到达需要固件处理的节点时响应。

这对可穿戴和 AIoT 产品尤其有价值,常见场景包括:

  • 监测传感器或 GPIO 模式;
  • 采集短时突发数据;
  • 服务自定义外部器件;
  • 在应用核心不持续活跃时维持时序;
  • 减少重复外设操作带来的中断频率。

实际节能效果取决于时钟、唤醒策略、代码和数据在存储器中的放置位置、外设状态及整体固件架构。PTM 可以执行小规模外设任务,避免每个步骤都唤醒 CPU。

PTM、RP2040 PIO 与 Nordic PPI/DPPI 对比

PTM、RP2040 PIO 和 Nordic PPI/DPPI 都可减少 CPU 对时序敏感工作的参与,但它们的底层工作方式不同,不能简单视为同类模块。

  • PTM 是可编程外设任务机:执行专用指令,可处理 IO、事件、FIFO/DMA、AHB 存储器和寄存器访问。
  • PIO 是可编程 IO 状态机:执行精简指令,重点解决自定义 GPIO 时序和串行类协议。
  • PPI/DPPI 是可编程外设互连:把外设事件连接到另一个外设的既有任务,不执行指令,也不处理数据。
表:PTM、RP2040 PIO 与 Nordic PPI/DPPI 对比
维度 SF32LB57x PTM RP2040 PIO Nordic PPI/DPPI
核心定位 可编程外设任务机,面向确定性 IO、自定义协议、传感器采集和事件驱动的外设流程。 可编程 IO 状态机,面向确定性 GPIO 和自定义串行类协议。 外设事件与任务之间的硬件互连;在具备所需端点时,可实现不依赖 CPU 的协同。
执行单元 按索引编号的 PTM 执行资源;需确认所选器件实际可用的资源。 2 个 PIO 模块,每个模块有 4 个状态机,共 8 个状态机。 事件通道;只传递触发,不执行程序。
底层方式 PTM 执行自定义指令任务。 状态机逐周期执行 PIO 指令。 PPI 连接事件端点和任务端点;DPPI 让发布者和订阅者外设使用同一通道。
时序模型 从 PTM TCM 执行时具备周期级时序控制,支持等待和固定延时。 状态机周期精确执行,支持延时槽和等待指令。 由外设事件直接触发既有任务;时序取决于连接的外设和互连实现。
IO 模型 SF32LB57x 的 1 个 PTM 模块共提供 16 路 IO 通道。 状态机通过引脚配置将指令映射到选定 GPIO。 不直接产生 GPIO 波形;可借助 GPIOTE、定时器等外设暴露的任务。
指令与逻辑 自定义指令集,覆盖 IO、总线读写、数据运算、条件跳转、等待和延时。 小型指令集,聚焦管脚 IO、移位、等待、跳转、FIFO 读写、中断和数据传送。 无指令、循环、分支或数据运算能力。
存储器/寄存器访问 可访问 AHB 存储器和外设寄存器。 主要面向 GPIO、FIFO 和移位寄存器;数据和配置通常由 CPU 或 DMA 提供。 不访问存储器或通用外设寄存器,只连接可用的事件和任务端点。
FIFO/DMA 支持带 DMA 接口的 FIFO。 发送/接收 FIFO,常与 DMA 配合使用。 互连本身没有数据通路,但可触发支持 DMA 的外设任务。
CPU 交互 可产生 CPU 中断,并通过内部事件衔接任务。 通过中断标志、FIFO、CPU/DMA 交互。 CPU 负责配置通道;运行时可由外设自主完成事件到任务的触发。
典型应用 自定义接口协议、自定义 PWM、自动传感器采集、批量存储器/寄存器操作和多模块调度。 UART/SPI/I2S 类自定义接口、WS2812 类波形、管脚级串行协议和精确 GPIO 时序。 RTC 或定时器事件启动 ADC 转换、计数器或其他已暴露任务端点的标准外设。

底层工作方式

这些机制的执行路径如下:

图:PPI、DPPI、PIO 与 PTM 的执行路径
PPI:事件端点 ──> PPI 通道 ──> 任务端点

DPPI:发布事件的外设 ──> DPPI 通道 ──> 订阅事件的外设任务

PIO:CPU/DMA ──> PIO 状态机指令 ──> GPIO 时序与 FIFO

PTM:CPU 配置 ──> PTM 任务指令 ──> IO+事件+FIFO/DMA+AHB 访问

PPI 和 DPPI 通过事件互连工作,不执行指令,但只能把已经存在的事件和任务连接起来,不能编写新的协议逻辑。PIO 可通过状态机定义新的管脚行为,但工作范围主要是 GPIO 与 FIFO。PTM 的任务范围更宽:除 IO 时序外,还可把事件等待、数据搬运、寄存器访问和多个小任务的协同组织成一个可执行流程。

PIO 遇到等待条件或 FIFO 满/空时可能暂停执行,系统 DMA 的供数时序也不能由指令时序保证。事件互连同样存在与实现相关的延迟。因此,不能仅凭这些架构差异判断哪一种方案的功耗最低。DPPI 跨电源域传递事件还要求所选器件实现相应的桥接模块,并非所有 DPPI 系统都支持。

Nordic PPI 与 DPPI

PPI 是 Nordic 的传统模型,见于 nRF52 系列等器件。软件为每条通道配置事件端点和任务端点;通道还可配置一个 fork 任务端点,但本质上仍是显式的端点连接。

DPPI 是 Nordic 较新的模型。外设将事件发布到某个通道,一个或多个外设任务订阅同一通道。发布者与订阅者因此解耦,适合较新的多电源域 Nordic 架构;若信号需要跨电源域,PPI Bridge 可在支持的 DPPI 通道之间传递信号。

表:Nordic PPI 与 DPPI 对比
维度 PPI DPPI
配置模型 软件为通道指定事件端点和一个或多个任务端点。 外设事件发布者和任务订阅者选择同一通道。
连接方式 显式的事件端点到任务端点连接。 发布/订阅连接。
一个事件触发多个任务 使用多个通道,或使用通道的 fork 任务端点。 多个任务订阅者可订阅同一已发布通道。
典型平台 支持传统 PPI 的 Nordic 器件,包括许多 nRF52 器件。 实现分布式事件系统的较新 Nordic 器件。
执行能力 不执行指令,也不处理数据。 不执行指令,也不处理数据。

智能手表传感器中枢

对智能手表中的常规传感器中枢,首选仍是标准 I2C/SPI 外设、DMA、定时器和低功耗唤醒机制。应先判断问题属于哪一类:

  • 常规采样链路:例如 RTC 或定时器到期后启动一个已支持的标准外设任务,并在采样完成或阈值满足时通知 CPU。在 Nordic 平台上,较早器件可使用 PPI,较新器件可使用 DPPI,来实现这类“事件触发既有任务”的链路;无需为此编写 PIO 或 PTM 程序。
  • 自定义电气协议:例如传感器需要非标准的引脚波形、位宽或时序,标准 I2C/SPI 无法覆盖。此时 PIO 更适合承担管脚级协议实现。
  • 自定义传感器流程:例如外设事务还需要等待多个触发、控制多路 IO、搬运短数据、读写寄存器并协调多个步骤。在 SF32LB57x 上,这类流程更适合由 PTM 承担,再在关键节点通知 CPU。

因此,PPI/DPPI、PIO 和 PTM 不是互斥的“优劣选项”,而是分别覆盖事件连接、管脚协议和外设任务自动化三个层级。对 SF32LB57x 项目,应先使用标准外设;只有标准外设无法覆盖实际时序或流程时,再考虑使用 PTM。

参考:思澈科技(SiFli)PTM 指令定义、RP2040 数据手册、Nordic PPI 规范、Nordic DPPI 事件系统。

设计建议

**时序与功耗边界:**指令可以按时钟周期控制,并不意味着整个事务的耗时固定:AHB 访问、等待 DMA 完成和等待外部事件都可能引入可变延迟。运行时必须保持所需的 PTM、存储器和外设时钟及电源域有效。CPU 不活动,并不意味着 PTM 在所有 SoC 睡眠模式下都能运行。应将保留时钟和唤醒开销计入总能耗,并与标准外设方案进行实测比较。

**资源归属:**SDK v2.5.1 的 SF32LB57x 无帧存储器(RAMless)DPI 显示驱动使用了 SDK 中标识为“PTM core 0”的执行资源、对应 TCM、事件 0、相关中断及分配到的 DMA 通道。这里的“PTM core 0”是 SDK 使用的资源标识;不能据此推定芯片的物理 PTM 核数量。该驱动展示了总线访问和 DMA 协同的实际实现,而不是可以自由复用的资源分配方案。不要覆盖正在运行的驱动所占用的资源;应明确 CPU 与 DMA 之间的缓冲区归属,并按需执行缓存维护。

应先确认目标器件为 SF32LB57x,且其文档针对当前设计明确列出 PTM;之后,当一个流程具备以下多项特征时,可以考虑使用 PTM:

  • 重复频率较高,由 CPU 持续处理会增加能耗或压缩时序余量;
  • 需要围绕 IO 边沿或触发响应实现确定性时序;
  • 标准外设无法很好覆盖自定义接口;
  • 数据搬运可从 FIFO/DMA 辅助中受益;
  • 逻辑可以表达为紧凑的状态机或任务序列;
  • 只需要在关键边界通知固件。

以下情况应避免使用 PTM:

  • 标准外设已经能够清晰实现协议;
  • 任务属于高层且分支复杂的应用逻辑;
  • 时序要求较宽松,普通中断或 RTOS 任务更简单;
  • 软件团队尚未具备 PTM 所需的 SDK 支持、示例或工具链。

好的 PTM 设计,首先应划清确定性工作和策略性工作的边界:把时序控制、短数据搬运和事件响应放入 PTM;把产品决策、错误处理策略、大型缓冲区和复杂状态管理留在固件中。

要点

  • SF32LB57x 硬件设计指南列出 1 个 PTM 模块和 16 路通道;其他器件应以各自文档为准。
  • 设计前应确认所选器件和 SDK 实际支持的 PTM 执行资源。
  • 它可以从 PTM TCM 或系统总线执行精简自定义指令。
  • 它支持 IO 控制、总线/寄存器访问、数据运算、等待、延时、FIFO/DMA、中断和内部事件。
  • 它适合处理介于固定功能硬件和普通固件之间的确定性自定义外设行为。
  • PTM 与 RP2040 PIO 在概念上有相似之处,但系统集成范围和任务范围都更广。
  • 对 SF32LB57x 设计而言,如果目标器件文档确认提供所需的 PTM 资源,PTM 可成为一项有价值的架构能力,尤其适用于自定义传感器、显示、执行器、协议适配和低开销外设自动化。

最后更新: