描述

動機

（極客直接跳到挑戰和現有解決方案部分）

用于監控各種環境和天氣條件（溫度、濕度、壓力、光線、雨水、氣體、運動）的（自制）物聯網系統的設計和部署已成為每個（初級）愛好者所做的最受歡迎的項目之一一生至少一次。來自 OEM 和 DIY 套件供應商的硬件構建塊的可用性，以及大量的免費軟件（開源、現成的解決方案、庫、驅動程序、IDE、應用程序、操作系統、云中間件等）已經使項目純粹是明智的。設計師的角色通常被簡化為只選擇正確的傳感器模塊，這些模塊連接到“強大”的 MCU 板（ESP32 、Raspberry 、Arduino)，將現有軟件（驅動程序、庫）粘合在一起，并編寫簡單的應用程序邏輯。更不用說無數的指南、博客和 YouTube 教程了。

這種方法具有許多優點，例如快速原型制作、不需要深入的知識和經驗、非常有趣、大量支持以及沒有（或顯著減少）挫折感。對于那些決定進一步推進該項目并希望在其財產中/周圍構建和部署大量傳感器，甚至商業化（至少將解決方案出售給您的朋友或家人）的少數人來說，這種方法有幾個缺點。最重要的是解決方案的整體價格（如果你賣掉它，利潤會更低）。事實上，它可能比知名品牌的高價產品便宜。但是，使用ESP32 （雙核 32 位 @ 160 或 240MHz、320 KiB RAM、448 KiB ROM CPU 以及大量 IO 和總線）從臭名昭著的傳感器（例如DHT11, DHT22 , DS18B20 , AM2320 , BMP280 ) 通過 SPI/I2C/單線總線。除此之外，使用 Wi-Fi 將幾個字節轉發到中央集線器（另一個 ESP32 或 Raspberry）與（能源）效率無關。藍牙低功耗 (BTE) 配置文件可能會有所改進，但是，模塊（例如HC-05）的價格比 MCU 本身（包括一些傳感器）貴數倍。

綜上所述，小型物聯網傳感器主要有兩個非功能性需求：

• 成本優化：由于數量大，生產要經濟。因此，物聯網傳感器應該體積小（PCB），基于低端和低成本的 MCU （以最大限度地利用資源），并使用廉價的連接進行遠程訪問。低端 MCU 的引腳數較少，有利于 PCB 優化，但它限制了連接的 IO 設備/傳感器的數量。此外，低端 MCU資源稀缺（閃存、RAM、IO、總線），這限制了整體功能（應用程序并需要 IO 協議的 SW bit-banging）。然而，物聯網傳感器通常只收集少數環境屬性（2 個，也許 3 個）。這不需要使用大量的引腳和 MCU 資源。
• 易于部署和自主：傳感器應易于重新部署（連接），無需改變其周圍和環境。不需要額外安裝電線來為傳感器提供電源和通信，即傳感器應該是無線的和電池供電的（或能夠從環境中提取能量）。因此，此類傳感器（包括通信模塊）需要超低功耗（納至微安范圍）以避免頻繁更換電池。

對于通信模塊，有多種 COTS 選項可以同時滿足低成本和超低功耗的需求。其中之一是收發器nRF24L01+，特別受創客和愛好者的歡迎。它價格低廉（中國網上商店的分線板從 0.8 美元起）和超低功耗（掉電模式下為 990nA，待機模式下為 22uA，最大功率下 TX/RX 期間為 12mA）。此外，它具有簡單的接口（盡管是 3.3V 供電設備，但具有 5V 容限邏輯引腳的 SPI）、許多有利的特性（例如 ISM 頻帶 2.4GHz，范圍從 100 到 1000m、0.5-1-2 Mbps 帶寬、自動-retransmit、auto CRC check、multiciever）、大量廉價（突破）模塊（見下文）和幾個 SW 庫（nRF24 用于 Arduino/Raspberry Linux ）。

受愛好者歡迎的典型低端（成本）MCU 是8 位 AVR子系列，帶有稱為ATtiny的有限外設集，特別是 8 針25/45/85和 14 針24/44/84版本（第一個數字是以 KiB 為單位的閃存大小）。Arduino 的 28 針ATmega328P屬于 ATmega 系列，具有廣泛的外設和指令集。它提供 32KiB 閃存、4 倍更大的 RAM、更多 IO 設備，而且價格更高。在 (PCB) 尺寸、低引腳數和成本非常重要的情況下，ATtiny 系列 25/45/85 和 24/44/84 可能比 328P 更可取。

