企业官网建设流程全解析

1. 曾经那句口诀为什么在当时成立

“树莓派跑系统、Arduino跑裸机”，我入坑那会儿，几乎所有论坛都在用这句话教新人选板。它简单、顺口，也确实概括了两边最核心的差异：树莓派是一台能跑完整 Linux 的精简电脑，Arduino 是一颗几乎光着膀子跑代码的微控制器。但放在当下，这句话已经明显不够用了。树莓派自己出了 Pico 这种纯 MCU 产品线，Arduino 也推出了能跑 Linux 的高性能 Portenta 系列，两边互相“渗透”的趋势越来越明显。你如果还靠这句口诀去选板子，大概率会在新项目上踩坑。

1.1 树莓派从设计之初就是为了跑完整操作系统

先回顾一下当年的局面。早期的树莓派 1 代用的是博通 BCM2835，单核 700MHz，配 256MB 内存，放在现在看是玩具配置，但它能启动一个完整的 Linux 发行版，比如当年的 Raspbian。有了 Linux，就意味着你能在上面跑 Python、装数据库、开 Web 服务，甚至架一个轻量级网站。它的定位一开始就不是单片机开发板，而是一台“可以折腾的教育电脑”。

正因为树莓派跑着 Linux，它对硬件的控制方式就和传统单片机完全不同。你要让一个 GPIO 输出高电平，在 Arduino 上是直接调用digitalWrite(13, HIGH)，在树莓派上则要经过设备树、内核驱动、sysfs 或 libgpiod 这一层层机制。这个“隔了一层”的架构，让树莓派天然适合做偏应用层的活儿，却不太适合做那些对时序极其敏感的控制任务。

1.2 Arduino 的裸机标签来自 AVR 时代

Arduino 阵营的经典代表是 Uno，核心是 Atmel 的 ATmega328P，8 位 AVR 架构，主频只有 16MHz，Flash 只有 32KB，SRAM 2KB。这个配置不要说跑 Linux，连一个最小化的精简系统都塞不进去。所以当时的 Arduino 程序就是典型的“裸机开发”：一个setup()做初始化，一个loop()无限循环，你的代码直接跑在硬件上，没有操作系统做任务调度，也没有内存保护。

这种模式在当年对新人非常友好。你能直接看到程序对引脚的影响，中断响应在微秒级别，用定时器产生 PWM 波形也极其可靠。于是“树莓派跑系统、Arduino跑裸机”就成为最省事的分类方法：一个管复杂逻辑，一个管精确控制。然而技术演进的速度，往往比口头禅更新得快。

2. 时代变了：产品线互相补课

从 2021 年前后开始，这两条产品线就变得越来越“不守规矩”。如果只盯着“是否跑 Linux”这一个标准来选型，你会发现你已经无法解释很多新板子到底算什么。树莓派 Pico 明明叫树莓派，但它就是不跑系统；Arduino Portenta H7 明明叫 Arduino，但它官方就能启动一个裁剪版 Linux。旧口诀的第一个裂缝，就是从这些“混血”产品开始的。

2.1 树莓派阵营里混进了 MCU

2021 年树莓派官方发布了 Pico 开发板，核心是自家设计的 RP2040 芯片，双核 Cortex-M0+，主频 133MHz，264KB SRAM。它没有任何操作系统概念，你写的代码直接被 CPU 执行，典型 MCU 形态。如果你拿“树莓派跑系统”这句话去套 Pico，会发现完全说不通，它甚至连内存管理单元 MMU 都没有，不可能启动现代 Linux。

但那之后，树莓派产品线的策略其实更清晰了：SBC 系列（3B/4B/5）继续跑完整 Linux，负责复杂场景；Pico 系列负责实时控制和低功耗场景。换句话说，树莓派这个品牌已经同时覆盖了“系统级”和“裸机级”两种产品，再拿“跑系统”当作整个树莓派家族的标签，本身就是一种误读。

硬件配置的差距要足够具体，才能避免配置焦虑。我整理了一份常用板卡的对比，新手选型前可以先过一眼：

上面这个表里的功耗和性能数据，不是用来“跑分”的，而是帮你判断一个项目的耗时和供电方式。后面第三部分的 5 个问题，会说明怎么综合看这些参数。

