当前位置： 首页 > news >正文

Linux RT 调度器的 SCHED_RR 策略：时间片轮转的实时公平性

news 2026/4/20 14:59:57

一、前言：为什么需要 SCHED_RR

在工业控制、音视频处理、通信基站等对时延敏感的场景中，Linux 系统的实时性往往决定着整个系统的稳定性。作为一名从事嵌入式 Linux 开发十余年的工程师，我深刻体会到：当多个同优先级的实时任务需要共享 CPU 时，单纯的 SCHED_FIFO 策略会导致"先到先服务"的饥饿问题，而 SCHED_RR（Round Robin，时间片轮转）策略通过引入固定时间片机制，在保证实时性的同时实现了同优先级任务间的公平调度。

SCHED_RR 的核心价值在于：它允许同优先级的实时任务以时间片为单位轮流执行，既避免了单一任务长期霸占 CPU，又确保了实时任务相对于普通 CFS 任务的绝对抢占优势。本文将从内核源码层面深入剖析 SCHED_RR 的实现机制，并通过实际案例展示如何在生产环境中配置和优化该策略。

二、核心概念与术语

2.1 实时调度类（RT Scheduling Class）

Linux 内核将调度器分为多个调度类（Scheduling Class），其中实时调度类（RT class）专门服务于实时任务，优先级高于完全公平调度器（CFS）。实时调度类包含两种策略：

  • SCHED_FIFO：先进先出策略，任务一旦获得 CPU 将一直运行，直到主动放弃（阻塞或调用sched_yield()）或被更高优先级任务抢占。同优先级任务之间不会自动切换，先就绪的任务一直执行到结束。

  • SCHED_RR：轮转策略，与 SCHED_FIFO 类似，但为同优先级任务分配固定时间片（默认 100ms）。当时间片耗尽，任务被放到同优先级就绪队列的尾部，等待下一次调度。

2.2 时间片（Time Slice）

时间片是 SCHED_RR 的核心概念，指任务在单次调度周期内允许连续运行的时间长度。根据内核版本不同，默认时间片可能为 100ms 或 25ms（某些发行版如 SUSE 默认调整为 25ms 以提升交互性）。时间片用完后，任务会被强制让出 CPU，但仅在同优先级任务之间轮转，高优先级任务仍可随时抢占。

2.3 实时优先级（RT Priority）

实时优先级范围为 1-99（数值越大优先级越高），与 CFS 的 nice 值（-20 到 19）完全独立。实时任务始终优先于普通任务，这是由调度类的层级决定的。

2.4 RT 带宽控制（RT Bandwidth Control）

为防止实时任务耗尽 CPU 资源导致系统饿死，内核引入了 RT 带宽控制机制。默认配置下，实时任务每周期（1秒）最多运行 950ms（95%），剩余 5% 留给普通任务。相关参数包括：

  • kernel.sched_rt_period_us：周期长度，默认 1,000,000 微秒（1秒）

  • kernel.sched_rt_runtime_us：周期内 RT 任务可运行时间，默认 950,000 微秒（0.95秒）

三、环境准备

3.1 硬件与系统要求

进行 SCHED_RR 策略的实战测试，建议准备以下环境：

硬件配置：

  • x86_64 架构 PC 或 ARM 嵌入式开发板（树莓派 4、NXP i.MX6/8 等）

  • 至少 2GB RAM，多核 CPU 更佳（便于观察多核调度行为）

  • 建议关闭 CPU 频率调节（cpufreq）以稳定测试结果：sudo cpupower frequency-set -g performance

操作系统：

  • Linux 内核版本 4.9+（推荐 5.10 LTS 或 6.x 主线版本）

  • 实时内核补丁（PREEMPT_RT）可选但推荐，用于硬实时场景

  • 发行版：Ubuntu 22.04 LTS、Debian 12、RHEL 8/9 或嵌入式 Buildroot/Yocto 系统

3.2 开发工具安装

# 安装基础开发工具 sudo apt-get update sudo apt-get install -y build-essential linux-headers-$(uname -r) \ manpages-posix-dev rt-tests stress-ng htop sysstat # 验证内核配置支持实时调度 zgrep CONFIG_RT_GROUP_SCHED /boot/config-$(uname -r) # 应输出 CONFIG_RT_GROUP_SCHED=y # 安装 chrt 工具（util-linux 包通常已包含） which chrt # /usr/bin/chrt