另一個有趣的低端 MCU 是帶有 1KiB 閃存和 64B SRAM的 8 針ATtiny13A 。它比 25/45/85 和 24/44/84 ATtiny 系列便宜 2-4 倍（< 1 美元）并且消耗更少的能量。因此，它在小型、簡單、電池供電的低成本設計（大多數無線傳感器都是如此）中特別受歡迎。

將 ATtiny13A 與低功耗無線模塊 nRF24L01+ 相結合，對于滿足上述非功能性要求的物聯網傳感器來說，似乎是一個可行的選擇。

為什么有人會費心將 nRF24L01+ 安裝在 8 針微型 ATtiny13A 和 1 KiB 閃存上的另一個原因，該閃存已經有 3 個針腳被超低功耗設備中的傳感器占用，這是……只是為了玩得開心，大笑，很棒有趣，因為：

“在 2K 中，你幾乎沒有刷牙的空間。”
-喬·德庫爾

挑戰和現有解決方案

由于硬件和軟件的挑戰，低端 8 針 ATtiny13A 與 nRF24L01 的組合并非易事。在我們對通用 8 引腳 MCU 的評論中，我們更詳細地描述了這種結合所面臨的硬件和軟件挑戰。回想一下，硬件挑戰如下圖所示：

ATtiny13A 實際上有 5 個引腳。如果我們將 PB5 從其主要功能（RESET/dWIRE）重新編程到 IO 端口，我們有 6 個引腳。但是，所有 6 引腳的使用都需要高壓編程。這對于在線串行編程 (ICSP) 并不總是可行的。此外，我們沒有任何備用引腳用于連接傳感器或連接到現場總線。從審查的現有解決方案來看，所有硬件提案原則上都適用于 ATtiny13A ，但每個都有相關的“成本”：

• Ralph 的 2 和 3 引腳解決方案需要幾個額外的無源元件。將 CE 永久拉高將無法充分利用 nRF24 模塊的節能功能。因此，它不是超低功耗應用的理想解決方案。
• 不使用 IRQ 信號將釋放 1 針（例如 PB5），可用于其主要功能（RST/dWIRE），但我們仍然無法連接其他設備。
• 共享 CE 引腳不是通用解決方案。CSN 低時不會干擾模塊。但是，當用于控制 nRF24 時，它可能與任何連接的設備或現場總線不兼容。
• 單向 SPI 適用于與主網關具有單向（單工）通信的無線傳感器網絡 (WSN)。因此，這不是通用解決方案，而是適用于特定類型的 WSN。

不幸的是，并非所有經過審查的軟件解決方案都具有足夠低的內存占用和/或支持所有功能：

• 用于 Arduino 和 RPi 的 nRF 驅動程序具有針對ATtiny 子系列的優化分支。前叉仍然很大，甚至無法容納內存是 t13a 兩倍的 ATtiny2313A。
• Nerd Ralp將針對 ATtiny84 （8KiB 閃存，14 針）定制的 tinkerer.eu 庫移植到他的 ATtiny85（8KiB 閃存）。目前尚不清楚總體占用空間是多少以及它是否適合 1KiB 閃存。此外，該庫依賴于 t13a 系列中未提供的通用串行接口 (USI) 外圍設備。這可以通過bit-banging來解決。
• 這個特定的共享 CE 引腳解決方案在 t13a 上運行，nRF24 的 SW 驅動程序是一個精簡的Mirf 庫，它只支持傳輸（盡管它需要具有 MOSI 和 MISO 信號的雙向 SPI）。

總而言之：所有列出的硬件解決方案都只優化了一個參數——引腳數。它們都沒有同時優化 1)能耗、2) 引腳數和3) 代碼占用空間。這對于超低功耗應用至關重要。此外，還缺少一個合適的 SW 驅動程序來支持半雙工無線通信，該驅動程序可以適合 t13a 以及支持一些引腳數優化解決方案。我們認為還有進一步提升的空間。出于這個原因，我們設計了一個全新的 SW 庫，將在本文的其余部分進行描述。該庫支持以下分別描述的三種硬件配置：