2.2 Arduino 也走上了高性能与 Linux 路线

Arduino 这边同样不甘示弱。2020 年发布的 Portenta H7，主芯片是 STM32H7，双核一个 Cortex-M7 跑 480MHz、一个 Cortex-M4 跑 240MHz，板载 2MB Flash 和 8MB SDRAM。它的定位已经远远超出“入门玩具”，官方支持运行裁剪版 Linux，也可以跑 TensorFlow Lite 的微控制器版本。更有意思的是，Arduino 官方生态里逐步加入了 MicroPython、Mbed OS 这类带系统底层的运行时，很多高阶板卡出厂甚至自带引导程序和任务调度。

所以你要是现在还说“Arduino 只能跑裸机”，也会被现实打脸。经典 AVR 板子确实裸机，但 Arduino 作为一个平台，已经覆盖从 8 位裸机到 32 位多核、甚至 Linux 的广阔区间。旧口诀里“一个”和“一个”的二元对立，站不住了。

3. 抛开旧口诀，用 5 个问题做选型

既然旧标签失效了，选型就得回到问题的本质：你的项目到底需要什么。我这些年帮朋友评估项目、自己也做过不少设备原型，总结出 5 个最关键的判断维度。不要一上来就问“这个板子能不能跑系统”，先问自己下面这 5 个问题，答案自然会让方向清晰起来。

3.1 问题一：延时敏感还是算力敏感

这句话听起来有点抽象，其实很直接：你的任务可以容忍多少毫秒的延迟。

所谓“延时敏感”，指的是任务必须在精确的时间窗口内完成。典型例子是给舵机输出 50Hz 的 PWM 信号，脉冲宽度差 10 微秒，舵机角度就有明显变化；再比如读取 DHT11 温湿度传感器，它要求主机严格地在几微秒内拉低总线并采样；还有步进电机的脉冲序列，脉冲频率要精确且均匀，否则电机会抖动甚至丢步。

这些任务交给树莓派 SBC 会很痛苦。Linux 本身是分时操作系统，上面的进程随时可能被更高优先级的任务打断。即使你给 Python 脚本设置了高优先级，内核线程、网络中断、显卡驱动、系统日志……每一样都可能让你的 GPIO 翻转时间出现不可控的抖动。我实测过，在树莓派 4B 上连续翻转 GPIO，抖动最坏能到几百微秒甚至毫秒级。做灯效、读按键还好说，做高精度波形就非常难受了。

反过来，“算力敏感”的任务又在另一个极端。比如你需要在视频流里实时跑目标检测、处理语音识别、维护一个带数据库的小型 Web 服务，或者跑复杂的图像处理算法，这类事情就需要完整操作系统和通用计算能力。树莓派 SBC 这时候如鱼得水，而 Arduino、Pico 这类 MCU 连想都不要想。它们的 RAM 和频率就摆在那里，跑不了 Python 生态里的那些重型库。

3.2 问题二：你的功耗预算有多少

这一点在实际项目中往往比性能参数更致命。

树莓派 4B 空载大概要 2.5W 左右，满载能到 6-7W，树莓派 5 更高。这意味着它基本离不开一块像样的电源，要么用插墙适配器，要么用大容量移动电源。而一个 Arduino Uno 工作电流也就几十毫安，Pico 在低功耗模式下能跑到微安级别。如果是户外传感器节点，打算用两节 18650 撑一个月，那树莓派 SBC 直接出局，MCU 方案几乎是唯一选项。

很多人会觉得“功耗”不重要，但当你真正把一个设备从桌面挪到现场、从插座供电改成电池供电时，功耗决定了你返工多少次。我见过有人非要用树莓派做温湿度采集节点，结果三天两头跑去换电池，最后老老实实换成 Arduino 加睡眠模式，同样两节电池撑了大半年。

3.3 问题三：要接哪一类外设

外设兼容性也是个容易被忽略的硬门槛，尤其要看你需要哪些接口。

模拟量采集是最典型的例子。Arduino Uno 自带 6 路 10 位 ADC，可以直接读电位器、光敏电阻、模拟输出的温湿度传感器；Pico 也有 12 位 ADC。而树莓派 SBC 的 40 针排针上，一个模拟输入口都没有，你要接模拟传感器就得再外挂 ADS1115 这类 ADC 模块，不仅多花钱，还得在布线、供电和 I2C 地址上多操一份心。反过来，树莓派 SBC 上有 HDMI、USB、网口、甚至 PCIe（树莓派 5），这是任何 MCU 都替代不了的连接能力。

