mirror of
https://github.com/DarkFlippers/unleashed-firmware
synced 2024-09-20 06:31:55 +00:00
Merge branch 'ofw_dev' into dev p1
This commit is contained in:
MX
parent
4e7f25a539
commit
58cd56a439
73 changed files with 958 additions and 229 deletions
3
.gitmodules
vendored
3
.gitmodules
vendored
|
|
@ -42,3 +42,6 @@
|
|||
path = applications/main/subghz_remote
|
||||
url = https://github.com/DarkFlippers/SubGHz_Remote.git
|
||||
branch = ufw_main_app
|
||||
[submodule "documentation/doxygen/doxygen-awesome-css"]
|
||||
path = documentation/doxygen/doxygen-awesome-css
|
||||
url = https://github.com/jothepro/doxygen-awesome-css.git
|
||||
|
|
|
|||
2
.vscode/ReadMe.md
vendored
2
.vscode/ReadMe.md
vendored
|
|
@ -1,4 +1,4 @@
|
|||
# Visual Studio Code workspace for Flipper Zero
|
||||
# Visual Studio Code workspace for Flipper Zero {#vscode}
|
||||
|
||||
## Setup
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
/**
|
||||
* @file furi_hal_subghz.h
|
||||
* SubGhz HAL API
|
||||
* @file cc1101_ext.h
|
||||
* @brief External CC1101 transceiver access API.
|
||||
*/
|
||||
|
||||
#pragma once
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
# Apps Assets folder Example
|
||||
# Apps Assets folder Example {#example_app_assets}
|
||||
|
||||
This example shows how to use the Apps Assets folder to store data that is not part of the application itself, but is required for its operation, and that data is provided with the application.
|
||||
|
||||
## Source code
|
||||
|
||||
Source code for this example can be found [here](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/examples/example_apps_assets).
|
||||
|
||||
## What is the Apps Assets Folder?
|
||||
|
||||
The **Apps Assets** folder is a folder where external applications unpack their assets.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
/**
|
||||
* @file example_apps_assets.c
|
||||
* @brief Application assets example.
|
||||
*/
|
||||
#include <furi.h>
|
||||
#include <storage/storage.h>
|
||||
#include <toolbox/stream/stream.h>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
# Apps Data folder Example
|
||||
# Apps Data folder Example {#example_app_data}
|
||||
|
||||
This example demonstrates how to utilize the Apps Data folder to store data that is not part of the app itself, such as user data, configuration files, and so forth.
|
||||
|
||||
## Source code
|
||||
|
||||
Source code for this example can be found [here](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/examples/example_apps_data).
|
||||
|
||||
## What is the Apps Data Folder?
|
||||
|
||||
The **Apps Data** folder is a folder used to store data for external apps that are not part of the main firmware.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
/**
|
||||
* @file example_apps_data.c
|
||||
* @brief Application data example.
|
||||
*/
|
||||
#include <furi.h>
|
||||
#include <storage/storage.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
/**
|
||||
* @file ble_beacon_app.h
|
||||
* @brief BLE beacon example.
|
||||
*/
|
||||
#pragma once
|
||||
|
||||
#include "extra_beacon.h"
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
/**
|
||||
* @file example_custom_font.c
|
||||
* @brief Custom font example.
|
||||
*/
|
||||
#include <furi.h>
|
||||
#include <furi_hal.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,21 @@
|
|||
# Application icons
|
||||
# Application icons {#example_app_images}
|
||||
|
||||
## Source code
|
||||
|
||||
Source code for this example can be found [here](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/examples/example_images).
|
||||
|
||||
## General principle
|
||||
|
||||
To use icons, do the following:
|
||||
* add a line to the application manifest: `fap_icon_assets="folder"`, where `folder` points to the folder where your icons are located
|
||||
* add `#include "application_id_icons.h"` to the application code, where `application_id` is the appid from the manifest
|
||||
* every icon in the folder will be available as a `I_icon_name` variable, where `icon_name` is the name of the icon file without the extension
|
||||
|
||||
* Add a line to the application manifest: `fap_icon_assets="folder"`, where `folder` points to the folder where your icons are located
|
||||
* Add `#include "application_id_icons.h"` to the application code, where `application_id` is the appid from the manifest
|
||||
* Every icon in the folder will be available as a `I_icon_name` variable, where `icon_name` is the name of the icon file without the extension
|
||||
|
||||
## Example
|
||||
|
||||
We have an application with the following manifest:
|
||||
|
||||
```
|
||||
App(
|
||||
appid="example_images",
|
||||
|
|
@ -17,6 +27,7 @@ App(
|
|||
So the icons are in the `images` folder and will be available in the generated `example_images_icons.h` file.
|
||||
|
||||
The example code is located in `example_images_main.c` and contains the following line:
|
||||
|
||||
```
|
||||
#include "example_images_icons.h"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
/**
|
||||
* @file example_images.c
|
||||
* @brief Custom images example.
|
||||
*/
|
||||
#include <furi.h>
|
||||
#include <furi_hal.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
/*
|
||||
* An example of a plugin host application.
|
||||
/**
|
||||
* @file example_plugins.c
|
||||
* @brief Plugin host application example.
|
||||
*
|
||||
* Loads a single plugin and calls its methods.
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
/*
|
||||
* An example of an advanced plugin host application.
|
||||
/**
|
||||
* @file example_plugins_multi.c
|
||||
* @brief Advanced plugin host application example.
|
||||
*
|
||||
* It uses PluginManager to load all plugins from a directory
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,9 @@
|
|||
/* A simple plugin implementing example_plugins application's plugin interface */
|
||||
/**
|
||||
* @file plugin1.c
|
||||
* @brief Plugin example 1.
|
||||
*
|
||||
* A simple plugin implementing example_plugins application's plugin interface
|
||||
*/
|
||||
|
||||
#include "plugin_interface.h"
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,9 @@
|
|||
/* Second plugin implementing example_plugins application's plugin interface */
|
||||
/**
|
||||
* @file plugin2.c
|
||||
* @brief Plugin example 2.
|
||||
*
|
||||
* Second plugin implementing example_plugins application's plugin interface
|
||||
*/
|
||||
|
||||
#include "plugin_interface.h"
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
/**
|
||||
* @file plugin_interface.h
|
||||
* @brief Example plugin interface.
|
||||
*
|
||||
* Common interface between a plugin and host application
|
||||
*/
|
||||
#pragma once
|
||||
|
||||
/* Common interface between a plugin and host application */
|
||||
|
||||
#define PLUGIN_APP_ID "example_plugins"
|
||||
#define PLUGIN_API_VERSION 1
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,12 @@
|
|||
#pragma once
|
||||
|
||||
/*
|
||||
/**
|
||||
* @file app_api.h
|
||||
* @brief Application API example.
|
||||
*
|
||||
* This file contains an API that is internally implemented by the application
|
||||
* It is also exposed to plugins to allow them to use the application's API.
|
||||
*/
|
||||
#pragma once
|
||||
|
||||
#include <stdint.h>
|
||||
|
||||
#ifdef __cplusplus
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
/*
|
||||
/**
|
||||
* @file plugin1.c
|
||||
* @brief Plugin example 1.
|
||||
*
|
||||
* This plugin uses both firmware's API interface and private application headers.
|
||||
* It can be loaded by a plugin manager that uses CompoundApiInterface,
|
||||
* which combines both interfaces.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
/*
|
||||
/**
|
||||
* @file plugin2.c
|
||||
* @brief Plugin example 2.
|
||||
*
|
||||
* This plugin uses both firmware's API interface and private application headers.
|
||||
* It can be loaded by a plugin manager that uses CompoundApiInterface,
|
||||
* which combines both interfaces.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
/**
|
||||
* @file plugin_interface.h
|
||||
* @brief Example plugin interface.
|
||||
*
|
||||
* Common interface between a plugin and host application
|
||||
*/
|
||||
#pragma once
|
||||
|
||||
/* Common interface between a plugin and host application */
|
||||
|
||||
#define PLUGIN_APP_ID "example_plugins_advanced"
|
||||
#define PLUGIN_API_VERSION 1
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,14 @@
|
|||
# 1-Wire Thermometer
|
||||
# 1-Wire Thermometer {#example_thermo}
|
||||
|
||||
This example application demonstrates the use of the 1-Wire library with a DS18B20 thermometer.
|
||||
It also covers basic GUI, input handling, threads and localisation.
|
||||
|
||||
## Source code
|
||||
|
||||
Source code for this example can be found [here](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/examples/example_thermo).
|
||||
|
||||
## Electrical connections
|
||||
|
||||
Before launching the application, connect the sensor to Flipper's external GPIO according to the table below:
|
||||
| DS18B20 | Flipper |
|
||||
| :-----: | :-----: |
|
||||
|
|
@ -15,12 +21,14 @@ Before launching the application, connect the sensor to Flipper's external GPIO
|
|||
*NOTE 2*: For any other pin than 17, connect an external 4.7k pull-up resistor to pin 9.
|
||||
|
||||
## Launching the application
|
||||
|
||||
In order to launch this demo, follow the steps below:
|
||||
1. Make sure your Flipper has an SD card installed.
|
||||
2. Connect your Flipper to the computer via a USB cable.
|
||||
3. Run `./fbt launch APPSRC=example_thermo` in your terminal emulator of choice.
|
||||
|
||||
## Changing the data pin
|
||||
|
||||
It is possible to use other GPIO pin as a 1-Wire data pin. In order to change it, set the `THERMO_GPIO_PIN` macro to any of the options listed below:
|
||||
|
||||
```c
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
/*
|
||||
/**
|
||||
* @file example_thermo.c
|
||||
* @brief 1-Wire thermometer example.
|
||||
*
|
||||
* This file contains an example application that reads and displays
|
||||
* the temperature from a DS18B20 1-wire thermometer.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -73,14 +73,14 @@ static const MfClassicKeyPair troika_4k_keys[] = {
|
|||
{.a = 0x7A38E3511A38, .b = 0xAB16584C972A}, //30
|
||||
{.a = 0x7545DF809202, .b = 0xECF751084A80}, //31
|
||||
{.a = 0x5125974CD391, .b = 0xD3EAFB5DF46D}, //32
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //33
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //34
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //35
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //36
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //37
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //38
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //39
|
||||
{.a = 0xFFFFFFFFFFFF, .b = 0xFFFFFFFFFFFF}, //40
|
||||
{.a = 0x7A86AA203788, .b = 0xE41242278CA2}, //33
|
||||
{.a = 0xAFCEF64C9913, .b = 0x9DB96DCA4324}, //34
|
||||
{.a = 0x04EAA462F70B, .b = 0xAC17B93E2FAE}, //35
|
||||
{.a = 0xE734C210F27E, .b = 0x29BA8C3E9FDA}, //36
|
||||
{.a = 0xD5524F591EED, .b = 0x5DAF42861B4D}, //37
|
||||
{.a = 0xE4821A377B75, .b = 0xE8709E486465}, //38
|
||||
{.a = 0x518DC6EEA089, .b = 0x97C64AC98CA4}, //39
|
||||
{.a = 0xBB52F8CCE07F, .b = 0x6B6119752C70}, //40
|
||||
};
|
||||
|
||||
static bool troika_get_card_config(TroikaCardConfig* config, MfClassicType type) {
|
||||
|
|
|
|||
|
|
@ -248,7 +248,6 @@ void canvas_draw_bitmap(
|
|||
* @param x x coordinate
|
||||
* @param y y coordinate
|
||||
* @param icon Icon instance
|
||||
* @param flip IconFlip
|
||||
* @param rotation IconRotation
|
||||
*/
|
||||
void canvas_draw_icon_ex(
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ CanvasOrientation canvas_get_orientation(const Canvas* canvas);
|
|||
|
||||
/** Draw a u8g2 bitmap
|
||||
*
|
||||
* @param canvas Canvas instance
|
||||
* @param u8g2 u8g2 instance
|
||||
* @param x x coordinate
|
||||
* @param y y coordinate
|
||||
* @param width width
|
||||
|
|
|
|||
|
|
@ -188,8 +188,7 @@ void elements_bubble(Canvas* canvas, uint8_t x, uint8_t y, uint8_t width, uint8_
|
|||
* @param canvas Canvas instance
|
||||
* @param x left x coordinates
|
||||
* @param y top y coordinate
|
||||
* @param width bubble width
|
||||
* @param height bubble height
|
||||
* @param text text to display
|
||||
* @param horizontal horizontal aligning
|
||||
* @param vertical aligning
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -114,7 +114,6 @@ void dialog_ex_set_text(
|
|||
* @param x x position
|
||||
* @param y y position
|
||||
* @param icon The icon
|
||||
* @param name icon to be shown
|
||||
*/
|
||||
void dialog_ex_set_icon(DialogEx* dialog_ex, uint8_t x, uint8_t y, const Icon* icon);
|
||||
|
||||
|
|
|
|||
|
|
@ -108,7 +108,6 @@ bool scene_manager_handle_back_event(SceneManager* scene_manager);
|
|||
* Calls Scene event handler with Tick event parameter
|
||||
*
|
||||
* @param scene_manager SceneManager instance
|
||||
* @return true if event was consumed, false otherwise
|
||||
*/
|
||||
void scene_manager_handle_tick_event(SceneManager* scene_manager);
|
||||
|
||||
|
|
|
|||
|
|
@ -34,44 +34,44 @@ typedef enum {
|
|||
typedef struct View View;
|
||||
|
||||
/** View Draw callback
|
||||
* @param canvas, pointer to canvas
|
||||
* @param view_model, pointer to context
|
||||
* @param canvas pointer to canvas
|
||||
* @param model pointer to model
|
||||
* @warning called from GUI thread
|
||||
*/
|
||||
typedef void (*ViewDrawCallback)(Canvas* canvas, void* model);
|
||||
|
||||
/** View Input callback
|
||||
* @param event, pointer to input event data
|
||||
* @param context, pointer to context
|
||||
* @param event pointer to input event data
|
||||
* @param context pointer to context
|
||||
* @return true if event handled, false if event ignored
|
||||
* @warning called from GUI thread
|
||||
*/
|
||||
typedef bool (*ViewInputCallback)(InputEvent* event, void* context);
|
||||
|
||||
/** View Custom callback
|
||||
* @param event, number of custom event
|
||||
* @param context, pointer to context
|
||||
* @param event number of custom event
|
||||
* @param context pointer to context
|
||||
* @return true if event handled, false if event ignored
|
||||
*/
|
||||
typedef bool (*ViewCustomCallback)(uint32_t event, void* context);
|
||||
|
||||
/** View navigation callback
|
||||
* @param context, pointer to context
|
||||
* @param context pointer to context
|
||||
* @return next view id
|
||||
* @warning called from GUI thread
|
||||
*/
|
||||
typedef uint32_t (*ViewNavigationCallback)(void* context);
|
||||
|
||||
/** View callback
|
||||
* @param context, pointer to context
|
||||
* @param context pointer to context
|
||||
* @warning called from GUI thread
|
||||
*/
|
||||
typedef void (*ViewCallback)(void* context);
|
||||
|
||||
/** View Update Callback Called upon model change, need to be propagated to GUI
|
||||
* throw ViewPort update
|
||||
* @param view, pointer to view
|
||||
* @param context, pointer to context
|
||||
* @param view pointer to view
|
||||
* @param context pointer to context
|
||||
* @warning called from GUI thread
|
||||
*/
|
||||
typedef void (*ViewUpdateCallback)(View* view, void* context);
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ View* view_stack_get_view(ViewStack* view_stack);
|
|||
* Adds View on top of ViewStack.
|
||||
*
|
||||
* @param view_stack instance
|
||||
* @view view view to add
|
||||
* @param view view to add
|
||||
*/
|
||||
void view_stack_add_view(ViewStack* view_stack, View* view);
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ void view_stack_add_view(ViewStack* view_stack, View* view);
|
|||
* If no View to remove found - ignore.
|
||||
*
|
||||
* @param view_stack instance
|
||||
* @view view view to remove
|
||||
* @param view view to remove
|
||||
*/
|
||||
void view_stack_remove_view(ViewStack* view_stack, View* view);
|
||||
|
||||
|
|
|
|||
|
|
@ -339,7 +339,7 @@ FS_Error storage_common_merge(Storage* storage, const char* old_path, const char
|
|||
* @brief Create a directory.
|
||||
*
|
||||
* @param storage pointer to a storage API instance.
|
||||
* @param fs_path pointer to a zero-terminated string containing the directory path.
|
||||
* @param path pointer to a zero-terminated string containing the directory path.
|
||||
* @return FSE_OK if the directory has been successfully created, any other error code on failure.
|
||||
*/
|
||||
FS_Error storage_common_mkdir(Storage* storage, const char* path);
|
||||
|
|
@ -366,7 +366,6 @@ FS_Error storage_common_fs_info(
|
|||
*
|
||||
* @param storage pointer to a storage API instance.
|
||||
* @param path pointer to a zero-terminated string containing the path in question.
|
||||
* @return true if the path was successfully resolved, false otherwise.
|
||||
*/
|
||||
void storage_common_resolve_path_and_ensure_app_directory(Storage* storage, FuriString* path);
|
||||
|
||||
|
|
@ -526,7 +525,8 @@ FS_Error storage_int_backup(Storage* storage, const char* dstname);
|
|||
* @param converter pointer to a filename conversion function (may be NULL).
|
||||
* @return FSE_OK if the storage was successfully restored, any other error code on failure.
|
||||
*/
|
||||
FS_Error storage_int_restore(Storage* api, const char* dstname, Storage_name_converter converter);
|
||||
FS_Error
|
||||
storage_int_restore(Storage* storage, const char* dstname, Storage_name_converter converter);
|
||||
|
||||
/***************** Simplified Functions ******************/
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
#include "storage.h"
|
||||
#include <toolbox/tar/tar_archive.h>
|
||||
|
||||
FS_Error storage_int_backup(Storage* api, const char* dstname) {
|
||||
TarArchive* archive = tar_archive_alloc(api);
|
||||
FS_Error storage_int_backup(Storage* storage, const char* dstname) {
|
||||
TarArchive* archive = tar_archive_alloc(storage);
|
||||
bool success = tar_archive_open(archive, dstname, TAR_OPEN_MODE_WRITE) &&
|
||||
tar_archive_add_dir(archive, STORAGE_INT_PATH_PREFIX, "") &&
|
||||
tar_archive_finalize(archive);
|
||||
|
|
@ -11,8 +11,9 @@ FS_Error storage_int_backup(Storage* api, const char* dstname) {
|
|||
return success ? FSE_OK : FSE_INTERNAL;
|
||||
}
|
||||
|
||||
FS_Error storage_int_restore(Storage* api, const char* srcname, Storage_name_converter converter) {
|
||||
TarArchive* archive = tar_archive_alloc(api);
|
||||
FS_Error
|
||||
storage_int_restore(Storage* storage, const char* srcname, Storage_name_converter converter) {
|
||||
TarArchive* archive = tar_archive_alloc(storage);
|
||||
bool success = tar_archive_open(archive, srcname, TAR_OPEN_MODE_READ) &&
|
||||
tar_archive_unpack_to(archive, STORAGE_INT_PATH_PREFIX, converter);
|
||||
tar_archive_free(archive);
|
||||
|
|
|
|||
|
|
@ -1,17 +1,19 @@
|
|||
# Requirements
|
||||
# Firmware Assets {#firmware_assets}
|
||||
|
||||
## Requirements
|
||||
|
||||
- Python3
|
||||
- Python3 packages: Pillow & heatshrink2
|
||||
|
||||
# Compiling
|
||||
## Compiling
|
||||
|
||||
```bash
|
||||
./fbt icons proto dolphin_internal dolphin_blocking dolphin_ext resources
|
||||
```
|
||||
|
||||
# Asset naming rules
|
||||
## Asset naming rules
|
||||
|
||||
## Images and Animations
|
||||
### Images and Animations
|
||||
|
||||
`NAME_VARIANT_SIZE`
|
||||
|
||||
|
|
@ -22,16 +24,16 @@
|
|||
Image names will be automatically prefixed with `I_`, animation names with `A_`.
|
||||
Icons and Animations will be gathered into `icon.h` and `icon.c`.
|
||||
|
||||
## Dolphin and Games assets
|
||||
### Dolphin and Games assets
|
||||
|
||||
Rules are same as for Images and Animations plus assets are grouped by level and level prepends `NAME`.
|
||||
Good starting point: https://docs.unrealengine.com/4.27/en-US/ProductionPipelines/AssetNaming/
|
||||
|
||||
# Important notes
|
||||
## Important notes
|
||||
|
||||
Don't include assets that you are not using, compiler is not going to strip unused assets.
|
||||
|
||||
# Structure
|
||||
## Structure
|
||||
- `dolphin` - Dolphin game assets sources. Goes to `compiled` and `resources` folders in `build` directory.
|
||||
- `icons` - Icons sources. Goes to `compiled` folder in `build` directory.
|
||||
- `protobuf` - Protobuf sources. Goes to `compiled` folder in `build` directory.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dolphin assets
|
||||
# Dolphin assets {#dolphin_assets}
|
||||
|
||||
Dolphin assets are split into 3 parts:
|
||||
|
||||
|
|
|
|||
3
documentation/.gitignore
vendored
3
documentation/.gitignore
vendored
|
|
@ -1,2 +1 @@
|
|||
/html
|
||||
/latex
|
||||
/doxygen/build
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
# Flipper Application Manifests (.fam)
|
||||
# Flipper Application Manifests (.fam) {#app_manifests}
|
||||
|
||||
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 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) for details on build configurations.
|
||||
|
||||
## Application definition
|
||||
|
||||
A firmware component's properties are declared in a Python code snippet, forming a call to the `App()` function with various parameters.
|
||||
|
||||
Only two parameters are mandatory: **_appid_** and **_apptype_**. Others are optional and may only be meaningful for certain application types.
|
||||
Only two parameters are mandatory: **appid** and **apptype**. Others are optional and may only be meaningful for certain application types.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Only two parameters are mandatory: **_appid_** and **_apptype_**. Others are opt
|
|||
- **flags**: internal flags for system apps. Do not use.
|
||||
- **cdefines**: C preprocessor definitions to declare globally for other apps when the current application is included in the active build configuration. **For external applications**: specified definitions are used when building the application itself.
|
||||
- **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 with which the current application conflicts. If any of them is found in the constructed application list, **`fbt`** will abort the firmware build process.
|
||||
- **conflicts**: list of application IDs with which the current application conflicts. 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 an 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.
|
||||
|
|
@ -55,11 +55,11 @@ The following parameters are used only for [FAPs](./AppsOnSDCard.md):
|
|||
- **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, it 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.
|
||||
- **fap_icon_assets**: string. If present, it 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) 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.
|
||||
- **fal_embedded**: boolean, default `False`. Applies only to PLUGIN type. If `True`, the plugin will be embedded into host application's .fap file as a resource and extracted to `apps_assets/APPID` folder on its start. This allows plugins to be distributed as a part of the host application.
|
||||
|
||||
Note that commands are executed at the firmware root folder, 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`**.
|
||||
Note that commands are executed at the firmware root folder, 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:
|
||||
|
||||
|
|
@ -105,12 +105,12 @@ 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 the `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.
|
||||
For that snippet, `fbt` will build 2 libraries: one from sources in `lib/mbedtls` folder and another from sources in the `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 with the application.
|
||||
|
||||
## `.fam` file contents
|
||||
## .fam file contents
|
||||
|
||||
The `.fam` file contains one or more application definitions. For example, here's a part of `applications/service/bt/application.fam`:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# FAP (Flipper Application Package)
|
||||
# FAP (Flipper Application Package) {#apps_on_sd_card}
|
||||
|
||||
[fbt](./fbt.md) supports building applications as FAP files. FAPs are essentially `.elf` executables with extra metadata and resources bundled in.
|
||||
|
||||
|
|
@ -6,7 +6,7 @@ FAPs are built with the `faps` target. They can also be deployed to the `dist` f
|
|||
|
||||
FAPs do not depend on being run on a specific firmware version. Compatibility is determined by the FAP's metadata, which includes the required [API version](#api-versioning).
|
||||
|
||||
## How to set up an application to be built as a FAP
|
||||
## How to set up an application to be built as a FAP {#fap-howto}
|
||||
|
||||
FAPs are created and developed the same way as internal applications that are part of the firmware.
|
||||
|
||||
|
|
@ -21,15 +21,15 @@ To build your application as a FAP, create a folder with your app's source code
|
|||
|
||||
FAPs can include static and animated images as private assets. They will be automatically compiled alongside application sources and can be referenced the same way as assets from the main firmware.
|
||||
|
||||
To use that feature, put your images in a subfolder inside your application's folder, then reference that folder in your application's manifest in the `fap_icon_assets` field. See [Application Manifests](./AppManifests.md#application-definition) for more details.
|
||||
To use that feature, put your images in a subfolder inside your application's folder, then reference that folder in your application's manifest in the `fap_icon_assets` field. See [Application Manifests](AppManifests.md) for more details.
|
||||
|
||||
To use these assets in your application, put `#include "{APPID}_icons.h"` in your application's source code, where `{APPID}` is the `appid` value field from your application's manifest. Then you can use all icons from your application's assets the same way as if they were a part of `assets_icons.h` of the main firmware.
|
||||
|
||||
Images and animated icons should follow the same [naming convention](../assets/ReadMe.md#asset-naming-rules) as those from the main firmware.
|
||||
Images and animated icons should follow the same [naming convention](../assets/ReadMe.md) as those from the main firmware.
|
||||
|
||||
## Debugging FAPs
|
||||
|
||||
**`fbt`** includes a script for gdb-py to provide debugging support for FAPs, `debug/flipperapps.py`. It is loaded in default debugging configurations by **`fbt`** and stock VS Code configurations.
|
||||
`fbt` includes a script for gdb-py to provide debugging support for FAPs, `debug/flipperapps.py`. It is loaded in default debugging configurations by `fbt` and stock VS Code configurations.
|
||||
|
||||
With it, you can debug FAPs as if they were a part of the main firmware — inspect variables, set breakpoints, step through the code, etc.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ To debug FAPs, do the following:
|
|||
|
||||
1. Build firmware with `./fbt`
|
||||
2. Flash it with `./fbt flash`
|
||||
3. [Build your FAP](#how-to-set-up-an-application-to-be-built-as-a-fap) and run it on Flipper
|
||||
3. [Build your FAP](#fap-howto) and run it on Flipper
|
||||
|
||||
After that, you can attach with `./fbt debug` or VS Code and use all debug features.
|
||||
|
||||
|
|
@ -59,25 +59,25 @@ Applications are built for a specific API version. It is a part of the hardware
|
|||
|
||||
The App Loader allocates memory for the application and copies it to RAM, processing relocations and providing concrete addresses for imported symbols using the [symbol table](#symbol-table). Then it starts the application.
|
||||
|
||||
## API versioning
|
||||
## API versioning {#api-versioning}
|
||||
|
||||
Not all parts of firmware are available for external applications. A subset of available functions and variables is defined in the "api_symbols.csv" file, which is a part of the firmware target definition in the `targets/` directory.
|
||||
|
||||
**`fbt`** uses semantic versioning for the API. The major version is incremented when there are breaking changes in the API. The minor version is incremented when new features are added.
|
||||
`fbt` uses semantic versioning for the API. The major version is incremented when there are breaking changes in the API. The minor version is incremented when new features are added.
|
||||
|
||||
Breaking changes include:
|
||||
|
||||
- Removing a function or a global variable
|
||||
- Changing the signature of a function
|
||||
|
||||
API versioning is mostly automated by **`fbt`**. When rebuilding the firmware, **`fbt`** checks if there are any changes in the API exposed by headers gathered from `SDK_HEADERS`. If so, it stops the build, adjusts the API version, and asks the user to go through the changes in the `.csv` file. New entries are marked with a "`?`" mark, and the user is supposed to change the mark to "`+`" for the entry to be exposed for FAPs, or to "`-`" for it to be unavailable.
|
||||
API versioning is mostly automated by `fbt`. When rebuilding the firmware, `fbt` checks if there are any changes in the API exposed by headers gathered from `SDK_HEADERS`. If so, it stops the build, adjusts the API version, and asks the user to go through the changes in the `.csv` file. New entries are marked with a "`?`" mark, and the user is supposed to change the mark to "`+`" for the entry to be exposed for FAPs, or to "`-`" for it to be unavailable.
|
||||
|
||||
**`fbt`** will not allow building a firmware until all "`?`" entries are changed to "`+`" or "`-`".
|
||||
`fbt` will not allow building a firmware until all "`?`" entries are changed to "`+`" or "`-`".
|
||||
|
||||
**NB:** **`fbt`** automatically manages the API version. The only case where manually incrementing the major API version is allowed (and required) is when existing "`+`" entries are to be changed to "`-`".
|
||||
**NB:** `fbt` automatically manages the API version. The only case where manually incrementing the major API version is allowed (and required) is when existing "`+`" entries are to be changed to "`-`".
|
||||
|
||||
### Symbol table
|
||||
### Symbol table {#symbol-table}
|
||||
|
||||
The symbol table is a list of symbols exported by firmware and available for external applications. It is generated by **`fbt`** from the API symbols file and is used by the App Loader to resolve addresses of imported symbols. It is build as a part of the `fap_loader` application.
|
||||
The symbol table is a list of symbols exported by firmware and available for external applications. It is generated by `fbt` from the API symbols file and is used by the App Loader to resolve addresses of imported symbols. It is build as a part of the `fap_loader` application.
|
||||
|
||||
**`fbt`** also checks if all imported symbols are present in the symbol table. If there are any missing symbols, it will issue a warning listing them. The application won't be able to run on the device until all required symbols are provided in the symbol table.
|
||||
`fbt` also checks if all imported symbols are present in the symbol table. If there are any missing symbols, it will issue a warning listing them. The application won't be able to run on the device until all required symbols are provided in the symbol table.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Expansion Module Protocol - Draft
|
||||
# Expansion Module Protocol {#expansion_protocol}
|
||||
|
||||
## Terms and definitions
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Run time checks and forced system crash
|
||||
# Run time checks and forced system crash {#furi_check}
|
||||
|
||||
The best way to protect system integrity is to reduce amount cases that we must handle and crash the system as early as possible.
|
||||
For that purpose we have bunch of helpers located in Furi Core check.h.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Using FuriHalBus API
|
||||
# Using FuriHalBus API {#furi_hal_bus}
|
||||
|
||||
## Basic info
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Furi HAL Debugging
|
||||
# Furi HAL Debugging {#furi_hal_debugging}
|
||||
|
||||
Some Furi subsystems got additional debugging features that can be enabled by adding additional defines to firmware compilation.
|
||||
Usually they are used for low level tracing and profiling or signal redirection/duplication.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## What a Firmware Target is
|
||||
## What a Firmware Target is {#hardware_targets}
|
||||
|
||||
Flipper's firmware is modular and supports different hardware configurations in a common code base. It encapsulates hardware-specific differences in `furi_hal`, board initialization code, linker files, SDK data and other information in a _target definition_.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ A target definition file, `target.json`, is a JSON file that can contain the fol
|
|||
|
||||
Not all applications are available on different hardware targets.
|
||||
|
||||
* For applications built into the firmware, you have to specify a compatible application set using `FIRMWARE_APP_SET=...` fbt option. See [fbt docs](./fbt.md#firmware-application-set) for details on build configurations.
|
||||
* For applications built into the firmware, you have to specify a compatible application set using `FIRMWARE_APP_SET=...` fbt option. See [fbt docs](./fbt.md) for details on build configurations.
|
||||
|
||||
* For applications built as external .faps, you have to explicitly specify compatible targets in application's manifest, `application.fam`. For example, to limit application to a single target, add `targets=["f7"],` to the manifest. It won't be built for other targets.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Key Combos
|
||||
# Key Combos {#key_combos}
|
||||
|
||||
There are times when your Flipper feels blue and doesn't respond to any of your commands due to a software issue. This guide will help you solve this problem.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Reading RAW RFID data
|
||||
# Reading RAW RFID data {#lfrfid_raw}
|
||||
|
||||
Flipper Zero has the option to read RAW data from 125 kHz cards that allows you to record the card's data and save it, similar to how a dictaphone records sound.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,22 @@
|
|||
# Executing code from RAM
|
||||
# Flipper Zero OTA update process {#ota_updates}
|
||||
|
||||
## Executing code from RAM
|
||||
|
||||
In Flipper firmware, we have a special boot mode that loads a specially crafted system image into RAM and transfers control to it. System image executing in RAM has full write access to Flipper's entire flash memory — something that's not possible when running main code from the same flash.
|
||||
|
||||
We leverage that boot mode to perform OTA firmware updates, including operations on a radio stack running on the second MCU core.
|
||||
|
||||
# How does Flipper OTA work?
|
||||
## How does Flipper OTA work?
|
||||
|
||||
Installation of OTA updates goes through 3 stages:
|
||||
|
||||
## 1. Backing up internal storage (`/int`)
|
||||
### 1. Backing up internal storage (/int)
|
||||
|
||||
It is a special partition of Flipper's flash memory, taking up all available space not used by the firmware code. Newer versions of firmware may be of different size, and simply installing them would cause flash repartitioning and data loss.
|
||||
|
||||
So, before taking any action on the firmware, we back up the current configuration from `/int` into a plain tar archive on the SD card.
|
||||
|
||||
## 2. Performing device update
|
||||
### 2. Performing device update
|
||||
|
||||
The main firmware loads an updater image — a customized build of the main Flipper firmware — into RAM and runs it. Updater performs operations on system flash as described by an Update manifest file.
|
||||
|
||||
|
|
@ -24,17 +26,17 @@ Then, updater validates and corrects Option Bytes — a special memory region co
|
|||
|
||||
After that, updater loads a `.dfu` file with firmware to be flashed, checks its integrity using CRC32, writes it to system flash and validates written data.
|
||||
|
||||
## 3. Restoring internal storage and updating resources
|
||||
### 3. Restoring internal storage and updating resources
|
||||
|
||||
After performing operations on flash memory, the system restarts into newly flashed firmware. Then it performs restoration of previously backed up `/int` contents.
|
||||
|
||||
If the update package contains an additional resources archive, it is extracted onto the SD card.
|
||||
|
||||
# Update manifest
|
||||
## Update manifest
|
||||
|
||||
An update package comes with a manifest that contains a description of its contents. The manifest is in Flipper File Format — a simple text file, comprised of key-value pairs.
|
||||
|
||||
## Mandatory fields
|
||||
### Mandatory fields
|
||||
|
||||
An update manifest must contain the following keys in the given order:
|
||||
|
||||
|
|
@ -50,7 +52,7 @@ An update manifest must contain the following keys in the given order:
|
|||
|
||||
- **Loader CRC**: CRC32 of loader file. Note that it is represented in little-endian hex.
|
||||
|
||||
## Optional fields
|
||||
### Optional fields
|
||||
|
||||
Other fields may have empty values. In this case, updater skips all operations related to these values.
|
||||
|
||||
|
|
@ -66,7 +68,7 @@ Other fields may have empty values. In this case, updater skips all operations r
|
|||
|
||||
- **OB reference**, **OB mask**, **OB write mask**: reference values for validating and correcting option bytes.
|
||||
|
||||
# OTA update error codes
|
||||
## OTA update error codes
|
||||
|
||||
We designed the OTA update process to be as fail-safe as possible. We don't start any risky operations before validating all related pieces of data to ensure we don't leave the device in a partially updated, or bricked, state.
|
||||
|
||||
|
|
@ -102,21 +104,21 @@ Even if something goes wrong, updater allows you to retry failed operations and
|
|||
| Restoring LFS | **12** | **0-100** | FS read/write error |
|
||||
| Updating resources | **13** | **0-100** | SD card read/write error |
|
||||
|
||||
# Building update packages
|
||||
## Building update packages
|
||||
|
||||
## Full package
|
||||
### Full package
|
||||
|
||||
To build a full update package, including firmware, radio stack and resources for the SD card, run:
|
||||
|
||||
`./fbt COMPACT=1 DEBUG=0 updater_package`
|
||||
|
||||
## Minimal package
|
||||
### Minimal package
|
||||
|
||||
To build a minimal update package, including only firmware, run:
|
||||
|
||||
`./fbt COMPACT=1 DEBUG=0 updater_minpackage`
|
||||
|
||||
## Customizing update bundles
|
||||
### Customizing update bundles
|
||||
|
||||
Default update packages are built with Bluetooth Light stack.
|
||||
You can pick a different stack if your firmware version supports it, and build a bundle with it by passing the stack type and binary name to `fbt`:
|
||||
|
|
@ -127,7 +129,7 @@ Note that `COPRO_OB_DATA` must point to a valid file in the `scripts` folder con
|
|||
|
||||
In certain cases, you might have to confirm your intentions by adding `COPRO_DISCLAIMER=...` to the build command line.
|
||||
|
||||
## Building partial update packages
|
||||
### Building partial update packages
|
||||
|
||||
You can customize package contents by calling `scripts/update.py` directly.
|
||||
For example, to build a package only for installing BLE FULL stack:
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Unit tests
|
||||
# Unit tests {#unit_tests}
|
||||
|
||||
## Intro
|
||||
|
||||
Unit tests are special pieces of code that apply known inputs to the feature code and check the results to see if they are correct.
|
||||
They are crucial for writing robust, bug-free code.
|
||||
|
||||
Flipper Zero firmware includes a separate application called [unit_tests](/applications/debug/unit_tests).
|
||||
Flipper Zero firmware includes a separate application called [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests).
|
||||
It is run directly on Flipper devices in order to employ their hardware features and rule out any platform-related differences.
|
||||
|
||||
When contributing code to the Flipper Zero firmware, it is highly desirable to supply unit tests along with the proposed features.
|
||||
|
|
@ -20,7 +20,7 @@ To run the unit tests, follow these steps:
|
|||
3. Launch the CLI session and run the `unit_tests` command.
|
||||
|
||||
**NOTE:** To run a particular test (and skip all others), specify its name as the command argument.
|
||||
See [test_index.c](/applications/debug/unit_tests/test_index.c) for the complete list of test names.
|
||||
See [test_index.c](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/debug/unit_tests/test_index.c) for the complete list of test names.
|
||||
|
||||
## Adding unit tests
|
||||
|
||||
|
|
@ -28,11 +28,11 @@ See [test_index.c](/applications/debug/unit_tests/test_index.c) for the complete
|
|||
|
||||
#### Entry point
|
||||
|
||||
The common entry point for all tests is the [unit_tests](/applications/debug/unit_tests) application. Test-specific code is placed into an arbitrarily named subdirectory and is then called from the [test_index.c](/applications/debug/unit_tests/test_index.c) source file.
|
||||
The common entry point for all tests is the [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests) application. Test-specific code is placed into an arbitrarily named subdirectory and is then called from the [test_index.c](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/test_index.c) source file.
|
||||
|
||||
#### Test assets
|
||||
|
||||
Some unit tests require external data in order to function. These files (commonly called assets) reside in the [unit_tests](/applications/debug/unit_tests/resources/unit_tests) directory in their respective subdirectories. Asset files can be of any type (plain text, FlipperFormat (FFF), binary, etc.).
|
||||
Some unit tests require external data in order to function. These files (commonly called assets) reside in the [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/resources/unit_tests) directory in their respective subdirectories. Asset files can be of any type (plain text, FlipperFormat (FFF), binary, etc.).
|
||||
|
||||
### Application-specific
|
||||
|
||||
|
|
@ -41,9 +41,9 @@ Some unit tests require external data in order to function. These files (commonl
|
|||
Each infrared protocol has a corresponding set of unit tests, so it makes sense to implement one when adding support for a new protocol.
|
||||
To add unit tests for your protocol, follow these steps:
|
||||
|
||||
1. Create a file named `test_<your_protocol_name>.irtest` in the [assets](/applications/debug/unit_tests/resources/unit_tests/infrared) directory.
|
||||
1. Create a file named `test_<your_protocol_name>.irtest` in the [assets](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/resources/unit_tests/infrared) directory.
|
||||
2. Fill it with the test data (more on it below).
|
||||
3. Add the test code to [infrared_test.c](/applications/debug/unit_tests/infrared/infrared_test.c).
|
||||
3. Add the test code to [infrared_test.c](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/debug/unit_tests/infrared/infrared_test.c).
|
||||
4. Build and install firmware with resources, install it on your Flipper and run the tests to see if they pass.
|
||||
|
||||
##### Test data format
|
||||
|
|
|
|||
76
documentation/UniversalRemotes.md
Normal file
76
documentation/UniversalRemotes.md
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
# Universal Remotes {#universal_remotes}
|
||||
|
||||
## Televisions
|
||||
|
||||
Adding your TV set to the universal remote is quite straightforward. Up to 6 signals can be recorded: `Power`, `Mute`, `Vol_up`, `Vol_dn`, `Ch_next`, and `Ch_prev`. Any of them can be omitted if not supported by your TV.
|
||||
|
||||
Each signal is recorded using the following algorithm:
|
||||
|
||||
1. Get the remote and point it to Flipper's IR receiver.
|
||||
2. Start learning a new remote if it's the first button or press `+` to add a new button otherwise.
|
||||
3. Press a remote button and save it under a corresponding name.
|
||||
4. Repeat steps 2-3 until all required signals are saved.
|
||||
|
||||
The signal names are self-explanatory. Remember to make sure that every recorded signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [TV universal remote file](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/tv.ir).
|
||||
|
||||
## Audio players
|
||||
|
||||
Adding your audio player to the universal remote is done in the same manner as described above. Up to 8 signals can be recorded: `Power`, `Play`, `Pause`, `Vol_up`, `Vol_dn`, `Next`, `Prev`, and `Mute`. Any of them can be omitted if not supported by the player.
|
||||
|
||||
The signal names are self-explanatory.
|
||||
On many remotes, the `Play` button doubles as `Pause`. In this case, record it as `Play` omitting the `Pause`.
|
||||
Make sure that every signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [audio player universal remote file](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/audio.ir).
|
||||
|
||||
## Projectors
|
||||
|
||||
Adding your projector to the universal remote is really simple. Up to 4 signals can be recorded: `Power`, `Mute`, `Vol_up`, `Vol_dn`. Any of them can be omitted if not supported by your projector.
|
||||
To save time, please make sure every recording has been named accordingly.
|
||||
In case of omitting, on most projectors with the 4 following buttons, you should not have a problem.
|
||||
|
||||
|
||||
## Air conditioners
|
||||
|
||||
Air conditioners differ from most other infrared-controlled devices because their state is tracked by the remote.
|
||||
The majority of A/C remotes have a small display that shows the current mode, temperature, and other settings.
|
||||
When the user presses a button, a whole set of parameters is transmitted to the device, which must be recorded and used as a whole.
|
||||
|
||||
In order to add a particular air conditioner to the universal remote, 6 signals must be recorded: `Off`, `Dh`, `Cool_hi`, `Cool_lo`, `Heat_hi`, and `Heat_lo`.
|
||||
Each signal (except `Off`) is recorded using the following algorithm:
|
||||
|
||||
1. Get the remote and press the **Power Button** so that the display shows that A/C is ON.
|
||||
2. Set the A/C to the corresponding mode (see table below), leaving other parameters such as fan speed or vane on **AUTO** (if applicable).
|
||||
3. Press the **POWER** button to switch the A/C off.
|
||||
4. Start learning a new remote on Flipper if it's the first button or press `+` to add a new button otherwise.
|
||||
5. Point the remote to Flipper's IR receiver as directed and press **POWER** button once again.
|
||||
6. Save the resulting signal under the specified name.
|
||||
7. Repeat steps 2-6 for each signal from the table below.
|
||||
|
||||
| Signal | Mode | Temperature | Note |
|
||||
| :-----: | :--------: | :---------: | ----------------------------------- |
|
||||
| Dh | Dehumidify | N/A | |
|
||||
| Cool_hi | Cooling | See note | Lowest temperature in cooling mode |
|
||||
| Cool_lo | Cooling | 23°C | |
|
||||
| Heat_hi | Heating | See note | Highest temperature in heating mode |
|
||||
| Heat_lo | Heating | 23°C | |
|
||||
|
||||
Finally, record the `Off` signal:
|
||||
|
||||
1. Make sure the display shows that the A/C is ON.
|
||||
2. Start learning a new signal on Flipper and point the remote towards the IR receiver.
|
||||
3. Press the **POWER** button so that the remote shows the OFF state.
|
||||
4. Save the resulting signal under the name `Off`.
|
||||
|
||||
The resulting remote file should now contain 6 signals. You can omit any of them, but you then won't be able to use their functionality.
|
||||
Test the file against the actual device. Make sure that every signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [A/C universal remote file](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/ac.ir).
|
||||
|
||||
## Final steps
|
||||
|
||||
The order of signals is not important, but they should be preceded by the following comment: `# Model: <Your model name>` in order to keep the library organized.
|
||||
|
||||
When done, open a pull request containing the changed file.
|
||||
246
documentation/devboard/Firmware update on Developer Board.md
Normal file
246
documentation/devboard/Firmware update on Developer Board.md
Normal file
|
|
@ -0,0 +1,246 @@
|
|||
# Firmware update on Developer Board {#dev_board_fw_update}
|
||||
|
||||
It's important to regularly update your Developer Board to keep it up to date. This tutorial will guide you through the necessary steps to successfully update the firmware of your Developer Board.
|
||||
|
||||
This tutorial assumes that you're familiar with the basics of the command line. If you’re unfamiliar with the command line, please refer to the [Windows](https://www.digitalcitizen.life/command-prompt-how-use-basic-commands/) or [MacOS/Linux](https://ubuntu.com/tutorials/command-line-for-beginners#1-overview) command line tutorials.
|
||||
|
||||
***
|
||||
|
||||
## Downloading the latest firmware
|
||||
|
||||
The first thing you need to do is to download the latest Developer Board firmware.
|
||||
|
||||
To get the latest pre-built firmware, do the following:
|
||||
|
||||
1. Go to the [Update Server page](https://update.flipperzero.one/builds/blackmagic-firmware).
|
||||
|
||||
|
||||
There, you can find the following version of the Developer Board firmware:
|
||||
|
||||
* **Release:** The most stable version of the firmware, which went through rigorous testing. The Release firmware version has the following format: **X.Y.Z/**, where X, Y, and Z are the build numbers. We recommend installing this version of the firmware.
|
||||
|
||||
* **Release-candidate:** The firmware version that hasn't been tested yet and may contain bugs. The Release-candidate firmware version has the following format: **X.Y.Z-rc/**, where X, Y, and Z are the build numbers.
|
||||
|
||||
* **Development:** The firmware version which builds every day and contains the latest features but might be unstable.
|
||||
|
||||
2. Open the folder with the latest Release firmware and download the `blackmagic-firmware-s2-full-X.Y.Z.tgz` file.
|
||||
|
||||
***
|
||||
|
||||
## Extracting the firmware
|
||||
|
||||
After downloading the firmware archive, extract it into a folder:
|
||||
|
||||
* On Windows, you can use any archive manager for this, for example, [7-Zip](https://www.7-zip.org/).
|
||||
|
||||
* On MacOS and Linux, you can use the `tar` command:
|
||||
|
||||
```text
|
||||
tar -xzf blackmagic-firmware-s2-full-X.Y.Z.tgz -C <destination_directory>
|
||||
```
|
||||
|
||||
Don't forget to replace `X.Y.Z` with the actual version number and set the destination directory!
|
||||
|
||||
***
|
||||
|
||||
## Installing the prerequisites for flashing
|
||||
|
||||
Install the tools below if you haven't already.
|
||||
|
||||
### Python
|
||||
|
||||
Download and install [Python3](https://www.python.org/downloads/). Make sure to check the “Add Python to PATH” option during installation.
|
||||
|
||||
### pip
|
||||
|
||||
To install the pip package manager, run the following command in the Terminal:
|
||||
|
||||
```text
|
||||
python3 -m ensurepip --upgrade
|
||||
```
|
||||
|
||||
If this command fails, please refer to the [official pip documentation](https://pip.pypa.io/en/stable/installation/) for alternative installation methods.
|
||||
|
||||
### esptool
|
||||
|
||||
esptool is a command-line utility for flashing ESP8266 and ESP32 microcontrollers, including the ESP32-S2 in your Developer Board.
|
||||
|
||||
To install esptool, run the following command in the Terminal:
|
||||
|
||||
```text
|
||||
pip3 install esptool
|
||||
```
|
||||
|
||||
If this command fails, try using **pip** instead of **pip3**. If this didn’t help, please refer to the [official esptool installation manual](https://docs.espressif.com/projects/esptool/en/latest/esp32/installation.html).
|
||||
|
||||
***
|
||||
|
||||
## Connecting the Developer Board to your computer
|
||||
|
||||
1. List all of the serial devices on your computer.
|
||||
|
||||
* ***Windows***
|
||||
|
||||
On Windows, go to Device Manager and expand the Ports (COM & LPT) section.
|
||||
|
||||
* ***macOS***
|
||||
|
||||
On macOS, you can run the following command in the Terminal:
|
||||
|
||||
```text
|
||||
ls /dev/cu.*
|
||||
```
|
||||
|
||||
* ***Linux***
|
||||
|
||||
On Linux, you can run the following command in the Terminal:
|
||||
|
||||
```text
|
||||
ls /dev/tty*
|
||||
```
|
||||
|
||||
View the devices in the list.
|
||||
|
||||
2. Connect the Developer Board to your computer using a USB-C cable.\
|
||||
|
||||
|
||||
3. Switch your Developer Board to Bootloader mode:
|
||||
|
||||
3.1. Press and hold the **BOOT** button.
|
||||
|
||||
3.2. Press the **RESET** button while holding the **BOOT** button.
|
||||
|
||||
3.3. Release the **BOOT** button.
|
||||
|
||||
|
||||
4. Repeat Step 1 and view the name of your Developer Board that appeared in the list.
|
||||
|
||||
For example, on macOS:
|
||||
|
||||
```text
|
||||
/dev/cu.usbmodem01
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## Flashing the firmware
|
||||
|
||||
### Getting the flash command
|
||||
|
||||
1. Run the Terminal and navigate to the folder with the extracted firmware.
|
||||
|
||||
2. Run the following command to read the file with the flash command:
|
||||
|
||||
```text
|
||||
cat flash.command
|
||||
```
|
||||
|
||||
If you see a similar output, you can proceed to the Flashing step:
|
||||
|
||||
```text
|
||||
esptool.py -p (PORT) -b 460800 --before default_reset --after hard_reset --chip esp32s2 write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 bootloader.bin 0x10000 blackmagic.bin 0x8000 partition-table.bin
|
||||
```
|
||||
|
||||
Don't use the exact command above for your Developer Board in the next step since it's just an example and may not match your firmware version!
|
||||
|
||||
If you get an error, ensure you’re in the correct directory and extracted the firmware archive correctly.
|
||||
|
||||
***
|
||||
|
||||
### Flashing
|
||||
|
||||
1. Copy the command you got from the previous step and replace the `(PORT)` part with the name of the serial device you learned earlier.
|
||||
|
||||
For Windows, replace `(PORT)` with the COM port number—for example, `COM3`.
|
||||
|
||||
2. Run the command in the Terminal.
|
||||
|
||||
Your command should look similar to this:
|
||||
|
||||
```text
|
||||
esptool.py -p /dev/cu.usbmodem01 -b 460800 --before default_reset --after hard_reset --chip esp32s2 write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 bootloader.bin 0x10000 blackmagic.bin 0x8000 partition-table.bin
|
||||
```
|
||||
|
||||
If you get an error, ensure that you’ve entered the correct serial device name and that the Developer Board is in Bootloader mode.
|
||||
|
||||
3. Wait till the firmware flashing is over. The flashing process takes about 30 seconds.
|
||||
|
||||
The Terminal output should look similar to this:
|
||||
|
||||
```text
|
||||
esptool.py v4.6.1
|
||||
Serial port /dev/cu.usbmodem01
|
||||
Connecting...
|
||||
Chip is ESP32-S2 (revision v0.0)
|
||||
Features: WiFi, No Embedded Flash, No Embedded PSRAM, ADC and temperature sensor
|
||||
calibration in BLK2 of efuse V2
|
||||
Crystal is 40MHz
|
||||
MAC: 00:11:22:33:44:55
|
||||
Uploading stub...
|
||||
Running stub...
|
||||
Stub running...
|
||||
Changing baud rate to 460800
|
||||
Changed.
|
||||
Configuring flash size...
|
||||
Flash will be erased from 0x00001000 to 0x00004fff...
|
||||
Flash will be erased from 0x00010000 to 0x000ecfff...
|
||||
Flash will be erased from 0x00008000 to 0x00008fff...
|
||||
Compressed 13248 bytes to 9298...
|
||||
Wrote 13248 bytes (9298 compressed) at 0x00001000 in 0.3 seconds (effective 402.7 kbit/s)...
|
||||
Hash of data verified.
|
||||
Compressed 904288 bytes to 562550...
|
||||
Wrote 904288 bytes (562550 compressed) at 0x00010000 in 6.7 seconds (effective 1076.5 kbit/s)...
|
||||
Hash of data verified.
|
||||
Compressed 3072 bytes to 124...
|
||||
Wrote 3072 bytes (124 compressed) at 0x00008000 in 0.1 seconds (effective 360.8 kbit/s)...
|
||||
Hash of data verified.
|
||||
Leaving...
|
||||
Hard resetting via RTS pin...
|
||||
```
|
||||
|
||||
If the Terminal output has these two lines at the end, your Developer Board has been successfully updated:
|
||||
|
||||
```text
|
||||
Leaving...
|
||||
Hard resetting via RTS pin...
|
||||
```
|
||||
|
||||
If you get this warning, you can safely ignore it:
|
||||
|
||||
```text
|
||||
WARNING: ESP32-S2 (revision v0.0) chip was placed into download mode using GPIO0.
|
||||
esptool.py can not exit the download mode over USB. To run the app, reset the chip manually.
|
||||
To suppress this note, set --after option to 'no_reset
|
||||
```
|
||||
|
||||
#### If flashing failed
|
||||
|
||||
If you get an error message during the flashing process, such as:
|
||||
|
||||
```text
|
||||
A fatal error occurred: Serial data stream stopped: Possible serial noise or corruption.
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```text
|
||||
FileNotFoundError: [Errno 2] No such file or directory: '/dev/cu.usbmodem01'
|
||||
```
|
||||
|
||||
Try doing the following:
|
||||
|
||||
* Disconnect the Developer Board from your computer, then reconnect it.
|
||||
|
||||
* Use a different USB port on your computer.
|
||||
|
||||
* Use a different USB-C cable.
|
||||
|
||||
***
|
||||
|
||||
## Finishing the installation
|
||||
|
||||
After flashing the firmware, you can reboot the Developer Board by pressing the **RESET** button.
|
||||
|
||||
|
||||
|
||||
The Developer Board should appear as a serial device on your computer. Now, you can use it with the Black Magic Debug client of your choice.
|
||||
175
documentation/devboard/Get started with the Dev Board.md
Normal file
175
documentation/devboard/Get started with the Dev Board.md
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
# Get started with the Dev Board {#dev_board_get_started}
|
||||
|
||||
The Wi-Fi Developer Board serves as a tool to debug the Flipper Zero firmware. To debug the firmware, the initial step involves compiling the firmware from its source code. This process enables the debugging functionality within the firmware and generates all the necessary files required for debugging purposes.
|
||||
|
||||
> **NOTE:** Building and debugging the Flipper Zero firmware is fully supported on MacOS and Linux. Support for Windows is in beta test.
|
||||
|
||||
***
|
||||
|
||||
## Updating the firmware of your Developer Board
|
||||
|
||||
Update the firmware of your Developer Board before using it. For more information, visit [Firmware update on Developer Board](https://docs.flipperzero.one/development/hardware/wifi-debugger-module/update).
|
||||
|
||||
***
|
||||
|
||||
## Installing Git
|
||||
|
||||
You’ll need Git installed on your computer to clone the firmware repository. If you don’t have Git, install it by doing the following:
|
||||
|
||||
* **MacOS**
|
||||
|
||||
On MacOS, install the **Xcode Command Line Tools** package, which includes Git as one of the pre-installed command-line utilities, by running in the Terminal the following command:
|
||||
|
||||
```text
|
||||
xcode-select --install
|
||||
```
|
||||
|
||||
* **Linux**
|
||||
|
||||
On Linux, you can install Git using your package manager. For example, on Ubuntu, run in the Terminal the following command:
|
||||
|
||||
```text
|
||||
sudo apt install git
|
||||
```
|
||||
|
||||
For other distributions, refer to your package manager documentation.
|
||||
|
||||
***
|
||||
|
||||
## Building the firmware
|
||||
|
||||
First, clone the firmware repository:
|
||||
|
||||
```text
|
||||
git clone --recursive https://github.com/flipperdevices/flipperzero-firmware.git
|
||||
cd flipperzero-firmware
|
||||
```
|
||||
|
||||
Then, run the **Flipper Build Tool** (FBT) to build the firmware:
|
||||
|
||||
```text
|
||||
./fbt
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## Connecting the Developer Board
|
||||
|
||||
The Developer Board can work in the **Wired** mode and two **Wireless** modes: **Wi-Fi access point (AP)** mode and **Wi-Fi client (STA)** mode. The Wired mode is the simplest to set up, but requires a USB Type-C cable. The Wireless modes are more complex to set up, but they allow you to debug your Flipper Zero wirelessly.
|
||||
|
||||
> **NOTE:** Use the following credentials when connecting to the Developer Board in **Wi-Fi access point** mode: Name: **blackmagic**, Password: **iamwitcher**
|
||||
|
||||
## Wired
|
||||
|
||||
|
||||
|
||||
To connect the Developer Board in **Wired** mode, do the following:
|
||||
|
||||
1. Cold-plug the Developer Board by turning off your Flipper Zero and connecting the Developer Board, and then turning it back on.
|
||||
|
||||
2. On your computer, open the **Terminal** and run the following:
|
||||
|
||||
* **MacOS**
|
||||
|
||||
```text
|
||||
ls /dev/cu.*
|
||||
```
|
||||
|
||||
* **Linux**
|
||||
|
||||
```text
|
||||
ls /dev/tty*
|
||||
```
|
||||
|
||||
Note the list of devices.
|
||||
|
||||
3. Connect the Developer Board to your computer via a USB-C cable.
|
||||
|
||||
4. Rerun the command. Two new devices have to appear: this is the Developer Board.
|
||||
|
||||
> **NOTE:** If the Developer Board doesn’t appear in the list of devices, try using a different cable, USB port, or computer.
|
||||
>
|
||||
> **NOTE:** Flipper Zero logs can only be viewed when the Developer Board is connected via USB. The option to view logs over Wi-Fi will be added in future updates. For more information, visit [Reading logs via the Dev Board](https://docs.flipperzero.one/development/hardware/wifi-debugger-module/reading-logs).
|
||||
|
||||
## Wireless
|
||||
|
||||
### Wi-Fi access point (AP) mode
|
||||
|
||||
|
||||
|
||||
Out of the box, the Developer Board is configured to work as a **Wi-Fi access point**. This means it will create its own Wi-Fi network to which you can connect. If your Developer Board doesn’t create a Wi-Fi network, it is probably configured to work in **Wi-Fi client** mode. To reset your Developer Board back to **Wi-Fi access point** mode, press and hold the **BOOT** button for 10 seconds, then wait for the module to reboot.
|
||||
|
||||
|
||||
|
||||
To connect the Developer Board in **Wi-Fi access point** mode, do the following:
|
||||
|
||||
1. Cold-plug the Developer Board by turning off your Flipper Zero and connecting the Developer Board, and then turning it back on.
|
||||
|
||||
2. Open Wi-Fi settings on your client device (phone, laptop, or other).
|
||||
|
||||
3. Connect to the network:
|
||||
|
||||
* Name: **blackmagic**
|
||||
* Password: **iamwitcher**
|
||||
|
||||
4. To configure the Developer Board, open a browser and go to `http://192.168.4.1`.
|
||||
|
||||
#### Wi-Fi client (STA) mode
|
||||
|
||||
|
||||
|
||||
To connect the Developer Board in **Wi-Fi client** mode, you need to configure it to connect to your Wi-Fi network by doing the following:
|
||||
|
||||
1. Cold-plug the Developer Board by turning off your Flipper Zero and connecting the Developer Board, and then turning it back on.
|
||||
|
||||
2. Connect to the Developer Board in **Wi-Fi access point** mode.
|
||||
|
||||
3. In a browser, go to the configuration page on `http://192.168.4.1`.
|
||||
|
||||
4. Select the **STA** mode and enter your network’s **SSID** (name) and **password**. For convenience, you can click the **+** button to see the list of nearby networks.
|
||||
|
||||
5. Save the configuration and reboot the Developer Board.
|
||||
|
||||
|
||||
|
||||
After rebooting, the Developer Board connects to your Wi-Fi network. You can connect to the device using the mDNS name [blackmagic.local](http://blackmagic.local) or the IP address it got from your router (you’ll have to figure this out yourself, every router is different).
|
||||
|
||||
After connecting to your debugger via [blackmagic.local](http://blackmagic.local), you can find its IP address in the **SYS** tab. You can also change the debugger’s mode to **AP** or **STA** there.
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Debugging the firmware
|
||||
|
||||
Open the **Terminal** in the **flipperzero-firmware** directory that you cloned earlier and run the following command:
|
||||
|
||||
```text
|
||||
./fbt flash_blackmagic
|
||||
```
|
||||
|
||||
This will upload the firmware you’ve just built to your Flipper Zero via the Developer Board. After that, you can start debugging the firmware using the [GDB](https://www.gnu.org/software/gdb/) debugger. We recommend using **VSCode** with the recommended extensions, and we have pre-made configurations for it.
|
||||
|
||||
To debug in **VSCode**, do the following:
|
||||
|
||||
1. In VSCode, open the **flipperzero-firmware** directory.
|
||||
|
||||
2. You should see a notification about recommended extensions. Install them.
|
||||
|
||||
If there were no notifications, open the **Extensions** tab, enter `@recommended` in the search bar, and install the workspace recommendations.
|
||||
|
||||
3. In the **Terminal**, run the `./fbt vscode_dist` command. This will generate the VSCode configuration files needed for debugging.
|
||||
|
||||
4. In VSCode, open the **Run and Debug** tab and select **Attach FW (blackmagic)** from the dropdown menu.
|
||||
|
||||
5. If needed, flash your Flipper Zero with the `./fbt flash_blackmagic` command, then click the **Play** button in the debug sidebar to start the debugging session.
|
||||
|
||||
6. Note that starting a debug session halts the execution of the firmware, so you’ll need to click the **Continue** button on the toolbar at the top of your VSCode window to continue execution.
|
||||
|
||||
|
||||
|
||||
To learn about debugging, visit the following pages:
|
||||
|
||||
* [Debugging with GDB](https://sourceware.org/gdb/current/onlinedocs/gdb.pdf)
|
||||
|
||||
* [Debugging in VS Code](https://code.visualstudio.com/docs/editor/debugging)
|
||||
152
documentation/devboard/Reading logs via the Dev Board.md
Normal file
152
documentation/devboard/Reading logs via the Dev Board.md
Normal file
|
|
@ -0,0 +1,152 @@
|
|||
# Reading logs via the Dev Board {#dev_board_reading_logs}
|
||||
|
||||
The Developer Board allows you to read Flipper Zero logs via UART. Unlike reading logs via the command-line interface (CLI), the Developer Board enables you to collect logs from the device directly to a serial console independently from the operating system of Flipper Zero. It allows you to see the device's logs when it's loading, updating, or crashing. It's useful for debugging and troubleshooting during software development.
|
||||
|
||||
> **NOTE:** Flipper Zero logs can only be viewed when the developer board is connected via USB. The option to view logs over Wi-Fi will be added in future updates.
|
||||
|
||||
## Setting the log level
|
||||
|
||||
Depending on your needs, you can set the log level by going to Main Menu -> Settings -> Log Level. To learn more about logging levels, visit [Settings](https://docs.flipperzero.one/basics/settings#d5TAt).
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Viewing Flipper Zero logs
|
||||
|
||||
Depending on your operating system, you need to install an additional application on your computer to read logs via the Developer Board:
|
||||
|
||||
### MacOS
|
||||
|
||||
On MacOS, you need to install the **minicom** communication program by doing the following:
|
||||
|
||||
1. [Install Homebrew](https://brew.sh/) by running in the Terminal the following command:
|
||||
|
||||
```text
|
||||
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
||||
```
|
||||
|
||||
2. After installation of Homebrew, run the following command to install minicom:
|
||||
|
||||
```text
|
||||
brew install minicom
|
||||
```
|
||||
|
||||
After installation of minicom on your macOS computer, you can connect to the Developer Board to read Flipper Zero logs by doing the following:
|
||||
|
||||
1. Cold-plug the Developer Board into your Flipper Zero by turning off the Flipper Zero, connecting the developer board, and then turning it back on.
|
||||
|
||||
2. On your computer, open the Terminal and run the following command:
|
||||
|
||||
```text
|
||||
ls /dev/cu.*
|
||||
```
|
||||
|
||||
Note the list of devices.
|
||||
|
||||
3. Connect the developer board to your computer using a USB Type-C cable.\
|
||||
|
||||
|
||||
4. Rerun the command. Two new devices have to appear: this is the Developer Board.
|
||||
|
||||
```text
|
||||
/dev/cu.usbmodemblackmagic1
|
||||
/dev/cu.usbmodemblackmagic3
|
||||
```
|
||||
|
||||
Your Developer Board might have different names.
|
||||
|
||||
5. Run the following command:
|
||||
|
||||
```text
|
||||
minicom -D /dev/<port> -b 230400
|
||||
```
|
||||
|
||||
Where `<port>` is the name of your device with a bigger number.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
minicom -D /dev/cu.usbmodemblackmagic3 -b 230400
|
||||
```
|
||||
|
||||
6. View logs of your Flipper Zero in the Terminal.
|
||||
|
||||
7. To quit, close the minicom window or quit via the minicom menu.
|
||||
|
||||
### Linux
|
||||
|
||||
On Linux, you need to install the **minicom** communication program. For example, on Ubuntu, run in the Terminal the following command:
|
||||
|
||||
```text
|
||||
sudo apt install minicom
|
||||
```
|
||||
|
||||
After installation of minicom on your Linux computer, you can connect to the Developer Board to read Flipper Zero logs by doing the following:
|
||||
|
||||
1. Cold-plug the Developer Board into your Flipper Zero by turning off the Flipper Zero, connecting the developer board, and then turning it back on.
|
||||
|
||||
2. On your computer, open the Terminal and run the following command:
|
||||
|
||||
```text
|
||||
ls /dev/tty*
|
||||
```
|
||||
|
||||
Note the list of devices.
|
||||
|
||||
3. Connect the developer board to your computer using a USB Type-C cable.
|
||||
|
||||
|
||||
4. Rerun the command. Two new devices have to appear: this is the Developer Board.
|
||||
|
||||
```text
|
||||
/dev/ttyACM0
|
||||
/dev/ttyACM1
|
||||
```
|
||||
|
||||
Your Developer Board might have different names.
|
||||
|
||||
5. Run the following command:
|
||||
|
||||
```text
|
||||
minicom -D /dev/<port> \-b 230400
|
||||
```
|
||||
|
||||
Where `<port>` is the name of your device with a bigger number.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
minicom -D /dev/ttyACM1 \-b 230400
|
||||
```
|
||||
|
||||
6. View logs of your Flipper Zero in the Terminal.
|
||||
|
||||
> **NOTE:** If no logs are shown in the Terminal, try running the command from Step 5 with another device name.
|
||||
|
||||
7. To quit, close the minicom window or quit via the minicom menu.
|
||||
|
||||
### Windows
|
||||
|
||||
On Windows, do the following:
|
||||
|
||||
1. On your computer, [install the PuTTY application](https://www.chiark.greenend.org.uk/\~sgtatham/putty/latest.html).
|
||||
|
||||
2. Cold-plug the Developer Board into your Flipper Zero by turning off the Flipper Zero, connecting the developer board, and then turning it back on.
|
||||
|
||||
3. Connect the developer board to your computer using a USB Type-C cable.
|
||||
|
||||
|
||||
4. Find the serial port that the developer board is connected to by going to **Device Manager -> Ports (COM & LPT)** and looking for a new port that appears when you connect the Wi-Fi developer board.
|
||||
|
||||
|
||||
5. Run the PuTTY application and select **Serial** as the connection type.
|
||||
|
||||
6. Enter the port number you found in the previous step into the **Serial line** field.
|
||||
|
||||
7. Set the **Speed** parameter to **230400** and click **Open**.
|
||||
|
||||
|
||||
8. View logs of your Flipper Zero in the PuTTY terminal window.
|
||||
|
||||
9. To quit, close the PuTTY window.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Flipper Build Tool
|
||||
# Flipper Build Tool {#fbt}
|
||||
|
||||
FBT is the entry point for firmware-related commands and utilities.
|
||||
It is invoked by `./fbt` in the firmware project root directory. Internally, it is a wrapper around [scons](https://scons.org/) build system.
|
||||
|
|
@ -58,7 +58,7 @@ To use language servers other than the default VS Code C/C++ language server, us
|
|||
|
||||
## FBT targets
|
||||
|
||||
**`fbt`** keeps track of internal dependencies, so you only need to build the highest-level target you need, and **`fbt`** will make sure everything they depend on is up-to-date.
|
||||
`fbt` keeps track of internal dependencies, so you only need to build the highest-level target you need, and `fbt` will make sure everything they depend on is up-to-date.
|
||||
|
||||
### High-level (what you most likely need)
|
||||
|
||||
|
|
@ -83,8 +83,8 @@ To use language servers other than the default VS Code C/C++ language server, us
|
|||
|
||||
### Firmware targets
|
||||
|
||||
- `faps` - build all external & plugin apps as [`.faps`](./AppsOnSDCard.md#fap-flipper-application-package).
|
||||
- **`fbt`** also defines per-app targets. For example, for an app with `appid=snake_game` target names are:
|
||||
- `faps` - build all external & plugin apps as [`.faps`](AppsOnSDCard.md).
|
||||
- `fbt` also defines per-app targets. For example, for an app with `appid=snake_game` target names are:
|
||||
- `fap_snake_game`, etc. - build single app as `.fap` by its application ID.
|
||||
- Check out [`--extra-ext-apps`](#command-line-parameters) for force adding extra apps to external build.
|
||||
- `fap_snake_game_list`, etc - generate source + assembler listing for app's `.fap`.
|
||||
|
|
@ -103,7 +103,7 @@ To use language servers other than the default VS Code C/C++ language server, us
|
|||
- `proto_ver` - generate `.h` with a protobuf version
|
||||
- `dolphin_internal`, `dolphin_blocking` - generate `.c+.h` for corresponding dolphin assets
|
||||
|
||||
## Command-line parameters
|
||||
## Command-line parameters {#command-line-parameters}
|
||||
|
||||
- `--options optionfile.py` (default value `fbt_options.py`) - load a file with multiple configuration values
|
||||
- `--extra-int-apps=app1,app2,appN` - force listed apps to be built as internal with the `firmware` target
|
||||
|
|
|
|||
|
|
@ -1,21 +1,23 @@
|
|||
# Command syntax
|
||||
# BadUSB File Format {#badusb_file_format}
|
||||
|
||||
## 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 functional keys.
|
||||
|
||||
# Script file format
|
||||
## Script file format
|
||||
|
||||
BadUsb app can execute only text scripts from `.txt` files, no compilation is required. Both `\n` and `\r\n` line endings are supported. Empty lines are allowed. You can use spaces or tabs for line indentation.
|
||||
|
||||
# Command set
|
||||
## Command set
|
||||
|
||||
## Comment line
|
||||
### Comment line
|
||||
|
||||
Just a single comment line. The interpreter will ignore all text after the REM command.
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ------------ | ----- |
|
||||
| REM | Comment text | |
|
||||
|
||||
## Delay
|
||||
### Delay
|
||||
|
||||
Pause script execution by a defined time.
|
||||
| Command | Parameters | Notes |
|
||||
|
|
@ -24,7 +26,7 @@ Pause script execution by a defined time.
|
|||
| DEFAULT_DELAY | Delay value in ms | Add delay before every next command |
|
||||
| DEFAULTDELAY | Delay value in ms | Same as DEFAULT_DELAY |
|
||||
|
||||
## Special keys
|
||||
### Special keys
|
||||
|
||||
| Command | Notes |
|
||||
| ------------------ | ---------------- |
|
||||
|
|
@ -53,7 +55,7 @@ Pause script execution by a defined time.
|
|||
| APP | Same as MENU |
|
||||
| Fx | F1-F12 keys |
|
||||
|
||||
## Modifier keys
|
||||
### Modifier keys
|
||||
|
||||
Can be combined with a special key command or a single character.
|
||||
| Command | Notes |
|
||||
|
|
@ -85,7 +87,7 @@ Will wait indefinitely for a button to be pressed
|
|||
| WAIT_FOR_BUTTON_PRESS | None | Will wait for the user to press a button to continue script execution |
|
||||
|
||||
|
||||
## String
|
||||
### String
|
||||
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ----------- | ----------------- |
|
||||
|
|
@ -100,13 +102,13 @@ Delay between keypresses.
|
|||
| STRING_DELAY | Delay value in ms | Applied once to next appearing STRING command |
|
||||
| STRINGDELAY | Delay value in ms | Same as STRING_DELAY |
|
||||
|
||||
## Repeat
|
||||
### Repeat
|
||||
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ---------------------------- | ----------------------- |
|
||||
| REPEAT | Number of additional repeats | Repeat previous command |
|
||||
|
||||
## ALT+Numpad input
|
||||
### ALT+Numpad input
|
||||
|
||||
On Windows and some Linux systems, you can print characters by holding `ALT` key and entering its code on Numpad.
|
||||
| Command | Parameters | Notes |
|
||||
|
|
@ -115,14 +117,14 @@ On Windows and some Linux systems, you can print characters by holding `ALT` key
|
|||
| ALTSTRING | Text string | Print text string using ALT+Numpad method |
|
||||
| ALTCODE | Text string | Same as ALTSTRING, presents in some Duckyscript implementations |
|
||||
|
||||
## SysRq
|
||||
### SysRq
|
||||
|
||||
Send [SysRq command](https://en.wikipedia.org/wiki/Magic_SysRq_key)
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ---------------- | ----- |
|
||||
| SYSRQ | Single character | |
|
||||
|
||||
## USB device ID
|
||||
### USB device ID
|
||||
|
||||
You can set the custom ID of the Flipper USB HID device. ID command should be in the **first line** of script, it is executed before script run.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Infrared Flipper File Formats
|
||||
# Infrared Flipper File Formats {#infrared_file_format}
|
||||
|
||||
## Supported protocols list for "type: parsed"
|
||||
|
||||
## Supported protocols list for `type: parsed`
|
||||
```
|
||||
NEC
|
||||
NECext
|
||||
|
|
@ -17,6 +17,7 @@
|
|||
Kaseikyo
|
||||
RCA
|
||||
```
|
||||
|
||||
## Infrared Remote File Format
|
||||
|
||||
### Example
|
||||
|
|
@ -51,7 +52,7 @@ Each button is separated from others by a comment character (`#`) for better rea
|
|||
|
||||
Known protocols are represented in the `parsed` form, whereas non-recognized signals may be saved and re-transmitted as `raw` data.
|
||||
|
||||
#### Version history:
|
||||
#### Version history
|
||||
|
||||
1. Initial version.
|
||||
|
||||
|
|
@ -72,19 +73,19 @@ Known protocols are represented in the `parsed` form, whereas non-recognized sig
|
|||
|
||||
### Examples
|
||||
|
||||
- [TV Universal Library](/applications/main/infrared/resources/infrared/assets/tv.ir)
|
||||
- [A/C Universal Library](/applications/main/infrared/resources/infrared/assets/ac.ir)
|
||||
- [Audio Universal Library](/applications/main/infrared/resources/infrared/assets/audio.ir)
|
||||
- [TV Universal Library](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/tv.ir)
|
||||
- [A/C Universal Library](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/ac.ir)
|
||||
- [Audio Universal Library](https://github.com/flipperdevices/flipperzero-firmware/blob/dev/applications/main/infrared/resources/infrared/assets/audio.ir)
|
||||
|
||||
### Description
|
||||
|
||||
Filename extension: `.ir`
|
||||
|
||||
This file format is used to store universal remote libraries. It is identical to the previous format, differing only in the `Filetype` field.\
|
||||
This file format is used to store universal remote libraries. It is identical to the previous format, differing only in the `Filetype` field.
|
||||
It also has predefined button names for each universal library type, so that the universal remote application can understand them.
|
||||
See [Universal Remotes](/documentation/UniversalRemotes.md) for more information.
|
||||
See [Universal Remotes](../UniversalRemotes.md) for more information.
|
||||
|
||||
### Version history:
|
||||
### Version history
|
||||
|
||||
1. Initial version.
|
||||
|
||||
|
|
@ -92,7 +93,7 @@ See [Universal Remotes](/documentation/UniversalRemotes.md) for more information
|
|||
|
||||
### Examples
|
||||
|
||||
See [Infrared Unit Tests](/applications/debug/unit_tests/resources/unit_tests/infrared/) for various examples.
|
||||
See [Infrared Unit Tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/resources/unit_tests/infrared) for various examples.
|
||||
|
||||
### Description
|
||||
|
||||
|
|
@ -103,10 +104,10 @@ It is mostly similar to the two previous formats, with the main difference being
|
|||
|
||||
Each infrared protocol must have corresponding unit tests complete with an `.irtest` file.
|
||||
|
||||
Known protocols are represented in the `parsed_array` form, whereas raw data has the `raw` type.\
|
||||
Known protocols are represented in the `parsed_array` form, whereas raw data has the `raw` type.
|
||||
Note: a single parsed signal must be represented as an array of size 1.
|
||||
|
||||
### Version history:
|
||||
### Version history
|
||||
|
||||
1. Initial version.
|
||||
|
||||
|
|
@ -141,4 +142,4 @@ and the number is a sequential integer: 1, 2, 3, etc., which produces names like
|
|||
| decoder_expected | parsed_array | An array of parsed signals containing the expected decoder output. 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. |
|
||||
|
||||
See [Unit Tests](/documentation/UnitTests.md#infrared) for more info.
|
||||
See [Unit Tests](../UnitTests.md) for more info.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# LF RFID key file format
|
||||
# LF RFID key file format {#lfrfid_file_format}
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# NFC Flipper File Formats
|
||||
# NFC Flipper File Formats {#nfc_file_format}
|
||||
|
||||
## UID + Header (General format)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,20 @@
|
|||
# File Formats for Flipper's SubGhz Subsystem
|
||||
# SubGhz Subsystem File Formats {#subghz_file_format}
|
||||
|
||||
## `.sub` File Format
|
||||
## .sub File Format
|
||||
|
||||
Flipper uses `.sub` files to store SubGhz transmissions. These are text files in Flipper File Format. `.sub` files can contain either a SubGhz Key with a certain protocol or SubGhz RAW data.
|
||||
Flipper uses `.sub` files to store SubGhz signals. These files use the Flipper File Format. `.sub` files can contain either a SubGhz Key with a certain protocol or SubGhz RAW data.
|
||||
|
||||
A `.sub` files consist of 3 parts:
|
||||
A `.sub` file consist of 3 parts:
|
||||
|
||||
- **header**, contains file type, version, and frequency
|
||||
- **header**, contains the file type, version, and frequency
|
||||
- **preset information**, preset type and, in case of a custom preset, transceiver configuration data
|
||||
- **protocol and its data**, contains protocol name and its specific data, such as key, bit length, etc., or RAW data
|
||||
|
||||
Flipper's SubGhz subsystem uses presets to configure the radio transceiver. Presets are used to configure modulation, bandwidth, filters, etc. There are several presets available in stock firmware, and there is a way to create custom presets. See [SubGhz Presets](#adding-a-custom-preset) for more details.
|
||||
Flipper's SubGhz subsystem uses presets to configure the radio transceiver. Presets are used to configure modulation, bandwidth, filters, etc. There are several presets available in stock firmware, and there is a way to create custom presets. See [SubGhz Presets](#adding-a-custom-preset) section for more details.
|
||||
|
||||
## Header format
|
||||
|
||||
Header is a mandatory part of `.sub` file. It contains file type, version, and frequency.
|
||||
Header is a mandatory part of a `.sub` file. It contains the file type, version, and frequency.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ----------- | ------ | ----------------------------------------------------------------- |
|
||||
|
|
@ -41,7 +41,7 @@ Built-in presets:
|
|||
- `FuriHalSubGhzPreset2FSKDev238Async` — 2 Frequency Shift Keying, deviation 2kHz, 270kHz bandwidth, async(IO throw GP0)
|
||||
- `FuriHalSubGhzPreset2FSKDev476Async` — 2 Frequency Shift Keying, deviation 47kHz, 270kHz bandwidth, async(IO throw GP0)
|
||||
|
||||
### Transceiver Configuration Data
|
||||
### Transceiver Configuration Data {#transceiver-configuration-data}
|
||||
|
||||
Transceiver configuration data is a string of bytes, encoded in hex format, separated by spaces. For CC1101 data structure is: `XX YY XX YY .. 00 00 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ`, where:
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ You can find more details in the [CC1101 datasheet](https://www.ti.com/lit/ds/sy
|
|||
|
||||
## File Data
|
||||
|
||||
`.sub` file data section contains either key data — protocol name and its specific data, bit length, etc., or RAW data — an array of signal timings, recorded without any protocol-specific processing.
|
||||
`.sub` file data section can either contain key data, consisting of a protocol name and its specific data, bit length, etc., or RAW data, which consists of an array of signal timings, recorded without any protocol-specific processing.
|
||||
|
||||
### Key Files
|
||||
|
||||
|
|
@ -88,20 +88,20 @@ RAW `.sub` files contain raw signal data that is not processed through protocol-
|
|||
For RAW files, 2 fields are required:
|
||||
|
||||
- **Protocol**, must be `RAW`
|
||||
- **RAW_Data**, contains an array of timings, specified in microseconds Values must be non-zero, start with a positive number, and interleaved (change sign with each value). Up to 512 values per line. Can be specified multiple times to store multiple lines of data.
|
||||
- **RAW_Data**, contains an array of timings, specified in microseconds. Values must be non-zero, start with a positive number, and interleaved (change sign with each value). Up to 512 values per line. Can be specified multiple times to store multiple lines of data.
|
||||
|
||||
Example of RAW data:
|
||||
|
||||
Protocol: RAW
|
||||
RAW_Data: 29262 361 -68 2635 -66 24113 -66 11 ...
|
||||
|
||||
Long payload not fitting into internal memory buffer and consisting of short duration timings (< 10us) may not be read fast enough from the SD card. That might cause the signal transmission to stop before reaching the end of the payload. Ensure that your SD Card has good performance before transmitting long or complex RAW payloads.
|
||||
A long payload that doesn't fit into the internal memory buffer and consists of short duration timings (< 10us) may not be read fast enough from the SD card. That might cause the signal transmission to stop before reaching the end of the payload. Ensure that your SD Card has good performance before transmitting long or complex RAW payloads.
|
||||
|
||||
### BIN_RAW Files
|
||||
|
||||
BinRAW `.sub` files and `RAW` files both contain data that has not been decoded by any protocol. However, unlike `RAW`, `BinRAW` files only record a useful repeating sequence of durations with a restored byte transfer rate and without broadcast noise. These files can emulate nearly all static protocols, whether Flipper knows them or not.
|
||||
|
||||
- Usually, you have to receive the signal a little longer so that Flipper accumulates sufficient data for correct analysis.
|
||||
- Usually, you have to receive the signal a little longer so that Flipper accumulates sufficient data to analyze it correctly.
|
||||
|
||||
For `BinRAW` files, the following parameters are required and must be aligned to the left:
|
||||
|
||||
|
|
@ -188,7 +188,7 @@ Data_RAW: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DE 02 D3 54 D5 4C D2 C
|
|||
|
||||
SubGhz application provides support for adding extra radio presets and additional keys for decoding transmissions in certain protocols.
|
||||
|
||||
## SubGhz `keeloq_mfcodes_user` file
|
||||
## SubGhz keeloq_mfcodes_user file
|
||||
|
||||
This file contains additional manufacturer keys for Keeloq protocol. It is used to decode Keeloq transmissions.
|
||||
This file is loaded at subghz application start and is located at path `/ext/subghz/assets/keeloq_mfcodes_user`.
|
||||
|
|
@ -228,7 +228,7 @@ For each key, a name and encryption method must be specified, according to comme
|
|||
AABBCCDDEEFFAABB:1:Test1
|
||||
AABBCCDDEEFFAABB:1:Test2
|
||||
|
||||
## SubGhz `setting_user` file
|
||||
## 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 being loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
|
||||
|
||||
|
|
@ -256,7 +256,7 @@ Header must contain the following fields:
|
|||
|
||||
Repeating the same frequency will cause Flipper to listen to this frequency more often.
|
||||
|
||||
#### Adding a Custom Preset
|
||||
#### Adding a Custom Preset {#adding-a-custom-preset}
|
||||
|
||||
You can have as many presets as you want. Presets are embedded into `.sub` files, so another Flipper can load them directly from that file.
|
||||
Each preset is defined by the following fields:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# iButton key file format
|
||||
# iButton key file format {#ibutton_file_format}
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ FURI_NORETURN void __furi_halt_implementation();
|
|||
|
||||
/** Crash system
|
||||
*
|
||||
* @param optional message (const char*)
|
||||
* @param ... optional message (const char*)
|
||||
*/
|
||||
#define furi_crash(...) M_APPLY(__furi_crash, M_IF_EMPTY(__VA_ARGS__)((NULL), (__VA_ARGS__)))
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ FURI_NORETURN void __furi_halt_implementation();
|
|||
|
||||
/** Halt system
|
||||
*
|
||||
* @param optional message (const char*)
|
||||
* @param ... optional message (const char*)
|
||||
*/
|
||||
#define furi_halt(...) M_APPLY(__furi_halt, M_IF_EMPTY(__VA_ARGS__)((NULL), (__VA_ARGS__)))
|
||||
|
||||
|
|
@ -71,8 +71,7 @@ FURI_NORETURN void __furi_halt_implementation();
|
|||
|
||||
/** Check condition and crash if failed
|
||||
*
|
||||
* @param condition to check
|
||||
* @param optional message (const char*)
|
||||
* @param ... condition to check and optional message (const char*)
|
||||
*/
|
||||
#define furi_check(...) \
|
||||
M_APPLY(__furi_check, M_DEFAULT_ARGS(2, (__FURI_CHECK_MESSAGE_FLAG), __VA_ARGS__))
|
||||
|
|
@ -97,8 +96,7 @@ FURI_NORETURN void __furi_halt_implementation();
|
|||
*
|
||||
* @warning only will do check if firmware compiled in debug mode
|
||||
*
|
||||
* @param condition to check
|
||||
* @param optional message (const char*)
|
||||
* @param ... condition to check and optional message (const char*)
|
||||
*/
|
||||
#define furi_assert(...) \
|
||||
M_APPLY(__furi_assert, M_DEFAULT_ARGS(2, (__FURI_ASSERT_MESSAGE_FLAG), __VA_ARGS__))
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ void furi_delay_tick(uint32_t ticks);
|
|||
*
|
||||
* @warning This should never be called in interrupt request context.
|
||||
*
|
||||
* @param[in] ticks The tick until which kerel should delay task execution
|
||||
* @param[in] tick The tick until which kerel should delay task execution
|
||||
*
|
||||
* @return The furi status.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ void furi_log_init(void);
|
|||
|
||||
/** Add log TX callback
|
||||
*
|
||||
* @param[in] callback The callback
|
||||
* @param[in] handler The callback and its context
|
||||
*
|
||||
* @return true on success, false otherwise
|
||||
*/
|
||||
|
|
@ -59,7 +59,7 @@ bool furi_log_add_handler(FuriLogHandler handler);
|
|||
|
||||
/** Remove log TX callback
|
||||
*
|
||||
* @param[in] callback The callback
|
||||
* @param[in] handler The callback and its context
|
||||
*
|
||||
* @return true on success, false otherwise
|
||||
*/
|
||||
|
|
@ -112,15 +112,16 @@ FuriLogLevel furi_log_get_level(void);
|
|||
/** Log level to string
|
||||
*
|
||||
* @param[in] level The level
|
||||
* @param[out] str String representation of the level
|
||||
*
|
||||
* @return The string
|
||||
* @return True if success, False otherwise
|
||||
*/
|
||||
bool furi_log_level_to_string(FuriLogLevel level, const char** str);
|
||||
|
||||
/** Log level from string
|
||||
*
|
||||
* @param[in] str The string
|
||||
* @param level The level
|
||||
* @param[out] level The level
|
||||
*
|
||||
* @return True if success, False otherwise
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -18,13 +18,13 @@ extern "C" {
|
|||
*
|
||||
* @param thread_id - thread id to track
|
||||
*/
|
||||
void memmgr_heap_enable_thread_trace(FuriThreadId taks_handle);
|
||||
void memmgr_heap_enable_thread_trace(FuriThreadId thread_id);
|
||||
|
||||
/** Memmgr heap disable thread allocation tracking
|
||||
*
|
||||
* @param thread_id - thread id to track
|
||||
*/
|
||||
void memmgr_heap_disable_thread_trace(FuriThreadId taks_handle);
|
||||
void memmgr_heap_disable_thread_trace(FuriThreadId thread_id);
|
||||
|
||||
/** Memmgr heap get allocatred thread memory
|
||||
*
|
||||
|
|
@ -32,7 +32,7 @@ void memmgr_heap_disable_thread_trace(FuriThreadId taks_handle);
|
|||
*
|
||||
* @return bytes allocated right now
|
||||
*/
|
||||
size_t memmgr_heap_get_thread_memory(FuriThreadId taks_handle);
|
||||
size_t memmgr_heap_get_thread_memory(FuriThreadId thread_id);
|
||||
|
||||
/** Memmgr heap get the max contiguous block size on the heap
|
||||
*
|
||||
|
|
|
|||
|
|
@ -32,7 +32,6 @@ void furi_message_queue_free(FuriMessageQueue* instance);
|
|||
* @param instance pointer to FuriMessageQueue instance
|
||||
* @param[in] msg_ptr The message pointer
|
||||
* @param[in] timeout The timeout
|
||||
* @param[in] msg_prio The message prio
|
||||
*
|
||||
* @return The furi status.
|
||||
*/
|
||||
|
|
@ -43,7 +42,6 @@ FuriStatus
|
|||
*
|
||||
* @param instance pointer to FuriMessageQueue instance
|
||||
* @param msg_ptr The message pointer
|
||||
* @param msg_prio The message prioority
|
||||
* @param[in] timeout The timeout
|
||||
*
|
||||
* @return The furi status.
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ void furi_string_reserve(FuriString* string, size_t size);
|
|||
/**
|
||||
* @brief Reset string.
|
||||
* Make the string empty.
|
||||
* @param s
|
||||
* @param string
|
||||
*/
|
||||
void furi_string_reset(FuriString* string);
|
||||
|
||||
|
|
|
|||
|
|
@ -235,8 +235,6 @@ int32_t furi_thread_get_return_code(FuriThread* thread);
|
|||
/** Thread related methods that doesn't involve FuriThread directly */
|
||||
|
||||
/** Get FreeRTOS FuriThreadId for current thread
|
||||
*
|
||||
* @param thread FuriThread instance
|
||||
*
|
||||
* @return FuriThreadId or NULL
|
||||
*/
|
||||
|
|
@ -263,7 +261,7 @@ uint32_t furi_thread_flags_wait(uint32_t flags, uint32_t options, uint32_t timeo
|
|||
* @brief Enumerate threads
|
||||
*
|
||||
* @param thread_array array of FuriThreadId, where thread ids will be stored
|
||||
* @param array_items array size
|
||||
* @param array_item_count array size
|
||||
* @return uint32_t threads count
|
||||
*/
|
||||
uint32_t furi_thread_enumerate(FuriThreadId* thread_array, uint32_t array_item_count);
|
||||
|
|
|
|||
|
|
@ -98,8 +98,7 @@ bool elf_file_is_init_complete(ELFFile* elf);
|
|||
/**
|
||||
* @brief Get actual entry point for ELF file
|
||||
* @param elf_file
|
||||
* @param args
|
||||
* @return int32_t
|
||||
* @return void*
|
||||
*/
|
||||
void* elf_file_get_entry_point(ELFFile* elf_file);
|
||||
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ void nfc_set_fdt_listen_fc(Nfc* instance, uint32_t fdt_listen_fc);
|
|||
* @brief Set mask receive time.
|
||||
*
|
||||
* @param[in,out] instance pointer to the instance to be modified.
|
||||
* @param[in] mask_rx_time mask receive time, in carrier cycles.
|
||||
* @param[in] mask_rx_time_fc mask receive time, in carrier cycles.
|
||||
*/
|
||||
void nfc_set_mask_receive_time_fc(Nfc* instance, uint32_t mask_rx_time_fc);
|
||||
|
||||
|
|
|
|||
|
|
@ -72,14 +72,14 @@ NfcScanner* nfc_scanner_alloc(Nfc* nfc);
|
|||
/**
|
||||
* @brief Delete an NfcScanner instance.
|
||||
*
|
||||
* @param[in,out] pointer to the instance to be deleted.
|
||||
* @param[in,out] instance pointer to the instance to be deleted.
|
||||
*/
|
||||
void nfc_scanner_free(NfcScanner* instance);
|
||||
|
||||
/**
|
||||
* @brief Start an NfcScanner.
|
||||
*
|
||||
* @param[in,out] pointer to the instance to be started.
|
||||
* @param[in,out] instance pointer to the instance to be started.
|
||||
* @param[in] callback pointer to the callback function (will be called upon a detection event).
|
||||
* @param[in] context pointer to the caller-specific context (will be passed to the callback).
|
||||
*/
|
||||
|
|
@ -88,7 +88,7 @@ void nfc_scanner_start(NfcScanner* instance, NfcScannerCallback callback, void*
|
|||
/**
|
||||
* @brief Stop an NfcScanner.
|
||||
*
|
||||
* @param[in,out] pointer to the instance to be stopped.
|
||||
* @param[in,out] instance pointer to the instance to be stopped.
|
||||
*/
|
||||
void nfc_scanner_stop(NfcScanner* instance);
|
||||
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ FuriHalRtcHeapTrackMode furi_hal_rtc_get_heap_track_mode(void);
|
|||
|
||||
/** Set locale units
|
||||
*
|
||||
* @param[in] mode The RTC Locale Units
|
||||
* @param[in] value The RTC Locale Units
|
||||
*/
|
||||
void furi_hal_rtc_set_locale_units(FuriHalRtcLocaleUnits value);
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,8 @@ void furi_hal_bt_reinit();
|
|||
/** Change BLE app
|
||||
* Restarts 2nd core
|
||||
*
|
||||
* @param profile FuriHalBleProfileTemplate instance
|
||||
* @param profile_template FuriHalBleProfileTemplate instance
|
||||
* @param profile_params Parameters to pass to the profile. Can be NULL
|
||||
* @param event_cb GapEventCallback instance
|
||||
* @param context pointer to context
|
||||
*
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ bool furi_hal_i2c_tx(
|
|||
* @param size Size of data buffer
|
||||
* @param begin How to begin the transaction
|
||||
* @param end How to end the transaction
|
||||
* @param timer Timeout timer
|
||||
* @param timeout Timeout in milliseconds
|
||||
*
|
||||
* @return true on successful transfer, false otherwise
|
||||
*/
|
||||
|
|
@ -131,7 +131,7 @@ bool furi_hal_i2c_rx(
|
|||
* @param size Size of data buffer
|
||||
* @param begin How to begin the transaction
|
||||
* @param end How to end the transaction
|
||||
* @param timer Timeout timer
|
||||
* @param timeout Timeout in milliseconds
|
||||
*
|
||||
* @return true on successful transfer, false otherwise
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -36,15 +36,15 @@ typedef void (*FuriHalInfraredTxSignalSentISRCallback)(void* context);
|
|||
|
||||
/** Signature of callback function for receiving continuous INFRARED rx signal.
|
||||
*
|
||||
* @param ctx[in] context to pass to callback
|
||||
* @param level[in] level of input INFRARED rx signal
|
||||
* @param duration[in] duration of continuous rx signal level in us
|
||||
* @param[in] ctx context to pass to callback
|
||||
* @param[in] level level of input INFRARED rx signal
|
||||
* @param[in] duration duration of continuous rx signal level in us
|
||||
*/
|
||||
typedef void (*FuriHalInfraredRxCaptureCallback)(void* ctx, bool level, uint32_t duration);
|
||||
|
||||
/** Signature of callback function for reaching silence timeout on INFRARED port.
|
||||
*
|
||||
* @param ctx[in] context to pass to callback
|
||||
* @param[in] ctx context to pass to callback
|
||||
*/
|
||||
typedef void (*FuriHalInfraredRxTimeoutCallback)(void* ctx);
|
||||
|
||||
|
|
|
|||
|
|
@ -228,9 +228,9 @@ FuriHalNfcError furi_hal_nfc_poller_tx(const uint8_t* tx_data, size_t tx_bits);
|
|||
*
|
||||
* The receive buffer must be big enough to accomodate all of the expected data.
|
||||
*
|
||||
* @param rx_data[out] pointer to a byte array to be filled with received data.
|
||||
* @param rx_data_size[in] maximum received data size, in bytes.
|
||||
* @param rx_bits[out] pointer to the variable to hold received data size, in bits.
|
||||
* @param[out] rx_data pointer to a byte array to be filled with received data.
|
||||
* @param[in] rx_data_size maximum received data size, in bytes.
|
||||
* @param[out] rx_bits pointer to the variable to hold received data size, in bits.
|
||||
* @returns FuriHalNfcErrorNone on success, any other error code on failure.
|
||||
*/
|
||||
FuriHalNfcError furi_hal_nfc_poller_rx(uint8_t* rx_data, size_t rx_data_size, size_t* rx_bits);
|
||||
|
|
@ -249,9 +249,9 @@ FuriHalNfcError furi_hal_nfc_listener_tx(const uint8_t* tx_data, size_t tx_bits)
|
|||
*
|
||||
* The receive buffer must be big enough to accomodate all of the expected data.
|
||||
*
|
||||
* @param rx_data[out] pointer to a byte array to be filled with received data.
|
||||
* @param rx_data_size[in] maximum received data size, in bytes.
|
||||
* @param rx_bits[out] pointer to the variable to hold received data size, in bits.
|
||||
* @param[out] rx_data pointer to a byte array to be filled with received data.
|
||||
* @param[in] rx_data_size maximum received data size, in bytes.
|
||||
* @param[out] rx_bits pointer to the variable to hold received data size, in bits.
|
||||
* @returns FuriHalNfcErrorNone on success, any other error code on failure.
|
||||
*/
|
||||
FuriHalNfcError furi_hal_nfc_listener_rx(uint8_t* rx_data, size_t rx_data_size, size_t* rx_bits);
|
||||
|
|
@ -395,9 +395,9 @@ FuriHalNfcError furi_hal_nfc_iso14443a_tx_sdd_frame(const uint8_t* tx_data, size
|
|||
*
|
||||
* The receive buffer must be big enough to accomodate all of the expected data.
|
||||
*
|
||||
* @param rx_data[out] pointer to a byte array to be filled with received data.
|
||||
* @param rx_data_size[in] maximum received data size, in bytes.
|
||||
* @param rx_bits[out] pointer to the variable to hold received data size, in bits.
|
||||
* @param[in] rx_data pointer to a byte array to be filled with received data.
|
||||
* @param[in] rx_data_size maximum received data size, in bytes.
|
||||
* @param[in] rx_bits pointer to the variable to hold received data size, in bits.
|
||||
* @returns FuriHalNfcErrorNone on success, any other error code on failure.
|
||||
*/
|
||||
FuriHalNfcError
|
||||
|
|
|
|||
|
|
@ -135,9 +135,7 @@ float furi_hal_power_get_battery_charge_voltage_limit();
|
|||
*
|
||||
* Invalid values will be clamped downward to the nearest valid value.
|
||||
*
|
||||
* @param voltage[in] voltage in V
|
||||
*
|
||||
* @return voltage in V
|
||||
* @param[in] voltage voltage in V
|
||||
*/
|
||||
void furi_hal_power_set_battery_charge_voltage_limit(float voltage);
|
||||
|
||||
|
|
@ -161,7 +159,7 @@ uint32_t furi_hal_power_get_battery_design_capacity();
|
|||
|
||||
/** Get battery voltage in V
|
||||
*
|
||||
* @param ic FuriHalPowerIc to get measurment
|
||||
* @param[in] ic FuriHalPowerIc to get measurment
|
||||
*
|
||||
* @return voltage in V
|
||||
*/
|
||||
|
|
@ -169,7 +167,7 @@ float furi_hal_power_get_battery_voltage(FuriHalPowerIC ic);
|
|||
|
||||
/** Get battery current in A
|
||||
*
|
||||
* @param ic FuriHalPowerIc to get measurment
|
||||
* @param[in] ic FuriHalPowerIc to get measurment
|
||||
*
|
||||
* @return current in A
|
||||
*/
|
||||
|
|
@ -177,7 +175,7 @@ float furi_hal_power_get_battery_current(FuriHalPowerIC ic);
|
|||
|
||||
/** Get temperature in C
|
||||
*
|
||||
* @param ic FuriHalPowerIc to get measurment
|
||||
* @param[in] ic FuriHalPowerIc to get measurment
|
||||
*
|
||||
* @return temperature in C
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in a new issue