mirror of
https://github.com/meshtastic/firmware.git
synced 2026-09-16 00:10:11 -04:00
Thomas Göttgens
fa81b47ecb
* chore(deps): unify SensorLib on 0.4.1 and port the 0.4.x API changes The 19 SensorLib declarations were split across 0.3.1, 0.3.4 and 0.4.1. Pin all of them to 0.4.1 and fix the renovate datasource on ThinkNode-M9 (custom -> custom.pio). API changes in 0.4.x: - BMA423Sensor: the configAccelerometer/enableFeature/readIrqStatus surface is gone. SensorBMA423 now derives from SensorBMA4XX and dispatches tilt and tap through callbacks driven by update(). - BHI260APSensor: SensorRemap is a scoped enum in sensor/SensorDefs.hpp, and BoschSensorInfo members are protected, so read them through the accessors. - ExtensionIOXL9555 is renamed to IoExpanderXL9555 and the touch drivers moved under touch/. Point the includes at the current paths instead of the compatibility shims, which emit warnings on every build. Drop four lewisxhe/PCF8563_Library declarations. Nothing in the tree includes pcf8563.h; all RTC code goes through SensorLib. Drop the BMA423_INT block. No variant defines BMA423_INT (t-watch-s3 defines BMA4XX_INT), so it has never been compiled. Interrupt-driven wake on BMA423 is unimplemented rather than regressed by this change. Drop the T_WATCH_S3 branch in BHI260APSensor. That file requires HAS_BHI260AP, which T_WATCH_S3 does not define. SensorQMC6309.hpp does not exist in 0.3.4, so src/motion/QMC6309Sensor.cpp compiles for the first time on 0.4.1. * fix(motion): fail BMA423 init when the sensor rejects its configuration configAccelerometer, enableTiltDetector and enableTapDetector return false only on an I2C or driver-level failure, so treat them the way QMC6309Sensor treats configMagnetometer rather than initializing a sensor that never took its settings. Trim the t-watch-ultra placement comment to the two lines the coding guidelines allow. * refactor(rtc): drive the PCF clocks from PCF8xRTC instead of SensorLib SensorLib reaches its PCF8563 and PCF85063 drivers through a comm layer spanning Arduino, ESP-IDF, SPI and custom callbacks, which is a lot of code to link for four calls on an I2C RTC. Measured against develop, the boards that pull SensorLib grew about 10 KB moving from 0.3.4 to 0.4.1, while the nRF52 boards that do not pull it moved by 100-300 bytes. meshtastic/PCF8xRTC covers both parts in one class over Adafruit BusIO, which every board with a PCF part already links. Ten boards used SensorLib for nothing but the RTC and now drop it entirely; the remaining seven keep it for a BMA423, BHI260AP, QMI8658, XL9555 or touch controller and take the new driver for their RTC. Behaviour changes with it. Both parts latch an oscillator-stop flag on power loss, which the old path ignored: readFromRTC() now refuses a calendar the chip has marked invalid rather than feeding a plausible wrong date to BUILD_EPOCH, the result of begin() is checked, and a failed set is logged. The isBitSet workaround moves from configuration.h to MMC5983MASensor.h. It worked only because configuration.h pulled SensorLib.h in first, so the later include was a no-op and the macro stayed undefined; with the global include gone it has to sit where SensorLib and the SparkFun header actually meet. * fix(rtc): report a missing PCF chip separately from a stopped oscillator lostPower() reads a register, so it also returns true when the chip cannot be reached at all. Folding it into one warning meant a failed begin() reported "oscillator stopped", which is a different fault. * fix(t5s3): read GT911 touches through getTouchPoints 0.4.x dropped the default argument from getPoint(x, y, count) and marked it deprecated, so the two-argument call no longer resolves: variant.cpp:618:27: error: no matching function for call to 'TouchDrvGT911::getPoint(int16_t*, int16_t*)' Use getTouchPoints(), which is what the deprecation points at, rather than passing the count to a call that is on its way out.
Meshtastic Firmware
Overview
This repository contains the official device firmware for Meshtastic, an open-source LoRa mesh networking project designed for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware supports various hardware platforms, including ESP32, nRF52, RP2040/RP2350, and Linux-based devices.
Meshtastic enables text messaging, location sharing, and telemetry over a decentralized mesh network, making it ideal for outdoor adventures, emergency preparedness, and remote operations.
Get Started
- 🔧 Building Instructions - Learn how to compile the firmware from source.
- ⚡ Flashing Instructions - Install or update the firmware on your device.
Join our community and help improve Meshtastic! 🚀
Stats
