Merge branch 'fz-dev' into dev

This commit is contained in:
MX
2022-12-28 21:01:36 +03:00
21 changed files with 276 additions and 139 deletions
+34 -32
View File
@@ -1,63 +1,65 @@
# Flipper Application Manifests (.fam)
All components of Flipper Zero firmware — services, user applications, system settings — are developed independently. Each component has a build system manifest file, named `application.fam`, which defines basic properties of that component and its relations to other parts of the system.
All components of Flipper Zero firmware — services, user applications, and system settings — are developed independently. Each component has a build system manifest file, named `application.fam`, which defines the basic properties of that component and its relations to other parts of the system.
When building firmware, **`fbt`** collects all application manifests and processes their dependencies. Then it builds only those components that are referenced in the current build configuration. See [fbt docs](./fbt.md#firmware-application-set) for details on build configurations.
When building firmware, **`fbt`** collects all application manifests and processes their dependencies. Then it builds only those components referenced in the current build configuration. See [fbt docs](./fbt.md#firmware-application-set) for details on build configurations.
## Application definition
Properties of a firmware component are declared in a form of a Python code snippet, forming a call to App() function with various parameters.
A firmware component's properties are declared in a Python code snippet, forming a call to App() function with various parameters.
Only 2 parameters are mandatory: ***appid*** and ***apptype***, others are optional and may only be meaningful for certain application types.
Only 2 parameters are mandatory: ***appid*** and ***apptype***; others are optional and may only be meaningful for certain application types.
### Parameters
* **appid**: string, application id within the build system. Used for specifying which applications to include in build configuration and to resolve dependencies and conflicts.
* **appid**: string, application id within the build system. Used to specify which applications to include in the build configuration and resolve dependencies and conflicts.
* **apptype**: member of FlipperAppType.* enumeration. Valid values are:
| Enum member | Firmware component type |
|--------------|--------------------------|
| SERVICE | System service, created at early startup |
| SYSTEM | Application not being shown in any menus. Can be started by other apps or from CLI |
| APP | Regular application for main menu |
| PLUGIN | Application to be built as a part of firmware an to be placed in Plugins menu |
| SYSTEM | Application is not being shown in any menus. It can be started by other apps or from CLI |
| APP | Regular application for the main menu |
| PLUGIN | Application to be built as a part of the firmware and to be placed in the Plugins menu |
| DEBUG | Application only visible in Debug menu with debug mode enabled |
| ARCHIVE | One and only Archive app |
| SETTINGS | Application to be placed in System settings menu |
| SETTINGS | Application to be placed in the system settings menu |
| STARTUP | Callback function to run at system startup. Does not define a separate app |
| EXTERNAL | Application to be built as .fap plugin |
| METAPACKAGE | Does not define any code to be run, used for declaring dependencies and application bundles |
* **name**: Name that is displayed in menus.
* **entry_point**: C function to be used as application's entry point. Note that C++ function names are mangled, so you need to wrap them in `extern "C"` in order to use them as entry points.
* **entry_point**: C function to be used as the application's entry point. Note that C++ function names are mangled, so you need to wrap them in `extern "C"` to use them as entry points.
* **flags**: Internal flags for system apps. Do not use.
* **cdefines**: C preprocessor definitions to declare globally for other apps when current application is included in active build configuration.
* **requires**: List of application IDs to also include in build configuration, when current application is referenced in list of applications to build.
* **conflicts**: List of application IDs that current application conflicts with. If any of them is found in constructed application list, **`fbt`** will abort firmware build process.
* **cdefines**: C preprocessor definitions to declare globally for other apps when the current application is included in the active build configuration.
* **requires**: List of application IDs to include in the build configuration when the current application is referenced in the list of applications to build.
* **conflicts**: List of application IDs that the current application conflicts with. If any of them is found in the constructed application list, **`fbt`** will abort the firmware build process.
* **provides**: Functionally identical to ***requires*** field.
* **stack_size**: Stack size, in bytes, to allocate for application on its startup. Note that allocating a stack that is too small for an app to run will cause system crash due to stack overflow, and allocating too much stack space will reduce usable heap memory size for apps to process data. *Note: you can use `ps` and `free` CLI commands to profile your app's memory usage.*
* **icon**: Animated icon name from built-in assets to be used when building app as a part of firmware.
* **order**: Order of an application within its group when sorting entries in it. The lower the order is, the closer to the start of the list the item is placed. *Used for ordering startup hooks and menu entries.*
* **stack_size**: Stack size, in bytes, to allocate for application on its startup. Note that allocating a stack too small for an app to run will cause a system crash due to stack overflow, and allocating too much stack space will reduce usable heap memory size for apps to process data. *Note: you can use `ps`, and `free` CLI commands to profile your app's memory usage.*
* **icon**: Animated icon name from built-in assets to be used when building the app as a part of the firmware.
* **order**: Order of an application within its group when sorting entries in it. The lower the order is, the closer to the start of the list the item is placed. *Used for ordering startup hooks and menu entries.*
* **sdk_headers**: List of C header files from this app's code to include in API definitions for external applications.
* **targets**: list of strings, target names, which this application is compatible with. If not specified, application is built for all targets. Default value is `["all"]`.
* **targets**: list of strings, target names, which this application is compatible with. If not specified, the application is built for all targets. The default value is `["all"]`.
#### Parameters for external applications
The following parameters are used only for [FAPs](./AppsOnSDCard.md):
* **sources**: list of strings, file name masks, used for gathering sources within app folder. Default value of `["*.c*"]` includes C and C++ source files. Application cannot use `"lib"` folder for their own source code, as it is reserved for **fap_private_libs**.
* **fap_version**: tuple, 2 numbers in form of (x,y): application version to be embedded within .fap file. Default value is (0,1), meaning version "0.1".
* **sources**: list of strings, file name masks used for gathering sources within the app folder. The default value of `["*.c*"]` includes C and C++ source files. Applications cannot use the `"lib"` folder for their own source code, as it is reserved for **fap_private_libs**.
* **fap_version**: tuple, 2 numbers in the form of (x,y): application version to be embedded within .fap file. The default value is (0,1), meaning version "0.1".
* **fap_icon**: name of a .png file, 1-bit color depth, 10x10px, to be embedded within .fap file.
* **fap_libs**: list of extra libraries to link application against. Provides access to extra functions that are not exported as a part of main firmware at expense of increased .fap file size and RAM consumption.
* **fap_category**: string, may be empty. App subcategory, also works as path of FAP within apps folder in the file system.
* **fap_libs**: list of extra libraries to link the application against. Provides access to extra functions that are not exported as a part of main firmware at the expense of increased .fap file size and RAM consumption.
* **fap_category**: string, may be empty. App subcategory, also determines the path of the FAP within apps folder in the file system.
* **fap_description**: string, may be empty. Short application description.
* **fap_author**: string, may be empty. Application's author.
* **fap_weburl**: string, may be empty. Application's homepage.
* **fap_icon_assets**: string. If present, defines a folder name to be used for gathering image assets for this application. These images will be preprocessed and built alongside the application. See [FAP assets](./AppsOnSDCard.md#fap-assets) for details.
* **fap_icon_assets**: string. If present defines a folder name to be used for gathering image assets for this application. These images will be preprocessed and built alongside the application. See [FAP assets](./AppsOnSDCard.md#fap-assets) for details.
* **fap_extbuild**: provides support for parts of application sources to be built by external tools. Contains a list of `ExtFile(path="file name", command="shell command")` definitions. **`fbt`** will run the specified command for each file in the list.
Note that commands are executed at the firmware root folder's root, and all intermediate files must be placed in a application's temporary build folder. For that, you can use pattern expansion by **`fbt`**: `${FAP_WORK_DIR}` will be replaced with the path to the application's temporary build folder, and `${FAP_SRC_DIR}` will be replaced with the path to the application's source folder. You can also use other variables defined internally by **`fbt`**.
Note that commands are executed at the firmware root folder's root, and all intermediate files must be placed in an application's temporary build folder. For that, you can use pattern expansion by **`fbt`**: `${FAP_WORK_DIR}` will be replaced with the path to the application's temporary build folder, and `${FAP_SRC_DIR}` will be replaced with the path to the application's source folder. You can also use other variables defined internally by **`fbt`**.
Example for building an app from Rust sources:
@@ -71,16 +73,16 @@ Example for building an app from Rust sources:
),
```
* **fap_private_libs**: list of additional libraries that are distributed as sources alongside the application. These libraries will be built as a part of the application build process.
* **fap_private_libs**: a list of additional libraries distributed as sources alongside the application. These libraries will be built as a part of the application build process.
Library sources must be placed in a subfolder of "`lib`" folder within the application's source folder.
Each library is defined as a call to `Lib()` function, accepting the following parameters:
- **name**: name of library's folder. Required.
- **fap_include_paths**: list of library's relative paths to add to parent fap's include path list. Default value is `["."]` meaning library's source root.
- **sources**: list of filename masks to be used for gathering include files for this library. Paths are relative to library's source root. Default value is `["*.c*"]`.
- **cflags**: list of additional compiler flags to be used for building this library. Default value is `[]`.
- **cdefines**: list of additional preprocessor definitions to be used for building this library. Default value is `[]`.
- **cincludes**: list of additional include paths to be used for building this library. Paths are relative to application's root. Can be used for providing external search paths for this library's code - for configuration headers. Default value is `[]`.
- **fap_include_paths**: list of library's relative paths to add to parent fap's include path list. The default value is `["."]` meaning the library's source root.
- **sources**: list of filename masks to be used for gathering include files for this library. Paths are relative to the library's source root. The default value is `["*.c*"]`.
- **cflags**: list of additional compiler flags to be used for building this library. The default value is `[]`.
- **cdefines**: list of additional preprocessor definitions to be used for building this library. The default value is `[]`.
- **cincludes**: list of additional include paths to be used for building this library. Paths are relative to the application's root. This can be used for providing external search paths for this library's code - for configuration headers. The default value is `[]`.
Example for building an app with a private library:
@@ -103,10 +105,10 @@ Example for building an app with a private library:
],
```
For that snippet, **`fbt`** will build 2 libraries: one from sources in `lib/mbedtls` folder, and another from sources in `lib/loclass` folder. For `mbedtls` library, **`fbt`** will add `lib/mbedtls/include` to the list of include paths for the application and compile only the files specified in `sources` list. Additionally, **`fbt`** will enable `MBEDTLS_ERROR_C` preprocessor definition for `mbedtls` sources.
For `loclass` library, **`fbt`** will add `lib/loclass` to the list of include paths for the application and build all sources in that folder. Also **`fbt`** will disable treating compiler warnings as errors for `loclass` library specifically - that can be useful when compiling large 3rd-party codebases.
For that snippet, **`fbt`** will build 2 libraries: one from sources in `lib/mbedtls` folder and another from sources in `lib/loclass` folder. For the `mbedtls` library, **`fbt`** will add `lib/mbedtls/include` to the list of include paths for the application and compile only the files specified in the `sources` list. Additionally, **`fbt`** will enable `MBEDTLS_ERROR_C` preprocessor definition for `mbedtls` sources.
For the `loclass` library, **`fbt`** will add `lib/loclass` to the list of the include paths for the application and build all sources in that folder. Also, **`fbt`** will disable treating compiler warnings as errors for the `loclass` library, which can be useful when compiling large 3rd-party codebases.
Both libraries will be linked into the application.
Both libraries will be linked with the application.
## .fam file contents
+1 -1
View File
@@ -37,7 +37,7 @@ With it, you can debug FAPs as if they were a part of main firmware — inspect
### Setting up debugging environment
Debugging support script looks up debugging information in latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
Debugging support script looks up debugging information in the latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
So, to debug FAPs, do the following:
1. Build firmware with `./fbt`
+26 -26
View File
@@ -1,6 +1,6 @@
# Key Combos
There are times when your flipper feels blue and doesn't respond to your commands.
There are times when your Flipper feels blue and doesn't respond to your commands.
In that case, you may find this guide useful.
@@ -12,10 +12,10 @@ In that case, you may find this guide useful.
- Press `LEFT` and `BACK` and hold for a couple of seconds
- Release `LEFT` and `BACK`
This combo performs hardware reset by pulling MCU reset line down.
This combo performs a hardware reset by pulling MCU reset line down.
Main components involved: Keys -> DD8(NC7SZ32M5X, OR-gate) -> DD1(STM32WB55, MCU)
There is 1 case when it's not working:
There is 1 case where it does not work:
- MCU debug block is active and holding reset line from inside.
@@ -25,32 +25,32 @@ There is 1 case when it's not working:
- Disconnect USB and any external power supplies
- Disconnect USB once again
- Make sure that you've disconnected USB and any external power supplies
- Press `BACK` and hold for 30 seconds (Only will work with USB Disconnected)
- Press `BACK` and hold for 30 seconds (Will only work with USB disconnected)
- If you have not disconnected USB, then disconnect USB and repeat previous step
- Release `BACK` key
This combo performs a reset by switching SYS power line off and then on.
Main components involved: Keys -> DD6(bq25896, charger)
There is 1 case when it's not working:
There is 1 case where it does not work:
- Power supply is connected to USB or 5V_ext
### Software DFU
- Press `LEFT` on boot to enter DFU with flipper boot-loader
- Press `LEFT` on boot to enter DFU with Flipper boot-loader
There is 1 case when it's not working:
There is 1 case where it does not work:
- Flipper Boot-loader is damaged or absent
- Flipper boot-loader is damaged or absent
### Hardware DFU
- Press `OK` on boot to enter DFU with ST boot-loader
There is 1 case when it's not working:
There is 1 case where it does not work:
- Option Bytes are damaged or set to ignore `OK` key
@@ -65,25 +65,25 @@ There is 1 case when it's not working:
- Device will enter DFU with indication (Blue LED + DFU Screen)
- Release `LEFT`
This combo performs hardware reset by pulling MCU reset line down.
Then `LEFT` key indicates to boot-loader that DFU mode is requested.
This combo performs a hardware reset by pulling MCU reset line down.
Then, `LEFT` key indicates to the boot-loader that DFU mode is requested.
There are 2 cases when it's not working:
There are 2 cases where it does not work:
- MCU debug block is active and holding reset line from inside
- Flipper Boot-loader is damaged or absent
- Flipper boot-loader is damaged or absent
### Hardware Reset + Hardware DFU
- Press `LEFT` and `BACK` and `OK` and hold for a couple of seconds
- Press `LEFT`, `BACK` and `OK` and hold for a couple of seconds
- Release `BACK` and `LEFT`
- Device will enter DFU without indication
This combo performs hardware reset by pulling MCU reset line down.
Then `OK` key forces MCU to load internal boot-loader.
This combo performs a hardware reset by pulling MCU reset line down.
Then, `OK` key forces MCU to load internal boot-loader.
There are 2 cases when it's not working:
There are 2 cases where it does not work:
- MCU debug block is active and holding reset line from inside
- Option Bytes are damaged or set to ignore `OK` key
@@ -96,15 +96,15 @@ There are 2 cases when it's not working:
- Release `BACK`
- Device will enter DFU with indication (Blue LED + DFU Screen)
- Release `LEFT`
- Plug USB
- Plug in USB
This combo performs reset by switching SYS power line off and then on.
Then `LEFT` key indicates to boot-loader that DFU mode requested.
This combo performs a reset by switching SYS power line off and then on.
Then, `LEFT` key indicates to boot-loader that DFU mode requested.
There are 2 cases when it's not working:
There are 2 cases where it does not work:
- Power supply is connected to USB or 5V_ext
- Flipper Boot-loader is damaged or absent
- Flipper boot-loader is damaged or absent
### Hardware Power Reset + Hardware DFU
@@ -115,10 +115,10 @@ There are 2 cases when it's not working:
- Device will enter DFU without indication
- Plug USB
This combo performs reset by switching SYS power line off and then on.
Then `OK` key forces MCU to load internal boot-loader.
This combo performs a reset by switching SYS power line off and then on.
Then, `OK` key forces MCU to load internal boot-loader.
There are 2 cases when it's not working:
There are 2 cases where it does not work:
- Power supply is connected to USB or 5V_ext
- Option Bytes are damaged or set to ignore `OK` key
@@ -131,4 +131,4 @@ If none of the described methods were useful:
- Disconnect the battery and connect again (Requires disassembly)
- Try to Flash device with ST-Link or other programmer that supports SWD
If you still here and your device is not working: it's not a software issue.
If you still are here and your device is not working: it's not a software issue.
@@ -1,5 +1,5 @@
# Command syntax
BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more fuctional keys.
BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more functional keys.
# Script file format
BadUsb app can execute only text scrips from .txt files, no compilation is required. Both `\n` and `\r\n` line endings are supported. Empty lines are allowed. You can use spaces ore tabs for line indentation.
# Command set
@@ -95,17 +95,17 @@ Note: a single parsed signal must be represented as an array of size 1.
| data | raw | uint32 | Ditto. |
#### Signal names
The signal names in an `.irtest` file folow a convention `<name><test_number>`, where the name is one of:
The signal names in an `.irtest` file follow a convention `<name><test_number>`, where the name is one of:
- decoder_input
- decoder_expected
- encoder_decoder_input,
and the number is a sequential integer: 1, 2, 3...etc, which produces names like `decoder_input1`, `encoder_decoder_input3`, and so on.
| Name | Type | Description |
| --------------------- | ------------ | ----------- |
| decoder_input | raw | A raw signal contaning the decoder input. Is also used as the expected encoder output. |
| Name | Type | Description |
| --------------------- | ------------ |-------------------------------------------------------------------------------------------------------|
| decoder_input | raw | A raw signal containing the decoder input. Is also used as the expected encoder output. |
| decoder_expected | parsed_array | An array of parsed signals containing the expected decoder output. Is also used as the encoder input. |
| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
See [Unit Tests](/documentation/UnitTests.md#infrared) for more info.
+1 -1
View File
@@ -68,7 +68,7 @@ This file format is used to store the UID, SAK and ATQA of a Mifare Ultralight/N
The "Signature" field contains the reply of the tag to the READ_SIG command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 31)
The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the responce of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the response of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
Other fields are the direct representation of the card's internal state, more on them can be found in the same datasheet.
@@ -197,7 +197,7 @@ For each key, a name and encryption method must be specified, according to comme
## SubGhz `setting_user` File
This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is be loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is being loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
### File Format