上个月,我把一块树莓派5从开发桌搬进了车间,塞进设备控制柜里,目标很明确:给一台用了快十年的老设备做数据采集和状态看板。选树莓派5而不是直接上PLC,原因很现实——它有四核A76、四十针GPIO、能跑Python和Node-RED,改逻辑不用反复刷固件,板子几百块钱,试错成本比工业网关低太多。但真把它当车间设备用起来,我才发现“能开机”和“能长期稳定跑”之间,隔着一整个职业生涯。
从烧录系统到最终稳定运行,我前前后后卡在六件事上:供电不稳导致反复重启、高温降频、无头模式下连不上网、GPIO引脚电平不匹配、软件环境里到处是旧经验失效的坑,以及无人值守时的自恢复问题。这篇记录就是这六件事的完整复盘,适合那些不打算把树莓派5当桌面玩具,而是想让它七乘二十四小时待在车间、控制柜、机房里干活的人。如果你正准备这么干,下面的内容值得提前看一遍。
1. 第一道坎:用手机充电头给树莓派5供电,车间电压一抖它就重启
1.1 故障现场:跑着跑着SSH就断了
第一天通电,我把树莓派5接在一个标称5V/3A的手机充电头上,塞进控制柜。因为没有显示器,我用SSH连进去跑系统更新,进度条一卡一卡的,没到一半连接就断了。再连上去,uptime显示系统刚刚重启过,时间只有两分钟。一开始我以为是系统镜像有问题,重烧了一次卡,问题依旧。
后来我在dmesg里看到大量和供电相关的提示,再用vcgencmd get_throttled一查,返回值不是0,而是欠压标志位。这台树莓派5从开机起就一直处于“电压不足”的状态,只是无头模式下没有那个经典的黄色闪电图标,我根本看不见。
1.2 为什么树莓派5对电源这么挑剔
树莓派5的官方电源要求是5V/5A,峰值电流比4B高了不少。普通手机充电头虽然写着5V/3A或5V/2A,但那是在理想条件下的额定值,USB线材本身还有压降,线稍微长一点、细一点,到树莓派输入端可能只剩4.6V。树莓派5内部的电源管理芯片检测到电压低于阈值,就会先把外设电流压住,再严重就直接保护性重启。
车间环境比桌面恶劣得多。我这台设备所在的工位,同一条电源线上还接着电钻、伺服电机和变频器。这些设备启动瞬间,母线电压会抖得很厉害,220V都能晃下去二三十伏,手机充电头这种轻量开关电源根本扛不住,输出跟着一起跳水。在办公室里永远不会遇到的问题,在车间里成了第一道坎。
1.3 排查过程与最终供电方案
排查思路很简单,就是一步步缩小范围:
- 先换一根质量好、长度短的USB-C线,确认不是线材压降。
- 把树莓派5单独接一个插座,避开大功率设备,观察是否还重启。
- 用万用表量树莓派5输入端电压,空载和满载时分别看跌落多少。
- 最后直接换上足够余量的工业电源。
我当时在三个方案里选了半天,各有适用场景:
| 方案 | 优点 | 坑 |
|---|---|---|
| 官方27W USB-C电源 | 协议匹配,插上就能用 | 控制柜里不好固定,线太软,不太适应车间环境 |
| 5V/5A工业开关电源 | DIN导轨安装,接线牢固,抗干扰强 | 需要配一根像样的USB-C线,注意线材压降 |
| 24V转5V隔离DC-DC模块 | 直接借用控制柜里的24V母线,电压域干净 | 电流余量要留足,建议选10W以上 |
最终我选的是第三种:控制柜里本来就有24V开关电源给传感器供电,我加了一个24V转5V的隔离DC-DC模块,输出直接接到树莓派5的USB-C口。这样做的好处是树莓派5和车间的24V设备共用一个电压参考,少了一层浮地干扰。供电问题解决后,vcgencmd get_throttled的值再也没变过。
提示:无头模式下一定要学会用
vcgencmd get_throttled判断供电和温度问题。返回值第0位是欠压,第1位是温度受限,定期查一次,比看什么指示灯都管用。
2. 第二道坎:夏天车间里散热和防尘打架,不加风扇只能看着CPU降频
2.1 裸板+被动散热片:半小时就撞温度墙
供电稳定之后系统能跑起来了,但第二个问题很快暴露。车间里夏天三十五六度是常态,控制柜里更闷,我最初用的是官方散热器加一个被动铝合金外壳,觉得自己不做重负载应该够。结果跑了一个多小时数据采集,vcgencmd measure_temp显示已经到82°C,vcgencmd get_throttled里温度受限标志位也亮了,CPU频率从2.4GHz一路掉到1.2GHz左右。
树莓派5的四核A76性能确实强,但发热也实打实比4B高,满载功耗能到10W以上。被动散热片在通风良好的桌面上没问题,放进半封闭的控制柜,基本就是闷罐。数据采集程序虽然不挑CPU,但一旦后台再跑Node-RED、SQLite和一个网页看板,降频之后整个系统的响应速度肉眼可见地变慢。
2.2 防尘和散热的平衡:不是加个风扇那么简单
车间的粉尘金属屑很多,直接加一个暴力风扇,等于把灰尘往散热片上吹,效果反而是长期噩梦。我看到不止一个人这样干,散热倒是好了,两三个月后风扇和散热片缝隙里全是灰,风量下降,温度比不加风扇还高。
我的做法是正压风道设计:外壳进风口加一层过滤棉,风扇放在进风口附近往里吹,让机箱内部气压略高于外部,灰尘不容易从缝隙钻进去。出风口朝下,避开正上方的金属屑。树莓派5的40针排针旁边有5V引脚,可以直接给风扇供电,再用一个PWM引脚控制转速,温度低时低速运转,温度高时全速。
2.3 温度监控与降频策略
散热方案定下来之后,我还给系统加了一个简单的监控服务:每分钟读一次vcgencmd measure_temp,写入日志文件,温度超过75°C就往看板里写一条告警记录。没有配邮件通知,因为车间里那台树莓派5本身就不依赖互联网。
另外在/boot/firmware/config.txt里可以设置软温度限制,例如temp_soft_limit=75,让系统在75°C就开始提前降频,而不是等到80°C附近才被固件强制压。提前一点点降频换来的是不会突然卡顿,对数据采集这种场景更划算。这套组合下来,后续两个月没有一次因为温度触发重启或丢数据。
注意:买铝合金散热壳的时候,确认导热硅脂垫上面的保护膜撕掉了。我见过有人装了被动壳之后温度直接奔90°C,拆开一看膜还贴在散热垫上,白折腾一场。
3. 第三道坎:控制柜里没有屏幕,树莓派5装完系统连不上网
3.1 系统版本变了,老经验不能直接复用
我犯的第一个新手错误,是用老思路烧录系统:下载镜像、写进SD卡、插电,以为和树莓派4时代一样,默认账号pi/raspberry就能登录。结果新版Raspberry Pi OS(Bookworm起)默认关闭SSH,默认用户名也不再是pi,官方推荐用烧录工具预设置。我塞了几次卡进去都连不上,最后只能把卡拔出来,拿到办公室电脑上重新配置。
正确的做法是直接用Raspberry Pi Imager烧录镜像时,点击右下角的齿轮图标,预先设置主机名、用户名、SSH公钥和无线网络。无头模式最建议用密钥登录,别设密码,树莓派一旦忘记密码,没有显示器和键盘的话只能重刷系统。
3.2 车间的无线环境:铁皮柜是5GHz的杀手
配置好SSH之后,我又踩了第二个坑:树莓派5塞进铁皮控制柜,Wi-Fi信号直接被屏蔽了一半以上。树莓派5的无线模块虽然支持5GHz,但5GHz穿金属柜的能力还不如2.4GHz,在控制柜里基本等于残废。我一度以为是天线问题,后来用网线一拉,连接瞬间就稳了。
车间里做长期部署,别指望无线。就算控制柜旁边就有AP,门一关、设备一运转,信道干扰和金属屏蔽都会让SSH变得极不稳定。最终我拉了根超五类网线,从控制柜底部的穿线孔进柜,接到树莓派5的千兆网口上。树莓派5网口是千兆的,这点比很多工业网关都厚道。
3.3 静态IP与远程访问
连上网之后,我又发现DHCP分配的地址在车间网络里不固定,很可能一次重启之后IP就变了,远程管理又要重新去柜子里翻地址。解决办法是设静态IP,Bookworm系统的网络由NetworkManager接管,老教程里改/etc/network/interfaces或/etc/dhcpcd.conf的方式已经不管用了,要用nmcli:
# 先看连接名,一般是 "Wired connection 1" nmcli con show sudo nmcli con mod "Wired connection 1" ipv4.addresses 192.168.10.99/24 sudo nmcli con mod "Wired connection 1" ipv4.gateway 192.168.10.1 sudo nmcli con mod "Wired connection 1" ipv4.dns "192.168.10.1" sudo nmcli con mod "Wired connection 1" ipv4.method manual sudo nmcli con up "Wired connection 1"远程管理这一层,我在办公室路由器上给树莓派5的SSH做了一个端口映射,映射到外网一个不常用的端口,同时禁用密码登录,只保留公钥认证。树莓派5放在车间内网里,平时我都是在办公室直接SSH进去改配置、看日志、拉数据。如果对安全要求更高,可以考虑内网穿透类的组网方案,原理上是让设备主动向外发起连接,不需要在车间路由器上开端口,适合跨区域部署。
4. 第四道坎:对照引脚图接线本身没错,但24V信号直接怼坏了GPIO
4.1 引脚图:物理引脚和BCM编号别搞混
“树莓派5引脚图”这组词搜索量一直很高,说明大家都在这上面出过问题。树莓派5的40针排针,引脚顺序和4B是一样的,网上很多树莓派4的引脚图可以直接参考。但要注意,引脚图里有两种编号:物理引脚号(排针上的1到40)和BCM编号(系统里用的GPIO号)。用Python的GPIO.setup(17, ...)操作的是BCM17,也就是物理第11脚,不是第17脚。这个区别非常容易让人一脸懵。
树莓派5的系统层用的是RP1芯片来管理IO,老教程里基于wiringPi的那套pin编号已经过时了,查状态建议用pinctrl或raspi-gpio,而不是gpio readall。比如:
pinctrl get 17常见的引脚对照,我自己做了个简化表放在控制柜里:
| 功能 | 物理引脚 | BCM编号 |
|---|---|---|
| 3V3 | 1 | - |
| 5V | 2、4 | - |
| GND | 6、9、14、20、25 | - |
| I2C1 SDA / SCL | 3 / 5 | 2 / 3 |
| UART TX / RX | 8 / 10 | 14 / 15 |
| SPI0 CE0 / CE1 | 24 / 26 | 8 / 7 |
4.2 翻车现场:24V接近开关直连GPIO
当时我从车间设备上引了一根接近开关的信号线,想着“不就是高低电平吗,3.3V和24V反正都是高电平”,直接就把24V信号接到了树莓派5的GPIO上。结果通电没多久,树莓派的网口灯灭了,供电电流异常,我赶紧断电。之后再开机,那一排GPIO引脚里有两路怎么读都是1,完全不受控制——RP1的IO引脚被24V硬怼伤了。这还算运气好,只是坏了那一路,没把整块板子带走。
这件事的核心错误在于:树莓派5的GPIO是3.3V电平的TTL,不是24V电平,车间的传感器、继电器、PLC端口绝大多数是24V电平或干接点,直接接上去根本不是“电平识别”问题,而是电气击穿问题。
4.3 隔离方案:光耦是车间的必修课
正确接入方式是在24V信号和树莓派5之间加一层隔离,最常用的是光耦。24V信号串一个限流电阻进光耦的发光二极管侧,光耦输出侧的集电极接树莓派5的GPIO,发射极接GND。这样两边电气上是隔开的,24V再怎么波动都不会直接怼到RP1的引脚上。
对车间里的NPN/PNP传感器,处理逻辑不太一样。NPN传感器输出是开集电极,拉低信号;PNP传感器输出是主动输出高电平。无论哪种,我的建议都是中间加光耦或继电器隔离,不要图省事直接接。如果信号频率不高,中间继电器也行,就是体积大、有机械寿命;光耦体积小、响应快,数据采集场景基本都够用。
还有一个容易忽略的点:GPIO引脚复用冲突。树莓派5系统默认把I2C1占用了,物理第3脚和第5脚的I2C功能是默认开的;串口引脚默认被调试控制台占用,如果你把扫码枪或串口传感器接在物理第8、10脚上,会收到一堆开机日志,这是因为UART0被console吃掉了,需要在/boot/firmware/config.txt里把console关掉或者把串口改到其他引脚。
5. 第五道坎:软件环境比硬件更磨人:换源、安装搜狗输入法、老教程失效
5.1 安装搜狗输入法,折腾了一个晚上
网上搜“树莓派5安装搜狗输入法”的热度高,说明这不只是我的问题。我在调试阶段用屏幕加键盘操作树莓派5桌面,发现没有中文输入法,于是去搜狗官网下载了Linux版输入法的deb包,想着dpkg装一下就能用。结果依赖检查报错:缺少fcitx框架,强行安装之后,系统自带的ibus和fcitx两个输入法框架打架,切换输入法时候选词完全不显示,一个字母一个字母往外蹦。
这还没完,新版Raspberry Pi OS桌面默认走Wayland,搜狗输入法还是基于X11时代的fcitx 4那套架构,在Wayland会话下兼容性很差,要么面板不出现,要么输不进去。我折腾到半夜,最后把搜狗卸载,装了fcitx5,配好自带拼音,三分钟搞定。
我的建议很直接:如果你想在树莓派5桌面上用中文输入法,别折腾搜狗,直接装fcitx5和拼音输入法,省下来的时间够跑好几个业务了。而且对车间部署来说,树莓派5最终是无头的,桌面输入法只是调试期的一段插曲,不值得在上面耗太多精力。
5.2 换源、Python虚拟环境和串口权限
软件环境的另一个坑是老教程失效。树莓派5是arm64架构,系统也是Debian Bookworm底层的Raspberry Pi OS,很多写给树莓派3时代、armhf架构的教程已经不能再照搬了。
默认软件源在海外,车间这边带宽又不够,apt下载速度感人。我把源换成了清华镜像,注意新版系统的源文件不在/etc/apt/sources.list老位置,而是/etc/apt/sources.list.d/debian.sources这种deb822格式的文件,替换里面的URL就可以了:
# /etc/apt/sources.list.d/debian.sources # 将 deb.debian.org 换成 mirrors.tuna.tsinghua.edu.cn sudo apt update其余的软件环境建议很常规但重要:Python包不要直接往系统里装,用python3 -m venv建虚拟环境;串口通信要先把当前用户加进dialout组,否则读不到/dev/ttyUSB0:
sudo usermod -aG dialout $USER5.3 无外网环境下的时间同步问题
这个坑藏得比较深。车间控制柜里没有外网,树莓派5不能NTP校时,每次断电重启后,如果没有RTC模块,时间会回到系统默认值,导致SSH证书验证失败、日志时间错乱、MQTT消息时间戳全乱。我第一次遇到时以为是网络问题,排查了半天,最后发现是时间差了整整八年。
解决办法是在树莓派5的I2C接口上接一个DS3231硬件时钟模块,几块钱的东西,断电后时间照样走。接好之后把RTC驱动加载并同步一次,之后每次开机系统自己读硬件时钟,不用管它。如果项目里对时间精度要求不高,也可以用开机时从PLC或上位机同步一次时间,总之千万别裸奔。
6. 第六道坎:无人值守才是终极大考:TF卡掉盘、掉电自恢复与断网重连
6.1 TF卡是最大的不稳定源,上NVMe
前面五道坎基本是“装起来能跑”,车间里真正决定能不能长期用的,是无人值守的稳定性。第一个暴露的问题就是TF卡。树莓派5跑采集程序,SQLite写库、日志轮转、系统缓存都在往TF卡上写,几周之后卡里的数据出现CRC错误,文件系统只读,程序直接崩。
树莓派5有PCIe接口,可以接M.2 HAT转接板,插一块NVMe SSD,性能和稳定性完全不是一个级别。系统装到NVMe之后,我实测数据传输快了几倍,也更扛得住频繁写日志和掉电。如果你不想一开始就上NVMe,至少把日志重定向到内存文件系统,比如用log2ram把/var/log放到内存里定时同步,减少TF卡的写入次数。SQLite的写库也建议开WAL模式,掉电后损坏概率比默认模式低很多。
6.2 systemd服务自恢复和看门狗
数据采集程序不能只靠手动拉起,要用systemd托管。我写了一个最简单的service:
[Unit] Description=collector After=network-online.target Wants=network-online.target [Service] ExecStart=/home/u0_a/.venv/bin/python /opt/collector/main.py Restart=always RestartSec=10 User=u0_a [Install] WantedBy=multi-user.targetRestart=always意味着进程无论什么原因退出,10秒后都会自动拉起来。这是最基础的一层保障。再往上,如果整个系统卡死,进程级自恢复就无效了,需要看门狗。树莓派5内核自带bcm2835_wdt模块,启用之后用/dev/watchdog喂狗,系统一旦长时间不响应,硬件就会强制重启。做法是装watchdog包,配置/etc/watchdog.conf指向/dev/watchdog,然后启用服务。
6.3 断网自动重连和PLC/传感器通信
车间网络也不是完全可靠,偶尔交换机会重启,或者有人拔错网线。我在系统里加了一个定时探测脚本,每分钟ping一次网关,失败就重启网卡,连续失败就重启NetworkManager服务,保证断网后能自动恢复。数据链路这一侧,树莓派5通过USB转485模块和老设备的Modbus RTU通信,先确认系统识别到/dev/ttyUSB0,再把当前用户加入dialout组。
Modbus RTU通信第一个容易踩的坑是A/B线接反,另一端没反应时可以先把两根线对调试一下,用串口调试工具先收发几个字节,确认通了再跑程序。第二坑是RS485半双工方向控制,如果USB转485模块是自动方向切换的,不用操心;如果是手动控制的,需要用树莓派5的一个GPIO控制DE/RE引脚,否则只能发出去收不到。
数据存储和看板方面,树莓派5的性能足够同时跑SQLite、Node-RED和Web看板。我在断网上传的场景里,把采集数据先写进SQLite本地队列,网络恢复后再批量上传,避免MQTT断线重连风暴。这套东西稳定跑下来,CPU占用基本在30%上下,树莓派5完全吃得消。
这套盒子最终在车间里稳定跑了两个多月,六件事现在回头看,其实都指向同一个问题:你是把它当开发板折腾,还是想把它当生产工具来用。供电、散热、隔离、网络、软件环境、自愈能力,这六件事的性质完全不同,但共同点是,它们都在设备“上电之后、真正跑业务之前”等着你。
以我个人的体会,做这种项目最贵的不是树莓派5本身,而是现场临时抓瞎的时间。下次再做同类部署,我会在选型阶段就把工业电源、光耦隔离模块、防尘散热外壳、NVMe转接板全部列进采购清单,这些东西每一个都比树莓派5便宜,但漏掉任何一个,到了现场都只能用几十倍的时间成本去补。希望这篇记录能让你少走同样的弯路。