前陣子參加了一個嵌入式開發聚會，聊天時發現很多資深工程師都面臨同樣的困境：手上的 NRF52 專案運行良好，但新的 NRF54L 硬體性能誘人，卻不想被迫學習 Zephyr RTOS。
「我們用 NRF5 SDK 已經五年了，程式碼庫穩定可靠，真的要為了新硬體重新學 Zephyr 嗎？」一位做醫療設備的朋友這樣問。
這個問題其實反映了嵌入式開發領域一個普遍的現象：硬體進步很快，但軟體遷移成本往往被低估。幸好，Nordic Semiconductor 最近推出了 NRF Connect SDK Bare Metal 選項，為這個問題提供了優雅的解決方案。
經過深度研究 Nordic 官方 webinar 內容以及實際測試數據，我發現這個新選項不僅解決了遷移問題，更在技術實現上有不少突破。讓我從開發者的角度，詳細分析這個技術方案的來龍去脈。
嵌入式開發的選擇光譜：從底層到抽象
談到 Nordic 的新策略，得先理解嵌入式軟體開發的完整光譜。從直接操作暫存器到運行完整作業系統，每個層級都有其適用場景。
底層直控：暫存器層級開發
最底層是直接操作硬體暫存器。想像你要控制一個 SPI 介面，你需要：
// 直接設置 SPI 暫存器
SPI_CR1 |= SPI_CR1_SPE; // 啟用 SPI
SPI_DR = data_byte; // 寫入數據
while (!(SPI_SR & SPI_SR_TXE)); // 等待發送完成
這種方式在 8 位元 MCU 時代很常見，開發者需要深度了解每個暫存器的功能。優點是完全掌控，缺點是開發效率低，程式碼可移植性差。
事件驅動：Bare Metal 的進化
接下來是事件驅動的 bare metal 開發，這也是 Nordic NRF5 SDK 採用的方式。系統基於事件循環運行：
int main(void) {
// 初始化硬體
hardware_init();
bluetooth_stack_init();
// 主事件循環
for (;;) {
// 處理藍牙事件
if (ble_event_pending()) {
handle_ble_events();
}
// 處理感測器數據
if (sensor_data_ready()) {
process_sensor_data();
}
// 進入低功耗模式
power_manage();
}
}
這種架構適合業務邏輯相對線性的應用：啟動→廣播→連接→數據交換→睡眠→重複。Nordic 稱之為「簡單藍牙應用」的典型模式。
多工處理：RTOS 的領域
當應用複雜度提升，需要同時處理多個任務時，RTOS 就派上用場：
// 不同優先級的任務
void sensor_task(void *param) {
while (1) {
read_sensors();
vTaskDelay(100); // 每100ms讀取一次
}
}
void ui_task(void *param) {
while (1) {
update_display();
handle_user_input();
vTaskDelay(50);
}
}
void ble_task(void *param) {
while (1) {
process_ble_events();
vTaskDelay(10); // 高頻處理
}
}
RTOS 提供任務排程、同步機制、記憶體管理等服務，但也帶來了額外的系統開銷。
Nordic 硬體演進：從 NRF52 到 NRF54L 的技術跨越
NRF52 時代：成熟穩定的選擇
2015 年推出的 NRF52 系列可以說是藍牙 LE 開發的經典平台：
核心規格：
- Cortex-M4 @ 64MHz
- 最大 1MB Flash / 256KB RAM
- 藍牙 5.0 支援
- 豐富的周邊介面
軟體生態：
- NRF5 SDK：bare metal 開發環境
- NRF Connect SDK：基於 Zephyr RTOS
這個組合在過去幾年支撑了數十億顆晶片的出貨，從智能手環到工業感測器都能看到它的身影。
NRF54L 系列：新一代的性能突破
2024 年 11 月推出的 NRF54L 系列代表了 Nordic 在低功耗無線技術上的新突破：
硬體升級亮點：
處理器性能翻倍
- Cortex-M33 @ 128MHz（vs M4 @ 64MHz）
- 22nm 製程 vs 90nm
- 處理效率提升 3 倍
功耗優化顯著
- 廣播電流：115μA（100ms 間隔）
- 閒置電流：低至 2.2μA
- 整體功耗降低約 30%
記憶體配置靈活
- NRF54L15：1.5MB Flash / 256KB RAM
- NRF54L10：1.0MB Flash / 192KB RAM
- NRF54L05：0.5MB Flash / 96KB RAM
新增功能特性
- 藍牙 6.0 Channel Sounding 支援
- RISC-V 協處理器
- 14-bit ADC
- 強化的安全功能
實際測試數據對比：
| 項目 | NRF52840 | NRF54L15 | 改善幅度 |
|---|---|---|---|
| CPU 時脈 | 64MHz | 128MHz | +100% |
| 廣播功耗 | 165μA | 115μA | -30% |
| 連接功耗 | 19μA | 14.5μA | -24% |
| 處理效率 | 基準 | 3x | +200% |
這些數據來自 Nordic 官方實測，使用相同測試條件和應用場景。
軟體架構深度解析：Bare Metal 選項的技術實現
軟體堆疊架構
Nordic NRF Connect SDK Bare Metal 選項採用了精心設計的分層架構：
┌─────────────────────────────────┐
│ 應用程式碼 │
│ (Customer Application) │
├─────────────────────────────────┤
│ 軟體設備 (SoftDevice) │
│ S115 (周邊模式) / S145 (多角色) │
├─────────────────────────────────┤
│ NRFX 底層驅動 │
│ (硬體抽象層 & 驅動程式) │
├─────────────────────────────────┤
│ NRF54L 硬體 │
│ (處理器、記憶體、周邊) │
└─────────────────────────────────┘
軟體設備 (SoftDevice) 詳解
軟體設備是 Nordic 的核心技術，提供預編譯的藍牙協定堆疊：
S115 軟體設備特性：
- 純周邊模式 (Peripheral Only)
- 支援最多 2 個並發連接
- 記憶體優化設計
- 適合簡單藍牙應用
S145 軟體設備特性：
- 多角色支援 (Central + Peripheral)
- 支援最多 8 個並發連接
- LE Coded PHY 支援
- 廣播擴展功能
API 相容性：
// NRF5 SDK 風格的 API 調用
ret_code_t err_code;
// 初始化軟體設備
err_code = sd_softdevice_enable(&clock_lf_cfg, fault_handler);
APP_ERROR_CHECK(err_code);
// 設置藍牙事件處理
err_code = sd_ble_evt_handler_set(ble_evt_handler);
APP_ERROR_CHECK(err_code);
// 開始廣播
err_code = sd_ble_gap_adv_start(&m_adv_handle, BLE_CONN_CFG_TAG_DEFAULT);
APP_ERROR_CHECK(err_code);
這些 API 與 NRF5 SDK v17 高度相容，讓現有程式碼能順利遷移。
NRFX 驅動層深度分析
NRFX 是 Nordic 的硬體抽象層，提供統一的周邊存取介面：
// UART 驅動使用範例
#include "nrfx_uarte.h"
// 配置 UART
nrfx_uarte_config_t config = NRFX_UARTE_DEFAULT_CONFIG;
config.pseltxd = TX_PIN_NUMBER;
config.pselrxd = RX_PIN_NUMBER;
config.baudrate = NRF_UARTE_BAUDRATE_115200;
// 初始化 UART
err_code = nrfx_uarte_init(&uart_inst, &config, uart_handler);
// 發送數據
nrfx_uarte_tx(&uart_inst, tx_buffer, tx_length);
NRFX 的關鍵優勢：
- 硬體抽象一致性：無論 NRF52 還是 NRF54L，API 保持一致
- 效能優化：直接操作硬體暫存器，最小化軟體開銷
- RTOS 無關性：可用於 bare metal 或任何 RTOS 環境
開發環境整合
Nordic 提供了統一的開發環境，bare metal 和 Zephyr 選項共存：
VS Code 整合流程：
- SDK 安裝
# 使用 nRF Util 安裝
nrf-util toolchain-manager install --sdk ncs-bare-metal --version v0.8.0
- 專案建立
# 複製範例專案
nrf-util create-app --example peripheral_lbs --sdk ncs-bare-metal
- 編譯建置
# West 工具鏈編譯
west build -b nrf54l15dk_nrf54l15_cpuapp
- 燒錄除錯
# 燒錄到開發板
west flash
專案結構範例：
my_ble_app/
├── src/
│ ├── main.c # 主程式
│ └── ble_services/ # 藍牙服務
├── include/
│ └── app_config.h # 應用配置
├── boards/
│ └── nrf54l15dk_nrf54l15_cpuapp.overlay # 硬體配置
├── prj.conf # Kconfig 配置
└── CMakeLists.txt # 建置配置
性能實測數據深度分析
記憶體使用量比較
基於 Nordic 官方測試數據，我們看到有趣的記憶體使用模式：
Nordic UART Service 範例：
| 項目 | Zephyr RTOS | Bare Metal | 差異 |
|---|---|---|---|
| RAM 使用量 | 31 KB | 19 KB | -38% |
| Flash 使用量 | 174 KB | 154 KB | -11% |
LED Button Service 範例：
| 項目 | Zephyr RTOS | Bare Metal | 差異 |
|---|---|---|---|
| RAM 使用量 | 22.5 KB | 19.3 KB | -14% |
| Flash 使用量 | 168 KB | 135 KB | -20% |
關鍵發現：
- RAM 差異顯著：Bare metal 在 RAM 使用上有明顯優勢，特別是簡單應用
- Flash 差異適中：Zephyr 的系統服務確實占用額外空間，但差距可控
- 差異隨複雜度縮小：當應用功能增加時，RTOS 開銷占比會相對減少
功耗性能深度測試
廣播模式功耗分析：
測試條件：100ms 廣播間隔，1Mbps PHY
| 測試項目 | Zephyr RTOS | Bare Metal | 差異 |
|---|---|---|---|
| 平均廣播電流 | 115.2 μA | 113.0 μA | -1.9% |
| 閒置電流 | 2.2 μA | 2.4 μA | +9% |
| 廣播事件功耗 | 3.9 mA | 3.7 mA | -5% |
連接模式功耗分析：
測試條件：360ms 連接間隔
| 測試項目 | Zephyr RTOS | Bare Metal | 差異 |
|---|---|---|---|
| 平均連接電流 | 14.5 μA | 14.3 μA | -1.4% |
深度分析：
- 功耗差異微小：兩種方案在功耗表現上幾乎相同
- 無線電主導：系統功耗主要來自無線電模組，CPU 開銷相對較小
- 誤解澄清：選擇 bare metal 不會帶來顯著的功耗優勢
這個發現很重要，因為很多開發者誤以為 bare metal 一定更省電。實際上，現代 MCU 的 CPU 功耗相比無線電幾乎可以忽略不計。
實時性能測試
中斷回應時間：
| 事件類型 | Zephyr RTOS | Bare Metal | 改善幅度 |
|---|---|---|---|
| GPIO 中斷 | 2μs | 0.5μs | 75% |
| UART 中斷 | 3μs | 0.8μs | 73% |
| 藍牙事件 | 15μs | ~10μs | 33% |
Bare metal 在中斷回應時間上確實有優勢，這對需要快速回應的應用很重要。
開發實務與應用場景深度指南
選擇框架的決策樹
基於實際開發經驗和技術特性，我整理了詳細的選擇指南：
選擇 Bare Metal 的場景：
簡單藍牙應用
- 感測器數據收集器
- 簡單的遙控設備
- 基礎的信標 (Beacon) 應用
現有程式碼移植
- 基於 NRF5 SDK 的成熟專案
- 已投入大量開發成本的程式碼庫
- 需要保持 API 相容性的場景
特殊合規要求
- 醫療設備需要嚴格的軟體驗證
- 安全關鍵應用需要最小化第三方程式碼
- 需要完整控制軟體堆疊的場景
資源受限環境
- 使用 NRF54L05 (96KB RAM) 等小型版本
- 成本敏感的大量產品
- 電池供電的極簡設備
選擇 Zephyr RTOS 的場景：
複雜多工應用
- 同時處理多個無線協定
- 需要並行執行多個任務
- 包含 AI 推理的邊緣運算
豐富的生態需求
- 需要大量第三方函式庫
- 使用 Bluetooth Mesh 或 Matter
- 整合網路協定堆疊
快速原型開發
- 新產品概念驗證
- 需要快速上市的專案
- 團隊對 RTOS 開發熟悉
擴展性考量
- 產品功能可能持續增長
- 需要支援 OTA 更新
- 多產品線共用程式碼
實際開發案例研究
案例一：智慧手環心率監測
某客戶開發智慧手環，原本使用 NRF52832 + NRF5 SDK：
// 原有架構（簡化版）
void main(void) {
// 初始化
timers_init();
ble_stack_init();
gap_params_init();
services_init(); // 心率服務
advertising_init();
conn_params_init();
// 主循環
for (;;) {
if (m_heart_rate_measurement_ready) {
heart_rate_measurement_send();
m_heart_rate_measurement_ready = false;
}
power_manage();
}
}
遷移到 NRF54L15 的考量：
- 硬體優勢：30% 功耗降低，延長穿戴時間
- 軟體相容：API 相似，遷移成本低
- 記憶體充足：1.5MB Flash 足夠容納更多功能
實際遷移結果：
- 開發時間：2 週（vs 預估 2 個月用 Zephyr）
- 功耗改善：續航從 5 天提升到 7 天
- 程式碼複用率：85%
案例二：工業感測器閘道器
另一個客戶開發多協定感測器閘道器：
// 需要同時處理的任務
void sensor_task(void) {
// 每秒收集感測器數據
collect_temperature_data();
collect_humidity_data();
collect_pressure_data();
}
void ble_task(void) {
// 處理手機 App 連接
process_ble_events();
handle_configuration_requests();
}
void thread_task(void) {
// 處理 Thread 網路通信
process_thread_messages();
forward_sensor_data();
}
void storage_task(void) {
// 本地數據緩存
manage_flash_storage();
implement_wear_leveling();
}
為什麼選擇 Zephyr：
- 多工需求：4 個並行任務需要排程管理
- 協定複雜性：BLE + Thread 需要 RTOS 支援
- 社群資源：Thread 實作依賴 OpenThread
開發結果：
- 開發時間：6 週
- 系統穩定性：優秀的任務隔離
- 擴展性：易於增加新協定
遷移實務指南
從 NRF5 SDK 遷移到 Bare Metal 的詳細步驟：
- 環境準備
# 安裝必要工具
nrf-util install toolchain-manager
nrf-util toolchain-manager install --sdk ncs-bare-metal
# 設置環境變數
export NRF_CONNECT_SDK_PATH=/path/to/ncs-bare-metal
- 程式碼審查與規劃
// 檢查使用的 API
grep -r "sd_ble_" src/ # 軟體設備 API
grep -r "nrf_drv_" src/ # 驅動 API
grep -r "app_" src/ # 應用函式庫
逐步移植策略
- 第一階段：移植基本藍牙功能
- 第二階段：移植周邊驅動
- 第三階段：移植應用邏輯
- 第四階段：優化與測試
常見移植問題與解決方案
| 問題 | 原因 | 解決方案 |
|---|---|---|
| 編譯錯誤 | API 版本差異 | 參考官方遷移指南更新 API |
| 功能異常 | 配置差異 | 檢查 prj.conf 和設備樹配置 |
| 性能問題 | 優化設置 | 調整編譯器優化選項 |
技術深度剖析：單bank DFU 實現
DFU 機制對比分析
雙bank DFU（傳統方案）：
Flash Layout:
┌─────────────────────┐ 0x00000000
│ Bootloader │
├─────────────────────┤ 0x00010000
│ Application Bank A │ (運行中)
├─────────────────────┤ 0x00080000
│ Application Bank B │ (新韌體)
├─────────────────────┤ 0x000F0000
│ User Data │
└─────────────────────┘
優點：安全性高，更新失敗不會磚機 缺點：需要對等的兩個應用空間，限制應用程式大小
單bank DFU（新實現）：
Flash Layout:
┌─────────────────────┐ 0x00000000
│ Bootloader │
├─────────────────────┤ 0x00008000
│ │
│ Application Space │ (更大的可用空間)
│ │
├─────────────────────┤ 0x000E0000
│ User Data │
└─────────────────────┘
優點：最大化應用程式空間，適合資源受限設備 缺點：更新過程中存在風險，需要可靠的更新機制
單bank DFU 技術實現
更新流程設計：
- 進入更新模式
// 應用程式觸發更新
void enter_dfu_mode(void) {
// 保存關鍵狀態
save_application_state();
// 設置更新標誌
set_dfu_flag();
// 軟重啟進入 Bootloader
NVIC_SystemReset();
}
- Bootloader 驗證
// Bootloader 中的驗證邏輯
bool validate_new_firmware(uint32_t fw_addr, uint32_t fw_size) {
// 1. 檢查數位簽名
if (!verify_digital_signature(fw_addr, fw_size)) {
return false;
}
// 2. 檢查韌體完整性
if (!verify_checksum(fw_addr, fw_size)) {
return false;
}
// 3. 檢查版本相容性
if (!check_version_compatibility(fw_addr)) {
return false;
}
return true;
}
- 原地更新實現
void update_firmware_in_place(uint32_t new_fw_addr, uint32_t new_fw_size) {
// 分段更新，避免掉電風險
uint32_t sector_size = FLASH_SECTOR_SIZE;
uint32_t sectors = (new_fw_size + sector_size - 1) / sector_size;
for (uint32_t i = 0; i < sectors; i++) {
uint32_t sector_addr = APPLICATION_START_ADDR + i * sector_size;
uint32_t src_addr = new_fw_addr + i * sector_size;
// 擦除並寫入新扇區
flash_erase_sector(sector_addr);
flash_write_sector(sector_addr, src_addr, sector_size);
// 每個扇區完成後驗證
if (!verify_sector(sector_addr, sector_size)) {
// 更新失敗，停留在 Bootloader
enter_recovery_mode();
return;
}
}
// 更新完成，跳轉到新應用
jump_to_application();
}
風險控制機制
斷電保護策略：
- 分段更新：每次只更新一個 Flash 扇區
- 進度記錄：在專用區域記錄更新進度
- 回滾機制：保留最小可運行版本
錯誤恢復流程：
void handle_update_failure(void) {
// 檢查失敗類型
dfu_error_t error = get_dfu_error();
switch (error) {
case DFU_ERROR_POWER_LOSS:
// 斷電恢復，繼續未完成的更新
resume_interrupted_update();
break;
case DFU_ERROR_INVALID_FIRMWARE:
// 韌體無效，回滾到安全模式
enter_recovery_mode();
break;
case DFU_ERROR_FLASH_WRITE:
// Flash 寫入錯誤，嘗試修復
repair_flash_errors();
break;
}
}
市場生態與競爭分析
Nordic 在藍牙 LE 市場的地位
市場占有率數據：
- 藍牙 LE SoC 市場占有率：約 40%（2024）
- 累積出貨量：超過 50 億顆
- 客戶數量：數千家活躍開發者
技術優勢分析：
軟體生態成熟
- NRF5 SDK：經過 9 年迭代優化
- NRF Connect SDK：基於 Zephyr 的現代化平台
- 豐富的範例程式和文件
硬體性能領先
- 功耗效率業界前茅
- RF 性能穩定可靠
- 豐富的周邊接口
開發工具完善
- nRF Connect for VS Code
- 功耗分析工具
- 協定分析器
競爭對手分析
主要競爭對手比較：
| 廠商 | 代表產品 | 優勢 | 劣勢 |
|---|---|---|---|
| Nordic | nRF54L | 生態成熟、功耗優秀 | 價格較高 |
| Silicon Labs | EFR32 | 多協定支援強 | 軟體學習曲線陡 |
| Espressif | ESP32 | 成本低、WiFi 整合 | 功耗較高 |
| Dialog | DA1469x | 超低功耗 | 生態相對小 |
Nordic Bare Metal 選項的競爭優勢：
- 降低遷移門檻：讓現有客戶輕鬆升級硬體
- 保持生態黏性：避免客戶流失到其他平台
- 擴大適用範圍：吸引偏好 bare metal 的開發者
第三方生態支援
模組合作夥伴：
- Raytac：AN54L15Q 模組，已通過 FCC/CE 認證
- Laird Connectivity：工業級模組產品線
- u-blox：NINA-B5 系列模組
開發工具整合：
- Segger：J-Link 除錯器支援
- IAR：編譯器工具鏈
- Keil：MDK-ARM 開發環境
Edge AI 生態：
- Edge Impulse：已支援 nRF54L15 DK
- ST：X-NUCLEO-IKS02A1 感測器擴展板
- TensorFlow Lite：微控制器 ML 推理
未來發展路線圖與技術趨勢
Nordic 官方路線圖
2025 年發展計劃：
Q1 2025：
- S115 軟體設備正式版（production ready）
- 藍牙資格認證完成
- 單bank DFU 穩定版發布
Q2-Q3 2025：
- S145 多角色軟體設備發布
- 支援 Central 和 Observer 模式
- NFC 功能整合
Q4 2025：
- S145 production ready 版本
- 性能優化和功耗降低
- 更多範例程式和文件
長期發展方向：
硬體演進
- nRF54H 系列：面向高性能應用
- 更先進的製程技術
- AI 協處理器整合
軟體功能擴展
- 更多協定支援考慮中
- 安全功能強化
- 開發工具持續改善
嵌入式開發趨勢分析
技術發展趨勢：
Edge AI 普及
- TinyML 在 MCU 上的部署
- 感測器融合與智能決策
- 即時機器學習推理
安全性要求提升
- IoT 安全法規趨嚴
- 硬體安全模組標配
- 端到端加密普及
多協定整合
- Matter 生態成熟
- Thread 與 WiFi 協作
- 5G RedCap 在 IoT 的應用
開發效率優化
- 低程式碼/無程式碼開發
- AI 輔助程式設計
- 雲端開發環境普及
對 Bare Metal vs RTOS 選擇的影響：
Bare Metal 仍有價值
- 超低功耗應用需求持續存在
- 安全關鍵應用偏好簡單架構
- 成本敏感市場的重要性
RTOS 功能持續擴展
- AI 推理需要複雜任務管理
- 多協定併行處理需求增長
- OTA 和遠程管理成為標配
開發者技能發展建議
技術能力建構：
基礎技能
- 深度理解藍牙 LE 協定
- 熟練掌握 C/C++ 嵌入式開發
- 硬體除錯和分析能力
進階技能
- RTOS 原理和實作
- 無線射頻知識
- 功耗優化技術
新興技能
- Edge AI 和 TinyML
- 資訊安全最佳實務
- IoT 雲端整合
學習資源推薦：
官方資源
- Nordic Developer Academy
- Technical documentation
- Github 範例程式庫
社群資源
- DevZone 技術論壇
- Zephyr Project 社群
- 技術會議和工作坊
實戰建議與最佳實務
專案啟動檢查清單
技術評估階段：
□ 應用複雜度分析
□ 任務數量 < 3 個 → 考慮 Bare Metal
□ 需要嚴格時序控制 → 傾向 Bare Metal
□ 多協定併行 → 建議 RTOS
□ 資源限制評估
□ RAM < 128KB → Bare Metal 優勢明顯
□ Flash < 512KB → 考慮單bank DFU
□ 功耗 < 10μA → 兩者差異不大
□ 團隊技能匹配
□ NRF5 SDK 經驗 → Bare Metal 學習成本低
□ RTOS 開發經驗 → Zephyr 上手快
□ 新手團隊 → 建議從範例開始
開發環境設置：
- 必要工具安裝
# 基礎工具鏈
nrf-util install toolchain-manager
nrf-util install device
# VS Code 擴展
code --install-extension nordic-semiconductor.nrf-connect
# 除錯工具
# 確保 J-Link 驅動已安裝
- 專案模板選擇
| 應用類型 | 推薦模板 | 說明 |
|---|---|---|
| 簡單感測器 | peripheral_lbs | LED/按鈕控制範例 |
| 數據收集 | peripheral_uart | UART 數據傳輸 |
| 心率監測 | peripheral_hrs | 標準健康服務 |
| 自定義服務 | peripheral_template | 空白模板 |
除錯技巧與故障排除
常見問題診斷：
- 藍牙連接問題
// 增加除錯訊息
#define NRF_LOG_MODULE_NAME main
#define NRF_LOG_LEVEL 4
#include "nrf_log.h"
void on_ble_evt(ble_evt_t const * p_ble_evt) {
switch (p_ble_evt->header.evt_id) {
case BLE_GAP_EVT_CONNECTED:
NRF_LOG_INFO("Connected to device");
break;
case BLE_GAP_EVT_DISCONNECTED:
NRF_LOG_INFO("Disconnected, reason: %d",
p_ble_evt->evt.gap_evt.params.disconnected.reason);
break;
}
}
- 功耗分析技術
// 使用 Power Profiler Kit 配合程式碼標記
void enter_measurement_mode(void) {
// 標記測量開始
nrf_gpio_pin_set(DEBUG_PIN_1);
// 執行測量任務
perform_sensor_reading();
// 標記測量結束
nrf_gpio_pin_clear(DEBUG_PIN_1);
}
- 記憶體使用監控
# 編譯後分析記憶體使用
arm-none-eabi-size build/zephyr/zephyr.elf
# 詳細的記憶體分配報告
arm-none-eabi-objdump -h build/zephyr/zephyr.elf
效能優化策略
程式碼層級優化：
- 中斷處理最小化
// 錯誤範例 - 在中斷中做複雜處理
void TIMER0_IRQHandler(void) {
if (NRF_TIMER0->EVENTS_COMPARE[0]) {
// 避免在中斷中做複雜運算
complex_data_processing(); // ❌
NRF_TIMER0->EVENTS_COMPARE[0] = 0;
}
}
// 正確範例 - 中斷中只設置標誌
volatile bool data_ready = false;
void TIMER0_IRQHandler(void) {
if (NRF_TIMER0->EVENTS_COMPARE[0]) {
data_ready = true; // ✅
NRF_TIMER0->EVENTS_COMPARE[0] = 0;
}
}
// 在主循環中處理
int main(void) {
while (1) {
if (data_ready) {
complex_data_processing();
data_ready = false;
}
power_manage();
}
}
- 記憶體存取優化
// 結構體對齊優化
typedef struct {
uint32_t timestamp; // 4 bytes
uint16_t sensor_value; // 2 bytes
uint8_t status; // 1 byte
uint8_t reserved; // 1 byte padding
} __attribute__((packed)) sensor_data_t; // 總共 8 bytes
系統層級優化：
- 時鐘配置優化
// 根據應用需求選擇時鐘源
static void clock_init(void) {
// 高精度應用使用外部晶振
nrf_clock_lfclk_t lfclk_cfg = {
.source = NRF_CLOCK_LFCLK_Xtal,
.accuracy = NRF_CLOCK_LFCLK_ACCURACY_20_PPM
};
// 成本敏感應用使用內部 RC
// .source = NRF_CLOCK_LFCLK_RC
}
- 功耗模式管理
void power_manage(void) {
// 檢查是否有待處理事件
if (!pending_events()) {
// 進入最深睡眠模式
sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
sd_app_evt_wait();
}
}
結論：技術選擇的智慧
經過深入分析，Nordic NRF Connect SDK Bare Metal 選項確實為嵌入式開發社群帶來了有價值的新選擇。它不只是一個技術產品，更是對開發者需求的深刻理解。
核心價值總結
技術層面的突破：
- 性能數據證實：功耗和記憶體使用的實測數據破除了許多迷思
- API 相容性：與 NRF5 SDK 的高度相容降低了遷移成本
- 開發體驗：統一的工具鏈讓 bare metal 和 RTOS 並存
商業價值體現：
- 降低遷移壁壘：讓現有客戶能夠無痛升級硬體
- 擴大市場覆蓋：吸引偏好 bare metal 的開發者群體
- 生態系統完整：從晶片到工具的端到端支援
實務建議精華
選擇決策框架：
- 簡單應用 + 資源受限 → Bare Metal
- 複雜應用 + 豐富功能 → Zephyr RTOS
- 現有程式碼 + 遷移需求 → 優先考慮 Bare Metal
- 新專案 + 未來擴展 → 建議使用 Zephyr
成功要素：
- 深入理解應用需求：不要被表面的技術特性迷惑
- 基於數據做決策：參考實測性能而非主觀印象
- 考慮長期發展：技術選擇要配合產品路線圖
- 團隊技能匹配：選擇符合團隊經驗的技術路線
未來展望
Nordic 這次推出 Bare Metal 選項，展現了成熟技術公司對市場需求的敏銳洞察。在 RTOS 成為主流趨勢的今天，仍然為 bare metal 開發保留一席之地，體現了技術多元化的價值。
對於嵌入式開發者而言，這意味著更多的選擇自由，也意味著更高的技術判斷要求。關鍵在於理解不同方案的本質差異，結合具體應用場景做出明智選擇。
技術沒有絕對的優劣，只有適合與否。Nordic NRF Connect SDK Bare Metal 選項為我們提供了一個很好的範例：如何在技術進步和開發者需求之間找到平衡點。
無論最終選擇哪種技術路線，持續學習和保持開放心態都是開發者成長的關鍵。畢竟，技術工具會改變，但解決問題的思維方式和對品質的追求永遠不會過時。
這篇文章基於 Nordic Semiconductor 官方 webinar 內容以及多方技術資料整理而成。所有性能數據來自官方測試報告，建議讀者在實際專案中進行驗證。
相關資源連結：
本文最初發布於 HackMD @BASHCAT。
圖一
注意 必須出現(.venv)才是在python的venv下面,才繼續進行後面步驟
找到我們需要的板子
可以找到{rpi_pico}這個資料夾
今天的主角pico將
將zephyr.uf2拖曳到pico裡面,板子自已就開始閃阿閃
可以找到main.c文件,沒錯,程式碼就只有簡簡單單的這份!
將秒數從1000->100
熱門的ST,Nordic,ESP32也是在其中的喔
今天如果要把blinky轉換到ESP32上運行呢?
west build -b <改為ESP32或是Nordci的板子>
或是指定輸出的目錄即可.
透過nRFConnect的Programmer燒寫hex
這下連nrfConnect都不用開起來了
