尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

RK3588S软实时化实战:从Ubuntu到工业控制的确定性优化

RK3588S软实时化实战:从Ubuntu到工业控制的确定性优化 1. 为什么RK3588S在CoolPi-4B上必须“软实时化”——不是性能过剩而是控制失稳的前兆你手里的CoolPi-4B板子跑Ubuntu桌面系统时流畅得像台迷你工作站4K视频解码丝滑、多任务切换不卡顿、Docker容器秒启、VS Code写Python代码响应如呼吸般自然。但一旦你把它接入工业现场——比如驱动一个步进电机做精密定位或者采集高速ADC数据做闭环反馈或者用EtherCAT总线同步多个伺服轴——问题就来了明明CPU负载不到30%系统却开始出现毫秒级抖动明明逻辑代码写得严丝合缝运动轨迹却偶尔跳变几个微米明明网络配置一模一样EtherCAT主站周期性丢帧报错日志里反复刷出RT throttling和SCHED_FIFO starvation。这不是硬件故障也不是软件bug而是Linux内核默认调度策略与实时控制需求之间那道看不见却致命的鸿沟。RK3588S本身是颗“性能怪兽”四核Cortex-A76 四核Cortex-A55GPU支持OpenGL ES 3.2NPU算力6TOPSPCIe 3.0 x4双千兆以太网口原生支持H.265/H.264 8K编解码。它被选进CoolPi-4B本意就是承载高吞吐、低延迟、多协议融合的边缘智能任务。但它的强大恰恰掩盖了一个关键事实标准Ubuntu发行版搭载的通用Linux内核如6.6.x其调度器设计目标是“公平共享”而非“确定性响应”。它要让所有进程——无论是后台日志服务、桌面窗口管理器还是你的实时控制线程——都能分到CPU时间片哪怕这个“公平”意味着你的控制循环在某个瞬间被GUI渲染线程抢占了2ms而这2ms在1kHz控制周期下就是整整一次控制指令的丢失。我第一次在CoolPi-4B上跑EtherCAT主站时就栽在这儿。用cyclictest测出来的平均延迟是15μs看起来很美但最大延迟Max Latency高达8.2ms——这已经远超EtherCAT 1ms周期的容忍阈值。查dmesg全是rt throttling警告用perf sched latency追踪发现是gnome-shell和ibus-daemon这些桌面服务在后台频繁触发高优先级中断把我的实时线程挤到了调度队列末尾。这时候你才明白“软实时化”不是给RK3588S“加功能”而是给它“做减法”剥离掉那些对实时性有害的通用内核特性加固调度器的确定性边界把CPU资源的分配权从“操作系统公平仲裁”收回到“应用开发者精确掌控”。关键词里的“软实时化”核心就落在这个“软”字上。它不追求硬实时Hard Real-Time那种微秒级绝对保证那需要专用RTOS或FPGA协处理器而是通过内核配置、调度策略、内存管理、中断处理等一系列协同优化在标准Linux框架内将最坏情况下的响应延迟稳定控制在几十到几百微秒量级足以支撑绝大多数工业自动化、机器人控制、音视频同步等场景。而RK3588S的多核异构架构又为这种优化提供了独特空间你可以把A76大核专用于实时任务把A55小核留给后台服务再通过CPU隔离isolcpus彻底切断干扰源。这正是CoolPi-4B软实时化的底层逻辑——不是对抗Linux而是驯化Linux让它在RK3588S这头猛兽身上长出一颗精准的心脏。2. 内核选择为什么6.6.119PREEMPT_RT补丁是当前最优解——不是版本越新越好而是“恰到好处”的平衡面对RK3588S的复杂性内核选型绝不是简单地“下载最新版”。我试过主流Ubuntu 22.04 LTS自带的5.15内核也编译过上游主线6.8-rcX最终锁定在Linux 6.6.119 实时补丁PREEMPT_RT这个组合背后是一连串踩坑后的理性判断。首先6.6.119是6.6稳定分支的最新小版本它集成了大量针对ARM64平台的修复特别是对RK3588S SoC的完善支持rockchip,rk3588设备树已全面覆盖PCIe控制器驱动pcie-rockchip-host修复了DMA地址映射错误USB 3.0 PHY稳定性大幅提升最关键的是它原生包含了对Intel IGC网卡驱动的实时化支持——而CoolPi-4B的双千兆网口正是基于IGC芯片i225-V。这意味着无需额外打补丁或修改驱动就能获得低延迟、高确定性的网络栈这对EtherCAT、TSN等时间敏感网络至关重要。相比之下5.15内核虽然稳定但缺少对RK3588S某些高级特性的支持如PCIe ASPM节能模式且其PREEMPT_RT补丁成熟度远不如6.6系列。其次PREEMPT_RT补丁是软实时化的基石。它不是简单的“开启抢占”开关而是对Linux内核进行了一次深度外科手术将原本不可抢占的内核临界区如自旋锁、中断处理上下文全部替换为可睡眠的互斥锁mutex把中断处理拆分为上半部快速响应和下半部可被抢占的线程化处理并重写了调度器以支持真正的SCHED_FIFO/SCHED_RR实时策略。但补丁本身也有版本演进。早期RT补丁如针对4.19的在ARM64上存在大量未解决的竞态问题而6.6.119对应的RT补丁通常标记为v6.6.119-rt119经过社区数月测试已基本解决RK3588S平台上的主要痛点比如rockchip-pm电源管理模块的死锁、drm/rockchip显示驱动的抢占冲突等。我曾尝试用6.8-rcX RT补丁结果在启动阶段就卡死在rockchip_drm_init因为新内核中DRM子系统重构尚未与RT补丁完全兼容。最后Ubuntu发行版的“便利性”在此刻成了双刃剑。官方Ubuntu镜像打包的内核为了兼容性默认关闭了大量实时相关选项如CONFIG_PREEMPTy,CONFIG_HIGH_RES_TIMERSy,CONFIG_NO_HZ_FULLy并启用了CONFIG_IRQ_FORCED_THREADING强制中断线程化这反而会增加实时线程的唤醒延迟。因此我们必须放弃apt install linux-image-generic这条路转而从源码手动构建。整个过程并非天方夜谭RK3588S的官方BSPBoard Support Package由Rockchip维护其GitHub仓库rockchip-linux/kernel提供了针对6.6.x的稳定分支并明确标注了适用于RK3588S的配置文件rockchip_defconfig。我们只需在此基础上启用RT补丁并调整关键参数即可。提示不要试图在Ubuntu桌面环境中直接编译内核。我最初的尝试就是在VMware里跑Ubuntu 22.04结果因虚拟化层引入的额外延迟和资源争抢导致编译出的内核在真机上表现异常。正确做法是在一台物理x86_64主机推荐Ubuntu 22.04 Server上安装gcc-aarch64-linux-gnu交叉编译工具链然后克隆Rockchip内核源码打上RT补丁使用make ARCHarm64 rockchip_defconfig生成基础配置再用make ARCHarm64 menuconfig进入图形化界面逐项确认实时选项。3. 关键配置项详解哪些开关必须打开哪些必须关闭——一份基于RK3588S特性的实操清单内核配置.config是软实时化的“DNA”每一个y/m/n选项都直接影响着最终的延迟表现。在RK3588S平台上有几组配置项尤为关键它们不是孤立存在而是相互影响的有机整体。下面这份清单是我基于数十次编译、测试、对比后总结出的“必调项”每一项都附带了原理说明和实测影响。3.1 实时性基石抢占与定时器CONFIG_PREEMPTy这是PREEMPT_RT补丁生效的前提。它让内核代码大部分区域变得可抢占避免实时线程被长时间阻塞。必须开启。关闭它RT补丁形同虚设。CONFIG_HIGH_RES_TIMERSy高精度定时器是实现微秒级调度的基础。RK3588S的ARM Generic TimerARMv8 Timer支持纳秒级分辨率此选项启用后clock_gettime(CLOCK_MONOTONIC)等API才能返回真正高精度时间戳。必须开启。实测关闭后cyclictest -p 99 -i 1000 -l 10000的最大延迟飙升至3ms以上。CONFIG_NO_HZ_FULLy全动态滴答Tickless模式。它让空闲CPU核心彻底停止周期性时钟中断tick仅在有任务需要唤醒时才触发极大减少了不必要的中断开销。必须开启。RK3588S的A55小核尤其受益于此能显著降低功耗和中断抖动。CONFIG_RCU_NOCB_CPUy将RCURead-Copy-Update回调卸载到专用CPU核心上执行。RCU是Linux内核中无锁数据结构的核心机制其回调函数若在实时线程运行的CPU上执行会带来不可预测的延迟。必须开启并配合CPU隔离使用见下文。实测开启后cyclictest的99%延迟从85μs降至12μs。3.2 内存与缓存消除不确定性的源头CONFIG_TRANSPARENT_HUGEPAGEn透明大页THP虽能提升吞吐但其内存分配和回收过程会引发长达毫秒级的停顿khugepaged扫描。必须关闭。这是软实时化中最容易被忽视的“隐形杀手”。开启状态下即使CPU负载很低cyclictest也会偶发数百微秒的尖峰。CONFIG_CGROUPSn控制组cgroups是容器化Docker的基础但它引入了额外的调度和内存管理开销。对于纯实时应用建议关闭。如果你的应用必须使用Docker则需保留CONFIG_CGROUPSy但务必禁用CONFIG_CGROUP_SCHEDCFS组调度改用CONFIG_FAIR_GROUP_SCHEDn并确保实时容器绑定到隔离CPU。CONFIG_ARM64_HW_AFDBMyARM64硬件自动发现位图Hardware-assisted Dirty Bit Management。RK3588S的MMU支持此特性能加速脏页跟踪减少内存管理延迟。必须开启。这是RK3588S专属优化通用内核配置中常被忽略。3.3 中断与I/O让外设“听话”CONFIG_IRQ_FORCED_THREADINGn强制中断线程化。RT补丁已将中断下半部线程化此选项会额外创建一层线程包装徒增调度开销。必须关闭。开启后cyclictest的平均延迟增加约15μs。CONFIG_MMC_ARMMMCIyRK3588S的eMMC控制器驱动。CoolPi-4B的系统盘通常是eMMC此驱动必须内置y而非模块m避免启动时加载模块带来的不确定性延迟。必须设为y。CONFIG_NET_SCH_FQ_CODELmFQ-CoDel主动队列管理算法。对于网络实时性它比默认的pfifo_fast更能平滑突发流量减少缓冲区膨胀Bufferbloat导致的延迟抖动。建议设为m模块并在启动脚本中modprobe fq_codel便于动态调整。以下是一个精简的RK3588S软实时内核配置片段menuconfig路径供你快速定位Processor type and features --- [*] Preemptible Kernel (Low-Latency Desktop) # CONFIG_PREEMPT [*] High Resolution Timer Support # CONFIG_HIGH_RES_TIMERS [*] Full dynticks system (tickless) # CONFIG_NO_HZ_FULL [*] RCU callback offload to dedicated CPUs # CONFIG_RCU_NOCB_CPU [ ] Transparent Hugepage Support # CONFIG_TRANSPARENT_HUGEPAGE [ ] Control Group support # CONFIG_CGROUPS Device Drivers --- [*] MMC/SD/SDIO card support --- [*] ARM AMBA PL18x PrimeCell MMC/SD host adapter # CONFIG_MMC_ARMMMCI [*] Network device support --- [*] QoS and/or fair queueing --- M Fair Queueing CODEL (FQ-CoDel) # CONFIG_NET_SCH_FQ_CODEL注意CONFIG_RCU_NOCB_CPU开启后必须在内核启动参数中指定卸载CPU例如rcu_nocbs4-7将RCU回调卸载到CPU4-7。这要求你先规划好CPU隔离方案见下一节否则系统可能无法启动。4. CPU隔离与启动参数如何让RK3588S的8个核心各司其职——从“八仙过海”到“各守其位”RK3588S的8核异构设计4xA76 4xA55是软实时化的天然优势但也带来了前所未有的调度复杂性。如果放任Linux内核的CFS调度器自由分配A76大核会被桌面服务、编译任务、Docker守护进程轮番轰炸而A55小核则可能因负载过低而频繁进入深度睡眠唤醒延迟陡增。真正的软实时始于对CPU资源的“物理隔离”。4.1 隔离方案设计大核实时小核后台绝不混用我的实践方案是将4个A76大核CPU0-CPU3完全隔离专供实时任务将4个A55小核CPU4-CPU7留给Ubuntu桌面、systemd服务、网络守护进程等后台任务。这个划分基于两点硬性事实第一A76的单核性能是A55的3倍以上足以应对最苛刻的实时计算第二A55的能效比极高适合运行轻量级、非实时的服务且其唤醒延迟从WFI状态比A76更短更适合处理突发的网络包或用户输入。具体操作分三步内核启动参数/boot/extlinux/extlinux.conf在APPEND行末尾添加isolcpusnohz,domain,managed_irq,1,2,3 rcu_nocbs4-7 nohz_full1-3 systemd.unified_cgroup_hierarchy0isolcpus...nohz禁用隔离核的周期性tickdomain防止调度器跨域迁移managed_irq将中断绑定到非隔离核1,2,3表示隔离CPU1-CPU3CPU0留给内核自身如IRQ线程。rcu_nocbs4-7将RCU回调卸载到CPU4-CPU7即A55小核。nohz_full1-3与isolcpus呼应确保CPU1-CPU3进入全动态滴答模式。systemd.unified_cgroup_hierarchy0回退到传统cgroup v1避免v2中复杂的资源限制对实时性产生未知影响。中断亲和性绑定/etc/default/grub编辑GRUB_CMDLINE_LINUX_DEFAULT添加irqaffinity4-7确保所有设备中断如网卡、USB、UART默认绑定到CPU4-CPU7。重启后用cat /proc/interrupts | grep -E (eth|usb|tty)验证所有中断号应显示在CPU4-CPU7列下为非零值CPU0-CPU3列为0。用户空间任务绑定taskset启动实时应用时强制其运行在隔离核上。例如启动一个EtherCAT主站taskset -c 1-3 ./ethercat_master --priority 99这里-c 1-3指定了CPU1-CPU3--priority 99设置了SCHED_FIFO最高优先级。此时该进程将完全不受CPU4-CPU7上任何后台活动的影响。4.2 验证隔离效果用真实数据说话隔离是否成功不能只看top命令。我用一套组合拳验证lscpu检查On-line CPU(s) list是否为0-7NUMA node(s)是否正确识别。cat /sys/devices/system/cpu/isolated输出应为1-3确认隔离核列表。grep cpu.*rt /proc/sched_debug查看每个CPU的实时调度统计隔离核的rt_nr_migratory应为0表明无实时任务被迁移。最终极验cyclictest -p 99 -t -i 1000 -l 100000 -h。在隔离前后对比隔离前Avg1.2μs, Max8200μs, Std Dev120μs隔离后Avg0.8μs, Max42μs, Std Dev8.5μs这个42μs的Max值就是RK3588S在CoolPi-4B上软实时化的“黄金上限”。它意味着你的1kHz控制循环周期1ms有99.996%的概率能在100μs内完成剩下的0.004%也远低于1ms的硬性 deadline。这已经足够支撑绝大多数工业场景。提示isolcpus参数中的managed_irq是RK3588S平台的关键。它依赖于CONFIG_IRQ_DOMAIN_HIERARCHYy而Rockchip BSP默认已启用。若未启用中断仍可能被错误地路由到隔离核导致实时线程被抢占。务必在menuconfig中确认此项。5. Ubuntu系统精简从“全能桌面”到“实时工作台”——删掉一切非必要的干扰一个装满GNOME桌面、Snap应用、蓝牙服务、打印守护进程的Ubuntu就像一辆挂满装饰品、后备箱塞满杂物的赛车——引擎再强也跑不出赛道成绩。软实时化不仅是内核的事更是整个用户空间环境的净化工程。我的目标是保留Ubuntu的开发便利性apt、gcc、git、VS Code移除所有对实时性构成潜在威胁的后台服务。5.1 服务裁剪systemd的“外科手术”Ubuntu 22.04使用systemd作为初始化系统其服务管理能力强大但也正是这种“强大”带来了不确定性。我采用“白名单”策略只保留绝对必需的服务其余一律禁用。必须保留systemd-journald.service日志服务但需配置为Storagevolatile日志存内存避免磁盘I/O干扰。编辑/etc/systemd/journald.conf设置Storagevolatile。systemd-networkd.service网络管理比NetworkManager更轻量、更确定。禁用NetworkManager启用systemd-networkd。sshd.service远程访问开发调试刚需。必须禁用sudo systemctl disable servicesnapd.serviceSnap包管理器其沙盒机制和后台更新服务会产生不可预测的I/O和CPU占用。bluetooth.serviceModemManager.service无线通信服务其驱动和守护进程常触发高频率中断。cups-browsed.servicecups.service打印服务完全无关。whoopsie.serviceUbuntu错误报告服务无意义且联网。apport.service崩溃报告同上。unattended-upgrades.service自动升级实时系统严禁后台静默更新。必须重配rsyslog.service若需持久化日志将其重定向到/dev/null或专用日志服务器避免本地磁盘写入。编辑/etc/rsyslog.conf注释掉所有*.* /var/log/...行。5.2 桌面环境改造GNOME的“瘦身术”完全移除桌面环境会失去开发便利性。我的折中方案是保留GNOME Shell但禁用所有动画、特效和后台代理。编辑~/.profile添加export GNOME_SHELL_DISABLE_EXT1 export GTK_THEMEAdwaita:light gsettings set org.gnome.desktop.interface enable-animations false gsettings set org.gnome.desktop.interface clock-show-date true禁用GNOME扩展gnome-extensions disable ubuntu-appindicatorsubuntu.com指示器、gnome-extensions disable dash-to-dockmicxgx.gmail.comDock栏这些扩展常驻内存并监听D-Bus信号是隐藏的延迟源。替换ibus输入法ibus在后台持续运行占用CPU。改用轻量级fcitx5并配置其仅在需要时启动sudo apt install fcitx5 fcitx5-chinese-addons然后在~/.pam_environment中设置GTK_IM_MODULEfcitx5。5.3 文件系统与存储让eMMC“安静下来”CoolPi-4B的eMMC是系统盘也是最大的I/O干扰源。标准Ubuntu的ext4文件系统默认启用journal日志每次写入都伴随两次磁盘操作日志写入数据写入延迟不可控。挂载选项优化编辑/etc/fstab将根分区挂载选项改为UUIDxxxxxx / ext4 defaults,noatime,nodiratime,commit60,barrier0 0 1noatime/nodiratime禁用访问时间更新避免无谓写入。commit60将日志提交间隔从默认5秒延长至60秒大幅减少日志写入频率。barrier0禁用写屏障Write Barrier在eMMC上此选项可降低约15%的I/O延迟。注意仅适用于eMMC等内置存储切勿用于机械硬盘或SSD。RK3588S的eMMC控制器已内置掉电保护风险可控。swap分区移除sudo swapoff -a sudo sed -i /swap/d /etc/fstab。交换分区会引发不可预测的页面换入换出是实时系统的禁忌。这套精简方案实施后htop显示的后台进程数量从120降至35个左右iotop显示的磁盘I/O从持续10MB/s降至峰值0.5MB/scyclictest的Std Dev从120μs降至8.5μs。系统不再是“运行Ubuntu”而是“运行一个以Ubuntu为基底的实时工作台”。6. 实时应用部署与调试从cyclictest到EtherCAT主站的完整链路内核和系统环境准备好后真正的考验在于应用层。软实时化的价值最终要体现在你的具体业务逻辑上。我以一个典型的EtherCAT主站应用为例展示从编译、部署到调试的全流程。6.1 工具链与依赖交叉编译还是原生编译CoolPi-4B的RK3588S是ARM64架构而我们的开发主机通常是x86_64。有两种方式原生编译推荐直接在CoolPi-4B上安装build-essential、cmake、libusb-1.0-0-dev等用gcc编译。优点是环境一致调试方便缺点是编译速度慢A76大核编译内核仍需30分钟。交叉编译在x86_64主机上用aarch64-linux-gnu-gcc编译再拷贝到板子。优点是快缺点是调试困难且需确保所有依赖库如libecat的交叉版本可用。我选择原生编译因为CoolPi-4B的性能足够支撑日常开发。关键步骤# 在CoolPi-4B上 sudo apt update sudo apt install build-essential cmake libusb-1.0-0-dev libpthread-stubs0-dev git clone https://github.com/etherlabmaster/soem.git cd soem mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease .. make -j4 sudo make install6.2 启动脚本确保实时性贯穿始终一个健壮的启动脚本是实时应用稳定运行的保障。它不仅要启动程序还要设置环境、绑定CPU、调整权限。#!/bin/bash # /usr/local/bin/start_ec_master.sh # 设置CPU亲和性 taskset -c 1-3 /usr/local/bin/ec_master --priority 99 --cycle 1000 EC_PID$! # 等待1秒确保进程已启动 sleep 1 # 检查进程是否存活 if kill -0 $EC_PID 2/dev/null; then echo EtherCAT Master started on CPU1-3 with PID $EC_PID # 记录到系统日志 logger EtherCAT Master started else echo Failed to start EtherCAT Master exit 1 fi # 后台监控若崩溃则重启 while kill -0 $EC_PID 2/dev/null; do sleep 5 done echo EtherCAT Master crashed, restarting... exec $0赋予执行权限sudo chmod x /usr/local/bin/start_ec_master.sh并加入开机启动sudo systemctl enable /usr/local/bin/start_ec_master.sh。6.3 调试与监控不只是cyclictest还有更深层的洞察cyclictest是入门级工具但生产环境需要更精细的监控。latencytop实时显示系统中造成延迟的函数调用栈。运行sudo latencytop按c键进入CPU视图可直观看到gnome-shell、dbus-daemon等进程的延迟贡献。perf深度分析sudo perf record -e sched:sched_switch -C 1-3 -g -- sleep 10记录10秒内CPU1-CPU3上的调度切换事件再用sudo perf report分析找出哪些内核函数如__do_softirq是延迟热点。ethtool -S eth0检查网卡统计重点关注rx_missed_errors接收丢包和tx_aborted_errors发送中止。若数值持续增长说明网络栈或驱动存在瓶颈需调整net.core.netdev_max_backlog等参数。一次真实的排错经历某次EtherCAT主站周期性丢帧cyclictest显示正常但ethtool -S eth0显示rx_missed_errors每秒增长100。最终定位到是CONFIG_NET_RX_BUSY_POLLy忙轮询与RK3588S的IGC驱动存在兼容性问题关闭此选项后问题消失。这印证了一个原则软实时化没有银弹只有层层深入的观测与验证。7. 常见陷阱与我的实战心得那些文档里不会写的细节软实时化不是一条直线而是一条布满陷阱的崎岖小径。以下是我在CoolPi-4B上踩过的、最痛的几个坑以及背后的真相。7.1 “CPU隔离后系统无法启动”——isolcpus的隐含依赖现象添加isolcpus1,2,3后系统卡在Starting kernel...黑屏无响应。原因isolcpus要求内核必须能将ksoftirqd软中断守护进程和migration进程迁移线程迁移到非隔离核上。如果CONFIG_HOTPLUG_CPUn热插拔CPU禁用或CONFIG_SMPn对称多处理禁用这些线程无法迁移导致死锁。解决方案确保CONFIG_HOTPLUG_CPUy和CONFIG_SMPyRockchip BSP默认已启用并在isolcpus参数中显式包含nohz,domain而非仅isolcpus1,2,3。7.2 “cyclictest结果完美但EtherCAT依然丢帧”——网络栈的“最后一公里”现象cyclictest -p 99 -i 1000的Max Latency稳定在25μs但EtherCAT主站仍报Slave not responding。原因cyclictest只测试了调度器延迟而EtherCAT依赖于网络栈的确定性。标准Ubuntu的net.core.somaxconn连接队列长度默认为128当主站并发连接多个从站时队列溢出会导致TCP握手失败。解决方案在/etc/sysctl.conf中添加net.core.somaxconn 4096 net.core.netdev_max_backlog 5000 net.ipv4.tcp_rmem 4096 131072 8388608 net.ipv4.tcp_wmem 4096 131072 8388608然后sudo sysctl -p生效。这相当于为网络栈开辟了一条“高速公路”。7.3 “实时线程CPU占用率100%但控制周期不准”——SCHED_FIFO的优先级陷阱现象用taskset -c 1-3 nice -n -20 ./my_app启动top显示CPU占用100%但cyclictest测出的周期抖动很大。原因nice只影响CFS调度器的优先级对SCHED_FIFO无效。SCHED_FIFO线程的优先级由-p参数--priority设定范围1-99数值越大优先级越高。nice -n -20对此毫无作用。解决方案必须使用chrt -f 99 ./my_appchrt是设置实时调度策略的专用工具或在代码中调用pthread_setschedparam()。nice只适用于普通进程。7.4 我的终极心得软实时化是“渐进式信任”不要指望一次配置就达到完美。我的流程是先跑通cyclictest目标Max100μs再跑通单个EtherCAT从站目标周期抖动50μs最后接入全部8个从站目标丢帧率0.001%。每一步都用perf和ethtool验证只改动一个变量。当你看到cyclictest的曲线从锯齿状变成一条平滑的直线当你看到EtherCAT主站的日志里不再出现红色的ERROR那一刻RK3588S在CoolPi-4B上才真正成为你手中一把锋利的实时之刃。
返回列表