一套代码让Arduino与树莓派隔空对话：RF24跨平台无线通信实战

一套代码让Arduino与树莓派隔空对话：RF24跨平台无线通信实战

【免费下载链接】RF24OSI Layer 2 driver for nRF24L01 on Arduino & Raspberry Pi/Linux Devices项目地址: https://gitcode.com/gh_mirrors/rf/RF24

RF24 是一个专为 nRF24L01 无线模块打造的跨平台通信驱动库，从 Arduino、树莓派到各类 Linux 设备都能运行同一份驱动代码。这篇文章想帮你解决一个很现实的烦恼：家里的传感器挂在 Arduino 上，数据却要送到树莓派那边做展示，两边到底怎么才能"说上话"？我会从一次真实移植经历讲起，带你走完环境搭建、代码适配和避坑的全过程，让你也能在两小时内让两块板子隔着几米互相传数据。

为什么同一个无线模块，两边要写两遍代码

先讲一个我自己的小故事。去年想给阳台的花盆做一个湿度监控：Arduino 负责读传感器，树莓派负责存数据、画曲线，中间用一对 nRF24L01 无线模块连接。模块很便宜，功耗又低，本以为是个周末就能搞定的小活，结果一头扎进去才发现——真正难的从来不是无线模块本身，而是两边的代码"方言"完全不同。

一个常见的场景：传感器在 Arduino，服务器在树莓派

如果你也有过类似想法，大概能体会这种别扭：Arduino 上的程序结构是固定的setup()加loop()，管脚直接写数字编号，SPI 用 Arduino 自带的那套接口；而到了 Linux 那边，SPI 变成了/dev/spidev这样的设备文件，GPIO 的编号规则换了说法，编译还要靠 CMake 或者 Makefile。于是同一套业务逻辑，你被迫维护两份代码，改个发送频率都要同步改两处。

问题的本质：GPIO、SPI、时钟，平台各自为政

拆开看就会发现，无线收发本身只依赖三样底层能力：管脚控制（GPIO）、数据通道（SPI）和计时（millis()、delay()这类）。麻烦的是每个平台对这三样东西的称呼和用法都不一样，驱动代码一写到硬件层就开始"分叉"。而这正是 RF24 库想消灭的问题。

RF24 的思路：把接口统一，把实现藏起来

RF24 的应对方式很像家里那种万能插座：插头是统一的，换不同的转接器就能接到不同的墙上。核心驱动只认一组标准接口——spi.h提供收发字节的transfer()，gpio.h负责管脚读写，compatibility.h补齐millis()和delay()——至于底层是 AVR 还是 Linux，全部交给平台对应的适配文件去操心。你写的业务代码，永远只面对同一张"脸"。

先看成果，再拆原理：一份代码如何跑通两套硬件

在动手之前，我想先用"逆向拆解"的方式让你看见终点：下面的代码片段基本就是你需要在两端写出的全部"核心逻辑"，而且两端可以原样共用。

