Commit Graph
4 Commits
Author SHA1 Message Date
James RichandClaude Opus 4.8 269b974e96 feat: populate MyNodeInfo.device_id on all platforms (#10995)
* feat: populate MyNodeInfo.device_id on all platforms

RP2040/RP2350 use the 64-bit pico unique board id, STM32WL the 96-bit
silicon UID, ESP32-S2 joins the existing OPTIONAL_UNIQUE_ID efuse branch,
and everything else (classic ESP32 in particular) falls back to a
deterministic factory-MAC-derived id, resolving the long-standing FIXME.
Portduino keeps the config-supplied id preferred and now uses the MAC
fallback when the config omits one.

No proto or persistence changes; the id is re-read from silicon each
boot and PhoneAPI still zeroes it for unauthenticated clients.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: declare zero_mac const to satisfy cppcheck

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: address review feedback on device_id derivation

Clear any disk-loaded device_id before the silicon derivation so a failed
read leaves it unset rather than stale (Copilot), and size the portduino
config copy with sizeof instead of a literal 16 (CodeRabbit).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor: extract device_id generation into per-arch getDeviceId()

Per review feedback on #10995: move the platform-specific
MyNodeInfo.device_id derivation out of the #if/#elif ladder in
NodeDB.cpp into a getDeviceId() interface (target_specific.h)
implemented per-architecture alongside each platform's getMacAddr():

  - esp32:     efuse OPTIONAL_UNIQUE_ID (C3/S2/S3/C6); classic ESP32 -> MAC
  - nrf52:     FICR DEVICEID + DEVICEADDR
  - nrf54l15:  FICR->INFO.DEVICEID + DEVICEADDR (NRF_FICR-guarded, MAC fallback)
  - rp2xx0:    pico_get_unique_board_id()
  - stm32wl:   HAL_GetUIDw0/1/2()
  - portduino: config-supplied id preferred, else MAC

The shared MAC-derived fallback moves to meshUtils as
getMacAddrDeviceId(). NodeDB.cpp now zero-inits the field and makes a
single getDeviceId() call, dropping ~65 lines of platform boilerplate
plus the esp_efuse/pico/stm32 includes that came with it. No behavior
change: device_id is still re-read from silicon each boot and never
persisted.

Builds green: native-macos, tbeam, heltec-v3, rak4631, rak11310, rak3172.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix: address review of device_id refactor

- getMacAddrDeviceId(): zero-init the mac[6] buffer. getMacAddr() can return
  without writing (e.g. Portduino with no MAC source), so the old uninitialized
  buffer let stack garbage pass the all-zeros guard and become device_id. The
  pre-refactor code relied on the zero-initialized static ourMacAddr; restore
  that guarantee.
- nrf54l15 getDeviceId(): drop the `#if defined(NRF_FICR)` guard and read FICR
  unconditionally (as the pre-refactor NodeDB code did). The guarded #else fell
  back to getMacAddr()'s hard-coded placeholder MAC, which would give every unit
  an identical device_id; a missing NRF_FICR should be a loud compile error.
- NodeDB.cpp: `#include "target_specific.h"` instead of hand-copied externs for
  getMacAddr/getDeviceId; retire the stale FIXME. Same for meshUtils.cpp (whose
  extern comment wrongly claimed the TU was Arduino-free).
- Delete the orphaned commented-out device_id hex-dump block in NodeDB.cpp.
- Trim/de-duplicate the getDeviceId contract comments (single-sourced in
  target_specific.h).

Builds green: native-macos, tbeam.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: trim device_id comments to the repo's 1-2 line guideline

Addresses CodeRabbit review nitpick on #10995: shorten the getDeviceId()
(target_specific.h), getMacAddrDeviceId() (meshUtils.h), device-id refresh
(NodeDB.cpp), and nrf54l15 getDeviceId comments to two lines each, per the
"one or two lines maximum" coding guideline. Comment-only; no behavior change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-13 16:28:25 -05:00
Ben Meadors 72050530f1 NRF52 bluetooth cleanup and fix (#3328)
* NRF52 bluetooth cleanup. Fixes BLE not returning after serial PhoneAPI connection

* Use new var name in esp32 arch
2024-03-03 13:56:55 -06:00
geeksville b8d39845cf portduino now links! 2020-09-06 09:24:08 -07:00
geeksville 93a06906cb begin splitting up source files, so we can have a tree of sources...
unique to each architecture.  For now, we have "esp32" and "bare"

esp32 is the old esp stuff

bare is an target suitable for emulation that doesn't require any
particular hardware to run (no bluetooth, no i2c devices, no spi devices)
2020-04-10 12:15:35 -07:00