另外还有电平问题。经典 Arduino 是 5V 逻辑，很多老传感器也默认接 5V；树莓派 SBC 是 3.3V 逻辑，直接接 5V 设备轻则信号误判，重则烧掉 GPIO。选型之前把传感器的供电电压、逻辑电平和通信接口列全，再对照板卡的规格表，往往会避免一堆选错型的烦恼。

3.4 问题四：代码里有没有“重计算”

这个“重计算”可以理解成需要目标检测、图像分类、自然语言处理、复杂的网络协议栈、大数据文件读写这些活儿。这些任务基本都依赖 Python、C++、Java 这类高级语言生态，还要有足够的内存和文件系统来跑库、存模型、写日志。树莓派 SBC 跑这类任务非常合适，也正是它能装 Docker、能挂 SSD、能跑云原生工具链的原因。

但如果你要做的事情只是“每 100 毫秒读一次传感器，超过阈值就翻转一个引脚”，这种代码就算不上重计算。它需要的是稳定、低开销、低延迟。用一棵树莓派 4B 来干这个，相当于开着 2 吨重的皮卡去楼下买瓶酱油，不仅费电，还更复杂。启动要几十秒，系统更新要定期处理，SD 卡还有损坏风险，全是额外负担。

一个项目里其实可能同时包含重计算和轻控制。最常见的解决办法不是选一个板子硬扛，而是让两边的板子各干各的，这就是第四部分会提到的组合方案。

3.5 问题五：你的时间成本更花在哪边

最后一个问题，很多人都不会提前想：你更熟悉哪套开发环境，以及你的团队里其他人熟悉哪套。

Arduino 生态几千个现成传感器库是它最值钱的东西。你想用某个传感器，在 Arduino IDE 里的库管理器搜一下装进去，示例代码拿来改两行基本就能跑。树莓派 SBC 生态当然也成熟，但 GPIO 控制一直有“版本碎片化”的问题。早年教程教你写/sys/class/gpio/export，新版内核要求用 libgpiod，gpiozero 和 pigpio 的 API 又各有一套，权限规则、设备树覆盖项也经常踩坑。

如果项目工期紧，团队里的人只会 Arduino 那套流程，那就不要太勉强地把整个项目塞进树莓派；如果项目本身要对接 Web、数据库，而团队里又没人写过 AVR 寄存器，那就老老实实上树莓派或类似 Linux SBC。开发效率是真实的工程量，不是面子问题。

4. 三个真实场景，按这个逻辑选型

理论说多了容易飘，我挑三个我自己遇到过、也能代表大量同类需求的场景，把上面的 5 个问题实际走一遍。这三个场景覆盖了“电池供电”“视觉 AI”“多节点联网”三种典型模式，你大概率能从中找到自己的影子。

4.1 场景一：电池供电的室内温湿度记录仪

需求很简单：一个小的设备，每隔一分钟采集一次温度和湿度，存到 SD 卡或者通过外部接口取走，要求用两节 AA 电池能连续工作至少三个月。选树莓派 SBC 就是灾难——功耗太大，没有板载 ADC 也得外扩，而且给它配一个“能跑三个月”的电源方案几乎等于重新设计一个电源板。这个场景最合理的方案是 Arduino 兼容的 Pro Mini 或者树莓派 Pico，核心是利用睡眠模式，采集时醒过来干活，采集完继续睡。

我用过基于 ATmega328P 的 Pro Mini，开启睡眠模式后整机电流能压到 0.1mA 以下。间隔一分钟醒来，读一次传感器、打一个时间戳、写一次 SD，然后继续睡。两节新的 AA 电池（大约 2000mAh）算下来能撑几个月。如果你一定要用树莓派品牌，Pico 也能干这个，用 MicroPython 能快速调通，改用 C SDK 后可以手动控制 sleep 模式。核心是看低功耗能力和 ADC 接口，不是看品牌。

4.2 场景二：机械臂视觉识别抓取