3.3 内核参数检查

在开始实验前，先确认当前系统的 SCHED_RR 配置：

# 查看默认时间片（单位：毫秒） cat /proc/sys/kernel/sched_rr_timeslice_ms # 默认输出：100 # 或使用 sysctl sysctl kernel.sched_rr_timeslice_ms # kernel.sched_rr_timeslice_ms = 100 # 查看 RT 带宽控制参数 cat /proc/sys/kernel/sched_rt_period_us # 1000000 cat /proc/sys/kernel/sched_rt_runtime_us # 950000

四、应用场景：工业 PLC 控制系统的多轴运动控制

在实际的工业自动化项目中，我曾负责一个六轴机械臂控制系统。该系统需要同时处理六个伺服电机的实时控制循环，每个轴的控制任务周期为 1ms，且六个轴的控制算法优先级相同（避免某一轴的抖动影响整体协调性）。

技术挑战：

  • 六个同优先级的实时任务（每个轴一个控制线程）需要公平分配 CPU，避免某一轴长期得不到执行导致控制延迟

  • 控制周期严格为 1ms，任务必须在周期内完成计算并输出 PWM 信号

  • 系统还需运行非实时的 HMI（人机界面）任务，用于状态显示和参数配置

解决方案：采用 SCHED_RR 策略，将六个轴控制线程设为优先级 80，时间片调整为 10ms（远小于控制周期，确保每个任务在一个控制周期内都有机会执行）。HMI 任务使用普通 CFS 调度，优先级低于实时任务。通过 RT 带宽控制预留 5% CPU 给 HMI，避免界面卡死。

这种配置下，六个控制线程以 10ms 时间片轮流执行，在一个 1ms 的控制周期内，每个线程都能获得足够的 CPU 时间完成 PID 计算，同时 SCHED_RR 的公平性保证了不会出现某个轴"饿死"的情况。

五、实战案例：SCHED_RR 策略的深度实践

5.1 案例一：验证时间片轮转行为

以下程序创建两个同优先级的 SCHED_RR 任务，通过记录时间戳验证时间片轮转机制：

/* sched_rr_demo.c * 验证 SCHED_RR 的时间片轮转行为 * 编译：gcc -o sched_rr_demo sched_rr_demo.c -pthread * 运行：sudo ./sched_rr_demo */ #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <sched.h> #include <time.h> #include <unistd.h> #include <string.h> #define THREAD_NUM 2 #define ITERATIONS 20 typedef struct { int id; struct timespec start_time; volatile long long counter; } thread_data_t; thread_data_t thread_data[THREAD_NUM]; pthread_barrier_t barrier; // 获取当前时间（微秒） static inline long long get_us() { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); return (long long)ts.tv_sec * 1000000 + ts.tv_nsec / 1000; } // 工作线程：执行密集计算并记录执行时间 void* worker_thread(void* arg) { thread_data_t* data = (thread_data_t*)arg; int id = data->id; // 设置 SCHED_RR 策略，优先级 50 struct sched_param param; param.sched_priority = 50; if (pthread_setschedparam(pthread_self(), SCHED_RR, &param) != 0) { perror("pthread_setschedparam failed"); pthread_exit(NULL); } // 同步所有线程启动 pthread_barrier_wait(&barrier); clock_gettime(CLOCK_MONOTONIC, &data->start_time); long long last_print = get_us(); data->counter = 0; for (int i = 0; i < ITERATIONS; i++) { // 模拟计算密集型工作 volatile double result = 0.0; for (int j = 0; j < 10000000; j++) { result += j * 0.000001; } data->counter++; long long now = get_us(); long long elapsed = now - last_print; last_print = now; // 打印执行信息，观察时间片切换点 printf("[Thread %d] Iter %d: CPU time ~%lld us, counter=%lld\n", id, i, elapsed, data->counter); } return NULL; } int main() { pthread_t threads[THREAD_NUM]; pthread_barrier_init(&barrier, NULL, THREAD_NUM + 1); // 包含主线程 printf("=== SCHED_RR Time Slice Verification ===\n"); printf("Default time slice: "); fflush(stdout); system("cat /proc/sys/kernel/sched_rr_timeslice_ms"); // 创建实时线程 for (int i = 0; i < THREAD_NUM; i++) { thread_data[i].id = i; pthread_create(&threads[i], NULL, worker_thread, &thread_data[i]); } // 主线程也设为 SCHED_RR，确保不会被抢占 struct sched_param param; param.sched_priority = 60; // 略高于工作线程 sched_setscheduler(0, SCHED_RR, &param); pthread_barrier_wait(&barrier); // 启动所有工作线程 // 等待所有线程完成 for (int i = 0; i < THREAD_NUM; i++) { pthread_join(threads[i], NULL); } printf("\n=== Summary ===\n"); for (int i = 0; i < THREAD_NUM; i++) { printf("Thread %d total iterations: %lld\n", i, thread_data[i].counter); } pthread_barrier_destroy(&barrier); return 0; }

