Fix spelling and white space mistakes

This commit is contained in:
Vega Deftwing 2024-04-11 19:45:38 +00:00
parent f5f776f815
commit 9053b6b5b3
10 changed files with 18 additions and 18 deletions

View File

@ -12,5 +12,5 @@ listed source code repository logs.
This program and the accompanying materials are made available under the terms This program and the accompanying materials are made available under the terms
of the Apache Software License 2.0 which is available at of the Apache Software License 2.0 which is available at
https://www.apache.org/licenses/LICENSE-2.0, or the MIT license which is https://www.apache.org/licenses/LICENSE-2.0, or the MIT license which is
available at https://opensource.org/licenses/MIT available at https://opensource.org/licenses/MIT

View File

@ -7,7 +7,7 @@ Embassy is the next-generation framework for embedded applications. Write safe,
The Rust programming language is blazingly fast and memory-efficient, with no runtime, garbage collector or OS. It catches a wide variety of bugs at compile time, thanks to its full memory- and thread-safety, and expressive type system. The Rust programming language is blazingly fast and memory-efficient, with no runtime, garbage collector or OS. It catches a wide variety of bugs at compile time, thanks to its full memory- and thread-safety, and expressive type system.
Rust's <a href="https://rust-lang.github.io/async-book/">async/await</a> allows for unprecedently easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation, and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is <a href="https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown">faster and smaller than one!</a> Rust's <a href="https://rust-lang.github.io/async-book/">async/await</a> allows for unprecedentedly easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation, and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is <a href="https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown">faster and smaller than one!</a>
## Batteries included ## Batteries included
@ -89,7 +89,7 @@ async fn main(spawner: Spawner) {
## Examples ## Examples
Examples are found in the `examples/` folder seperated by the chip manufacturer they are designed to run on. For example: Examples are found in the `examples/` folder separated by the chip manufacturer they are designed to run on. For example:
* `examples/nrf52840` run on the `nrf52840-dk` board (PCA10056) but should be easily adaptable to other nRF52 chips and boards. * `examples/nrf52840` run on the `nrf52840-dk` board (PCA10056) but should be easily adaptable to other nRF52 chips and boards.
* `examples/nrf5340` run on the `nrf5340-dk` board (PCA10095). * `examples/nrf5340` run on the `nrf5340-dk` board (PCA10095).
@ -130,8 +130,8 @@ For more help getting started, see [Getting Started][1] and [Running the Example
## Developing Embassy with Rust Analyzer based editors ## Developing Embassy with Rust Analyzer based editors
The [Rust Analyzer](https://rust-analyzer.github.io/) is used by [Visual Studio Code](https://code.visualstudio.com/) The [Rust Analyzer](https://rust-analyzer.github.io/) is used by [Visual Studio Code](https://code.visualstudio.com/)
and others. Given the multiple targets that Embassy serves, there is no Cargo workspace file. Instead, the Rust Analyzer and others. Given the multiple targets that Embassy serves, there is no Cargo workspace file. Instead, the Rust Analyzer
must be told of the target project to work with. In the case of Visual Studio Code, must be told of the target project to work with. In the case of Visual Studio Code,
please refer to the `.vscode/settings.json` file's `rust-analyzer.linkedProjects`setting. please refer to the `.vscode/settings.json` file's `rust-analyzer.linkedProjects`setting.
## Minimum supported Rust version (MSRV) ## Minimum supported Rust version (MSRV)

View File

@ -2,7 +2,7 @@
An [Embassy](https://embassy.dev) project. An [Embassy](https://embassy.dev) project.
An adaptation of `embassy-boot` for nRF. An adaptation of `embassy-boot` for nRF.
## Features ## Features

View File

@ -15,7 +15,7 @@ The bootloader divides the storage into 4 main partitions, configurable when cre
* BOOTLOADER - Where the bootloader is placed. The bootloader itself consumes about 8kB of flash, but if you need to debug it and have space available, increasing this to 24kB will allow you to run the bootloader with probe-rs. * BOOTLOADER - Where the bootloader is placed. The bootloader itself consumes about 8kB of flash, but if you need to debug it and have space available, increasing this to 24kB will allow you to run the bootloader with probe-rs.
* ACTIVE - Where the main application is placed. The bootloader will attempt to load the application at the start of this partition. The minimum size required for this partition is the size of your application. * ACTIVE - Where the main application is placed. The bootloader will attempt to load the application at the start of this partition. The minimum size required for this partition is the size of your application.
* DFU - Where the application-to-be-swapped is placed. This partition is written to by the application. This partition must be at least 1 page bigger than the ACTIVE partition. * DFU - Where the application-to-be-swapped is placed. This partition is written to by the application. This partition must be at least 1 page bigger than the ACTIVE partition.
* BOOTLOADER STATE - Where the bootloader stores the current state describing if the active and dfu partitions need to be swapped. * BOOTLOADER STATE - Where the bootloader stores the current state describing if the active and dfu partitions need to be swapped.
For any partition, the following preconditions are required: For any partition, the following preconditions are required:

View File

@ -13,8 +13,8 @@ memory management designed to work well for embedded systems, aiming for a more
- TCP, UDP, DNS, DHCPv4, IGMPv4 - TCP, UDP, DNS, DHCPv4, IGMPv4
- TCP sockets implement the `embedded-io` async traits. - TCP sockets implement the `embedded-io` async traits.
See the [`smoltcp`](https://github.com/smoltcp-rs/smoltcp) README for a detailed list of implemented and See the [`smoltcp`](https://github.com/smoltcp-rs/smoltcp) README for a detailed list of implemented and
unimplemented features of the network protocols. unimplemented features of the network protocols.
## Hardware support ## Hardware support

View File

@ -4,5 +4,5 @@ This crate contains the driver trait used by the [`embassy-time`](https://crates
You should rarely need to use this crate directly. Only use it when implementing your own timer queue. You should rarely need to use this crate directly. Only use it when implementing your own timer queue.
There is two timer queue implementations, one in `embassy-time` enabled by the `generic-queue` feature, and There is two timer queue implementations, one in `embassy-time` enabled by the `generic-queue` feature, and
another in `embassy-executor` enabled by the `integrated-timers` feature. another in `embassy-executor` enabled by the `integrated-timers` feature.

View File

@ -5,7 +5,7 @@ Timekeeping, delays and timeouts.
Timekeeping is done with elapsed time since system boot. Time is represented in Timekeeping is done with elapsed time since system boot. Time is represented in
ticks, where the tick rate is defined either by the driver (in the case of a fixed-rate ticks, where the tick rate is defined either by the driver (in the case of a fixed-rate
tick) or chosen by the user with a [tick rate](#tick-rate) feature. The chosen tick) or chosen by the user with a [tick rate](#tick-rate) feature. The chosen
tick rate applies to everything in `embassy-time` and thus determines the maximum tick rate applies to everything in `embassy-time` and thus determines the maximum
timing resolution of <code>(1 / tick_rate) seconds</code>. timing resolution of <code>(1 / tick_rate) seconds</code>.
Tick counts are 64 bits. The default tick rate of 1Mhz supports Tick counts are 64 bits. The default tick rate of 1Mhz supports

View File

@ -34,8 +34,8 @@ They can be set in two ways:
- Via Cargo features: enable a feature like `<name>-<value>`. `name` must be in lowercase and - Via Cargo features: enable a feature like `<name>-<value>`. `name` must be in lowercase and
use dashes instead of underscores. For example. `max-interface-count-3`. Only a selection of values use dashes instead of underscores. For example. `max-interface-count-3`. Only a selection of values
is available, check `Cargo.toml` for the list. is available, check `Cargo.toml` for the list.
- Via environment variables at build time: set the variable named `EMBASSY_USB_<value>`. For example - Via environment variables at build time: set the variable named `EMBASSY_USB_<value>`. For example
`EMBASSY_USB_MAX_INTERFACE_COUNT=3 cargo build`. You can also set them in the `[env]` section of `.cargo/config.toml`. `EMBASSY_USB_MAX_INTERFACE_COUNT=3 cargo build`. You can also set them in the `[env]` section of `.cargo/config.toml`.
Any value can be set, unlike with Cargo features. Any value can be set, unlike with Cargo features.
Environment variables take precedence over Cargo features. If two Cargo features are enabled for the same setting Environment variables take precedence over Cargo features. If two Cargo features are enabled for the same setting

View File

@ -2,16 +2,16 @@
## Overview ## Overview
This bootloader leverages `embassy-boot` to interact with the flash. This bootloader leverages `embassy-boot` to interact with the flash.
This example targets STM32 devices with dual-bank flash memory, with a primary focus on the STM32H747XI series. This example targets STM32 devices with dual-bank flash memory, with a primary focus on the STM32H747XI series.
Users must modify the `memory.x` configuration file to match with the memory layout of their specific STM32 device. Users must modify the `memory.x` configuration file to match with the memory layout of their specific STM32 device.
Additionally, this example can be extended to utilize external flash memory, such as QSPI, for storing partitions. Additionally, this example can be extended to utilize external flash memory, such as QSPI, for storing partitions.
## Memory Configuration ## Memory Configuration
In this example's `memory.x` file, various symbols are defined to assist in effective memory management within the bootloader environment. In this example's `memory.x` file, various symbols are defined to assist in effective memory management within the bootloader environment.
For dual-bank STM32 devices, it's crucial to assign these symbols correctly to their respective memory banks. For dual-bank STM32 devices, it's crucial to assign these symbols correctly to their respective memory banks.
### Symbol Definitions ### Symbol Definitions

View File

@ -8,7 +8,7 @@
// If you want to save SPI for other purpose, you may want to take a look at `ws2812_pwm_dma.rs` file, which make use of TIM and DMA. // If you want to save SPI for other purpose, you may want to take a look at `ws2812_pwm_dma.rs` file, which make use of TIM and DMA.
// //
// Warning: // Warning:
// DO NOT stare at ws2812 directy (especially after each MCU Reset), its (max) brightness could easily make your eyes feel burn. // DO NOT stare at ws2812 directly (especially after each MCU Reset), its (max) brightness could easily make your eyes feel burn.
#![no_std] #![no_std]
#![no_main] #![no_main]