Repository navigation
feat(companion): move chip features behind MainBoard - #28
Merged
Merged
Conversation
The device MAC, the bootloader reboot into download mode, the SNMP memory figures and the ota status progress called ESP32 APIs straight from MyMesh.cpp and CompanionSNMP.cpp, each behind its own chip #if. Every new chip family found a guard someone missed: #14 (nRF52), #17 (classic ESP32) and #22 (C6) each fixed a build broken that way. MainBoard gains getDeviceMac, canRebootToBootloader/rebootToBootloader, getMemStats and getHttpOtaProgress, with defaults that report "not available". ESP32Board implements them, and the S2/S3/C3-only force-download register write now lives there. NRF52Board reports the BLE address from FICR. The companion code just asks the board. Replies are unchanged except: bootloader on non-ESP32 boards says "not supported on this chip" (was "ESP32-only"), and mac on nRF52 shows the BLE address instead of n/a.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Four new
mesh::MainBoardvirtuals. Each default reports "not available":getDeviceMac(kind, mac[6])esp_read_mac(Wi-Fi STA, BT)canRebootToBootloader()/rebootToBootloader()getMemStats(MemStats&)ESP.*+heap_caps_*getHttpOtaProgress(pct, line)The callers change to match:
MyMesh.cpp:mac,get mac/wifi.mac/ble.mac,bootloader/dfuandota statuscall the board. The ESP32 include block,MESHCOMOD_HAS_FORCE_DOWNLOADand four chip#ifblocks are gone.CompanionSNMP.cpp: the.4.xmemory OIDs readboard.getMemStats(), and the file no longer includesesp_heap_caps.h. Its Wi-Fi calls stay, because the agent is Wi-Fi-only by design.macrow and changelog entry.Why
Candidate 5 of the architecture review. Companion features called the chip directly, so every new chip family hit a guard someone had missed:
heap_capsand the OTA globals.The fork had already put
checkManifestOtaonMainBoard. This uses the same seam for the rest. The chip-specific guards now live in one file per platform, and app code gets a working default on any new board.How it was tested
DISABLE_DEBUG=1 build.sh build-firmware, all of which build with no new warnings in the touched files:heltec_v4_companion_radio_usb_tcp(S3, SNMP, manifest OTA)Heltec_T190_companion_radio_usb_tcp(S3 withPIN_TFT_LEDA_CTL)Heltec_v2_companion_radio_ble(classic ESP32)M5Stack_Unit_C6L_companion_radio_ble(C6)WioTrackerL1_companion_radio_ble(nRF52)Other checks:
ESP32Board::rebootToBootloader()is 0x36 bytes andcanRebootToBootloader()returns true. So the force-download path still compiles where it did before, not the "unsupported" stub.pio test -e native: 94 of 94 pass.mac,bootloader(should enter download mode and darken the screen as before),ota status, and an SNMP walk of.4. On an nRF52 board, check thatmacmatches the address the phone sees.Firmware or build impact
bootloaderon non-ESP32 boards now repliesnot supported on this chip(wasESP32-only).macon nRF52 now shows the BLE address instead ofn/a.MainBoardis a MeshCore header. The new methods have default bodies, so other boards and upstream code are unaffected.Left as is: the PSRAM allocator in the backup import (
#if defined(ESP32)aroundheap_caps_malloc), and the Wi-Fi and multi-transport guards in MyMesh. Those are about which transports exist, not about the chip.