proofread docs

ReadMe.md

@@ -9,8 +9,8 @@
 # Flipper Zero Firmware
 
 - [Flipper Zero Official Website](https://flipperzero.one). A simple way to explain to your friends what Flipper Zero can do.
-- [Flipper Zero Firmware Update](https://update.flipperzero.one). Improvements for your dolphin: latest firmware releases, upgrade tools for PC and mobile devices.
-- [User Documentation](https://docs.flipperzero.one). Learn more about your dolphin: specs, usage guides, and anything you want to ask.
+- [Flipper Zero Firmware Update](https://flipperzero.one/update). Improvements for your dolphin: latest firmware releases, upgrade tools for PC and mobile devices.
+- [User Documentation](https://docs.flipper.net). Learn more about your dolphin: specs, usage guides, and anything you want to ask.
 - [Developer Documentation](https://developer.flipper.net/flipperzero/doxygen). Dive into the Flipper Zero Firmware source code: build system, firmware structure, and more.
 
 # Contributing
@@ -19,7 +19,7 @@ Our main goal is to build a healthy and sustainable community around Flipper, so
 
 ## I need help
 
-The best place to search for answers is our [User Documentation](https://docs.flipperzero.one). If you can't find the answer there, check our [Discord Server](https://flipp.dev/discord) or our [Forum](https://forum.flipperzero.one/). If you want to contribute to the firmware development, or modify it for your own needs, you can also check our [Developer Documentation](https://developer.flipper.net/flipperzero/doxygen).
+The best place to search for answers is our [User Documentation](https://docs.flipper.net). If you can't find the answer there, check our [Discord Server](https://flipp.dev/discord) or our [Forum](https://forum.flipperzero.one/). If you want to contribute to the firmware development or modify it for your own needs, you can also check our [Developer Documentation](https://developer.flipper.net/flipperzero/doxygen).
 
 ## I want to report an issue
 

applications/examples/example_number_input/ReadMe.md

@@ -1,13 +1,13 @@
 # Number Input {#example_number_input}
 
-Simple keyboard that limits user inputs to a full number (integer). Useful to enforce correct entries without the need of intense validations after a user input. 
+Simple keyboard that limits user inputs to a full number (integer). Useful to enforce correct entries without the need for intense validations after a user input. 
 
 ## Source code
 
 Source code for this example can be found [here](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/examples/example_number_input).
 
 ## General principle
 
-Definition of min/max values is required. Numbers are of type int32_t. If negative numbers are allowed withing min - max, an additional button is displayed to switch the sign between + and -. 
+Definition of min/max values is required. Numbers are of type int32_t. If negative numbers are allowed within min - max, an additional button is displayed to switch the sign between + and -. 
 
-It is also possible to define a header text, shown in this example app with the 3 different input options. 
+It is also possible to define a header text, as shown in this example app with the 3 different input options. 

documentation/AppManifests.md

@@ -106,7 +106,7 @@ 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 app 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 app 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 the `loclass` library, `fbt` will add `lib/loclass` to the list of the included paths for the app 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 app.
 

documentation/AppsOnSDCard.md

@@ -10,7 +10,7 @@ FAPs do not depend on being run on a specific firmware version. Compatibility is
 
 FAPs are created and developed the same way as internal apps that are part of the firmware.
 
-To build your app as a FAP, create a folder with your app's source code in `applications_user`, then write its code the way you'd do when creating a regular built-in app. Then configure its `application.fam` manifest, and set its _apptype_ to FlipperAppType.EXTERNAL. See [Flipper App Manifests](AppManifests.md) for more details.
+To build your app as a FAP, create a folder with your app's source code in `applications_user`, then write its code the way you'd do when creating a regular built-in app. Then configure its `application.fam` manifest, and set its `apptype` to `FlipperAppType.EXTERNAL`. See [Flipper App Manifests](AppManifests.md) for more details.
 
 - To build your app, run `./fbt fap_{APPID}`, where APPID is your app's ID in its manifest.
 - To build your app and upload it over USB to run on Flipper, use `./fbt launch APPSRC=applications_user/path/to/app`. This command is configured in the default [VS Code profile](../.vscode/ReadMe.md) as a "Launch App on Flipper" build action (Ctrl+Shift+B menu).
@@ -33,7 +33,7 @@ Images and animated icons should follow the same [naming convention](../assets/R
 
 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.
 
-If debugging session is active, firmware will trigger a breakpoint after loading a FAP it into memory, but before running any code from it. This allows you to set breakpoints in the FAP's code. Note that any breakpoints set before the FAP is loaded may need re-setting after the FAP is actually loaded, since before loading it debugger cannot know the exact address of the FAP's code.
+If debugging session is active, firmware will trigger a breakpoint after loading a FAP into memory, but before running any code from it. This allows you to set breakpoints in the FAP's code. Note that any breakpoints set before the FAP is loaded may need re-setting after the FAP is actually loaded, since the debugger cannot know the exact address of the FAP's code before loading the FAP.
 
 ### Setting up debugging environment
 
@@ -45,15 +45,15 @@ To debug FAPs, do the following:
 2. Flash it with `./fbt flash`
 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.
+After that, you can attach the debugger with `./fbt debug` or VS Code and use all debug features.
 
 It is **important** that firmware and app build type (debug/release) match and that the matching firmware folder is linked as `build/latest`. Otherwise, debugging will not work.
 
 ## How Flipper runs an app from an SD card
 
 Flipper's MCU cannot run code directly from external storage, so it needs to be copied to RAM first. That is done by the App Loader app responsible for loading the FAP from the SD card, verifying its integrity and compatibility, copying it to RAM, and adjusting it for its new location.
 
-Since FAP has to be loaded to RAM to be executed, the amount of RAM available for allocations from heap is reduced compared to running the same app from flash, as a part of the firmware. Note that the amount of occupied RAM is less than the total FAP file size since only code and data sections are allocated, while the FAP file includes extra information only used at app load time.
+Since the FAP has to be loaded to RAM to be executed, the amount of RAM available for allocations from heap is reduced compared to running the same app from flash, as a part of the firmware. Note that the amount of occupied RAM is less than the total FAP file size since only code and data sections are allocated, while the FAP file includes extra information only used at app load time.
 
 Apps are built for a specific API version. It is a part of the hardware target's definition and contains a major and minor version number. The App Loader checks if the app's major API version matches the firmware's major API version.
 

documentation/ExpansionModules.md

@@ -29,7 +29,7 @@ Depending on the UART selected for communication, the following pins area availa
 
 ## Frame structure
 
-Each frame consists of a header (1 byte), contents (size depends of frame type) and checksum (1 byte) fields:
+Each frame consists of a header (1 byte), contents (size depends on frame type) and checksum (1 byte) fields:
 
 | Header (1 byte) | Contents (0 or more bytes) | Checksum (1 byte) |
 |-----------------|----------------------------|-------------------|
@@ -79,7 +79,7 @@ CONTROL frames are used to control various aspects of the communication and enab
 |-----------------|-------------------|-------------------|
 | 0x04            | Command           | XOR checksum      |
 
-The `Command` field SHALL have one of the followind values:
+The `Command` field SHALL have one of the following values:
 
 | Command | Meaning                  | Note |
 |---------|--------------------------|:----:|
@@ -96,7 +96,7 @@ Notes:
 
 ### Data frame
 
-DATA frames are used to transmit arbitrary data in either direction. Each DATA frame can hold up to 64 bytes. If an RPC session is curretly open, all received bytes are forwarded to it.
+DATA frames are used to transmit arbitrary data in either direction. Each DATA frame can hold up to 64 bytes. If an RPC session is currently open, all received bytes are forwarded to it.
 
 | Header (1 byte) | Contents (1 to 65 byte(s)) | Checksum (1 byte) |
 |-----------------|----------------------------|-------------------|
@@ -110,7 +110,7 @@ The `Data` field SHALL have the following structure:
 
 ## Communication flow
 
-In order for the host to be able to detect the module, the respective feature must be enabled first. This can be done via the GUI by going to `Settings -> Expansion Modules` and selecting the required `Listen UART` or programmatically by calling `expansion_enable()`. Likewise, disabling this feature via the same GUI or by calling `expansion_disable()` will result in ceasing all communications and not being able to detect any connected modules.
+In order for the host to be able to detect the module, the respective feature must be enabled first. This can be done via the GUI by going to `Settings → Expansion Modules` and selecting the required `Listen UART` or programmatically by calling `expansion_enable()`. Likewise, disabling this feature via the same GUI or by calling `expansion_disable()` will result in ceasing all communications and not being able to detect any connected modules.
 
 The communication is always initiated by the module by the means of shortly pulling the RX pin down. The host SHALL respond with a HEARTBEAT frame indicating that it is ready to receive requests. The module then MUST issue a BAUDRATE request within Tto. Failure to do so will result in the host dropping the connection and returning to its initial state.
 

documentation/FuriCheck.md

@@ -1,13 +1,13 @@
 # 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.
+For that purpose, we have a bunch of helpers located in Furi Core `check.h`.
 
 ## Couple notes before start
 
-- Definition of Crash - log event, save crash information in RTC and reboot the system.
-- Definition of Halt - log event, stall the system.
-- Debug and production builds behaves differently: debug build will never reset system in order to preserve state for debugging.
+- Definition of Crash — log event, save crash information in RTC and reboot the system.
+- Definition of Halt — log event, stall the system.
+- Debug and production builds behave differently: debug build will never reset system in order to preserve state for debugging.
 - If you have debugger connected we will stop before reboot automatically.
 - All helpers accept optional MESSAGE_CSTR: it can be in RAM or Flash memory, but only messages from Flash will be shown after system reboot.
 - MESSAGE_CSTR can be NULL, but macros magic already doing it for you, so just don't.
@@ -16,10 +16,10 @@ For that purpose we have bunch of helpers located in Furi Core check.h.
 
 Assert condition in development environment and crash the system if CONDITION is false.
 
-- Should be used at development stage in apps and services
-- Keep in mind that release never contains this check
-- Keep in mind that libraries never contains this check by default, use `LIB_DEBUG=1` if you need it
-- Avoid putting function calls into CONDITION, since it may be omitted in some builds
+- Should be used at development stage in apps and services.
+- Keep in mind that release never contains this check.
+- Keep in mind that libraries never contain this check by default, use `LIB_DEBUG=1` if you need it.
+- Avoid putting function calls into CONDITION, since it may be omitted in some builds.
 
 ## `furi_check(CONDITION)` or `furi_check(CONDITION, MESSAGE_CSTR)`
 
@@ -31,10 +31,10 @@ Always assert condition and crash the system if CONDITION is false.
 
 Crash the system.
 
-- Use it to crash the system. For example: if abnormal condition detected.
+- Use it to crash the system. For example, if an abnormal condition is detected.
 
 ## `furi_halt()` or `furi_halt(MESSAGE_CSTR)`
 
 Halt the system.
 
-- We use it internally to shutdown flipper if poweroff is not possible.
+- We use it internally to shutdown Flipper if poweroff is not possible.

documentation/FuriHalBus.md

@@ -5,7 +5,7 @@
 On system startup, most of the peripheral devices are under reset and not clocked by default. This is done to reduce power consumption and to guarantee that the device will always be in the same state before use.
 Some crucial peripherals are enabled right away by the system, others must be explicitly enabled by the user code.
 
-**NOTE:** Here and afterwards the word *"system"* refers to any code belonging to the operating system, hardware drivers or built-in applications.
+**NOTE:** Here and afterwards, the word *"system"* refers to any code belonging to the operating system, hardware drivers or built-in applications.
 
 To **ENABLE** a peripheral, call `furi_hal_bus_enable()`. At the time of the call, the peripheral in question MUST be disabled, otherwise a crash will occur to indicate improper use. This means that any given peripheral cannot be enabled twice or more without disabling it first.
 
@@ -24,7 +24,7 @@ Built-in peripherals are divided into three categories:
 
 Below is the list of peripherals that are enabled by the system. The user code must NEVER attempt to disable them. If a corresponding API is provided, the user code must employ it in order to access the peripheral.
 
-*Table 1* - Peripherals enabled by the system
+*Table 1* — Peripherals enabled by the system
 
 | Peripheral    | Enabled at                |
 | :-----------: | :-----------------------: |
@@ -49,7 +49,7 @@ Below is the list of peripherals that are enabled and disabled by the system. Th
 
 When not using the API, these peripherals MUST be enabled by the user code and then disabled when not needed anymore.
 
-*Table 2* - Peripherals enabled and disabled by the system
+*Table 2* — Peripherals enabled and disabled by the system
 
 | Peripheral    | API header file       |
 | :-----------: | :-------------------: |
@@ -69,7 +69,7 @@ Below is the list of peripherals that are not enabled by default and MUST be ena
 Note that some of these peripherals may also be used by the system to implement its certain features.
 The system will take over any given peripheral only when the respective feature is in use.
 
-*Table 3* - Peripherals enabled and disabled by user
+*Table 3* — Peripherals enabled and disabled by user
 
 | Peripheral    | System    | Purpose                               |
 | :-----------: | :-------: | ------------------------------------- |
@@ -93,7 +93,7 @@ The DMA1,2 peripherals are a special case in that they have multiple independent
 
 Below is the list of DMA channels and their usage by the system.
 
-*Table 4* - DMA channels
+*Table 4* — DMA channels
 
 | DMA   | Channel   | System    | Purpose                   |
 | :---: | :-------: | :-------: | ------------------------- |

documentation/FuriHalDebuging.md

@@ -1,7 +1,7 @@
 # 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.
+Some Furi subsystems have 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.
 
 
 ## FuriHalOs
@@ -10,9 +10,9 @@ Usually they are used for low level tracing and profiling or signal redirection/
 
 There are 3 signals that will be exposed to external GPIO pins:
 
-- `AWAKE`   - `PA7` - High when system is busy with computations, low when sleeping. Can be used to track transitions to sleep mode.
-- `TICK`    - `PA6` - Flipped on system tick, only flips when no tick suppression in progress. Can be used to track tick skew and abnormal task scheduling.
-- `SECOND`  - `PA4` - Flipped each second. Can be used for tracing RT issue: time flow disturbance means system doesn't conforms Hard RT.
+- `AWAKE`   — `PA7` — High when system is busy with computations, low when sleeping. Can be used to track transitions to sleep mode.
+- `TICK`    — `PA6` — Flipped on system tick, only flips when no tick suppression in progress. Can be used to track tick skew and abnormal task scheduling.
+- `SECOND`  — `PA4` — Flipped each second. Can be used for tracing RT issue: time flow disturbance means system doesn't conform Hard RT.
 
 
 
@@ -22,8 +22,8 @@ There are 3 signals that will be exposed to external GPIO pins:
 
 There are 2 signals that will be exposed to external GPIO pins:
 
-- `WFI`     - `PB2` - Light sleep (wait for interrupt) used. Basically this is lightest and most non-breaking things power save mode. All function and debug should work correctly in this mode.
-- `STOP`    - `PC3` - STOP mode used. Platform deep sleep mode. Extremely fragile mode where most of the silicon is disabled or in unusable state. Debugging MCU in this mode is nearly impossible.
+- `WFI`     — `PB2` — Light sleep (wait for interrupt) used. Basically, this is the lightest and most non-breaking things power save mode. All functions and debug should work correctly in this mode.
+- `STOP`    — `PC3` — STOP mode used. Platform deep sleep mode. Extremely fragile mode where most of the silicon is disabled or in unusable state. Debugging MCU in this mode is nearly impossible.
 
 ## FuriHalSD