• 共享 CE 和 CSN 信號 - 它可以獨立使用，也可以與其余兩種配置組合使用。
• 3線SPI（合并MISO和MOSI），
• 可選單向 SPI（無 MISO）。

配置 1：共享 CE 和 CSN

CE 和 CSN 都是輸入引腳，根據nRF24 產品規范：

• CSN 是片選，低電平有效。需要至少 50ns的脈沖（低-高-低）持續時間來指示 SPI 上新事務的開始（規范中的第 49 頁，圖 25 和參數 Tcwh，表 18-25）。如果我們保持 CSN 關閉但不提供時鐘信號 (CSK)，則不會有數據流過，模塊也不會收到任何命令。因此，nRF24 將保持其當前狀態，內部寄存器不會受到影響。
• CE 用于在 RX 或 TX 模式下激活芯片，高電平有效。要將模塊的無線電切換到 TX 或 RX 模式，需要至少 10us的脈沖（第 22 頁的第 6.1.5 節和第 40 頁的圖 13）。

由此我們可以識別出共享 CE/CSN 信號的以下情況：

1) CE/CSN 為低電平，SCK 上無脈沖：默認情況，未啟用無線電，nRF24 不受影響。

2) CE/CSN 為低電平，SCK 上的時鐘信號：MCU 和 nRF 模塊之間通過 SPI 傳輸數據。

3) CE/CSN 上的脈沖大于 50ns 且小于 10us ：復位 SPI 接口并指示新事務的開始。

4) CE/CSN 上的10us脈沖：如果模塊之前處于StandBy-1模式（通過 SPI 接口設置配置寄存器中的 PWR_UP 位激活），則啟用無線電模式（TX 或 RX）。

5) 將 CE/CSN 拉高 10us 以上：在 RX 模式下用于等待新消息。

我們將使用條件 (1) CE/CSN 低作為信號的默認狀態。我們是否要啟用/禁用無線電（通常由 CE 控制）或通過 SPI 讀/寫寄存器（通常由 CSN 控制）的選擇將使用不同的脈沖持續時間“編碼”。

如果我們想在 SPI 上執行事務（訪問控制/狀態寄存器和 TX/RX 數據緩沖區），該過程將采取以下步驟：

• 1 -> 3 -> 2 -> 1 。

要啟用收音機，讓我們首先看看 TX 模式。在我們切換到 TX 模式之前，我們必須正確配置 nRF24 模塊（上電，進入StandBy-1模式）并將數據上傳到 TX 緩沖區。這是通過上述常規 SPI 事務和步驟完成的。之后，觸發傳輸的過程將采取以下步驟：

• 1 -> 4 -> 1

模塊將切換到 TX 模式，將執行所有操作（傳輸、等待確認、重傳、超時），并且在所有 TX 緩沖區為空后將切換回StandBy-1模式，因為 CE 為低電平。如果我們一直保持 CE 為高電平，即使緩沖區為空，模塊也會進入StandBy-2狀態。不同之處在于功耗：22uA 與 320uA，即StandBy-2 的15 倍。這樣的功耗等于完全激活狀態下 1MHz 的 ATtiny13A。模塊將停留在StandBy-1直到 MCU 將 nRF24 池化為狀態并最終關閉無線電（PWR_UP=0 位），即切換到PowerDown僅消耗 990nA 的狀態。CE 上的這個短脈沖節省了一些能量，這在超低功耗應用中確實很重要。

接收（RX模式）的情況略有不同，因為我們要等待比較長的一段時間才能接收到一些數據。在 CE/CSN 上執行 10us 的短脈沖是不夠的。一種選擇是將 CE/CSN 保持高電平一段所需的時間。在此期間，我們無法使用 SPI 訪問 nRF24。這個問題可以通過在發送端設置足夠多的重傳、超時和消息確認屬性來緩解。應配置 SPI 事務讀取狀態寄存器的持續時間短于整個傳輸會話（包括重新傳輸）。該程序將采取以下步驟：

• 1 -> 5 -> 1

此解決方案適用于主要用于傳輸的設備，但對于預期設備永久處于接收器模式的情況效果較差。對于這種情況，不合并 CE 和 CSN 可能更有效。相反，將 CE 拉至 Vcc（高電平）將使 ATtiny13A 無需關閉無線電即可匯集新消息。

配置 2：3 線 SPI

這個想法是通過一個電阻將 SPI 數據信號 MOSI 和 MISO 合并為一個，如下圖所示：