代码解析：

  1. 两个工作线程设置为 SCHED_RR 策略，优先级均为 50

  2. 主线程优先级设为 60，确保在初始化阶段不被工作线程抢占

  3. 每个线程执行 20 次迭代，每次包含大量浮点运算模拟 CPU 密集型负载

  4. 通过clock_gettime精确测量每次迭代的执行时间，观察是否出现约 100ms 的时间片边界

预期输出分析：当时间片（默认 100ms）耗尽时，当前线程会被放到同优先级队列尾部，另一个线程开始执行。在输出中可以看到，单个线程的连续执行时间应接近 100ms（100,000 微秒），然后发生切换。

5.2 案例二：动态调整时间片并观察影响

通过修改sched_rr_timeslice_ms参数，观察不同时间片对系统行为的影响：

/* adjust_timeslice.c * 动态调整 SCHED_RR 时间片并测试其影响 */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #include <sched.h> #include <string.h> #define NUM_TASKS 3 // 设置指定 PID 的调度策略为 SCHED_RR int set_rr_policy(pid_t pid, int priority) { struct sched_param param; param.sched_priority = priority; return sched_setscheduler(pid, SCHED_RR, &param); } // 工作进程：持续运行并报告状态 void worker_process(int id) { struct timespec ts; volatile unsigned long long counter = 0; // 获取并打印当前时间片 if (sched_rr_get_interval(0, &ts) == 0) { printf("[Worker %d] Initial timeslice: %ld.%09ld seconds\n", id, (long)ts.tv_sec, ts.tv_nsec); } // 记录开始时间 struct timespec start, current; clock_gettime(CLOCK_MONOTONIC, &start); while (1) { counter++; // 每秒输出一次统计信息 clock_gettime(CLOCK_MONOTONIC, &current); long elapsed = current.tv_sec - start.tv_sec; if (elapsed >= 5) { // 运行 5 秒后退出 printf("[Worker %d] Completed. Counter: %llu\n", id, counter); break; } } exit(0); } int main() { pid_t pids[NUM_TASKS]; int original_timeslice; FILE *fp; // 保存原始时间片 fp = fopen("/proc/sys/kernel/sched_rr_timeslice_ms", "r"); fscanf(fp, "%d", &original_timeslice); fclose(fp); printf("Original timeslice: %d ms\n", original_timeslice); // 测试不同的时间片配置 int test_slices[] = {10, 50, 100, 200}; for (int t = 0; t < 4; t++) { int new_slice = test_slices[t]; printf("\n=== Testing with timeslice = %d ms ===\n", new_slice); // 修改时间片（需要 root 权限） char cmd[128]; snprintf(cmd, sizeof(cmd), "echo %d > /proc/sys/kernel/sched_rr_timeslice_ms", new_slice); system(cmd); // 验证修改 fp = fopen("/proc/sys/kernel/sched_rr_timeslice_ms", "r"); int verified; fscanf(fp, "%d", &verified); fclose(fp); printf("Verified timeslice: %d ms\n", verified); // 创建多个同优先级工作进程 for (int i = 0; i < NUM_TASKS; i++) { pids[i] = fork(); if (pids[i] == 0) { // 子进程 if (set_rr_policy(0, 50) < 0) { perror("set_rr_policy failed"); exit(1); } worker_process(i); } } // 父进程等待所有子进程 for (int i = 0; i < NUM_TASKS; i++) { waitpid(pids[i], NULL, 0); } } // 恢复原始时间片 char cmd[128]; snprintf(cmd, sizeof(cmd), "echo %d > /proc/sys/kernel/sched_rr_timeslice_ms", original_timeslice); system(cmd); printf("\nRestored original timeslice: %d ms\n", original_timeslice); return 0; }

