这阵子嵌入式圈子里聊 SBC单板计算机选型的人特别多供应链波动让不少人从“看着便宜就囤”变成了“先想清楚用途再下手”。我手上这块 Apollo Lake 平台的 Pico-ITX 板子就是在这种背景下反复对比之后留下的主力测试平台。带 Dual GbE Ports 的小板子不少但能把尺寸、功耗、扩展和网络性能平衡到这种程度的确实不多。简单说这是一块 100mm x 72mm 左右的主板尺寸比一张名片大不了多少集成 Intel Apollo Lake 系列处理器板载两个千兆网口。它最适合的场景是工业网关、边缘数据采集、轻量网络设备、小型 NAS 原型验证以及各种对空间和功耗敏感、又需要 x86 生态的嵌入式项目。如果你在选型阶段或者刚拿到类似板子不知道怎么下手这篇文章会把我最近的折腾过程、测试数据和踩过的坑一次讲清楚。1. 先搞清楚这块板子的定位它到底解决什么问题很多朋友一看到 Pico-ITX 就下意识拿它和树莓派比这其实是个误区。树莓派是 ARM 生态适合跑 Python 脚本、GPIO 控制和轻量服务而 Apollo Lake 是 x86 架构能直接跑标准 Linux 发行版、Windows 系统兼容绝大多数工业软件和 x86 编译的二进制程序。选 SBC 不是看谁跑分高而是看谁能用最小的代价完成你的业务闭环。1.1 为什么 Apollo Lake 到现在还有生命力Apollo Lake 是 Intel 在 2016 年前后发布的低功耗 SoC 平台14nm 工艺集成核显和内存控制器TDP 根据型号不同在 6W 到 10W 之间。放到今天看它的绝对性能确实比不上最新的 N100、N200 这些平台但在嵌入式领域“够用”和“稳定”往往比“性能强”更重要。我做过一个很直观的对比平台制程典型TDP支持内存千兆网口数市场货源Apollo Lake (N3350/N4200)14nm6W-10WDDR3L/DDR4/LPDDR4理论最多2个二手和工业渠道充足Gemini Lake (N4000/N4100)14nm6W-10WDDR4/LPDDR4最多2个消费级常见Jasper Lake (N5100/N6000)10nm6W-10WDDR4/LPDDR4最多2个逐渐增多Elkhart Lake (N6210)10nm6.5W-12WDDR4最多2个工业渠道为主Apollo Lake 的核心优势不是性能而是生态和成本。它在 Linux 内核里的支持非常成熟从 4.x 到最新的 6.x 内核都能良好运行驱动问题少网上能查到的资料和踩坑记录也最丰富。对于做产品原型或者小批量设备这是一个巨大的隐性优势因为你不需要花大量时间去移植驱动。1.2 Pico-ITX 尺寸带来的设计约束Pico-ITX 是 VIA 最早提出的超小主板规格尺寸固定为 100mm x 72mm。这个尺寸比 Mini-ITX170mm x 170mm小了将近一半比树莓派的 85mm x 56mm 大一些但仍然属于“巴掌大”的范畴。尺寸小的代价是接口布局必须非常紧凑。我这块板子的双网口挨在一起旁边就是 USB 口和显示接口如果机箱设计得不好网口插拔时手指很容易碰到旁边的线缆。另一个约束是扩展能力Pico-ITX 通常只有一个 M.2 或 mPCIe 插槽甚至有些板子直接焊死存储选型前一定要确认你需要的接口是否齐全。一个值得注意的细节是散热。Pico-ITX 板子大多是被动散热设计Apollo Lake 的发热量不大但如果你的应用场景是长期满负载运行比如持续转发流量散热片的大小和机箱风道仍然会直接影响稳定性。我后面会专门讲温度测试数据。1.3 双千兆网口为什么是核心竞争力标题里特意强调 Dual GbE Ports说明双网口是这块板子的核心卖点。为什么要双网口最直接的应用是做网关一个口接 WAN一个口接 LAN中间做转发和过滤。哪怕是入门级的软路由应用双千兆也能轻松跑满千兆线速转发因为 Apollo Lake 的性能对付纯网络转发绰绰有余。除了网关双网口还能做桥接、链路聚合需要交换机配合、网络隔离、数据采集旁路镜像等。对于工业场景很多设备需要同时接入两个不同网段的网络比如一个网段连接 PLC 和传感器另一个网段连接上层管理系统双网口就能做到物理隔离不用额外加交换机。2. 硬件细节拆解哪些参数决定实际体验拿到板子不能光看宣传页要拆开看关键芯片型号、供电设计、接口实现方式。这些细节决定了你后面能跑到什么性能、遇到什么坑。2.1 SoC 与内存配置的取舍Apollo Lake 家族里常见的型号有 Celeron N3350双核、N3450四核、N4200四核以及 Atom x5-E3930、x7-E3950 这些工业级版本。N3350 在 Pico-ITX 板型里最常见因为它的成本和功耗最低对于网络转发、串口采集这类负载双核完全够用。我这块板子用的是 N4200 版本四核四线程主频 1.1GHz睿频到 2.5GHz应付轻量虚拟化和多路串口采集比 N3350 从容很多。内存方面板载 LPDDR4容量从 2GB 到 8GB 都有选型时建议直接上 4GB 起步。很多嵌入式板子内存是焊死的后续无法升级这是硬约束你必须提前想清楚业务需要多少内存。一个容易被忽略的问题是内存频率和时序。Apollo Lake 对内存兼容性的要求比消费级平台高实际使用中我发现某些低电压内存条如果是 SO-DIMM 版本会偶发开机失败不过板载 LPDDR4 一般没有这个问题所以追求稳定的话优先选板载内存版本。2.2 网络芯片网口体验的关键双网口不是简单地堆两个 PHY 芯片还要看配套的 MAC 控制器和驱动。Apollo Lake 平台内部通常集成一个 Gigabit MAC另一个网口则通过 PCIe 外接网卡芯片实现。我碰到的板子多采用 Intel i211 或 Realtek RTL8111/RTL8168 系列作为第二网口。从长期使用的角度来看Intel i211 的 Linux 驱动igb成熟度远高于 Realtek 的 r8169 驱动尤其是在高负载下Intel 网卡的 CPU 占用和稳定性表现更好。当然 Realtek 芯片也不是不能用只是当你做高吞吐测试时可能会遇到断流或者延迟抖动的问题这在工业控制场景中是不可接受的。如果你手里的板子用的是 Realtek 网卡也不要急着否定可以先更新到最新的 r8169 驱动参数。部分内核版本对 Realtek 的 ASPM主动电源管理支持有问题导致网速不稳定可以在启动参数里加pcie_aspmoff来规避这个后面在问题排查部分会详细说。2.3 存储接口与 eMMC 的寿命问题Pico-ITX 板子通常有三种存储方案板载 eMMC、SATA 接口、M.2 或 mPCIe 转 NVMe/SATA。我手里这块板子板载 32GB eMMC同时带一个 M.2 B-Key 插槽可以转接 SATA SSD 或者 NVMe SSD受限于 PCIe 通道数量速度可能跑不满。eMMC 是一个容易踩坑的地方。它的读写速度虽然不如 SSD但对于嵌入式系统足够可问题在于寿命和写入放大。如果你在 eMMC 上运行一个频繁写日志的应用程序或者跑 Docker 容器Flash 的寿命会急剧下降。我见过一些设备因为日志写得太猛几个月后 eMMC 就出现坏块导致系统不可用。解决思路很简单系统放 eMMC数据和日志放到外部 SSD 或者通过网络存储。系统分区尽量用只读挂载日志用 tmpfs 或远程日志。如果你用的板子支持从 SATA 或 NVMe 启动直接把整个系统装到 SSD 上更省心。2.4 供电与复位设计稳定运行的地基工控板子的供电设计比消费主板严格得多。Pico-ITX 标准供电一般是 12V DC 输入但很多板子支持宽压输入比如 9V 到 36V这是为了适应工业现场的电源环境。我手里这块板子支持 12V 单电源DC 口旁边有反接保护和浪涌抑制电路这在现场调试时真的能救命。还有一个容易忽略的细节是看门狗Watchdog。工业设备要求系统死机后能自动复位很多 Apollo Lake 板子通过 Super I/O 芯片或者 Intel 平台自带的看门狗定时器实现。Linux 下可以用/dev/watchdog来控制如果设备部署在无人值守的现场这个功能必须测一遍。3. 从选型到部署一套能直接参考的实践流程这块板子到我手里之后我按“需求定义、系统安装、网络调优、压力验证”四个步骤走了一遍整个过程相对完整可以直接作为同类型 SBC 的落地参考。3.1 先定场景再谈配置很多朋友选 SBC 的习惯是“先买回来再想干什么”这个顺序容易造成浪费。我的建议是先列一个需求清单至少包含以下问题需要跑什么操作系统Ubuntu、Debian、Yocto 还是 Windows需要外接哪些设备USB 设备数量、串口数量、GPIO 需求网络流量有多大是偶尔传几个字节的 Modbus 报文还是持续几百 Mbps 的视频流环境温度范围是多少有没有风扇机箱是否密封供电条件怎么样是稳定 12V还是车载电源有波动我之前有一个项目客户说只需要“采集几个温湿度传感器”结果现场要求接 8 路 RS485 设备同时还要通过 4G 模块上传数据最终还需要一个千兆网口接摄像头。如果当初只看标题选板子肯定得换硬件所以需求清单能帮你在最开始就判断这块 Pico-ITX 是否够用。3.2 系统安装从 U 盘到启动进系统的完整过程Apollo Lake 板子安装 Linux 系统的过程和普通 x86 电脑几乎一样但有几个细节需要注意。准备一个 8GB 以上的 U 盘用 Rufus 或 balenaEtcher 写入 Ubuntu Server 22.04 或 Debian 12 的安装镜像。U 盘插入板子开机按 Del 或 F2 进入 BIOS确认启动顺序里 U 盘排在第一位。注意Apollo Lake 平台的 BIOS 默认可能是 UEFI 模式但部分老版本固件对 UEFI 启动支持不完善。如果 U 盘引导失败尝试在 BIOS 里开启 CSM兼容支持模块并选择 Legacy 启动模式。装好系统后再改回 UEFI 也不迟。系统安装过程中分区方案我建议这样处理/boot分 1GB/分 20GB剩余空间留给数据分区或者不分配。如果运行 Docker给 Docker 的数据目录单独分区会更好管理。装完系统第一件事是更新固件和内核sudo apt update sudo apt upgrade -y sudo apt install linux-generic-hwe-22.04 -yHWE 内核Hardware Enablement对较新硬件的支持更好虽然 Apollo Lake 很老但新内核修复了一些轻量虚拟化和高负载网络转发的 bug建议还是用新版本内核。3.3 双网口的性能调优从默认配置到跑满千兆系统装好后先确认两个网口是否都被正确识别lspci | grep -i ethernet ip link正常应该看到两个千兆网卡一个可能是eth0另一个是eth1或者系统使用enp1s0、enp2s0这种命名。用 ethtool 查看网卡速率和工作模式sudo ethtool eth0如果显示 Speed 为 1000Mb/s说明协商正常。如果只有 100Mb/s大概率是网线或对端设备问题可以强制指定速率再测sudo ethtool -s eth0 speed 1000 duplex full autoneg on接下来用 iperf3 测一下两个网口之间的最大吞吐。注意不要用同一台机器的两个网口互测那会走 loopback测的是 CPU 而不是网卡。正确做法是找另一台机器通过交换机分别连接这块板子的两个网口或者用一台电脑直连其中一个口板子上的另一个口接路由器通过电脑访问板子上的服务来间接测试。双网口板子最常见的应用是配置 NAT 网关。假设eth0接外网eth1接内网可以这样做# 启用 IP 转发 sudo sysctl -w net.ipv4.ip_forward1 # 配置内网口 IP sudo ip addr add 192.168.10.1/24 dev eth1 # 添加 NAT 规则 sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # 保存 iptables 规则 sudo apt install iptables-persistent -y sudo netfilter-persistent save这只是最简单的配置生产环境还涉及 DHCP 服务、防火墙规则、流量整形等但基础的转发通路要先跑通。调优方面有几个参数值得关注。Ring Buffer 决定了网卡驱动能缓存的包数量默认值有时候偏小高吞吐时会出现丢包可以调大sudo ethtool -G eth0 rx 4096 tx 4096中断合并coalescing也影响吞吐和延迟的平衡。默认配置偏向低延迟但对于持续大流量适当增大合并参数可以降低 CPU 占用sudo ethtool -C eth0 rx-usecs 100 tx-usecs 100在双网口同时高负载转发时需要确认两个网卡的中断是否合理分布在多个 CPU 核心上。APIC 自动分配不一定最优可以用htop观察各核心负载必要时手动绑定 IRQ 到指定核心# 查看 eth0 的中断号 cat /proc/interrupts | grep eth0 # 将中断绑定到 CPU1 echo 2 /proc/irq/中断号/smp_affinity这些调优不是必须的但如果你的应用对吞吐或延迟敏感这几个参数值得反复测试对比。我自己的实测结果是调优前后 UDP 小包转发性能提升了大约 30% 到 50%不过这个数值因内核版本和网卡型号而异不能照搬。3.4 远程管理与监控设备部署后的必修课嵌入式设备一旦装到现场大概率没有显示器可接所以远程管理方案要在部署前设计好。对于 Apollo Lake 板子我会做三件事第一配置静态 IP 或者 DHCP 保留地址保证设备重启后 IP 不变。第二安装 SSH 服务并配置密钥登录关闭密码登录。第三安装一个轻量的监控工具我用的是prometheus-node-exporter加简单的systemd定时任务把 CPU 温度、内存占用、丢包情况上报到中转服务器。Apollo Lake 平台有原生的温度传感器读取方法很直接sudo apt install lm-sensors -y sudo sensors你会在输出里看到类似Package id 0的温度值。如果温度持续超过 80 摄氏度就要考虑加强散热了。4. 实操排坑与经验小结这一部分是我觉得最有价值的内容。下面几个问题都是我在用这块板子时真实遇到过的有些问题在官方文档里根本查不到只能靠搜索引擎找别人的碎片经验来琢磨。4.1 网口顺序随机变化udev 规则必须写第一次重启后我发现两个网口的顺序反了。原来eth0是接外网的重启后变成了eth1网络直接断掉。这个问题在双网口板子里非常普遍原因是内核枚举 PCIe 设备的顺序不固定两个同型号网卡很容易被调换。解决方法是用 udev 规则绑定 MAC 地址到固定网口名。先把两个网口的 MAC 都记下来ip link然后在/etc/udev/rules.d/70-persistent-net.rules中写入SUBSYSTEMnet, ACTIONadd, ATTR{address}00:aa:bb:cc:dd:01, NAMEeth0 SUBSYSTEMnet, ACTIONadd, ATTR{address}00:aa:bb:cc:dd:02, NAMEeth1保存后执行sudo udevadm control --reload-rules sudo udevadm trigger注意不同系统对持久网口命名策略不一样Ubuntu 18.04 以上默认使用enpXsY风格命名主要是为了避免传统ethX的乱序问题。但由于我已经在/etc/netplan里用eth0写好了配置用 udev 规则固定名称更直观也更方便在其他板子之间复制配置。4.2 eMMC 被写爆的隐患日志重定向和只读挂载我前面提到 eMMC 寿命问题这里讲一个实际教训。最开始我把 Docker 和应用程序都装在 32GB eMMC 上跑了一个数据采集服务每秒钟往 SQLite 写入数量级不大但频率很高的记录。大约三个月后系统开始出现随机只读文件系统错误重启后 eMMC 分区无法挂载最后只能更换整板。排查过程让我意识到问题不只是 SQLite 写入本身还包括系统日志、Docker 日志、容器层文件系统的叠加写入。eMMC 本身没有 SSD 那样的磨损均衡机制完善连续小文件写入很容易放大写入放大系数。现在的做法是日志目录挂载到内存/var/log用tmpfs重启不保留日志但现场设备一般不需要历史日志保留关键日志则通过网络发送到日志服务器。Docker 默认的overlay2存储驱动会在容器写入时产生大量小文件 IO数据目录重定向到外部 SATA SSD。系统根文件系统启用noatime挂载参数减少访问时间戳写入。如果条件允许这类跑业务负载的板子直接上单独 SSD。eMMC 最合适的使用方式是只读启动盘或者仅存放不变的内核和只读系统镜像。4.3 电源波动触发的随机重启现场调试时遇到过几次随机重启时间点毫无规律。后来检查日志发现重启前没有 kernel panic也没有硬件报错最后用示波器测电源输入才确认是电源瞬时跌落。Apollo Lake 板子虽然支持宽压输入但从实验室稳定电源换到现场开关电源时仍然需要做一次完整的电压跌落测试。我的建议是确认电源输出电流至少是板子最大功耗的 1.5 倍。N4200 满载时整板功耗大概在 10W 到 12W12V 下电流约 1A但这还没算挂载的 USB 设备、4G 模块和 SSD。使用工业级 DC-DC 电源模块输出纹波要小于 50mV。如果供电线比较长在板子电源输入端并联一个大容量电解电容比如 470uF 或者 1000uF能有效抑制电压跌落。另外BIOS 里如果开启了 Power Failure Recovery 功能建议设置为 Power On这样意外断电后恢复供电时板子会自动开机对于无人值守设备很有用。4.4 常见问题速查表问题现象可能原因解决办法网口速度快不起来只有 100M网线质量差或对端设备不支持千兆换 Cat5e 以上网线强制 ethtool 指定千兆两个网口顺序乱跳PCIe 枚举顺序不定写 udev 规则绑定 MAC长时间运行后网络丢包网卡中断合并参数不合适ethtool 调整 rx-usecs 和 ring buffereMMC 文件系统变只读Flash 寿命耗尽或写入放大数据日志重定向到 SSD系统分区 noatime随机重启电源输入不稳加电容缓冲换输出能力更强的电源BIOS 设置无法保存电池没电或 CMOS 跳线问题检查 RTC 电池重新插拔跳线系统启动极慢eMMC 随机读取性能差换 SSD 启动或优化系统分区布局USB 设备不识别BIOS 里 XHCI 未开启进入 BIOS 开启 Legacy USB 和 XHCI Hand-off4.5 散热处理被动散热不是一劳永逸我一直认为嵌入式板子的散热是被低估的问题。Apollo Lake 的 TDP 虽然只有 6W 到 10W但在封闭机箱里如果周围还有电源模块、4G 模块发热局部温度很容易超过器件规格。我做过一个 25 摄氏度室温下的压力测试用stress-ng让四个核心全部满载持续 30 分钟用被动散热片不加风扇最终 CPU 核心温度稳定在 78 摄氏度左右。这个温度在规格书允许范围内但摸散热片已经有些烫手。如果现场环境温度达到 40 摄氏度以上CPU 温度可能逼近降频阈值。解决方案有几种换更大的散热片加一个 5V 静音风扇或者在机箱设计时预留通风孔。实测中加一个 4010 规格的小风扇核心温度能降 15 到 20 摄氏度非常有效。注意给嵌入式板子加风扇要注意风扇的供电和噪音。Pico-ITX 板子不一定有标准风扇插座可能需要从 USB 口取电或者用转接线从 DC 输入取电。工业现场如果对噪音不敏感直接上风扇是最省事的方案。4.6 关于 SBC 选型的一些个人看法这个圈子最近不太平静SBC 市场从缺货到降价再到一些品牌出现问题大家选型时比以往更看重供应链的可持续性。我的习惯是不把鸡蛋放在一个篮子里至少选择两个引脚兼容或功能兼容的备选方案以便在缺货或价格异常时快速切换。对于 Apollo Lake 这种生命周期已经非常成熟的平台我不担心它被淘汰反而担心厂商后续的 BIOS 更新和文档支持会逐步收缩。所以在项目设计阶段我会把 BIOS 配置、系统镜像、驱动包都归档到本地避免依赖厂商网站上随时可能下架的链接。5. 一点关于扩展的思考这块板子除了直接作为整机使用还可以作为模块嵌入到更大的系统里。Pico-ITX 的安装孔位是固定的和很多工业机箱的硬盘位兼容我在一个项目里就是把它直接装进了原有的 DIN 导轨机箱替换掉以前的 ARM 主控原来的结构完全不用改省了重新开模的费用。双网口带来的扩展性也比单网口强很多。比如一个典型的边缘计算架构中eth0接工业摄像头eth1接上层交换机通过板子上的 M.2 插槽扩展 AI 加速卡或 4G 模块整个系统的功能边界就大大扩展了。如果你打算在板子上跑轻量虚拟化比如 Proxmox VEApollo Lake 四核版本加上 8GB 内存也能同时跑两三个小型虚拟机适合做集中管理测试节点。关于系统性能我再补充一组实际数据。在 Ubuntu Server 22.04 下用 iperf3 测试双网口单向 UDP 转发数据包大小吞吐量CPU 占用64 Bytes约 350 Mbps约 70%256 Bytes约 850 Mbps约 50%1024 Bytes约 940 Mbps约 30%1518 Bytes约 980 Mbps约 25%可以明显看到大包转发性能非常接近线速而小包转发主要受限于 CPU 单核性能。这个数据在软路由和视频流接入场景里完全够用但如果要做高密度的小包转发还是需要更强的平台。最后聊一个很多人关心的功耗问题。实测 N4200 版本待机功耗在 5W 左右满载约 11W加上一块 SSD 和一个 USB 4G 模块整机功耗基本控制在 15W 以内。这对太阳能供电或者电池供电的设备来说是一个很友好的数字。如果你选 N3350 版本整机功耗还能再低 1W 到 2W。从我个人的经验来看Apollo Lake Pico-ITX 双网口板子的最大价值并不是某一方面特别突出而是在尺寸、功耗、性能和生态之间找到了一个非常实用的平衡点。它不会让你眼前一亮但能让你在交付项目时少担惊受怕。如果你是做小批量工业设备或者边缘网关的这块板子值得纳入备选清单。如果你只是拿它做开发测试那也完全够用剩下的精力可以多放在软件业务逻辑上。毕竟做嵌入式的都知道稳定、够用、买得到比任何跑分都重要。