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
|
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
|
||||||
|
@ -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)
|
||||||
|
@ -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
|
||||||
|
|
||||||
|
@ -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:
|
||||||
|
|
||||||
|
@ -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
|
||||||
|
|
||||||
|
@ -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.
|
||||||
|
@ -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
|
||||||
|
@ -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
|
||||||
|
@ -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
|
||||||
|
|
||||||
|
@ -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]
|
||||||
|
Loading…
Reference in New Issue
Block a user