关键观察点：

  • 时间片越小（如 10ms），任务切换越频繁，上下文切换开销增加，但响应更及时

  • 时间片越大（如 200ms），减少切换开销，但同优先级任务的等待时间变长

  • 通过sched_rr_get_interval()系统调用可以查询当前进程的时间片配置

5.3 案例三：使用 chrt 工具管理实时任务

在实际生产环境中，通常使用chrt命令行工具而非编程方式设置调度策略：

#!/bin/bash # sched_rr_management.sh # 使用 chrt 工具管理 SCHED_RR 任务 # 查看当前 shell 的调度策略和优先级 echo "=== Current shell scheduling info ===" chrt -p $$ # 以 SCHED_RR 优先级 50 运行 stress 测试 echo -e "\n=== Starting stress test with SCHED_RR ===" sudo chrt -r 50 stress-ng --cpu 1 --timeout 10s --metrics-brief & STRESS_PID=$! sleep 2 # 查看该进程的调度信息 echo -e "\n=== Process scheduling details ===" chrt -p $STRESS_PID cat /proc/$STRESS_PID/sched | grep -E "policy|prio|slice" # 动态修改已运行进程的优先级（提升到 70） echo -e "\n=== Changing priority to 70 ===" sudo chrt -r 70 -p $STRESS_PID chrt -p $STRESS_PID # 查看时间片信息（通过 /proc 接口） echo -e "\n=== Time slice info ===" cat /proc/sys/kernel/sched_rr_timeslice_ms # 等待 stress 结束 wait $STRESS_PID # 对比：以 SCHED_FIFO 运行相同测试 echo -e "\n=== Comparison: SCHED_FIFO ===" sudo chrt -f 50 stress-ng --cpu 1 --timeout 5s --metrics-brief

chrt 命令常用选项：

  • -r, --rr：使用 SCHED_RR 策略

  • -f, --fifo：使用 SCHED_FIFO 策略

  • -p, --pid：修改已存在进程的调度策略

  • -v, --verbose：显示详细输出

5.4 案例四：内核层面的时间片处理源码分析

深入内核源码理解 SCHED_RR 的时间片处理逻辑（基于 Linux 6.x 内核）：

// 文件：kernel/sched/rt.c // 全局变量：存储 RR 时间片的 jiffies 值 int sched_rr_timeslice = RR_TIMESLICE; // RR_TIMESLICE 默认为 100ms // 时间片耗尽时的处理函数 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) { // 如果是 SCHED_RR 且时间片耗尽，将任务放到队列尾部 if (p->sched_class == &rt_sched_class && p->policy == SCHED_RR && p->rt.time_slice == 0) { // 重新填充时间片 p->rt.time_slice = sched_rr_timeslice; // 将任务移动到同优先级队列尾部，实现轮转 list_move_tail(&p->rt.run_list, &rq->rt.active.queue[p->rt_prio]); } dequeue_rt_entity(rt_se_of(p), flags); } // 时钟中断中递减时间片 void scheduler_tick(void) { struct task_struct *curr = rq->curr; if (curr->policy == SCHED_RR && --curr->rt.time_slice <= 0) { // 时间片耗尽，设置 TIF_NEED_RESCHED 标志，触发调度 set_tsk_need_resched(curr); curr->rt.time_slice = sched_rr_timeslice; // 为下次运行重置 } }

关键机制：

  1. 每个 SCHED_RR 任务的task_struct中包含rt.time_slice字段，记录剩余时间片

  2. 每次时钟中断（tick）递减时间片，耗尽时设置重新调度标志

  3. 任务被移出运行队列时，如果时间片耗尽，会被放到同优先级队列尾部，实现公平轮转

六、常见问题与解答

Q1：为什么我的 SCHED_RR 任务没有按预期轮转？

