mirror of
https://github.com/alexhopeoconnor/firmware.git
synced 2026-10-21 02:35:57 +10:00
5f198c44d7
* nrf52: drop BSEC2/BME68x from the three targets nearest the flash cap
nrf52_promicro_diy_tcxo has been failing the nrf52_warm_region guard on
develop since 2026-08-05 (image ends at 0xEA918, 2328 B past the 0xEA000
warm-store cap). rak4631 and rak_wismesh_repeater_mini are ~14 KiB clear
while the nrf52 fleet drifts ~2 KiB/day, so both are close behind.
lib_ignore bsec2 + BME68x Sensor library defeats BME680Sensor's
__has_include(<bsec2.h>) gate, recovering ~46 KiB on each:
nrf52_promicro_diy_tcxo 0xEA918 (FAILED) -> 0xDF1A8, 43.6 KiB clear
rak4631 0xE6550 -> 0xDADE8, 60.0 KiB clear
rak_wismesh_repeater_mini 0xE65AC -> 0xDAE64, 59.9 KiB clear
This costs BME680/BME688 support, i.e. RAK1906 on WisBlock. It is a
temporary measure until the environmental sensor roster is opt-in per
board rather than linked into every target.
rak_wismesh_pocket inherits from env:rak4631 but has ~37 KiB clear, so it
is explicitly held at the nrf52 default and keeps BME680. Both lib_ignore
lists extend ${nrf52_base.lib_ignore} so BluetoothOTA and lvgl stay
ignored.
* nrf52: give the RAK boards BME680 back, drop their Ethernet instead
Excluding BSEC2 on rak4631 cost BME680/BME688 support, i.e. the RAK1906
WisBlock module - a common peripheral on the most popular nrf52 board. The
Ethernet stack is the better thing to lose: RAK13800 W5100S users are served
by the dedicated env:rak4631_eth_gw build, which has its own variant.h and
~163 KB clear, so the general-purpose image was carrying a networking stack
for hardware almost none of its users have.
rak_wismesh_pocket already set HAS_ETHERNET 0 for the same reason, so this
follows an existing in-tree precedent rather than inventing one.
rak4631 0xE6578 -> 0xE0D08, 35.7 KB clear (-21.6 KB)
rak_wismesh_repeater_mini -> 0xE0D58, 35.7 KB clear
rak4631_eth_gw -> 0xC1050, 163 KB clear (unchanged)
rak4631_eth_gw_dbg -> 0xC1210, 163 KB clear
That also brings rak4631 back under its declared flash budget in
bin/ram_budgets.json (766,216 vs 786,000 bytes), which develop is currently
failing - size-budget-gate is what has been ejecting PRs from the merge queue.
mqtt/ is deliberately kept: src/mqtt/MQTT.cpp carries both the networked
client (gated on HAS_NETWORKING, now 0) and the phone client-proxy path, so
dropping the directory would have removed MQTT-over-phone as well.
nrf52_promicro_diy_tcxo keeps the BSEC2 exclusion from the previous commit.
It has no Ethernet to reclaim - nrf52_base already filters mesh/eth, mesh/api
and mesh/wifi, and HAS_ETHERNET defaults to 0 - so the sensor library is the
only lever there. It goes 0xEA918 (FAILED) -> 0xDF1C0, 43.6 KB clear.
env:rak4631_eth_gw_dbg now extends env:rak4631_eth_gw rather than env:rak4631:
it already used the gateway env's build_flags and lib_deps, and only that env
still compiles mesh/eth + mesh/api.
* Address CodeRabbit review comments on PR #11363
- Condense the HAS_ETHERNET comment in rak4631/variant.h to one line
- Clarify rak4631/platformio.ini src-filter comment: Ethernet-free,
not networking-free, since MQTT is retained
- Restore custom_meshtastic_* metadata on env:rak4631_eth_gw so
env:rak4631_eth_gw_dbg (which now extends it) doesn't lose the
hw_model/display metadata it previously inherited via env:rak4631
---------
Co-authored-by: Jason P <applewiz@mac.com>
Co-authored-by: Claude <noreply@anthropic.com>
80 lines
3.8 KiB
INI
80 lines
3.8 KiB
INI
; The very slick RAK wireless RAK 4631 / 4630 board - Unified firmware for 5005/19003, with or without OLED RAK 1921
|
|
[env:rak4631_eth_gw]
|
|
custom_meshtastic_hw_model = 9
|
|
custom_meshtastic_hw_model_slug = RAK4631
|
|
custom_meshtastic_architecture = nrf52840
|
|
custom_meshtastic_actively_supported = true
|
|
custom_meshtastic_support_level = 1
|
|
custom_meshtastic_display_name = RAK WisBlock 4631
|
|
custom_meshtastic_images = rak4631.svg, rak4631_case.svg
|
|
custom_meshtastic_tags = RAK
|
|
|
|
extends = nrf52840_base
|
|
board_level = release
|
|
board = wiscore_rak4631
|
|
build_flags = ${nrf52840_base.build_flags}
|
|
-I variants/nrf52840/rak4631_eth_gw
|
|
-D RAK_4631
|
|
-DHAS_UDP_MULTICAST=1
|
|
-DEINK_DISPLAY_MODEL=GxEPD2_213_BN
|
|
-DEINK_WIDTH=250
|
|
-DEINK_HEIGHT=122
|
|
-DMESHTASTIC_EXCLUDE_WIFI=1
|
|
-DMESHTASTIC_EXCLUDE_SCREEN=1
|
|
; -DMESHTASTIC_EXCLUDE_PKI=1
|
|
-DMESHTASTIC_EXCLUDE_POWERMON=1
|
|
; -DMESHTASTIC_EXCLUDE_TZ=1
|
|
-DMESHTASTIC_EXCLUDE_EXTERNALNOTIFICATION=1
|
|
-DMESHTASTIC_EXCLUDE_PAXCOUNTER=1
|
|
-DMESHTASTIC_EXCLUDE_REMOTEHARDWARE=1
|
|
-DMESHTASTIC_EXCLUDE_STOREFORWARD=1
|
|
-DMESHTASTIC_EXCLUDE_CANNEDMESSAGES=1
|
|
-DMESHTASTIC_EXCLUDE_WAYPOINT=1
|
|
build_src_filter = ${nrf52_base.build_src_filter} +<../variants/nrf52840/rak4631_eth_gw> +<mesh/eth/> +<mesh/api/> +<mqtt/> +<serialization/>
|
|
lib_deps =
|
|
${nrf52840_base.lib_deps}
|
|
${networking_base.lib_deps}
|
|
# renovate: datasource=custom.pio depName=Melopero RV3028 packageName=melopero/library/Melopero RV3028
|
|
melopero/Melopero RV3028@1.2.0
|
|
# renovate: datasource=github-tags depName=RAK13800-W5100S packageName=RAKWireless/RAK13800-W5100S
|
|
https://github.com/RAKWireless/RAK13800-W5100S/archive/1.0.3.zip
|
|
# renovate: datasource=custom.pio depName=RAK NCP5623 RGB LED packageName=rakwireless/library/RAKwireless NCP5623 RGB LED library
|
|
rakwireless/RAKwireless NCP5623 RGB LED library@1.0.3
|
|
# renovate: datasource=git-refs depName=RAK12034-BMX160 packageName=https://github.com/RAKWireless/RAK12034-BMX160 gitBranch=main
|
|
https://github.com/RAKWireless/RAK12034-BMX160/archive/dcead07ffa267d3c906e9ca4a1330ab989e957e2.zip
|
|
; If not set we will default to uploading over serial (first it forces bootloader entry by talking 1200bps to cdcacm)
|
|
; Note: as of 6/2013 the serial/bootloader based programming takes approximately 30 seconds
|
|
;upload_protocol = jlink
|
|
|
|
; Allows programming and debug via the RAK NanoDAP as the default debugger tool for the RAK4631 (it is only $10!)
|
|
; programming time is about the same as the bootloader version.
|
|
; For information on this see the meshtastic developers documentation for "Development on the NRF52"
|
|
; Extends env:rak4631_eth_gw, not env:rak4631: it already takes that env's build_flags and
|
|
; lib_deps, and only the gateway env still compiles mesh/eth + mesh/api.
|
|
[env:rak4631_eth_gw_dbg]
|
|
extends = env:rak4631_eth_gw
|
|
board_level = extra
|
|
|
|
; if the builtin version of openocd has a buggy version of semihosting, so use the external version
|
|
; platform_packages = platformio/tool-openocd@3.1200.0
|
|
|
|
build_flags =
|
|
${env:rak4631_eth_gw.build_flags}
|
|
-D USE_SEMIHOSTING
|
|
|
|
lib_deps =
|
|
${env:rak4631_eth_gw.lib_deps}
|
|
# TODO renovate
|
|
https://github.com/geeksville/Armduino-Semihosting/archive/35b538fdf208c3530c1434cd099a08e486672ee4.zip
|
|
|
|
; NOTE: the pyocd support for semihosting is buggy. So I switched to using the builtin platformio support for the stlink adapter which worked much better.
|
|
; However the built in openocd version in platformio has buggy support for TCP to semihosting.
|
|
;
|
|
; So I'm now trying the external openocd - but the openocd scripts for nrf52.cfg assume you are using a DAP adapter not an STLINK adapter.
|
|
; In theory I could change those scripts. But for now I'm trying going back to a DAP adapter but with the external openocd.
|
|
|
|
upload_protocol = stlink
|
|
; eventually use platformio/tool-pyocd@2.3600.0 instad
|
|
;upload_protocol = custom
|
|
;upload_command = pyocd flash -t nrf52840 $UPLOADERFLAGS $SOURCE
|