0. 核心思路在 RK 平台上做机器人、运动控制或多轴执行器控制时最怕的不是平均 CPU 占用高而是控制周期突然抖一下。EtherCAT 这类实时总线通常要求周期稳定控制线程、网卡中断、PDO 收发、状态估计和安全监控都不能被视频、日志、网络、UI 或算法线程随便打断。因此优化顺序不能一上来就改业务代码而应该先把系统资源管理清楚CPU 不够先绑核绑核后仍有抖动就做中断隔离再不行才进入算法和控制代码重构。这套打法特别适合当前“全线产品双 RK 组合”的硬件形态。双 RK 不是简单堆算力而是把实时控制和感知计算拆成两块资源域一块 RK 尽量靠近 EtherCAT、伺服控制、安全 IO 和底层状态机另一块 RK 承担视觉、音视频、AI 推理、UI、网络和上层业务。这样做的目标不是让每块板都跑满而是让实时板足够干净让非实时板尽量把重任务吃掉避免控制代码在 Linux 普通调度噪声里硬扛。1. 为什么 RK 上能跑实时控制但必须做资源隔离以 RK3588 为例官方资料显示它是 4 个 Cortex-A76 加 4 个 Cortex-A55 的大小核结构并带有视频编解码、多媒体处理、NPU、双千兆网口等外设资源。这个配置对于嵌入式控制已经很强但强不等于天然实时。Linux 默认调度会把进程、内核线程、中断、软中断和后台任务在多个 CPU 之间动态迁移平均吞吐很好但对 EtherCAT 这种周期性控制任务来说随机迁移和异步中断就是 jitter 来源。因此 RK 平台优化的第一原则是把实时性当成资源规划问题而不是只当成代码性能问题。控制线程本身可能只占 10% CPU但如果它和摄像头解码、AI 推理、日志刷盘、网络收包、内核工作队列混在同一组核心上最坏时延会被这些非实时任务拉爆。真正要优化的是最坏情况不是平均情况所以必须通过绑核、cpuset、IRQ affinity、nohz_full、rcu_nocbs、PREEMPT_RT 等手段把控制链路保护起来。2. 双 RK 架构实时板和业务板要分工清楚双 RK 组合建议按“实时控制 RK 业务计算 RK”的方式拆分。实时控制 RK 负责 EtherCAT 主站、伺服周期任务、安全状态机、关键传感器采样、看门狗和低延迟通信业务计算 RK 负责相机输入、硬件解码、AI 识别、UI、日志、云端通信和上层策略。两块 RK 之间可以通过千兆以太网、PCIe、UART 或共享协议通信但不要让业务板直接卡住控制周期控制板只接受经过节流和时间戳管理的指令。如果使用 RK3588 一类大小核芯片实时板内部还要再做一次核级分工。一般可以把 A55 小核留给系统服务、日志、普通网络和 housekeeping把 A76 大核留给 EtherCAT 周期线程、控制线程和关键计算线程。实际 CPU 编号必须以板端查询为准不能靠经验硬写因为不同内核和设备树可能会改变核心编号。上线前至少要用lscpu -e和/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq确认大小核对应关系。lscpu-eforcin/sys/devices/system/cpu/cpu[0-9]*;doecho-n$(basename$c)cat$c/cpufreq/cpuinfo_max_freq2/dev/null||truedone2.1 RK3588 推荐核心规划不要先假设 CPU 编号很多 RK3588 板卡习惯上是 CPU0-3 对应 A55CPU4-7 对应 A76但产品内核、设备树、调度域和频率策略可能会让这个映射表现不完全一致所以真正上线前必须在目标镜像上确认。推荐的起步规划是CPU0-3 做 housekeeping承接 systemd、日志、普通网络、非实时中断和内核工作队列CPU4-5 做业务桥接、协议解析和轻量计算CPU6 做 EtherCAT 周期线程CPU7 做控制计算、安全监控或 EtherCAT IRQ 备选核心。这个规划不是唯一答案但它能把实时链路从系统噪声里先切出来便于后续用 jitter 数据做取舍。# RK3588 板端确认 CPU 拓扑、最大频率、当前 governor 和在线状态lscpu-eCPU,CORE,SOCKET,NODE,ONLINE,MAXMHZ,MINMHZ,MHZforcpuin/sys/devices/system/cpu/cpu[0-7];doecho$(basename$cpu)cat$cpu/topology/core_id2/dev/nullcat$cpu/cpufreq/cpuinfo_max_freq2/dev/nullcat$cpu/cpufreq/scaling_governor2/dev/nulldonecat/proc/cmdline2.2 双 RK 通信边界实时板只收“可控输入”双 RK 之间的通信要有边界不能让业务板把大图、复杂 JSON、无节流日志或不可预测的网络抖动直接打到实时板。实时板最好只接收三类输入带时间戳的目标指令、低频状态更新和经过限幅的参数修改。业务板如果有视觉识别结果应先做滤波、限频和时序对齐再以固定大小结构体或 protobuf flat message 发送。控制板收到后进入双缓冲由非实时通信线程写入 shadow buffer再由实时线程在周期边界读取快照。这样能避免业务板偶发卡顿污染 EtherCAT 周期。3. 第一层优化强制绑核把控制线程固定在确定核心上绑核是最先做的优化因为它成本最低、收益直接、风险可控。控制进程如果不绑核Linux 调度器可能会为了负载均衡把它从一个核心迁移到另一个核心迁移会带来 cache miss、调度延迟和不可控抖动。对于 EtherCAT 控制周期建议先把主控制线程、PDO 收发线程、状态估计线程固定到同一个或相邻的大核上把日志、UI、视频、AI 推理全部排除出去。最简单的方式是用taskset和chrt启动控制进程。taskset设置 CPU affinitychrt设置实时调度优先级。比如把 EtherCAT 控制进程固定到 CPU6并以 SCHED_FIFO 90 优先级运行可以先这样验证。如果系统还有安全监控线程可以放到 CPU7并用略低优先级运行避免它抢占主控制环路但仍能及时响应故障。sudochrt-f90taskset-c6./ecat_controlsudochrt-f80taskset-c7./safety_monitor taskset-a-p-c6$(pidof ecat_control)正式产品里不建议只靠启动脚本临时绑核因为进程重启、线程创建和 systemd 接管后可能丢失策略。更稳的做法是在程序里对关键线程调用pthread_setaffinity_np()并在 systemd unit 里写CPUAffinity做兜底。程序内部绑线程比只绑进程更精细因为一个进程里可能同时有实时线程、通信线程、日志线程和诊断线程它们不应该全部挤在同一个实时核心上。3.1 RK3588 bash 例子把控制、通信、日志分到不同核下面的例子假设 CPU6 是 EtherCAT 周期核CPU7 是控制计算核CPU4-5 是通信和协议桥CPU0-3 是系统 housekeeping。这个脚本适合在开发阶段快速验证不建议直接当最终产品方案。最终方案应由 systemd、程序内部线程 affinity 和启动参数共同保证。注意taskset -a会影响进程内所有线程如果要精细到线程级需要在程序里设置每个 pthread 的 affinity或者用ps -eLo pid,tid,psr,comm找到线程 TID 后单独设置。#!/usr/bin/env bashset-euopipefailECAT_BIN/opt/robot/bin/ecat_controlBRIDGE_BIN/opt/robot/bin/upper_bridgeLOG_BIN/opt/robot/bin/robot_logger# EtherCAT 周期线程所在进程高优先级固定 CPU6sudochrt-f90taskset-c6$ECAT_BIN# 上层通信桥中等优先级固定 CPU4-5sudochrt-f50taskset-c4-5$BRIDGE_BIN# 日志进程普通调度固定 housekeeping CPU0-3taskset-c0-3$LOG_BINsleep2ps-eLopid,tid,cls,rtprio,pri,psr,comm|egrepecat|bridge|logger3.2 systemd 例子产品化时用 CPUAffinity 兜底systemd 的CPUAffinity适合做服务级兜底保证进程启动时落在指定 CPU 集合。它的好处是可维护、可审计、适合量产镜像不足是线程级区分不够细所以实时主线程仍建议在程序内部调用 affinity API。下面例子把 EtherCAT 服务限制到 CPU6-7并开启实时优先级。不同发行版对LimitRTPRIO、LimitMEMLOCK和 systemd 版本支持略有差异部署时要用systemctl show和/proc/pid/status验证实际生效情况。[Unit] DescriptionRobot EtherCAT Realtime Control Afternetwork.target [Service] Typesimple ExecStart/opt/robot/bin/ecat_control CPUAffinity6 7 IOSchedulingClassrealtime IOSchedulingPriority0 LimitRTPRIO95 LimitMEMLOCKinfinity Restartalways RestartSec1 [Install] WantedBymulti-user.target4. 第二层优化ECAT 核心隔离把 EtherCAT 周期从系统噪声里拔出来绑核只能告诉调度器“这个进程尽量跑在哪些核心上”但不能保证这些核心没有别的内核噪声。Linux 内核文档把 CPU isolation 定义为让某个 CPU 尽可能只服务指定工作负载不被中断、定时器、workqueue、kthread 等噪声干扰。对 EtherCAT 来说真正有效的做法是把控制核心从普通调度域里隔离出来把系统 housekeeping 留给其他核心。一个常见 RK3588 规划是CPU0-3 留给系统服务和普通后台CPU4-5 留给业务通信、轻量感知或协议桥CPU6 留给 EtherCAT 周期线程CPU7 留给控制计算和安全监控。启动参数可以先从保守方案开始例如隔离 CPU6-7并把默认 IRQ 亲和性限制到 CPU0-5。实际是否使用nohz_full要看控制线程是否频繁系统调用如果控制线程大部分时间在用户态周期循环中运行收益更明显。isolcpusdomain,managed_irq,6-7 nohz_full6-7 rcu_nocbs6-7 irqaffinity0-5这里要注意isolcpus并不是万能开关。内核文档也明确提醒CPU isolation 有代价隔离核心越干净housekeeping 核心压力越大如果隔离核心频繁进入内核、触发 page fault 或被中断打入仍然会产生抖动。因此控制线程要配合mlockall()锁内存、启动前预热堆栈和缓存、避免实时环里动态分配内存、避免实时环里写文件或打印日志。4.1 RK3588 bootargs 例子先隔离 CPU6-7如果使用 extlinux 或 U-Boot 环境变量可以把隔离参数写进内核启动参数。下面是一个思路示例不同板厂镜像可能使用/boot/extlinux/extlinux.conf、/boot/firmware/extlinux/extlinux.conf、U-Boot env 或 vendor boot 分区路径不能直接照抄。建议先在开发板上做一版可回滚镜像确认串口可进 U-Boot再改启动参数。隔离 CPU6-7 后普通 IRQ 默认进 CPU0-5RCU 回调也从 CPU6-7 挪走减少实时核上的内核噪声。# 查看当前启动参数cat/proc/cmdline# extlinux 示例找到 APPEND 行后追加以下参数sudocp/boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.bakgrep-n^[[:space:]]*APPEND/boot/extlinux/extlinux.confsudoperl-0pi-es/(^[ \t]*APPEND[^\n]*)/$1 isolcpusdomain,managed_irq,6-7 nohz_full6-7 rcu_nocbs6-7 irqaffinity0-5/m\/boot/extlinux/extlinux.conf# 重启后验证sudorebootcat/proc/cmdlinecat/sys/devices/system/cpu/isolated2/dev/null||true4.2 cpuset 运行时隔离不用重启也能做分区验证如果暂时不想改 bootargs可以先用 cpuset/cgroup 做运行时隔离验证。cpuset 的作用是限制一组进程能在哪些 CPU 上运行内核文档也说明任务的 affinity 会被 cpuset 允许范围过滤。它不如启动级 isolation 干净因为中断、内核线程和 workqueue 仍需额外处理但很适合做 A/B 实验先把控制进程放入实时 cpuset把业务进程放入普通 cpuset看 EtherCAT jitter 是否明显改善。# cgroup v1 cpuset 示例具体路径取决于系统挂载方式sudomount-tcgroup-ocpuset cpuset /sys/fs/cgroup/cpuset2/dev/null||truecd/sys/fs/cgroup/cpusetsudomkdir-prt_housekeeping rt_ecatecho0-5|sudoteert_housekeeping/cpuset.cpusecho0|sudoteert_housekeeping/cpuset.memsecho6-7|sudoteert_ecat/cpuset.cpusecho0|sudoteert_ecat/cpuset.mems# 把当前 shell 或指定 PID 放入实时组echo$$|sudoteert_ecat/taskssudochrt-f90./ecat_control5. 第三层优化中断隔离把网卡 IRQ 和非实时 IRQ 分开如果绑核后仍然抖下一步就是看中断。EtherCAT 走以太网网卡 IRQ、软中断、NAPI 轮询、驱动线程和控制线程之间的关系会直接影响周期稳定性。Linux 的/proc/irq/*/smp_affinity可以设置某个 IRQ 允许在哪些 CPU 上运行内核文档也给出了通过该文件改变 IRQ affinity 的方式。实际调优时应先查出 EtherCAT 网卡对应 IRQ再决定它和控制线程是同核、邻核还是专用核。对 EtherCAT 来说网卡 IRQ 有两种常见策略。第一种是 IRQ 和 EtherCAT 周期线程放在同一个隔离核减少跨核唤醒和 cache 传递第二种是 IRQ 放在相邻隔离核控制线程独占一个核避免 IRQ 打断控制计算。哪种更好要以实测 jitter 为准不能只凭理论判断。普通摄像头、USB、Wi-Fi、存储、显示、非实时网口的 IRQ 应全部排到 housekeeping 核心绝不能和 EtherCAT 控制核混在一起。ECAT_IRQ123# 用 /proc/interrupts 查到的 EtherCAT 网卡 IRQ 号NONRT_IRQ456# 摄像头、USB、显示等非实时设备 IRQ 号示例grep-Eeth|enP|gmac|r8169|igb|stmmac/proc/interruptscat/proc/irq/${ECAT_IRQ}/smp_affinity_listecho6|sudotee/proc/irq/${ECAT_IRQ}/smp_affinity_listecho0-5|sudotee/proc/irq/${NONRT_IRQ}/smp_affinity_listsudosystemctl stop irqbalance如果系统里开了 irqbalance它可能会自动重新分配 IRQ直接破坏手工隔离策略。产品系统里建议禁用 irqbalance或者明确配置 banirq 和 CPU mask。还要检查/sys/devices/virtual/workqueue/cpumask把 unbound workqueue 从隔离核移走。否则即使应用绑核了内核工作队列仍可能在控制核上执行造成很难解释的随机尖峰。cat/sys/devices/virtual/workqueue/cpumaskecho0-5|sudotee/sys/devices/virtual/workqueue/cpumask5.1 RK3588 bash 例子自动找出高频 IRQ 和网卡 IRQ调 IRQ 之前不要直接猜先观察/proc/interrupts在压力下的增长速度。下面这个脚本每秒采样一次中断计数帮助找出增长最快的 IRQ。摄像头、USB、VPU、RGA、GPU、显示和非实时网口如果增长很快应该优先排出实时核。EtherCAT 网卡 IRQ 则单独测试同核策略和邻核策略各跑一轮 cyclictest 与 EtherCAT 周期统计比较 Max 和 P99.99而不是只看平均值。#!/usr/bin/env bashset-euopipefailechoTop IRQ deltas, press CtrlC to stopwhiletrue;doawkNR1 $1 ~ /^[0-9]:/ { irq$1; gsub(:,,irq); sum0; for (i2;iNF;i) if ($i ~ /^[0-9]$/) sum$i; name; for (iNF-2;iNF;i) if (i0) namename $i; print irq, sum, name; }/proc/interrupts|sort-k1,1n/tmp/irq.nowif[-f/tmp/irq.prev];thenjoin/tmp/irq.prev /tmp/irq.now|\awk{delta$3-$2; if(delta0) print delta, IRQ$1, substr($0,index($0,$4))}|\sort-nr|head-20echo----fimv/tmp/irq.now /tmp/irq.prevsleep1done5.2 两种 EtherCAT IRQ 策略的实测脚本下面的脚本把 EtherCAT 网卡 IRQ 分别放到 CPU6 和 CPU7各跑一次调度延迟测试。真实项目里还要同步记录 EtherCAT 主站周期、从站 WKC、Distributed Clocks 偏差和伺服报警。这个脚本的价值不是直接给答案而是让团队建立“IRQ 策略必须实测”的习惯。很多时候同核策略平均值更好但最大值更差邻核策略平均值略高却能把控制线程从突发 IRQ 中保护出来。#!/usr/bin/env bashset-euopipefailECAT_IRQ${1:?usage:$0 ecat_irq_number}forcpuin67;doecho Test ECAT IRQ on CPU${cpu}echo$cpu|sudotee/proc/irq/${ECAT_IRQ}/smp_affinity_listcat/proc/irq/${ECAT_IRQ}/smp_affinity_listsudocyclictest--mlockall--priority90--interval1000--affinity6--duration120s\|teecyclictest_irq_cpu${cpu}.logdone6. PREEMPT_RT 与 EtherCAT 主站不是“装了 RT 就完事”PREEMPT_RT 的价值在于降低内核不可抢占区域把很多中断处理线程化并让实时任务有更稳定的调度响应。但它不是魔法不能替代绑核、IRQ 亲和性、内存锁定和驱动选择。Linux 内核实时文档说明 PREEMPT_RT 会改变锁、中断和调度语义因此做 EtherCAT 时要把 RT 内核、主站驱动、网卡驱动和线程优先级一起验证而不是只看uname -a里有没有PREEMPT_RT。IgH EtherCAT Master 是 Linux 上常见的 EtherCAT 主站方案EtherLab 页面说明它可用于 Linux 实时应用并支持 RT-Preempt、Xenomai、RTAI 等实时环境。工程上要把配置阶段和实时周期阶段分开SDO、PDO 映射、从站扫描、状态切换这些配置动作放在普通上下文实时周期里只做必要的receive - process - send避免在实时环里做字符串处理、动态申请、复杂日志和阻塞等待。实时优先级建议形成层级而不是所有线程都设成 99。比如 EtherCAT 周期线程 90伺服控制计算 85安全监控 80通信桥 60日志和诊断保持普通优先级。这样可以避免多个 RT 线程互相饿死也方便分析谁抢占了谁。上线前必须用cyclictest、EtherCAT 周期统计和应用内部时间戳一起验证不能只看业务表现“感觉不卡”。sudocyclictest--mlockall--smp--priority80--interval200--distance0sudocyclictest--mlockall--priority90--interval1000--affinity66.1 RK3588 bash 例子确认 RT 内核、调度策略和内存锁定在 RK3588 上验证 PREEMPT_RT不能只看内核名字。要同时确认PREEMPT_RT配置、线程调度策略、实时优先级、内存锁定上限和实际运行 CPU。很多现场问题来自ulimit -l太小导致mlockall()失败或者 systemd 没放开LimitRTPRIO导致程序以为自己在实时调度实际仍是普通 SCHED_OTHER。下面这些命令适合写入产测脚本启动后自动输出实时环境状态。uname-azcat /proc/config.gz2/dev/null|egrepCONFIG_PREEMPT|CONFIG_PREEMPT_RT|CONFIG_HZulimit-rulimit-lps-eLopid,tid,cls,rtprio,pri,psr,comm|egrepecat|IRQ|cyclic|controlchrt-p$(pidof ecat_control)2/dev/null||truegrep-ECpus_allowed_list|Mems_allowed_list|voluntary_ctxt_switches|nonvoluntary_ctxt_switches\/proc/$(pidof ecat_control)/status2/dev/null||true7. 硬件编解码必须全上视频不能再用 CPU 硬扛在双 RK 产品里摄像头、录制、推流、识别预处理和 UI 显示经常和控制系统同时存在。如果视频解码、编码、缩放、颜色转换还在 CPU 上跑很容易把 A76 核吃满间接影响控制周期。Rockchip 官方 MPP 文档说明 MPP 是 Rockchip 平台的视频编解码 parser 和硬件抽象层RK3588 资料也列出 8K 视频解码、8K 视频编码、JPEG 编解码等多媒体能力所以视频链路必须优先走 MPP/RGA/硬件零拷贝。实际工程里要避免“看起来用了硬解实际还在 CPU 拷贝”的假加速。视频链路最好采用 MPP 解码、RGA 缩放或颜色转换、DMA-BUF/DRM PRIME 零拷贝再把结果送到显示、编码或 AI 预处理。跨 RK 传输时也不要传原始大图能传 H.264/H.265 就硬编后传能传 ROI、结构化结果和时间戳就不要传全帧实时控制板只接收轻量指令和状态不参与重视频处理。如果使用 FFmpeg/GStreamer要确认实际 codec 是否走rkmpp、V4L2 M2M 或板厂提供的硬件插件并用top、perf top、/proc/interrupts和温度频率记录验证。硬件编解码不是为了让视频更快而是为了把 CPU 从非实时任务里释放出来。只要视频软件解码占了控制板的大核就算平均帧率正常也可能在某个关键控制周期制造不可接受的抖动。7.1 RK3588 bash 例子检查 MPP/RGA/VPU 设备和 CPU 占用…详情请参照古月居
RK 双板架构下的 EtherCAT 实时控制优化实践：绑核、隔离、中断亲和、硬编解码与交叉编译
0. 核心思路在 RK 平台上做机器人、运动控制或多轴执行器控制时最怕的不是平均 CPU 占用高而是控制周期突然抖一下。EtherCAT 这类实时总线通常要求周期稳定控制线程、网卡中断、PDO 收发、状态估计和安全监控都不能被视频、日志、网络、UI 或算法线程随便打断。因此优化顺序不能一上来就改业务代码而应该先把系统资源管理清楚CPU 不够先绑核绑核后仍有抖动就做中断隔离再不行才进入算法和控制代码重构。这套打法特别适合当前“全线产品双 RK 组合”的硬件形态。双 RK 不是简单堆算力而是把实时控制和感知计算拆成两块资源域一块 RK 尽量靠近 EtherCAT、伺服控制、安全 IO 和底层状态机另一块 RK 承担视觉、音视频、AI 推理、UI、网络和上层业务。这样做的目标不是让每块板都跑满而是让实时板足够干净让非实时板尽量把重任务吃掉避免控制代码在 Linux 普通调度噪声里硬扛。1. 为什么 RK 上能跑实时控制但必须做资源隔离以 RK3588 为例官方资料显示它是 4 个 Cortex-A76 加 4 个 Cortex-A55 的大小核结构并带有视频编解码、多媒体处理、NPU、双千兆网口等外设资源。这个配置对于嵌入式控制已经很强但强不等于天然实时。Linux 默认调度会把进程、内核线程、中断、软中断和后台任务在多个 CPU 之间动态迁移平均吞吐很好但对 EtherCAT 这种周期性控制任务来说随机迁移和异步中断就是 jitter 来源。因此 RK 平台优化的第一原则是把实时性当成资源规划问题而不是只当成代码性能问题。控制线程本身可能只占 10% CPU但如果它和摄像头解码、AI 推理、日志刷盘、网络收包、内核工作队列混在同一组核心上最坏时延会被这些非实时任务拉爆。真正要优化的是最坏情况不是平均情况所以必须通过绑核、cpuset、IRQ affinity、nohz_full、rcu_nocbs、PREEMPT_RT 等手段把控制链路保护起来。2. 双 RK 架构实时板和业务板要分工清楚双 RK 组合建议按“实时控制 RK 业务计算 RK”的方式拆分。实时控制 RK 负责 EtherCAT 主站、伺服周期任务、安全状态机、关键传感器采样、看门狗和低延迟通信业务计算 RK 负责相机输入、硬件解码、AI 识别、UI、日志、云端通信和上层策略。两块 RK 之间可以通过千兆以太网、PCIe、UART 或共享协议通信但不要让业务板直接卡住控制周期控制板只接受经过节流和时间戳管理的指令。如果使用 RK3588 一类大小核芯片实时板内部还要再做一次核级分工。一般可以把 A55 小核留给系统服务、日志、普通网络和 housekeeping把 A76 大核留给 EtherCAT 周期线程、控制线程和关键计算线程。实际 CPU 编号必须以板端查询为准不能靠经验硬写因为不同内核和设备树可能会改变核心编号。上线前至少要用lscpu -e和/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq确认大小核对应关系。lscpu-eforcin/sys/devices/system/cpu/cpu[0-9]*;doecho-n$(basename$c)cat$c/cpufreq/cpuinfo_max_freq2/dev/null||truedone2.1 RK3588 推荐核心规划不要先假设 CPU 编号很多 RK3588 板卡习惯上是 CPU0-3 对应 A55CPU4-7 对应 A76但产品内核、设备树、调度域和频率策略可能会让这个映射表现不完全一致所以真正上线前必须在目标镜像上确认。推荐的起步规划是CPU0-3 做 housekeeping承接 systemd、日志、普通网络、非实时中断和内核工作队列CPU4-5 做业务桥接、协议解析和轻量计算CPU6 做 EtherCAT 周期线程CPU7 做控制计算、安全监控或 EtherCAT IRQ 备选核心。这个规划不是唯一答案但它能把实时链路从系统噪声里先切出来便于后续用 jitter 数据做取舍。# RK3588 板端确认 CPU 拓扑、最大频率、当前 governor 和在线状态lscpu-eCPU,CORE,SOCKET,NODE,ONLINE,MAXMHZ,MINMHZ,MHZforcpuin/sys/devices/system/cpu/cpu[0-7];doecho$(basename$cpu)cat$cpu/topology/core_id2/dev/nullcat$cpu/cpufreq/cpuinfo_max_freq2/dev/nullcat$cpu/cpufreq/scaling_governor2/dev/nulldonecat/proc/cmdline2.2 双 RK 通信边界实时板只收“可控输入”双 RK 之间的通信要有边界不能让业务板把大图、复杂 JSON、无节流日志或不可预测的网络抖动直接打到实时板。实时板最好只接收三类输入带时间戳的目标指令、低频状态更新和经过限幅的参数修改。业务板如果有视觉识别结果应先做滤波、限频和时序对齐再以固定大小结构体或 protobuf flat message 发送。控制板收到后进入双缓冲由非实时通信线程写入 shadow buffer再由实时线程在周期边界读取快照。这样能避免业务板偶发卡顿污染 EtherCAT 周期。3. 第一层优化强制绑核把控制线程固定在确定核心上绑核是最先做的优化因为它成本最低、收益直接、风险可控。控制进程如果不绑核Linux 调度器可能会为了负载均衡把它从一个核心迁移到另一个核心迁移会带来 cache miss、调度延迟和不可控抖动。对于 EtherCAT 控制周期建议先把主控制线程、PDO 收发线程、状态估计线程固定到同一个或相邻的大核上把日志、UI、视频、AI 推理全部排除出去。最简单的方式是用taskset和chrt启动控制进程。taskset设置 CPU affinitychrt设置实时调度优先级。比如把 EtherCAT 控制进程固定到 CPU6并以 SCHED_FIFO 90 优先级运行可以先这样验证。如果系统还有安全监控线程可以放到 CPU7并用略低优先级运行避免它抢占主控制环路但仍能及时响应故障。sudochrt-f90taskset-c6./ecat_controlsudochrt-f80taskset-c7./safety_monitor taskset-a-p-c6$(pidof ecat_control)正式产品里不建议只靠启动脚本临时绑核因为进程重启、线程创建和 systemd 接管后可能丢失策略。更稳的做法是在程序里对关键线程调用pthread_setaffinity_np()并在 systemd unit 里写CPUAffinity做兜底。程序内部绑线程比只绑进程更精细因为一个进程里可能同时有实时线程、通信线程、日志线程和诊断线程它们不应该全部挤在同一个实时核心上。3.1 RK3588 bash 例子把控制、通信、日志分到不同核下面的例子假设 CPU6 是 EtherCAT 周期核CPU7 是控制计算核CPU4-5 是通信和协议桥CPU0-3 是系统 housekeeping。这个脚本适合在开发阶段快速验证不建议直接当最终产品方案。最终方案应由 systemd、程序内部线程 affinity 和启动参数共同保证。注意taskset -a会影响进程内所有线程如果要精细到线程级需要在程序里设置每个 pthread 的 affinity或者用ps -eLo pid,tid,psr,comm找到线程 TID 后单独设置。#!/usr/bin/env bashset-euopipefailECAT_BIN/opt/robot/bin/ecat_controlBRIDGE_BIN/opt/robot/bin/upper_bridgeLOG_BIN/opt/robot/bin/robot_logger# EtherCAT 周期线程所在进程高优先级固定 CPU6sudochrt-f90taskset-c6$ECAT_BIN# 上层通信桥中等优先级固定 CPU4-5sudochrt-f50taskset-c4-5$BRIDGE_BIN# 日志进程普通调度固定 housekeeping CPU0-3taskset-c0-3$LOG_BINsleep2ps-eLopid,tid,cls,rtprio,pri,psr,comm|egrepecat|bridge|logger3.2 systemd 例子产品化时用 CPUAffinity 兜底systemd 的CPUAffinity适合做服务级兜底保证进程启动时落在指定 CPU 集合。它的好处是可维护、可审计、适合量产镜像不足是线程级区分不够细所以实时主线程仍建议在程序内部调用 affinity API。下面例子把 EtherCAT 服务限制到 CPU6-7并开启实时优先级。不同发行版对LimitRTPRIO、LimitMEMLOCK和 systemd 版本支持略有差异部署时要用systemctl show和/proc/pid/status验证实际生效情况。[Unit] DescriptionRobot EtherCAT Realtime Control Afternetwork.target [Service] Typesimple ExecStart/opt/robot/bin/ecat_control CPUAffinity6 7 IOSchedulingClassrealtime IOSchedulingPriority0 LimitRTPRIO95 LimitMEMLOCKinfinity Restartalways RestartSec1 [Install] WantedBymulti-user.target4. 第二层优化ECAT 核心隔离把 EtherCAT 周期从系统噪声里拔出来绑核只能告诉调度器“这个进程尽量跑在哪些核心上”但不能保证这些核心没有别的内核噪声。Linux 内核文档把 CPU isolation 定义为让某个 CPU 尽可能只服务指定工作负载不被中断、定时器、workqueue、kthread 等噪声干扰。对 EtherCAT 来说真正有效的做法是把控制核心从普通调度域里隔离出来把系统 housekeeping 留给其他核心。一个常见 RK3588 规划是CPU0-3 留给系统服务和普通后台CPU4-5 留给业务通信、轻量感知或协议桥CPU6 留给 EtherCAT 周期线程CPU7 留给控制计算和安全监控。启动参数可以先从保守方案开始例如隔离 CPU6-7并把默认 IRQ 亲和性限制到 CPU0-5。实际是否使用nohz_full要看控制线程是否频繁系统调用如果控制线程大部分时间在用户态周期循环中运行收益更明显。isolcpusdomain,managed_irq,6-7 nohz_full6-7 rcu_nocbs6-7 irqaffinity0-5这里要注意isolcpus并不是万能开关。内核文档也明确提醒CPU isolation 有代价隔离核心越干净housekeeping 核心压力越大如果隔离核心频繁进入内核、触发 page fault 或被中断打入仍然会产生抖动。因此控制线程要配合mlockall()锁内存、启动前预热堆栈和缓存、避免实时环里动态分配内存、避免实时环里写文件或打印日志。4.1 RK3588 bootargs 例子先隔离 CPU6-7如果使用 extlinux 或 U-Boot 环境变量可以把隔离参数写进内核启动参数。下面是一个思路示例不同板厂镜像可能使用/boot/extlinux/extlinux.conf、/boot/firmware/extlinux/extlinux.conf、U-Boot env 或 vendor boot 分区路径不能直接照抄。建议先在开发板上做一版可回滚镜像确认串口可进 U-Boot再改启动参数。隔离 CPU6-7 后普通 IRQ 默认进 CPU0-5RCU 回调也从 CPU6-7 挪走减少实时核上的内核噪声。# 查看当前启动参数cat/proc/cmdline# extlinux 示例找到 APPEND 行后追加以下参数sudocp/boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.bakgrep-n^[[:space:]]*APPEND/boot/extlinux/extlinux.confsudoperl-0pi-es/(^[ \t]*APPEND[^\n]*)/$1 isolcpusdomain,managed_irq,6-7 nohz_full6-7 rcu_nocbs6-7 irqaffinity0-5/m\/boot/extlinux/extlinux.conf# 重启后验证sudorebootcat/proc/cmdlinecat/sys/devices/system/cpu/isolated2/dev/null||true4.2 cpuset 运行时隔离不用重启也能做分区验证如果暂时不想改 bootargs可以先用 cpuset/cgroup 做运行时隔离验证。cpuset 的作用是限制一组进程能在哪些 CPU 上运行内核文档也说明任务的 affinity 会被 cpuset 允许范围过滤。它不如启动级 isolation 干净因为中断、内核线程和 workqueue 仍需额外处理但很适合做 A/B 实验先把控制进程放入实时 cpuset把业务进程放入普通 cpuset看 EtherCAT jitter 是否明显改善。# cgroup v1 cpuset 示例具体路径取决于系统挂载方式sudomount-tcgroup-ocpuset cpuset /sys/fs/cgroup/cpuset2/dev/null||truecd/sys/fs/cgroup/cpusetsudomkdir-prt_housekeeping rt_ecatecho0-5|sudoteert_housekeeping/cpuset.cpusecho0|sudoteert_housekeeping/cpuset.memsecho6-7|sudoteert_ecat/cpuset.cpusecho0|sudoteert_ecat/cpuset.mems# 把当前 shell 或指定 PID 放入实时组echo$$|sudoteert_ecat/taskssudochrt-f90./ecat_control5. 第三层优化中断隔离把网卡 IRQ 和非实时 IRQ 分开如果绑核后仍然抖下一步就是看中断。EtherCAT 走以太网网卡 IRQ、软中断、NAPI 轮询、驱动线程和控制线程之间的关系会直接影响周期稳定性。Linux 的/proc/irq/*/smp_affinity可以设置某个 IRQ 允许在哪些 CPU 上运行内核文档也给出了通过该文件改变 IRQ affinity 的方式。实际调优时应先查出 EtherCAT 网卡对应 IRQ再决定它和控制线程是同核、邻核还是专用核。对 EtherCAT 来说网卡 IRQ 有两种常见策略。第一种是 IRQ 和 EtherCAT 周期线程放在同一个隔离核减少跨核唤醒和 cache 传递第二种是 IRQ 放在相邻隔离核控制线程独占一个核避免 IRQ 打断控制计算。哪种更好要以实测 jitter 为准不能只凭理论判断。普通摄像头、USB、Wi-Fi、存储、显示、非实时网口的 IRQ 应全部排到 housekeeping 核心绝不能和 EtherCAT 控制核混在一起。ECAT_IRQ123# 用 /proc/interrupts 查到的 EtherCAT 网卡 IRQ 号NONRT_IRQ456# 摄像头、USB、显示等非实时设备 IRQ 号示例grep-Eeth|enP|gmac|r8169|igb|stmmac/proc/interruptscat/proc/irq/${ECAT_IRQ}/smp_affinity_listecho6|sudotee/proc/irq/${ECAT_IRQ}/smp_affinity_listecho0-5|sudotee/proc/irq/${NONRT_IRQ}/smp_affinity_listsudosystemctl stop irqbalance如果系统里开了 irqbalance它可能会自动重新分配 IRQ直接破坏手工隔离策略。产品系统里建议禁用 irqbalance或者明确配置 banirq 和 CPU mask。还要检查/sys/devices/virtual/workqueue/cpumask把 unbound workqueue 从隔离核移走。否则即使应用绑核了内核工作队列仍可能在控制核上执行造成很难解释的随机尖峰。cat/sys/devices/virtual/workqueue/cpumaskecho0-5|sudotee/sys/devices/virtual/workqueue/cpumask5.1 RK3588 bash 例子自动找出高频 IRQ 和网卡 IRQ调 IRQ 之前不要直接猜先观察/proc/interrupts在压力下的增长速度。下面这个脚本每秒采样一次中断计数帮助找出增长最快的 IRQ。摄像头、USB、VPU、RGA、GPU、显示和非实时网口如果增长很快应该优先排出实时核。EtherCAT 网卡 IRQ 则单独测试同核策略和邻核策略各跑一轮 cyclictest 与 EtherCAT 周期统计比较 Max 和 P99.99而不是只看平均值。#!/usr/bin/env bashset-euopipefailechoTop IRQ deltas, press CtrlC to stopwhiletrue;doawkNR1 $1 ~ /^[0-9]:/ { irq$1; gsub(:,,irq); sum0; for (i2;iNF;i) if ($i ~ /^[0-9]$/) sum$i; name; for (iNF-2;iNF;i) if (i0) namename $i; print irq, sum, name; }/proc/interrupts|sort-k1,1n/tmp/irq.nowif[-f/tmp/irq.prev];thenjoin/tmp/irq.prev /tmp/irq.now|\awk{delta$3-$2; if(delta0) print delta, IRQ$1, substr($0,index($0,$4))}|\sort-nr|head-20echo----fimv/tmp/irq.now /tmp/irq.prevsleep1done5.2 两种 EtherCAT IRQ 策略的实测脚本下面的脚本把 EtherCAT 网卡 IRQ 分别放到 CPU6 和 CPU7各跑一次调度延迟测试。真实项目里还要同步记录 EtherCAT 主站周期、从站 WKC、Distributed Clocks 偏差和伺服报警。这个脚本的价值不是直接给答案而是让团队建立“IRQ 策略必须实测”的习惯。很多时候同核策略平均值更好但最大值更差邻核策略平均值略高却能把控制线程从突发 IRQ 中保护出来。#!/usr/bin/env bashset-euopipefailECAT_IRQ${1:?usage:$0 ecat_irq_number}forcpuin67;doecho Test ECAT IRQ on CPU${cpu}echo$cpu|sudotee/proc/irq/${ECAT_IRQ}/smp_affinity_listcat/proc/irq/${ECAT_IRQ}/smp_affinity_listsudocyclictest--mlockall--priority90--interval1000--affinity6--duration120s\|teecyclictest_irq_cpu${cpu}.logdone6. PREEMPT_RT 与 EtherCAT 主站不是“装了 RT 就完事”PREEMPT_RT 的价值在于降低内核不可抢占区域把很多中断处理线程化并让实时任务有更稳定的调度响应。但它不是魔法不能替代绑核、IRQ 亲和性、内存锁定和驱动选择。Linux 内核实时文档说明 PREEMPT_RT 会改变锁、中断和调度语义因此做 EtherCAT 时要把 RT 内核、主站驱动、网卡驱动和线程优先级一起验证而不是只看uname -a里有没有PREEMPT_RT。IgH EtherCAT Master 是 Linux 上常见的 EtherCAT 主站方案EtherLab 页面说明它可用于 Linux 实时应用并支持 RT-Preempt、Xenomai、RTAI 等实时环境。工程上要把配置阶段和实时周期阶段分开SDO、PDO 映射、从站扫描、状态切换这些配置动作放在普通上下文实时周期里只做必要的receive - process - send避免在实时环里做字符串处理、动态申请、复杂日志和阻塞等待。实时优先级建议形成层级而不是所有线程都设成 99。比如 EtherCAT 周期线程 90伺服控制计算 85安全监控 80通信桥 60日志和诊断保持普通优先级。这样可以避免多个 RT 线程互相饿死也方便分析谁抢占了谁。上线前必须用cyclictest、EtherCAT 周期统计和应用内部时间戳一起验证不能只看业务表现“感觉不卡”。sudocyclictest--mlockall--smp--priority80--interval200--distance0sudocyclictest--mlockall--priority90--interval1000--affinity66.1 RK3588 bash 例子确认 RT 内核、调度策略和内存锁定在 RK3588 上验证 PREEMPT_RT不能只看内核名字。要同时确认PREEMPT_RT配置、线程调度策略、实时优先级、内存锁定上限和实际运行 CPU。很多现场问题来自ulimit -l太小导致mlockall()失败或者 systemd 没放开LimitRTPRIO导致程序以为自己在实时调度实际仍是普通 SCHED_OTHER。下面这些命令适合写入产测脚本启动后自动输出实时环境状态。uname-azcat /proc/config.gz2/dev/null|egrepCONFIG_PREEMPT|CONFIG_PREEMPT_RT|CONFIG_HZulimit-rulimit-lps-eLopid,tid,cls,rtprio,pri,psr,comm|egrepecat|IRQ|cyclic|controlchrt-p$(pidof ecat_control)2/dev/null||truegrep-ECpus_allowed_list|Mems_allowed_list|voluntary_ctxt_switches|nonvoluntary_ctxt_switches\/proc/$(pidof ecat_control)/status2/dev/null||true7. 硬件编解码必须全上视频不能再用 CPU 硬扛在双 RK 产品里摄像头、录制、推流、识别预处理和 UI 显示经常和控制系统同时存在。如果视频解码、编码、缩放、颜色转换还在 CPU 上跑很容易把 A76 核吃满间接影响控制周期。Rockchip 官方 MPP 文档说明 MPP 是 Rockchip 平台的视频编解码 parser 和硬件抽象层RK3588 资料也列出 8K 视频解码、8K 视频编码、JPEG 编解码等多媒体能力所以视频链路必须优先走 MPP/RGA/硬件零拷贝。实际工程里要避免“看起来用了硬解实际还在 CPU 拷贝”的假加速。视频链路最好采用 MPP 解码、RGA 缩放或颜色转换、DMA-BUF/DRM PRIME 零拷贝再把结果送到显示、编码或 AI 预处理。跨 RK 传输时也不要传原始大图能传 H.264/H.265 就硬编后传能传 ROI、结构化结果和时间戳就不要传全帧实时控制板只接收轻量指令和状态不参与重视频处理。如果使用 FFmpeg/GStreamer要确认实际 codec 是否走rkmpp、V4L2 M2M 或板厂提供的硬件插件并用top、perf top、/proc/interrupts和温度频率记录验证。硬件编解码不是为了让视频更快而是为了把 CPU 从非实时任务里释放出来。只要视频软件解码占了控制板的大核就算平均帧率正常也可能在某个关键控制周期制造不可接受的抖动。7.1 RK3588 bash 例子检查 MPP/RGA/VPU 设备和 CPU 占用…详情请参照古月居