可能原因：

  • 任务优先级不同：SCHED_RR 只在同优先级任务间轮转，高优先级任务会抢占低优先级任务

  • 任务阻塞：如果任务在时间片耗尽前调用sleep()或进行 I/O 操作，会主动让出 CPU，此时时间片会保留（下次继续用剩余时间片）

  • 单核系统上的优先级反转：确保所有参与轮转的任务优先级相同

排查方法：

# 查看任务的实时优先级 ps -eo pid,comm,rtprio,cls | grep RR # 使用 schedtool 查看详细信息（需安装） schedtool -v <PID>

Q2：如何永久修改默认时间片？

临时修改（立即生效，重启丢失）：

sudo sysctl kernel.sched_rr_timeslice_ms=50 # 或 echo 50 | sudo tee /proc/sys/kernel/sched_rr_timeslice_ms

永久修改：

# 编辑 /etc/sysctl.conf 或创建 /etc/sysctl.d/99-rt.conf echo "kernel.sched_rr_timeslice_ms = 50" | sudo tee /etc/sysctl.d/99-rt.conf sudo sysctl --system

Q3：SCHED_RR 与 SCHED_FIFO 如何选择？

选择建议：

  • SCHED_FIFO：适用于需要持续占用 CPU 直到完成的场景，如关键中断处理、单线程数据采集。注意：同优先级 FIFO 任务可能导致后者饿死。

  • SCHED_RR：适用于多个同优先级实时任务需要公平共享 CPU 的场景，如多路视频编码、多轴运动控制。时间片机制避免了任务饿死。

生产环境经验：在通信基站的基带处理中，我通常将关键时序任务设为 SCHED_FIFO（最高优先级），而将并行的数据处理任务设为 SCHED_RR（次高优先级），确保时序严格的同时避免数据处理线程相互阻塞。

Q4：时间片设置多少合适？

参考配置：

应用场景推荐时间片理由
工业控制（PLC）50-100ms平衡响应速度与切换开销
音频处理10-20ms避免音频缓冲欠载，需快速切换
视频编解码50ms多路编码时公平分配 CPU
网络转发5-10ms低延迟要求，减少抖动

调试技巧：使用ftrace观察实际切换频率：

sudo trace-cmd record -e sched_switch -P <PID> trace-cmd report | grep "sched_switch"

七、最佳实践与性能优化

7.1 CPU 亲和性绑定

在多核系统上，将 SCHED_RR 任务绑定到特定 CPU 可减少缓存失效和迁移开销：

// 绑定到 CPU 0 cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(0, &cpuset); sched_setaffinity(0, sizeof(cpuset), &cpuset);

或使用taskset命令：

sudo chrt -r 50 taskset -c 0 ./realtime_app

7.2 避免优先级反转

当实时任务需要访问共享资源时，使用优先级继承（Priority Inheritance）的互斥锁：

#include <pthread.h> pthread_mutexattr_t attr; pthread_mutex_t mutex; // 初始化互斥锁为优先级继承协议 pthread_mutexattr_init(&attr); pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT); pthread_mutex_init(&mutex, &attr);

7.3 监控与调试

实时监控 SCHED_RR 任务状态：

# 查看所有实时任务的 CPU 占用 ps -eo pid,comm,rtprio,%cpu,cls | grep -E "RR|FIFO" # 使用 perf 观察调度延迟 sudo perf sched record -- sleep 10 sudo perf sched latency # 查看 /proc 接口的调度统计 cat /proc/<PID>/sched | grep -E "se.sum_exec_runtime|nr_switches"

7.4 RT 带宽控制调优

在确保系统安全的前提下，可为实时任务分配更多 CPU 时间：

# 临时关闭 RT 节流（谨慎使用！） echo -1 > /proc/sys/kernel/sched_rt_runtime_us # 或增加 RT 时间配额到 98% echo 980000 > /proc/sys/kernel/sched_rt_runtime_us

警告：完全关闭 RT 节流（设为 -1）可能导致普通任务饿死，建议仅在隔离 CPU 核心（CPU isolation）的环境中使用。

八、总结

SCHED_RR 策略通过时间片轮转机制，在保证实时任务优先于普通任务的同时，实现了同优先级实时任务间的公平调度。掌握该策略的核心在于理解：

  1. 时间片机制：默认 100ms 的固定时间片可通过sched_rr_timeslice_ms调整，影响任务切换频率和系统响应性

  2. 优先级隔离：实时优先级 1-99 独立于 CFS 的 nice 值，且 SCHED_RR 仅在相同优先级内轮转

  3. 带宽控制：默认 95% 的 CPU 时间限制防止实时任务耗尽系统资源

