Mykhailo Shevchuk
7f76ec441f
Sub-GHz is the only main app still built into the firmware image, so everything in it costs internal flash permanently. The Frequency Analyzer is its only feature owning a view, a worker thread and a scene outright, so it moves to applications/main/subghz_frequency_analyzer/ and builds into subghz_frequency_analyzer.fal, mapped when its scene is entered and unmapped when it is left. The app keeps a thunk scene, a loader, and a private API table exporting the three app-internal functions the plugin calls. Release build: 181,684 -> 185,004 bytes of free flash (+3,320). The .fal costs 5,103 bytes of heap while the screen is open and nothing when it is closed. The sources had to leave applications/main/subghz/ entirely, because source exclusions in a manifest are silently ignored for built-in apps. The plugin also deploys to apps_data/subghz/plugins/features/ rather than the default apps_data/subghz/plugins/, which the radio device registry scans on every Sub-GHz start; a new optional fal_path in the app manifest allows that. The underlying loader behaviour is filed as #1130. Two ordering constraints are load-bearing and commented where they apply: the OK-long scene transition stays in the app, since leaving the scene unmaps the image the plugin would return into; and the plugin parks the dispatcher on an app-owned view before removing its own, since removing the current view latches an event loop stop and would otherwise quit Sub-GHz whenever the analyzer closed. Also drops the analyzer model's write-only is_ext_radio, and stops the analyzer view closing a notification record it never opened. Hardware validated: entering the analyzer maps the plugin (free heap -8,984 B, worker thread running at ~24% CPU), leaving it keeps Sub-GHz running and joins the worker, and seven enter/leave cycles show no heap drift.
About
This folder contains supplementary scripts that automates routine actions. Flashing scripts are based on cli version of STM32CubeProgrammer. You will need to add STM32_Programmer_CLI to your path to use them.
Flashing empty MCU/Flipper
Always flash your device in the following sequence:
- OTP (Only on empty MCU)
- Core1 and Core2 firmware flashing
- Option Bytes
Otp flashing
!!! Flashing incorrect OTP may permanently brick your device !!!
Normally OTP data generated and flashed at the factory.
In case if MCU was replaced you'll need correct OTP data to be able to use companion applications.
Use otp.py to generate and flash OTP data.
You will need exact main board revision to generate OTP data. It can be found on main PCB.
Also display type, region and etc...
!!! Flashing incorrect OTP may permanently brick your device !!!
Core1 and Core2 firmware flashing
Core2 goes first, then Core1. Never flash FUS or you will lose your job, girlfriend and keys in secure enclave.
Option Bytes
!!! Setting incorrect Option Bytes may brick your MCU !!!
Defaults are mostly OK, but there are couple things that we'd like to tune. Also, OB may be damaged, so we've made couple scripts to check and set option bytes.
!!! Setting incorrect Option Bytes may brick your MCU !!!
Checking option bytes:
ob.py check
Setting option bytes:
ob.py set
Assets delivery
Build the firmware and run in the root folder of the repo:
python scripts/storage.py -p <flipper_cli_port> send build/latest/resources /ext
Slideshow creation
Put fullscreen slideshow frames in .png format into assets/slideshow/my_show folder, named frame_xx.png, where xx is zero-padded frame number, starting with #0.
Then run
python scripts/slideshow.py -i assets/slideshow/my_show/ -o assets/slideshow/my_show/.slideshow
Upload generated .slideshow file to Flipper's internal storage and restart it.