这是一个典型的混合需求项目。一边是摄像头采集画面、跑目标检测模型、判断物体位置坐标，计算量很大；一边是机械臂五个舵机的精确运动控制，要求 PWM 信号稳定、响应及时。如果只用树莓派 SBC，Python 里跑模型没问题，但直接用它输出五路高精度 PWM 驱动舵机，就非常不稳定，模型推理一卡，PWM 跟着抖，机械臂表现很拉胯。如果只用 Arduino，舵机控制轻松搞定，但目标检测模型跑不动。

常规做法是“树莓派做脑、Arduino 做手”：树莓派 4B 运行一个轻量化目标检测模型，用 Python 算出物体在画面里的像素坐标，换算成机械臂的关节角度增量，然后通过串口把角度指令发给 Arduino Mega 或 Uno；Arduino 用定时器产生稳定的 PWM 信号驱动舵机，同时接收串口指令、控制舵机平滑运动。通信协议可以很简单，比如 115200 波特率的串口，一帧数据像#150,80,120\n这样，树莓派发角度，Arduino 解析后更新 PWM 占空比。

这个架构里你会发现，真正让项目稳定工作的是“脑”和“手”的分工，而不是哪块板子更牛。树莓派买的算力，Arduino 买的是实时性，各取所长。

4.3 场景三：多传感器果园环境监测网关

再来看一个复杂一点的场景：果园里分散布置十来个传感器节点，每个节点采集土壤湿度、空气温湿度、光照强度，通过无线方式汇聚到一个中心，中心要做数据存储、图表展示，并保留一个可扩展的接口。

这个项目如果每个节点都用树莓派 SBC，成本会直接失控，功耗和布线也麻烦。合理的架构是：每个传感节点用 ESP32 这类自带 Wi-Fi 或 LoRa 的 MCU，采集数据后通过 MQTT 发给中心的树莓派 4B；树莓派上运行一个简单的 Python 服务，订阅 MQTT 消息，把数据写入本地 SQLite 或带 Web 界面的仪表盘。树莓派这里承担的是“网关 + 数据服务”职责，而节点端负责低功耗采集和无线上报。

这个案例特别能说明：所谓“系统”和“裸机”并不冲突，它们出现在同一个系统的不同层级。节点的实时采集和低功耗要求偏 MCU，网关的数据处理和可视化需求偏 SBC。选型不是二选一，而是搭出一个能跑通的分层架构。

5. 别忘了中间选项：ESP32 和它的 RTOS

很多人选型时脑子里只有“树莓派”和“Arduino”两个选项，其实在两者中间还有一大片生态，最有代表性的就是 ESP32。它现在几乎是物联网开发的标准选择，两颗内核 240MHz，自带 Wi-Fi 和蓝牙，价格在同类产品里非常能打，而且还默认跑着一个实时操作系统 FreeRTOS。

5.1 “系统”并不只有 Linux 一种

旧口诀里“跑系统”三个字，默认系统就是 Linux，其实这是狭义理解。现代 MCU 上流行的实时操作系统 RTOS，比如 FreeRTOS、Zephyr、Mbed OS，也是一种“系统”。RTOS 的调度不像 Linux 那样分成用户态和内核态，它更像是一个“微型的任务管家”，提供线程、信号量、消息队列这些基础能力，但中断延迟和任务切换时间能做到微秒级别。

ESP32 出厂就用 FreeRTOS，你在 Arduino IDE 里写 ESP32 程序，表面上还是loop()，底层的 Arduino 核心和 Wi-Fi 协议栈其实都跑在 FreeRTOS 线程之上。这意味着 ESP32 已经是“跑系统”的 MCU 了，它不再是你想象中那种一个while(1)转到底的裸机设备。你用旧口号来归类它，只会觉得它左右都像又左右都不是。

5.2 中间地带的选型建议

如果你的项目需要无线联网，ESP32 类芯片往往比树莓派 SBC 更省钱、更省电，比 Arduino Uno 加外接 Wi-Fi 模块更省事。一个 ESP32 模块加上一些外围元件，成本也就几块钱到十几块钱，接电池、接传感器、发 MQTT 都是成熟路径。而树莓派 SBC 做同样的单点采集节点，是拿大炮打蚊子。

