liz/flipperzero-firmware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixing various typos in readme files #2208

Browse Source 
Co-authored-by: Konstantin Volkov <k.volkov@flipperdevices.com>
This commit is contained in:
Konstantin Volkov
2022-12-28 17:30:20 +03:00
committed by GitHub
parent 3108dc7c8c
commit 27ee0f73f7
13 changed files with 29 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/AppManifests.md
View File

@@ -57,8 +57,10 @@ The following parameters are used only for [FAPs](./AppsOnSDCard.md):
* **fap_weburl**: string, may be empty. Application's homepage.
* **fap_icon_assets**: string. If present defines a folder name to be used for gathering image assets for this application. These images will be preprocessed and built alongside the application. See [FAP assets](./AppsOnSDCard.md#fap-assets) for details.
* **fap_extbuild**: provides support for parts of application sources to be built by external tools. Contains a list of `ExtFile(path="file name", command="shell command")` definitions. **`fbt`** will run the specified command for each file in the list.
Note that commands are executed at the firmware root folder's root, and all intermediate files must be placed in 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:
```python

2
documentation/AppsOnSDCard.md
View File

@@ -37,7 +37,7 @@ With it, you can debug FAPs as if they were a part of main firmware — inspect
### Setting up debugging environment
Debugging support script looks up debugging information in latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
Debugging support script looks up debugging information in the latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
So, to debug FAPs, do the following:
1. Build firmware with `./fbt`

2
documentation/file_formats/BadUsbScriptFormat.md
View File

@@ -1,5 +1,5 @@
# Command syntax
BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more fuctional keys.
BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more functional keys.
# Script file format
BadUsb app can execute only text scrips from .txt files, no compilation is required. Both `\n` and `\r\n` line endings are supported. Empty lines are allowed. You can use spaces ore tabs for line indentation.
# Command set

10
documentation/file_formats/InfraredFileFormats.md
View File

@@ -95,17 +95,17 @@ Note: a single parsed signal must be represented as an array of size 1.
| data | raw | uint32 | Ditto. |
#### Signal names
The signal names in an `.irtest` file folow a convention `<name><test_number>`, where the name is one of:
The signal names in an `.irtest` file follow a convention `<name><test_number>`, where the name is one of:
- decoder_input
- decoder_expected
- encoder_decoder_input,
and the number is a sequential integer: 1, 2, 3...etc, which produces names like `decoder_input1`, `encoder_decoder_input3`, and so on.
| Name | Type | Description |
| --------------------- | ------------ | ----------- |
| decoder_input | raw | A raw signal contaning the decoder input. Is also used as the expected encoder output. |
| Name | Type | Description |
| --------------------- | ------------ |-------------------------------------------------------------------------------------------------------|
| decoder_input | raw | A raw signal containing the decoder input. Is also used as the expected encoder output. |
| decoder_expected | parsed_array | An array of parsed signals containing the expected decoder output. Is also used as the encoder input. |
| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
See [Unit Tests](/documentation/UnitTests.md#infrared) for more info.

2
documentation/file_formats/NfcFileFormats.md
View File

@@ -68,7 +68,7 @@ This file format is used to store the UID, SAK and ATQA of a Mifare Ultralight/N
The "Signature" field contains the reply of the tag to the READ_SIG command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 31)
The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the responce of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the response of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
Other fields are the direct representation of the card's internal state, more on them can be found in the same datasheet.

2
documentation/file_formats/SubGhzFileFormats.md
View File

@@ -197,7 +197,7 @@ For each key, a name and encryption method must be specified, according to comme
## SubGhz `setting_user` File
This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is be loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is being loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
### File Format