mirror of
https://github.com/embassy-rs/embassy.git
synced 2024-11-23 07:12:29 +00:00
Fix spelling and white space mistakes
This commit is contained in:
parent
f5f776f815
commit
9053b6b5b3
@ -12,5 +12,5 @@ listed source code repository logs.
|
||||
|
||||
This program and the accompanying materials are made available under the terms
|
||||
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
|
||||
|
@ -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.
|
||||
|
||||
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
|
||||
|
||||
@ -89,7 +89,7 @@ async fn main(spawner: Spawner) {
|
||||
|
||||
## 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/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
|
||||
|
||||
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
|
||||
must be told of the target project to work with. In the case of Visual Studio Code,
|
||||
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,
|
||||
please refer to the `.vscode/settings.json` file's `rust-analyzer.linkedProjects`setting.
|
||||
|
||||
## Minimum supported Rust version (MSRV)
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
An [Embassy](https://embassy.dev) project.
|
||||
|
||||
An adaptation of `embassy-boot` for nRF.
|
||||
An adaptation of `embassy-boot` for nRF.
|
||||
|
||||
## Features
|
||||
|
||||
|
@ -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.
|
||||
* 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.
|
||||
* 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:
|
||||
|
||||
|
@ -13,8 +13,8 @@ memory management designed to work well for embedded systems, aiming for a more
|
||||
- TCP, UDP, DNS, DHCPv4, IGMPv4
|
||||
- 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
|
||||
unimplemented features of the network protocols.
|
||||
See the [`smoltcp`](https://github.com/smoltcp-rs/smoltcp) README for a detailed list of implemented and
|
||||
unimplemented features of the network protocols.
|
||||
|
||||
## Hardware support
|
||||
|
||||
|
@ -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.
|
||||
|
||||
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.
|
||||
|
@ -5,7 +5,7 @@ Timekeeping, delays and timeouts.
|
||||
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
|
||||
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>.
|
||||
|
||||
Tick counts are 64 bits. The default tick rate of 1Mhz supports
|
||||
|
@ -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
|
||||
use dashes instead of underscores. For example. `max-interface-count-3`. Only a selection of values
|
||||
is available, check `Cargo.toml` for the list.
|
||||
- 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`.
|
||||
- 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`.
|
||||
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
|
||||
|
@ -2,16 +2,16 @@
|
||||
|
||||
## Overview
|
||||
|
||||
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 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.
|
||||
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.
|
||||
|
||||
## Memory Configuration
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Symbol Definitions
|
||||
|
||||
|
@ -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.
|
||||
//
|
||||
// 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_main]
|
||||
|
Loading…
Reference in New Issue
Block a user