這不是一個新想法，在各種設計中相對常見，以減少信號的數量。nRF24 模塊會在這樣的信號合并下正常工作嗎？此圖中顯示了 SPI 與文檔中的 nRF24 模塊的通信：

我們看到nRF24使用MISO發送狀態字節，而主控（MCU）向模塊發送命令，即全雙工通信。之后，MISO 線下降，僅在主 (MCU) 請求讀取操作時使用。兩個信號之間唯一可能的干擾是在開始時可能會破壞命令字節（在 MOSI 線上）。幸運的是，這種“沖突”是通過電阻解決的。其值應保證信號源/漏極不跨越 MCU 和模塊的引腳特性。在我們的案例中，從 4.7k 到 10k 的值運行良好。

合并的 MISO/MOSI 節省了一個可用于直接控制 CE 的引腳。如果需要，可以將此配置與第一個配置混合使用 - 共享 CE/CSN，如下圖所示：

配置 3：單向 SPI

這種配置降低了 MISO（主輸入，從輸出）線，使其成為 3 線 SPI，即減少了一個引腳數。我們可以將數據寫入 nRF24 模塊，但我們將無法讀取它們：

它可能非常嚴格，但適用于某種類型的無線應用程序 - 設備專門用作數據源（測量），它不接收來自其他設備或網關（中央集線器）的數據。如果我們可以有一個 3 線 SPI 來節省相同數量的引腳，為什么我們還需要單向 SPI？有兩個原因：

• 我們還希望最大限度地減少組件數量/成本和/或 PCB 尺寸和復雜性。
• 減少驅動程序的內存占用，從而為傳感器驅動程序和應用程序邏輯留下一些寶貴的空間。ATtiny13A 只有 1KiB 的閃存。

我們可以將此配置與第一個配置（共享 CE/CSN）相結合，以進一步優化 MCU 所需的引腳數，如下圖所示：

庫配置

代碼在 C ( nRF24L01.c) 和匯編程序 ( nRF24L01_asm.S) 中都實現。頭文件nRF24L01.h包含重要的常量和 API 函數的聲明。默認情況下，該庫使用全 4 線 SPI 和獨立的 CE 和 CSN 信號。通過在文件中定義相應的宏來配置庫以使用上述硬件選項之一。projdefs.h

#define	NRF24L01_SHARED_CE_CSN    // For shared CE/CSN configuration

此宏可以與以下任一（或無）組合：

#define	NRF24L01_3WIRE_SPI        // If used 3-wire SPI (with resistor)
#define	NRF24L01_DO_NOT_USE_MISO  // Uni-directional configuration

如果上述三個宏均未定義，則假定為默認配置。

定義連接到哪些端口 nRF24 信號也通過projdefs.h標頭中的宏完成。引腳配置宏是：

// MANDATORY macros for port output, port direction and pin reading:
#define NRF24L01_PORT		PORTB
#define NRF24L01_DDR		DDRB
#define NRF24L01_INPORT		PINB

為特定的引腳配置定義以下宏（如果適用 - 請參閱上面的功能）：

#define NRF24L01_CE     PB0    // Optional. Do not define if shared CE/SCN is enabled 
#define NRF24L01_CSN    PB2    // Mandatory
#define NRF24L01_SCK	PB1    // Mandatory
#define NRF24L01_MOSI	PB3    // Mandatory
#define NRF24L01_MISO	PB4    // Optional. Define only if 4-wire SPI is used.

API

API 只有 8 個（或 6 個，如果是單向的）方法。必須調用的第一個函數是初始化：

void nrf24_init(void);

其余功能根據 SPI 事務的長度進行拆分。零字節命令通過以下方式調用：

void nrf24_cmd(uint8_t cmd);

參數是文檔表 16 中的“命令字” ，例如：FLUSH_TX, FLUSH_RX, REUSE_TX_PL. 為方便起見，頭文件包含所有命令代碼的定義。

使用一個數據字節調用命令（通常寫入寄存器）：

void nrf24_writeReg(uint8_t cmd, uint8_t value);

如果我們沒有單向 SPI 配置，我們也可以讀取寄存器：

uint8_t nrf24_readReg(uint8_t cmd);

參數 cmd 包含作為單個字節的復合寄存器地址：如果讀取，則為 1 并且00wAAAAA是寄存器地址（第 9 章 - 寄存器映射）。wAAAAA

