Add multiple configuration options for a minimized build (GPS,WiFi,BT,…,MQTT,Screen)#3469
Conversation
|
@jimwhitelaw out of pure curiosity, what is your use case for shedding many of the peripherals for a minimized build? I know we're definitely looking at it as a way to easily cut down on things included in lower resource platforms like STM32. |
|
@thebentern My project using MT is a remote flag signalling system for motorsports. A network of nodes placed around a racetrack connected to large LED panels that display electronic “flags” to racers. The motivation to minimize is two-fold: 1) to keep the system as closed as possible to prevent any outside intervention with the system (can’t hack WiFi or BT if they aren’t available) and 2) to potentially reduce cpu utilization and flash space to allow for running other code. I have a working prototype using a custom module that can send and process signal messages and update individual LED panels on a small network of 5 nodes. Configuration is done via serial and uploading pre-built config files for each node. All the nodes will be stationary at known locations so no need for GPS. I don’t know much about STM32 development currently, but I’m happy to contribute what I can. With all that being said, since I started working with the project, I’ve become interested in the comms side and will be setting up a couple “permanent” nodes on the MT network and experimenting with that too. |
…,MQTT,Screen). (meshtastic#3469) Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
This change follows up on the work to exclude modules and webserver from a minimized build. It provides options to exclude Wifi, Bluetooth, GPS, Screen, and MQTT from hardware that would otherwise support those options. The options can be enabled individually or globally with -DMESHTASTIC_MINIMIZE_BUILD. Tested for unchanged mesh/messaging behaviour on TBeam and Lora32 v2.1-1.6 using CLI test and with other nodes sending messages through the system. I'm unable to test with other hardware currently.