另一个方向是 STM32 家族。STM32 的性能跨度极大，低端可以当高级 Arduino，高端比如 H7 系列配合 Mbed OS 或 Zephyr，能跑复杂一点的控制和边缘 AI。如果你觉得“Arduino 太玩具、Linux SBC 太重”，那 STM32 加 RTOS 就是最均衡的中间路线。当然，它的开发门槛比 Arduino 高，不是特别推荐给纯新手第一天就上手。

这张表的核心意思是：很多“中间地带的坑”其实是不了解这块生态导致的。选型不要非黑即白，ESP32、STM32 这些名字应该和 Arduino、树莓派并列放在你的候选清单里。

6. 常见误区与我的踩坑实录

最后一个部分，我想聊几个我在实际项目里见过、也踩过的坑。这些坑基本都源于“用标签替代码”的思维，你在网上搜教程时会发现大量案例，非常典型。

6.1 误区一：树莓派 GPIO 适合做高精度 PWM

先说这个最普遍的坑。树莓派 SBC 的 GPIO 硬件上确实有 PWM 外设，但如果你在用户态用 Python 的第三方库去生成 PWM，比如为了驱动一个舵机或者控制 LED 呼吸灯，本质上很多时候是软件在模拟电平翻转。Linux 调度一忙起来，脉冲宽度就会有肉眼可见的抖动。

我做过一个步进电机控制器原型，最初用树莓派 4B 的 Python 脚本直接输出脉冲，结果电机转起来嗡嗡响，用示波器一看，脉冲间隔参差不齐，最差的时候差了上百微秒。后来改成树莓派 Pico 用 PIO 或者硬件定时器来产生脉冲序列，波形干净利落，问题直接消失。所以凡是对时序要求高的输出，别指望用 Python 在 Linux 上现写，老老实实把实时任务放到 MCU 侧。

6.2 误区二：Arduino 性能差，什么都干不了

这个误区和上一个正好相反。很多人被“Arduino 是入门玩具”的标签影响，遇到稍微复杂一点的需求就把 Arduino 换掉。实际上，搭配 FreeRTOS 或相关库的 Arduino 兼容板、以及 STM32 核心的 Arduino 板，已经能完成不少“看起来很难”的任务，比如多任务调度、电机闭环控制、简单的信号处理。

更典型的是 TinyML 思路：现代微控制器已经能运行量化后的轻量神经网络。比如某些 MCU 板载资源足以做关键词唤醒或者简单姿态识别，不需要 Linux 底座也能完成边缘 AI 需求。判断一个任务是否超出 MCU 能力，最好看具体的内存占用和算力需求，而不是凭印象拍脑袋。

6.3 我最推荐的组合方案

如果让我给一个“万能起步方案”，我会推荐“树莓派 SBC + 一个 MCU 板”的组合。无论你选树莓派 4B 还是 5，都建议配一块 Pico 或 Arduino Nano。SBC 负责服务端业务，MCU 负责传感器采集和电机控制。两者通过 UART 或者 USB 虚拟串口通信，通信协议自己定义，比如固定帧头、命令字、校验位。树莓派侧用 Python 的 pyserial 收数据，MCU 侧解析后执行控制。这样既能享受 Linux 生态的丰富工具，又能保住控制层的实时性。

通信方式的选择也值得多说一句。I2C 适合板间短距离多设备接线，但时序要求严格；SPI 传输快，但线多；UART 最简单，通信速度适中，抗干扰能力其实比很多人想象的好。如果是两个板子放在同一个项目外壳里，我个人最常用 UART 或 USB 串口，因为调试方便，逻辑分析仪也能直接抓包看帧内容。

最后再分享一点我的实际体会

这些年折腾下来，我最大的感受是：选板子最忌讳的就是“拿着标签往项目上套”。旧口诀“一个跑系统、一个跑裸机”在入门阶段帮你建立初步概念没问题，但真正做项目时，你必须回到“延时、功耗、外设、算力、开发效率”这些原始需求上去。

如果一定要用一句话替代旧口诀，我可能会说：需要按时发生的控制交给 MCU，需要事后处理的逻辑交给 SBC。这不是一条铁律，但比“跑系统和跑裸机”可靠得多。你一旦掌握这套思路，会发现绝大多数项目的答案根本不复杂，要么属于这一边，要么属于那一边，要么像大多数有实际落地价值的东西一样，两边合作。