在实际项目中，建议结合chrt工具进行快速原型验证，通过sched_rr_get_interval()在代码中动态获取时间片信息，并利用 CPU 亲和性绑定优化多核性能。对于硬实时需求，建议配合 PREEMPT_RT 补丁使用，并考虑将关键任务设为 SCHED_FIFO，辅助任务设为 SCHED_RR 的混合策略。

通过本文提供的代码示例和调试方法，读者应能够在工业控制、音视频处理、通信设备等场景中正确配置和优化 SCHED_RR 策略，构建稳定可靠的实时 Linux 系统。

参考资源：

  • Linux Kernel Source:kernel/sched/rt.c

  • sched_rr_get_interval(2)man page

  • 《Linux Kernel Development》Robert Love, Chapter 4: Process Scheduling

  • PREEMPT_RT Patch Documentation: https://wiki.linuxfoundation.org/realtime/documentation/start

http://www.jsqmd.com/news/671751/

相关文章：

  • 2026年当下湖北体育看台膜结构服务商深度评测：谁主沉浮？ - 2026年企业推荐榜
  • 开发环境搭建指南：在无sudo权限的Ubuntu 20.04上，从零构建你的tmux工作环境
  • 2026年PE板厂家创新能力大揭秘，定制选哪个技术强的好 - 工业品牌热点
  • TouchGal完整指南：3步打造你的专属Galgame文化社区
  • 你以为毕业论文写作是“盖房子”？好写作AI告诉你，它是一次“极限拆墙”
  • PPTAgent：5分钟学会用AI智能生成专业演示文稿
  • 调参实战：如何用Silvaco优化你的BJT性能？以基区宽度和掺杂为例
  • ICF ACTC团队教练课程认证机构怎么选？北京上海深圳学员首选群智企业教练 - 新闻快传
  • 为什么你的native-image总OOM？GraalVM 22.3+内存分配器重构内幕（含--initialize-at-build-time误用预警）
  • 如何3分钟实现Axure RP全中文界面：免费开源语言包终极指南
  • 2026西安单位厂房整体搬迁靠谱机构综合盘点：双生新时代荣登榜首 - 深度智识库
  • 树莓派玩转HC-SR04超声波测距：从接线到Python代码的保姆级避坑指南
  • 3步掌握Dell G15散热控制：TCC-G15开源工具完全指南
  • Android 8.0 通知渠道适配踩坑
  • 为什么选择NHSE：深度解析动物森友会存档编辑器的5大核心功能
  • Java 深度解析：for 循环 vs Stream.forEach 及性能优化指南
  • 别再被软件里的“成本价”搞晕了！手把手教你用Excel算清股票真实成本（附公式模板）
  • 实测完8款AI开题报告工具后，我发现这款AI即使选题被推翻也能一周救急 - 逢君学术-AI论文写作
  • 别再和开发吵架了！用这份BUG定级与沟通指南，让你的测试报告更有说服力
  • 2026济南市成人学历提升白皮书：深耕济南17年，全国连锁合规标杆横评 - 商业科技观察
  • 从Wi-Fi到汽车雷达：手把手解析脉冲压缩技术在现代工程中的实战配置与避坑指南
  • ModTheSpire终极指南：5分钟内为《杀戮尖塔》安装模组加载器
  • 5个痛点，1个解决方案：Snap.Hutao如何彻底改变你的原神游戏体验
  • 用Python自动化你的日常：5个拿来即用的效率脚本（附源码）
  • Move Mouse：Windows防休眠与系统保持活跃的专业解决方案
  • 2026南昌股权纠纷律师哪家靠谱？专业处理股东权益诉讼的律师推荐 - 品牌2025
  • 剖析靠谱的海鲜池加工厂，哪家合作案例多？ - mypinpai
  • 半导体设备工程师必看：用C#和LabVIEW快速搞定SECS/GEM设备对接（附完整代码示例）
  • 3个步骤掌握BiliTools：免费高效的B站视频下载与AI总结神器
  • 群晖Video Station完整安装指南：3步解决DSM 7.2.2兼容性问题