RF24 radio(CE_PIN, CSN_PIN); void initRadio() { if (!radio.begin()) { // 模块没接好或 SPI 不通，会在这里停下 return; } radio.setChannel(76); // 两端必须用同一个频道 radio.setPALevel(RF24_PA_HIGH); // 发射功率，室内可调低 radio.openReadingPipe(1, 0xABCDABCDABLL); radio.startListening(); }

发送一个float数据也就是几行的事：radio.stopListening()切到发送模式，radio.write()把数据打进空中的帧里，接收端用radio.available()轮询有没有新消息，有就radio.read()取出来。这套 API 从 Arduino 到树莓派，写法完全一致。

utility/ 目录里的秘密：每个平台一张"适配卡"

那差异到底藏在哪里？答案是utility/目录。翻开源码你会看到utility/RPi/、utility/SPIDEV/、utility/pigpio/等一串子目录，里面各自装着对应平台的spi.h、gpio.h、compatibility.h。编译时通过一个宏告诉库"我现在跑在什么平台上"，它就会自动去加载对应的适配文件。这也是为什么官方文档docs/portability.md会专门说明：想移植到新板子，只需要仿照这些模板补一套接口文件即可。

为什么 Linux 端悄悄统一到了 SPIDEV

早期 Linux 上的驱动选择还挺多：树莓派专用的 BCM2835、pigpio、wiringPi、MRAA 等等，各有各的依赖。不过现在官方已经把 SPIDEV 定为了默认驱动——它直接走 Linux 内核通用的 SPI 用户态接口，兼容性最好，也不依赖某个具体厂家的库。所以你的树莓派只要开启了 SPI 内核模块，就几乎不用再为驱动选择发愁。

动手时间：让两块板子真正"对上话"

理论聊够了，下面是真正出成果的部分。整个过程大概分三步：装库、调参数、跑示例。

先给树莓派装好环境，大约十分钟

在 Linux 端，推荐用 CMake 方式从源码安装，命令就这么几条：

git clone https://gitcode.com/gh_mirrors/rf/RF24 cd RF24 mkdir build && cd build cmake .. -D RF24_DRIVER=SPIDEV make sudo make install

装完后别急着写代码，先确认树莓派上 SPI 接口已经启用（可以在系统配置里打开），并且当前用户对/dev/spidev0.0有访问权限，这一步是新手最容易卡住的地方。

移植时最容易踩的三个坑

第一，引脚编号的含义变了。Arduino 里RF24 radio(9, 10)的两个数字分别是 CE 和 CSN 的管脚号；而在 SPIDEV 模式下，第二个参数表示 SPI 总线上的片选编号（通常是 0 或 1），别拿 Arduino 的习惯直接往上套。第二，频道、地址、速率必须两端一致，两边各写各的配置却连不上，多半是这里没对齐。第三，室内测试建议把发射功率调低，两块板子离得太近时满功率反而可能让接收端"懵掉"，像示例里用RF24_PA_LOW就很稳。

最小可运行示例：发一个浮点数试试

项目自带的examples/GettingStarted/GettingStarted.ino就是一个很好的起点：它让两块板子各自打印一段提示，按一个键切换发送/接收角色，把一个不断自增的float在两端之间传来传去。逻辑就 60 多行，却能完整覆盖"初始化、发送、接收、切角色"四件事。先把它跑通，你对这套 API 的手感就基本建立起来了。

让跨平台无线通信更稳更远：几个值得记住的细节

当两块板子终于互相收到数据，那一刻的成就感是真实的。但如果你打算把它从"实验台"搬到真实环境，还有几件小事值得留意。

稳定通信的小细节：电源、屏蔽与天线

nRF24L01 对供电比较敏感，建议保证 3.3V 电源能稳定输出足够电流，纹波别太大，否则会出现"时好时坏"的诡异现象。如果你的设备周围干扰源多（路由器、微波炉都在 2.4GHz 频段附近），给模块做点简易屏蔽往往立竿见影——用铝箔把模块主体包起来，再留出天线和排针的接口，就是社区里流传很广的土办法：

图：用铝箔对 nRF24L01 模块做简易屏蔽，能明显减少周围环境的电磁干扰

图：屏蔽后的模块保留天线连接口，适合需要拉长通信距离的场景

更远的距离与更低的功耗，可以同时拥有吗

想传得更远，可以试试把数据速率降到 250kbps 并适当提高功率；想省电，空闲时调用powerDown()，需要时再唤醒，配合中断接收，电池供电的节点也能撑很久。这两类优化在两端平台上的写法是一致的，这也是跨平台设计带来的额外红利：优化经验可以一套通吃。

继续探索的入口

想深入的话，仓库里还有不少好东西：docs/using_cmake.md讲透编译选项，examples/里躺着扫描仪、多节点等更多示例，examples_pico/则展示了树莓派 Pico 这类新平台也能用同一套思路跑起来；如果你更习惯 Python，pyRF24/目录里还有现成的封装可以试。按自己的节奏慢慢挖就好。

写在最后：如果你正在为"Arduino 和树莓派怎么传数据"发愁，希望这个故事能帮你少走点弯路。第一次看到两块互不相识的板子隔空传递同一个数字时，那种"原来可以这么简单"的惊喜，值得你亲自体会一次。去把那个示例跑起来吧，你的第一对无线节点，离跑通只差一个git clone。

【免费下载链接】RF24OSI Layer 2 driver for nRF24L01 on Arduino & Raspberry Pi/Linux Devices项目地址: https://gitcode.com/gh_mirrors/rf/RF24