这次我们来看一块面向智能工控的 RK3572 开发板。和常见的极客型开发板不同它的重点不是单纯跑分而是工业现场的稳定性、多外设接入和长时间运行。从型号定位来看RK3572 属于瑞芯微面向工业级场景的处理器方案配套开发板通常会补齐双网口、多路串口、GPIO、显示接口这些工控刚需外设适合用来做工业 HMI、边缘网关、协议转换器或设备联网终端。如果你正在评估 RK3572 开发板能不能用于实际项目这篇内容会把你关心的几件事一次讲清楚系统怎么烧录、怎么挂载 Ubuntu、第二个网口怎么打开、Qt 程序怎么交叉编译部署到板子上以及启动后如何判断系统稳定性、如何做基本功能验证。文中涉及具体硬件参数的地方都会以官方数据手册和实际板卡配置为准涉及命令和代码的部分我会给出示例和替换说明保证你可以照着落地。先说结论RK3572 开发板适不适合你取决于你要不要一个能跑 Linux、能接多路工业外设、能支持二次开发的硬件平台。如果你之前做的是单片机裸机开发第一次接触这类运行完整操作系统的开发板会明显感觉到差异开发方式从“操作寄存器”变成“写应用 调驱动”调试手段从“单步执行”变成“看日志、查进程、看网络”。接下来我们从核心规格开始逐步拆解。1. 核心能力速览能力项说明项目类型面向智能工控场景的嵌入式开发板处理器瑞芯微 RK3572具体核心数、主频、NPU 算力以官方数据手册为准操作系统支持 Linux 系系统常见为 Buildroot / Ubuntu / Debian 定制镜像具体以厂商 BSP 为准网络能力工业场景通常配置多路网口实际数量以板卡型号为准主要外设串口 / RS485 / USB / GPIO / 显示接口等具体以实物原理图为准适用开发方式交叉编译、Qt 应用开发、网络服务、shell 脚本、设备树与内核调试是否支持挂载 Ubuntu支持可通过烧录 Ubuntu 根文件系统或 NFS 网络挂载方式实现是否支持第二个网口取决于硬件是否引出第二路 PHY需在设备树或内核配置中使能是否支持批量任务适合批量部署可通过统一镜像烧录和脚本初始化实现是否支持 API 服务可运行 Python / C / Node 等服务端程序对外提供 HTTP、Modbus 等接口适合场景工业 HMI、边缘计算网关、设备数据采集、协议转换、自动化产线控制这里要特别说明一点不同厂商的 RK3572 开发板在接口数量、内存大小、存储介质上可能不一样。选型时先看三样东西原理图、数据手册、BSP 源码包。只要这三样齐全后面的开发工作才谈得上可控。2. RK3572 开发板在智能工控中的适用边界很多刚接触工控开发的读者会问为什么不用单片机非要选 RK3572 这种带操作系统的开发板这个问题的答案其实也是 RK3572 的核心价值所在。单片机适合逻辑简单、实时性要求苛刻、成本敏感的场合比如按键采集、电机调速、传感器信号处理。但一旦业务复杂到需要跑 TCP/IP 协议栈、需要图形界面、需要本地数据库、需要远程升级单片机就会非常吃力。RK3572 开发板跑的是完整 Linux 系统可以用标准网络工具、数据库、Qt 图形框架甚至直接跑容器开发效率和后期维护性都比裸机方案好很多。适用的场景大致有几类。第一类是工业 HMI在屏幕上做设备状态显示、参数配置和数据报表Qt 是主力开发工具。第二类是边缘网关把现场总线的数据采集上来再通过以太网或 4G 上传到平台这里考验的是多网口和协议转发能力。第三类是设备控制器用 GPIO 和串口控制外围设备同时跑业务逻辑Linux 的进程管理和调试工具能显著降低开发门槛。不适合的场景也要说清楚。如果你要的是毫秒级以下、确定性极强的运动控制RK3572 这类 Linux 开发板不是最优选择实时性要求必须先评估清楚。如果只需要十几个引脚的控制逻辑用单片机的成本、功耗和体积都更有优势。另外工控设备一旦接入生产环境就是长期运行的不要拿“能启动”当标准要充分测试温度、网络稳定性、断电恢复这些指标。合规方面也要提醒RK3572 开发板接入工业现场时涉及设备安全、数据采集和远程访问必须遵守所在行业的安全生产规范和数据管理要求。如果采集的是人员、设备或生产数据要确认数据归属和使用边界不能越权采集和传输。开发阶段请在隔离测试环境验证不要直接在生产设备上做实验。3. 环境准备与前置条件在拿到 RK3572 开发板后先不要急着接线开机。把开发环境理清楚能省下后面大量排错时间。整套开发环境包括开发板、宿主机、串口调试线、网线、电源、SD 卡或 eMMC 烧录工具以及一套可以从厂商获取的 BSP 源码包。宿主机建议用 Ubuntu版本不用太新18.04 到 22.04 都可以。Windows 也能用但交叉编译、NFS 挂载这些操作在 Linux 上会更顺手。如果你只有 Windows可以先装 VMware 或 VirtualBox 跑一个 Ubuntu 虚拟机注意把虚拟机网络模式设置为桥接这样开发板和宿主机才能互通。需要准备的软件包括串口终端工具minicom、picocom、MobaXterm 都行、烧录工具、交叉编译工具链、TFTP/NFS 服务端。工具链的获取优先用厂商 SDK 自带的那一套不要自己随便从网上下载通用工具链。原因很简单RK3572 的 BSP 对内核版本、glibc 版本、编译器版本有匹配要求用错工具链会导致程序跑不起来排查起来很痛苦。开发板上电前最后检查一遍电源规格。工控开发板的电源接口可能是 DC 圆头、Type-C 或者端子排线电压和电流要求以产品说明书为准。电源反接或过压会烧板这个问题在工控场景里尤其不能忽视。插上串口线和网线之后先看串口有没有枚举出设备节点。如果有ls /dev/ttyUSB0或ls /dev/ttyACM0输出说明串口驱动正常如果没有先换线、换 USB 口、确认驱动再继续。4. 系统烧录与首次启动RK3572 开发板拿到手时厂商一般会预烧一个系统。如果你要做二次开发建议先跑通原厂系统确认板卡本身没问题再烧自己的镜像。系统烧录是整个开发流程里最容易出错、也最依赖具体环境的环节不同厂商的烧录工具差异很大但思路是通用的获取镜像文件、进入烧录模式、烧录到指定存储介质。常见烧录方式有两种。一种是通过 USB 连接开发板使用厂商提供的烧录工具直接烧写 eMMC适合整机量产另一种是制作 SD 卡启动卡把镜像写入 SD 卡开发板从 SD 卡启动。第二种对新手更友好不容易把板载存储搞坏。下面给一个 Linux 下写入 SD 卡的通用示例实际操作时请先确认设备节点不是系统盘# 查看 SD 卡设备节点 lsblk # 假设 SD 卡是 /dev/sdb请务必确认设备号 sudo umount /dev/sdb* 2/dev/null # 写入完整镜像bs4M 可以加快写入速度 sudo dd ifrk3572_industrial_v1.0.img of/dev/sdb bs4M statusprogress # 写入完成后同步并卸载 sync sudo eject /dev/sdb写入完成后把 SD 卡插入开发板连接串口线打开串口终端波特率一般设置为 115200然后上电。上电瞬间应该能在串口终端看到 U-Boot 的启动日志。如果屏幕完全空白优先检查三件事串口线是不是交叉线、波特率对不对、SD 卡有没有被正确识别。串口能看到启动日志说明开发板已经开始工作这是第一个成功标志。U-Boot 启动后会加载内核然后挂载根文件系统。如果系统正常起来串口会进入 Linux shell可以执行uname -a查看内核版本用cat /proc/cpuinfo确认 CPU 信息用free -h查看内存。到这里RK3572 开发板的首次启动就算跑通了。接下来的所有开发都将基于这套可运行的 Linux 环境展开。5. 开发板挂载 Ubuntu 根文件系统“开发板挂载 Ubuntu”是 RK 系列开发板使用频率非常高的一个需求也是很多新手困惑的地方。这里要分清两种含义一种是直接把 Ubuntu 根文件系统烧录到开发板的 eMMC 或 SD 卡里系统启动后就是一个完整的 Ubuntu 环境另一种是通过 NFS 把 Ubuntu 主机的目录挂载到开发板让开发板真正运行的根文件系统在主机上。两者在开发阶段都有价值第一种适合产品部署第二种适合调试因为每次修改不需要重新烧录。先看 NFS 挂载方式这是开发阶段效率最高的一种。在 Ubuntu 主机上安装 NFS 服务端导出一个目录# 主机端安装 NFS 服务 sudo apt update sudo apt install -y nfs-kernel-server # 创建导出目录 sudo mkdir -p /srv/nfs/rootfs # 编辑导出配置 sudo nano /etc/exports在/etc/exports中加入下面一行IP 段按你的测试网络调整/srv/nfs/rootfs 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)然后重启 NFS 服务sudo exportfs -ra sudo systemctl restart nfs-kernel-server开发板端需要先用一个可启动的系统起来再通过命令行挂载主机的 NFS 目录。假设开发板 IP 是 192.168.1.20主机 IP 是 192.168.1.100# 在开发板上执行将主机目录挂载到 /mnt/rootfs mount -t nfs -o nolock 192.168.1.100:/srv/nfs/rootfs /mnt/rootfs # 挂载后可以看到主机上的文件 ls /mnt/rootfs如果挂载时提示mount.nfs: Connection timed out最常见的原因是开发板和宿主机不在同一网段或者防火墙拦截了 NFS 端口。先 ping 一下主机 IP确认网络通再把主机防火墙临时关闭测试能挂载后再加白名单。如果你需要让开发板真正运行 Ubuntu 根文件系统流程会复杂一些从 Ubuntu 官方或厂商提供的仓库下载对应架构的 rootfs 压缩包解压到 SD 卡或 eMMC 的分区上然后用 chroot 或 qemu-user 模式安装必要的软件包。具体操作依赖 RK3572 的架构类型和分区表务必以厂商 BSP 文档为准。开发阶段用 NFS 调试产品阶段再做成完整 Ubuntu 镜像这个节奏最省事。6. Qt 交叉编译环境搭建与程序部署工业 HMI 开发绕不开 Qt。在 RK3572 开发板上跑 Qt 程序不是在开发板上直接安装 Qt Creator 写代码而是在 Ubuntu 主机上编译再把可执行文件和运行库拷贝到开发板。这种模式叫交叉编译也是热词里“Qt 如何交叉编译生成能在开发板运行的文件”的核心答案。搭建交叉编译环境的第一步是安装工具链。工具链优先从 RK3572 SDK 里获取里面通常包含编译器、调试器和 sysroot。如果没有 SDK可以安装通用的交叉编译工具链但版本必须匹配目标系统的 glibc 和内核头文件# 以 aarch64 交叉编译工具链为例请按 SDK 实际架构选择 sudo apt install -y gcc-aarch64-linux-gnu g-aarch64-linux-gnu第二步是准备 Qt 的交叉编译库。这里有两个思路如果 SDK 里已经带编译好的 Qt 库直接用如果 SDK 没有就得在主机上用交叉编译器编译 Qt 源码期间还要指定-xplatform、-prefix、-sysroot等参数。编译 Qt 源码耗时较长建议优先使用 SDK 自带的版本。配置好交叉编译环境后新建或修改一个 qmake 的交叉编译配置。下面是一个简化的 mkspec 片段实际使用时要把工具链前缀和 sysroot 路径替换成你自己的# qmake.conf 片段 QMAKE_CC aarch64-linux-gnu-gcc QMAKE_CXX aarch64-linux-gnu-g QMAKE_LINK aarch64-linux-gnu-g QMAKE_LINK_SHLIB aarch64-linux-gnu-g QMAKE_AR aarch64-linux-gnu-ar QMAKE_STRIP aarch64-linux-gnu-strip QMAKE_INCDIR /opt/rk3572-sdk/sysroot/usr/include QMAKE_LIBDIR /opt/rk3572-sdk/sysroot/usr/lib配置好之后编译一个最简单的 Qt 项目mkdir -p /work/rk3572-qt-hello/build cd /work/rk3572-qt-hello/build # 指定 qmake 路径和交叉编译配置 /opt/rk3572-sdk/qt5/bin/qmake ../hello.pro # 编译 make -j$(nproc) # 查看生成的程序架构 file hello执行file hello后如果输出里包含ARM aarch64或者对应的嵌入式架构标识说明编译成功。接下来把可执行文件拷贝到开发板scp hello root192.168.1.20:/root/在开发板上执行chmod x /root/hello export LD_LIBRARY_PATH/usr/local/qt5/lib:$LD_LIBRARY_PATH export QT_QPA_PLATFORMlinuxfb ./hello如果程序启动时报缺少libQt5Core.so这类错误说明开发板上没有对应的 Qt 运行库把主机编译出的 Qt 库目录整个拷贝到开发板的/usr/local/qt5下再运行。如果在运行界面程序时没有显示输出先确认 RK3572 开发板的显示接口已经接好或者使用linuxfb平台插件指定帧缓冲设备如QT_QPA_PLATFORMlinuxfb:fbdev/dev/fb0。交叉编译的坑大多集中在库路径和平台插件上这两点解决了Qt 在开发板上的运行就会顺畅很多。7. 开发板第二个网口怎么打开与配置很多 RK 平台开发板默认只启用了一路网口第二路网口虽然在硬件上存在但在系统里看不到eth1需要从设备树或内核配置层面把它打开。对于 RK3572 这种工控定位的开发板双网口是常见配置一路连办公网络一路连生产网络实现网络隔离所以“打开第二个网口”几乎是工控项目落地前的必做操作。先判断第二路网口有没有被内核识别。在开发板上执行ifconfig -a如果输出里只有eth0和lo说明第二路网口没有被枚举出来或者被设备树禁用了。打开设备树源文件找到以太网相关的节点检查第二路网口的status属性。常见写法如下gmac1 { status okay; phy-mode rgmii; pinctrl-names default; pinctrl-0 gmac1_rgmii_pins; phy-handle phy1; };如果你的设备树里对应节点写的是status disabled改成okay后重新编译设备树并烧录。如果找不到第二路网口节点问题可能出在 PHY 芯片没有正常工作这时要用dmesg | grep eth查看内核日志确认 PHY 有没有被探测到。很多时候第二路网口没起来不是因为设备树禁用而是 PHY 的复位引脚或时钟没有正确配置这类问题需要对照原理图排查。系统识别出eth1后还要配置 IP 地址。RK 系列开发板常见的网络配置方式有/etc/network/interfaces和netplan两种取决于系统用的是什么网络管理工具。老一点的系统用 interfaces 文件配置方式如下sudo nano /etc/network/interfaces添加auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet static address 192.168.2.100 netmask 255.255.255.0 gateway 192.168.2.1如果系统用的是 netplan配置文件在/etc/netplan/下类似这样network: version: 2 ethernets: eth0: dhcp4: true eth1: addresses: - 192.168.2.100/24配置完成后重启网络服务sudo systemctl restart networking # 或使用 netplan sudo netplan apply配置好之后用ip addr show eth1验证 IP 是否生效。双网口打开后建议在工控场景里明确两个网口的路由策略避免默认路由冲突导致外部网络不通。一个简单做法是业务网口设置静态 IP 且不设默认网关管理网口保留 DHCP 或指定默认网关这样内部通信和外部访问互不干扰。8. 工控功能测试与效果验证开发板能启动、Qt 能跑、网口能识别这些只是开始。工控项目要求的是长期稳定运行所以在正式投入使用之前必须做一轮系统性的功能测试。下面是一套可以直接照着做的验证流程覆盖网络、串口、GPIO 和系统稳定性。先测网络。用iperf3打流确认网口速率和稳定性。开发板一端执行iperf3 -s主机一端执行iperf3 -c 192.168.1.20 -t 30 -P 4如果测试中途出现大量重传或带宽剧烈波动先检查网线质量、PHY 协商速率和电源供电。工控现场环境复杂网口接触不良是常事但软件层面也要确认网卡有没有进入错误状态用ethtool eth0查看。再测串口。串口在工业设备通信中是不可或缺的最常见的测试方法是回环测试把串口的 TX 和 RX 短接然后往串口写数据看能否读到相同的数据# 以 ttyS3 为例设备节点以实际系统为准 stty -F /dev/ttyS3 115200 echo rk3572-serial-test /dev/ttyS3 cat /dev/ttyS3如果cat能输出rk3572-serial-test说明串口收发正常。回环测试通过之后再接实际设备测试 Modbus、自定义协议等通信逻辑重点观察长时间通信后有没有丢帧。然后是 GPIO 测试。GPIO 在工控里通常用来控制继电器、读取传感器状态。通过 sysfs 接口可以快速验证# 导出一个 GPIO编号以你的硬件为准 echo 66 /sys/class/gpio/export echo out /sys/class/gpio/gpio66/direction echo 1 /sys/class/gpio/gpio66/value执行后用万用表或继电器观察对应引脚电平变化确认输出正常。再把引脚方向改为输入接入一个开关或信号源读取数值echo in /sys/class/gpio/gpio66/direction cat /sys/class/gpio/gpio66/value如果输出从 0 变 1说明 GPIO 输入检测正常。GPIO 编号不是随便写的不同芯片、不同板卡的编号映射差异很大一定要以厂商提供的 GPIO 编号表或原理图为准。最后做稳定性测试。工控设备最怕的就是运行几个月后死机或重启。在开发板上跑一个长时间的压测任务同时监测温度、内存、进程状态# 查看 CPU 信息和当前负载 cat /proc/loadavg # 持续观察温度变化 watch -n 5 cat /sys/class/thermal/thermal_zone*/temp # 长时间压力测试把 CPU 跑满 stress --cpu 4 --timeout 3600运行期间每半小时记录一次温度和系统日志。如果温度持续升高超过芯片规格上限或者压力测试过程中出现内核 panic、网络中断说明散热或供电存在问题必须解决后才能进入下一阶段。稳定性测试的时长建议至少 72 小时数据也保留下来作为项目验收的依据。9. 资源占用与性能观察方法开发板资源占用情况直接决定你的应用能跑多大、能同时开几个服务。对 RK3572 开发板来说核心观察指标包括 CPU 占用、内存占用、温度、网络吞吐和磁盘 IO。用top或htop查看进程级的资源占用重点关注两个问题是否有内存泄漏是否有进程导致 CPU 持续满载。工控设备上常见的内存泄漏源是长时间运行的网络服务、Qt 界面的定时刷新、日志模块的不正常堆积。建议在跑应用前记录一份基线数据跑 24 小时后再记录一份对比内存占用变化。温度是工控开发板最容易忽略也最容易出问题的指标。RK 系列芯片工作时发热量不低如果外壳设计没有考虑散热长时间运行很容易触发降频甚至死机。查看温度的命令如下cat /sys/class/thermal/thermal_zone0/temp返回值的单位通常是毫摄氏度比如65000表示 65 摄氏度。在 25 摄氏度的室温下待机 40 到 60 摄氏度、满载 70 到 85 摄氏度都是可能出现的情况但具体数值取决于芯片规格、负载强度和散热方案。如果满载温度到了 85 摄氏度以上建议优先加强散热而不是靠软件降频硬扛。网络资源占用方面用iftop或nload实时查看带宽用netstat -tunlp查看端口监听情况。对于边缘网关类应用还要注意小包转发能力。工控现场往往有大量小数据包传输看起来带宽占用不高但 CPU 中断负载可能很高。此时要用top观察si软中断占用如果偏高考虑开启网卡多队列或调整中断亲和性。内存占用方面Linux 系统会把空闲内存用作缓存free -h里的available才 是真正可用的内存不要看到used高就认为内存不足。如果跑 Qt 界面加多个后台服务建议预留至少 20% 的内存余量避免内存不足时系统触发 OOM 杀手把关键进程杀掉。10. 常见问题与排查方法RK3572 开发板在开发和部署过程中会遇到不少问题大部分有共性的解决路径。下面整理一个排查表按频率从高到低排列。问题现象可能原因排查方式解决方案串口终端无任何输出串口线类型错误、波特率错误、未连接 GND换 USB 转串口模块核对 TX/RX/GND 接线使用交叉串口线波特率设为 115200烧录 SD 卡后无法启动镜像损坏、SD 卡质量差、未设置启动介质重新烧录换一张 SD 卡检查 U-Boot 日志使用高速 SD 卡重新 dd 写入并校验开发板上电后反复重启电源功率不足、供电线压降大测量实际电压电流检查电源适配器规格使用规格更高的电源尽量缩短电源线系统启动卡在 U-Boot 或内核早期阶段设备树配置错误、内核镜像不匹配查看串口日志最后定位的位置用厂商原始配置启动一次只改一个变量eth1网口不显示设备树禁用、PHY 驱动失败、引脚冲突dmesggrep eth、ifconfig -aNFS 挂载超时网段不互通、防火墙拦截、NFS 版本不匹配ping主机 IP查看主机/etc/exports调整网段开放 NFS 端口加-o nolockQt 程序启动报缺少共享库开发板没有程序所需的 Qt 运行库ldd hello查看依赖库拷贝对应.so到开发板设置LD_LIBRARY_PATHQt 界面无显示显示设备未配置、平台插件未指定测试 HDMI 或 LCD 接口是否正常设置QT_QPA_PLATFORMlinuxfb指定/dev/fb0系统运行一段时间后死机温度过高、供电不稳、内存不足查看温度日志、dmesg、free -h加强散热升级电源优化内存占用交叉编译程序在开发板上段错误工具链版本不匹配、sysroot 不一致用file检查程序架构对比 ld 版本使用 SDK 自带工具链重新编译断电后系统配置丢失系统运行在内存或只读文件系统查看挂载信息确认/etc是否可写将配置持久化到可写分区遇到问题时第一原则是“不要同时改多个变量”。很多开发者在板子起不来时同时换了镜像、改了设备树、换了电源结果问题反而更难看。先恢复到厂商默认配置确认基线正常再逐步引入自己的改动每次只改一个点改完测试通过了再改下一个。这个习惯能帮你减少大量无效排错时间。11. 最佳实践与使用建议把 RK3572 开发板用进实际工控项目之前有几条实践建议值得先落实。第一条先从厂商 BSP 跑通所有基础外设再开始写业务代码。很多团队拿到开发板就直接写 Qt 界面、写业务逻辑结果最后发现某个串口驱动有 bug、网口速率不对返工成本非常高。建议拿到板子的第一周把网口、串口、GPIO、显示、存储、看门狗全部测试一遍形成一份“开发板基线报告”。这份报告会是你后续所有开发工作的参考基准。第二条给整个项目建立清晰的目录结构。SDK 源码、开发板镜像、交叉编译工具链、应用代码、测试脚本、产线烧录工具这些内容一定要分目录管理最好用 Git 做版本控制。工控项目的生命周期通常很长三个月后再回来维护如果没有文档和目录规范你会连自己之前烧的镜像在哪都找不到。第三条批量部署要脚本化。如果一台 RK3572 开发板要部署到几十台设备上手动配置一定不可靠。建议制作一个部署脚本自动完成网络配置、时间同步、应用安装、启动项注册和日志配置。如果板卡的存储介质相同还可以先用一台设备做好系统配置再用镜像工具整盘克隆效率会高很多。批量部署前务必在测试环境跑通三遍以上因为产线上的问题会放大十倍。第四条接口服务要控制访问范围。RK3572 开发板在工控现场通常会被分配一个内网 IP也会可能暴露在办公网甚至公网。如果板卡上启动了 HTTP API 或 SSH 服务一定要限制访问来源不要使用默认密码。工控设备一旦被入侵后果不只是数据泄露还可能影响生产安全。所有远程访问接口都要有认证机制并且记录访问日志。第五条数据备份和恢复策略要提前设计。工控设备的运行数据如果只存在本地一旦存储损坏就会丢失。建议优先把数据同步到中心服务器或边缘节点本地只保留缓存。同时考虑系统分区与数据分区分离系统升级时不影响数据分区数据备份时也不需要停机。第六条发布前做完整验收。功能跑通不代表可以上线至少要完成72 小时压力测试、断电重启测试、网络异常恢复测试、外设长时间通信测试。每一步都要有记录有截图或日志存档这样后续出问题时有据可查。12. 总结与下一步RK3572 开发板给人的第一印象是“为工控而生”双网口、多串口、Linux 生态、Qt 支持这些特性组合在一起确实能覆盖大多数工业 HMI 和边缘网关项目。最值得先验证的功能是网络稳定性和外设通信这是工控方案的根基最容易踩的坑则是工具链不匹配和电源供电不足建议不要在这两件事上省时间。下一步可以做的事很明确先用厂商 BSP 跑通板卡基线把网口、串口、GPIO 都测一遍然后在主机端搭建 Qt 交叉编译环境把第一个示例程序部署到开发板再按你的实际业务设计网络拓扑打开需要的网口配置好路由。等这些基础工作完成再开始写业务代码你会发现问题可控很多。如果你是第一次接触 RK3572 开发板建议先把这篇文章里的通用流程在板子上完整跑一遍。任何基于文档的操作都有可能遇到版本差异但你记住一个原则就不会走偏先跑通厂商 BSP再改自己的东西每一步改动都留日志。工控开发没有捷径但按流程做你能走得稳。