寫入 TX 緩沖區和多字節寄存器：

void nrf24_writeRegs(uint8_t cmd, const uint8_t *buff, uint8_t size);

如果我們不使用單向 SPI 配置，讀取緩沖區的函數：

void nrf24_readRegs(uint8_t cmd, uint8_t *buff, uint8_t size);

參數列表是不言自明的。最后一組 API 函數用于在一段時間內“切換”CE 信號：

void nrf24_pulseCE(void);

這將在 CE 上產生大約 15us 的脈沖。該功能用于在無線電通電且 TX 緩沖區充滿數據后切換到 TX 模式。

為了使 CE 保持較高的持續時間（通常在使用共享 CE/CSN 配置時用于 RX 模式），應使用以下函數：

void nrf24_pulseCE_ms(uint16_t milliseconds);

如果我們不與 CSN 共享 CE（單獨連接），則由應用程序邏輯來控制 CE 引腳。

例子

該庫的存儲庫在main.c文件中包含一個工作示例，用于通過 nRF24L01 驅動程序發送和接收 32 位序列號。

帶 ATtiny13A 的發射器

發射器結合了第一個（共享 CE/CSN）和第三個（單向）硬件配置。這占用了 MCU 上的 3 個引腳，剩下 2 個（如果沒有 RST，則為 +1）用于其他設備/傳感器/應用程序。在我們的例子中，我們將一個紅色 LED 連接到 PB3：

應用程序每 2 秒遞增一次，并向通道 120 上的管道 0 發送一個 32 位無符號整數。LED 亮起 800 毫秒以指示周期的開始。源代碼展示了從對講機上電、配置模塊、將數據移入緩沖區、傳輸和對講機電源的整個過程。

包括為 nRF24 設計的庫在內的發射器應用程序的總體占用空間為372 字節（可用 1KiB）和 6 字節 SRAM（共 64 字節）。

帶 ATtiny13A 的接收器

接收器應用程序不使用共享 CE/CSN，因為該模塊僅在 RX 模式下工作并且不傳輸數據（確認數據包除外）。為了優化引腳數，我們應用了總共占用 3 個 MCU 引腳的 3 線 SPI：

應用軟件每 100 毫秒匯集一次狀態寄存器以獲取新數據包。如果數據包到達，則將其讀入 MCU，并清除狀態。如果接收到的序列號與前一個序列號的增量相同，則綠色 LED 亮 1 秒。

包括為 nRF24 設計的庫在內的接收器應用程序的總體占用空間為420字節（可用 1KiB）和 6 字節 SRAM（共 64 字節）。

運行演示應用程序

同時運行發射器和接收器：

如果接收器接收到預期的序列號，接收器的 LED（綠色）將亮起 1 秒。紅色 (TX) 和綠色 (RX) LED 之間的最大延遲約為 100 毫秒，這是由 RX 側的池化引起的。

概括

提議的 nRF24 庫的主要目標和成就是：

• 最小化管腳數：它支持三種通用管腳優化硬件配置（與此共享 CE 不同），不需要或單個電阻器（與Nerd Ralph 的解決方案不同）。nRF24 模塊在 MCU 上僅占用 3 個引腳而不是 6 個。這留下了其他 2 個引腳（如果 RST 用作 IO，則為 +1）用于連接傳感器或現場總線。
• 最小化功耗：專為超低功耗應用而設計。通過極少指令的優化庫實現節能。這減少了整體執行時間。與其他類似方法（共享 CE/CSN 與 CE 永久激活）相比，引腳數最小化的方式為 nRF24 模塊提供更好的能量管理。
• 最小化庫的占用空間：非常低的占用空間 - 演示應用程序有372 字節（發送器）和 420 字節（接收器），包括應用程序的邏輯。它可以輕松裝入 ATtiny13A 并為其他應用程序和連接的設備和現場總線留出足夠的空間。它可配置為半雙工或單工無線電通信，以進一步最小化占用空間。與其他通用庫不同，它還可以部署在 ATtiny 子系列中具有相同或更大內存的任何其他 MCU 上。SPI 接口實現為bit-banging，因此不依賴于通用串行接口 (USI)等外圍設備。

然而，實現給定的目標需要付出一定的代價。API 提供的低粒度方法不如RF24 庫或類似庫中的高級方法方便。