aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorUlf Lilleengen <[email protected]>2022-08-16 11:23:04 +0200
committerUlf Lilleengen <[email protected]>2022-08-16 11:27:57 +0200
commitd769e562c04261d86916f53c83e44d1a51f59c76 (patch)
tree8923160b860b773899e9d73ba0c42383219122b6
parent68931a36d5b04151cbe2bd343253b6bfffd8a7d6 (diff)
Rewrite documentation using correct module names
* Remove traits section now that we have embedded-hal-async and refer to it. * Explanation that embassy is multiple things. * Bootloader description image
-rw-r--r--docs/modules/ROOT/images/bootloader_flash.pngbin0 -> 32147 bytes
-rw-r--r--docs/modules/ROOT/nav.adoc12
-rw-r--r--docs/modules/ROOT/pages/basic_application.adoc20
-rw-r--r--docs/modules/ROOT/pages/bootloader.adoc5
-rw-r--r--docs/modules/ROOT/pages/getting_started.adoc6
-rw-r--r--docs/modules/ROOT/pages/hal.adoc5
-rw-r--r--docs/modules/ROOT/pages/index.adoc18
-rw-r--r--docs/modules/ROOT/pages/runtime.adoc4
-rw-r--r--docs/modules/ROOT/pages/traits.adoc8
9 files changed, 43 insertions, 35 deletions
diff --git a/docs/modules/ROOT/images/bootloader_flash.png b/docs/modules/ROOT/images/bootloader_flash.png
new file mode 100644
index 000000000..635783b05
--- /dev/null
+++ b/docs/modules/ROOT/images/bootloader_flash.png
Binary files differ
diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index a45da1958..86f2996f1 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -1,10 +1,10 @@
1* xref:runtime.adoc[Runtime]
2* xref:traits.adoc[APIs]
3* xref:hal.adoc[Hardware Abstraction Layer]
4** xref:nrf.adoc[nRF]
5** xref:stm32.adoc[STM32]
6* xref:bootloader.adoc[Bootloader]
7* xref:getting_started.adoc[Getting started] 1* xref:getting_started.adoc[Getting started]
8** xref:basic_application.adoc[Basic application] 2** xref:basic_application.adoc[Basic application]
9** xref:layer_by_layer.adoc[Layer by Layer] 3** xref:layer_by_layer.adoc[Layer by Layer]
4* xref:runtime.adoc[Executor]
5* xref:hal.adoc[HAL]
6** xref:nrf.adoc[nRF]
7** xref:stm32.adoc[STM32]
8* xref:bootloader.adoc[Bootloader]
9
10* xref:examples.adoc[Examples] 10* xref:examples.adoc[Examples]
diff --git a/docs/modules/ROOT/pages/basic_application.adoc b/docs/modules/ROOT/pages/basic_application.adoc
index a8875aa93..4dc4a6359 100644
--- a/docs/modules/ROOT/pages/basic_application.adoc
+++ b/docs/modules/ROOT/pages/basic_application.adoc
@@ -21,7 +21,7 @@ Then, what follows are some declarations on how to deal with panics and faults.
21 21
22[source,rust] 22[source,rust]
23---- 23----
24include::example$basic/src/main.rs[lines="5..6"] 24include::example$basic/src/main.rs[lines="11..12"]
25---- 25----
26 26
27=== Task declaration 27=== Task declaration
@@ -30,7 +30,7 @@ After a bit of import declaration, the tasks run by the application should be de
30 30
31[source,rust] 31[source,rust]
32---- 32----
33include::example$basic/src/main.rs[lines="18..27"] 33include::example$basic/src/main.rs[lines="13..22"]
34---- 34----
35 35
36An embassy task must be declared `async`, and may NOT take generic arguments. In this case, we are handed the LED that should be blinked and the interval of the blinking. 36An embassy task must be declared `async`, and may NOT take generic arguments. In this case, we are handed the LED that should be blinked and the interval of the blinking.
@@ -39,32 +39,32 @@ NOTE: Notice that there is no busy waiting going on in this task. It is using th
39 39
40=== Main 40=== Main
41 41
42The main entry point of an Embassy application is defined using the `#[embassy::main]` macro. The entry point is also required to take a `Spawner` and a `Peripherals` argument. 42The main entry point of an Embassy application is defined using the `#[embassy_executor::main]` macro. The entry point is also required to take a `Spawner` and a `Peripherals` argument.
43 43
44The `Spawner` is the way the main application spawns other tasks. The `Peripherals` type holds all peripherals that the application may use. In this case, we want to configure one of the pins as a GPIO output driving the LED: 44The `Spawner` is the way the main application spawns other tasks. The `Peripherals` type comes from the HAL and holds all peripherals that the application may use. In this case, we want to configure one of the pins as a GPIO output driving the LED:
45 45
46[source,rust] 46[source,rust]
47---- 47----
48include::example$basic/src/main.rs[lines="28..-1"] 48include::example$basic/src/main.rs[lines="23..-1"]
49---- 49----
50 50
51`#[embassy::main]` takes an optional `config` paramter specifying a function that returns an instance of HAL's `Config` struct. For example: 51`#[embassy_executor::main]` takes an optional `config` parameter specifying a function that returns an instance of HAL's `Config` struct. For example:
52 52
53```rust 53```rust
54fn embassy_config() -> embassy_nrf::config::Config { 54fn embassy_config() -> embassy_nrf::config::Config {
55 embassy_nrf::config::Config::default() 55 embassy_nrf::config::Config::default()
56} 56}
57 57
58#[embassy::main(config = "embassy_config()")] 58#[embassy_executor::main(config = "embassy_config()")]
59async fn main(_spawner: embassy::executor::Spawner, p: embassy_nrf::Peripherals) { 59async fn main(_spawner: Spawner, p: embassy_nrf::Peripherals) {
60 // ... 60 // ...
61} 61}
62``` 62```
63 63
64What happens when the `blinker` task have been spawned and main returns? Well, the main entry point is actually just like any other task, except that you can only have one and it takes some specific type arguments. The magic lies within the `#[embassy::main]` macro. The macro does the following: 64What happens when the `blinker` task have been spawned and main returns? Well, the main entry point is actually just like any other task, except that you can only have one and it takes some specific type arguments. The magic lies within the `#[embassy::main]` macro. The macro does the following:
65 65
66. Creates an Embassy Executor instance 66. Creates an Embassy Executor
67. Initializes the microcontroller to get the `Peripherals` 67. Initializes the microcontroller HAL to get the `Peripherals`
68. Defines a main task for the entry point 68. Defines a main task for the entry point
69. Runs the executor spawning the main task 69. Runs the executor spawning the main task
70 70
diff --git a/docs/modules/ROOT/pages/bootloader.adoc b/docs/modules/ROOT/pages/bootloader.adoc
index 3df2daf51..ae92e9d5d 100644
--- a/docs/modules/ROOT/pages/bootloader.adoc
+++ b/docs/modules/ROOT/pages/bootloader.adoc
@@ -20,7 +20,10 @@ In general, the bootloader works on any platform that implements the `embedded-s
20 20
21== Design 21== Design
22 22
23The bootloader divides the storage into 4 main partitions, configured by a linker script: 23image::bootloader_flash.png[Bootloader flash layout]
24
25The bootloader divides the storage into 4 main partitions, configurable when creating the bootloader
26instance or via linker scripts:
24 27
25* BOOTLOADER - Where the bootloader is placed. The bootloader itself consumes about 8kB of flash. 28* BOOTLOADER - Where the bootloader is placed. The bootloader itself consumes about 8kB of flash.
26* ACTIVE - Where the main application is placed. The bootloader will attempt to load the application at the start of this partition. This partition is only written to by the bootloader. 29* ACTIVE - Where the main application is placed. The bootloader will attempt to load the application at the start of this partition. This partition is only written to by the bootloader.
diff --git a/docs/modules/ROOT/pages/getting_started.adoc b/docs/modules/ROOT/pages/getting_started.adoc
index 23102b3b5..f3492a3d0 100644
--- a/docs/modules/ROOT/pages/getting_started.adoc
+++ b/docs/modules/ROOT/pages/getting_started.adoc
@@ -46,15 +46,13 @@ You can run an example by opening a terminal and entering the following commands
46[source, bash] 46[source, bash]
47---- 47----
48cd examples/nrf 48cd examples/nrf
49DEFMT_LOG=info cargo run --bin blinky --release 49cargo run --bin blinky --release
50---- 50----
51 51
52IMPORTANT: The DEFMT_LOG environment variable controls the example log verbosity. If you do not specify it, you will not see anything logged to the console.
53
54== Whats next? 52== Whats next?
55 53
56Congratulations, you have your first Embassy application running! Here are some alternatives on where to go from here: 54Congratulations, you have your first Embassy application running! Here are some alternatives on where to go from here:
57 55
58* Read more about the xref:runtime.adoc[runtime]. 56* Read more about the xref:runtime.adoc[executor].
59* Read more about the xref:hal.adoc[HAL]. 57* Read more about the xref:hal.adoc[HAL].
60* Start xref:basic_application.adoc[writing your application]. 58* Start xref:basic_application.adoc[writing your application].
diff --git a/docs/modules/ROOT/pages/hal.adoc b/docs/modules/ROOT/pages/hal.adoc
index 0b15e2fce..de4ab33be 100644
--- a/docs/modules/ROOT/pages/hal.adoc
+++ b/docs/modules/ROOT/pages/hal.adoc
@@ -1,9 +1,10 @@
1= Hardware Abstraction Layer (HAL) 1= Hardware Abstraction Layer (HAL)
2 2
3Embassy provides HAL's for several microcontroller families: 3Embassy provides HALs for several microcontroller families:
4 4
5* `embassy-nrf` for the nRF microcontrollers from Nordic Semiconductor 5* `embassy-nrf` for the nRF microcontrollers from Nordic Semiconductor
6* `embassy-stm32` for STM32 microcontrollers from ST Microelectronics 6* `embassy-stm32` for STM32 microcontrollers from ST Microelectronics
7* `embassy-rp` for the Raspberry Pi RP2040 microcontrollers 7* `embassy-rp` for the Raspberry Pi RP2040 microcontrollers
8 8
9These HALs implement async/await functionality for most peripherals while also implementing the async traits in Embassy. 9These HALs implement async/await functionality for most peripherals while also implementing the
10async traits in `embedded-hal-async`. You can also use these HALs with another executor.
diff --git a/docs/modules/ROOT/pages/index.adoc b/docs/modules/ROOT/pages/index.adoc
index 9a14e465d..0a17c6739 100644
--- a/docs/modules/ROOT/pages/index.adoc
+++ b/docs/modules/ROOT/pages/index.adoc
@@ -15,6 +15,20 @@ In Rust, non-blocking operations can be implemented using async-await. Async-awa
15 15
16== What is Embassy? 16== What is Embassy?
17 17
18Embassy is an executor and a Hardware Access Layer (HAL). The executor is a scheduler that generally executes a fixed number of tasks, allocated at startup, though more can be added later. The HAL is an API that you can use to access peripherals, such as USART, UART, I2C, SPI, CAN, and USB. Embassy provides implementations of both async and blocking APIs where it makes sense. DMA (Direct Memory Access) is an example where async is a good fit, whereas GPIO states are a better fit for a blocking API. 18The Embassy project consists of several crates that you can use together or independently:
19 19
20Embassy may also provide a system timer that you can use for both async and blocking delays. For less than one microsecond, blocking delays should be used because the cost of context-switching is too high and the executor will be unable to provide accurate timing. 20* **Executor** - The link:https://docs.embassy.dev/embassy-executor/[embassy-executor] is an async/await executor that generally executes a fixed number of tasks, allocated at startup, though more can be added later. The HAL is an API that you can use to access peripherals, such as USART, UART, I2C, SPI, CAN, and USB. Embassy provides implementations of both async and blocking APIs where it makes sense. DMA (Direct Memory Access) is an example where async is a good fit, whereas GPIO states are a better fit for a blocking API. The executor may also provide a system timer that you can use for both async and blocking delays. For less than one microsecond, blocking delays should be used because the cost of context-switching is too high and the executor will be unable to provide accurate timing.
21
22* **Hardware Abstraction Layers** - HALs implement safe, idiomatic Rust APIs to use the hardware capabilities, so raw register manipulation is not needed. The Embassy project maintains HALs for select hardware, but you can still use HALs from other projects with Embassy.
23** link:https://docs.embassy.dev/embassy-stm32/[embassy-stm32], for all STM32 microcontroller families.
24** link:https://docs.embassy.dev/embassy-nrf/[embassy-nrf], for the Nordic Semiconductor nRF52, nRF53, nRF91 series.
25
26* **Networking** - The link:https://docs.embassy.dev/embassy-net/[embassy-net] network stack implements extensive networking functionality, including Ethernet, IP, TCP, UDP, ICMP and DHCP. Async drastically simplifies managing timeouts and serving multiple connections concurrently.
27
28* **Bluetooth** - The link:https://github.com/embassy-rs/nrf-softdevice[nrf-softdevice] crate provides Bluetooth Low Energy 4.x and 5.x support for nRF52 microcontrollers.
29
30* **LoRa** - link:https://docs.embassy.dev/embassy-lora/[embassy-lora] supports LoRa networking on STM32WL wireless microcontrollers and Semtech SX127x transceivers.
31
32* **USB** - link:https://docs.embassy.dev/embassy-usb/[embassy-usb] implements a device-side USB stack. Implementations for common classes such as USB serial (CDC ACM) and USB HID are available, and a rich builder API allows building your own.
33
34* **Bootloader and DFU** - link:https://github.com/embassy-rs/embassy/tree/master/embassy-boot[embassy-boot] is a lightweight bootloader supporting firmware application upgrades in a power-fail-safe way, with trial boots and rollbacks.
diff --git a/docs/modules/ROOT/pages/runtime.adoc b/docs/modules/ROOT/pages/runtime.adoc
index 0adaa21a0..a7d6a8d0c 100644
--- a/docs/modules/ROOT/pages/runtime.adoc
+++ b/docs/modules/ROOT/pages/runtime.adoc
@@ -1,6 +1,6 @@
1= Embassy runtime 1= Embassy executor
2 2
3The Embassy runtime is an async/await executor designed for embedded usage along with support functionality for interrupts and timers. 3The Embassy executor is an async/await executor designed for embedded usage along with support functionality for interrupts and timers.
4 4
5== Features 5== Features
6 6
diff --git a/docs/modules/ROOT/pages/traits.adoc b/docs/modules/ROOT/pages/traits.adoc
deleted file mode 100644
index 38b8f2862..000000000
--- a/docs/modules/ROOT/pages/traits.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
1= Embassy Traits
2
3Embassy provides a set of traits and types specifically designed for `async` usage. Many of these futures will be upstreamed to the `embedded-hal` crate at some point in the future, probably when the required GAT (Generic Associated Types) feature is stabilized in Rust.
4
5* `embassy::io`: `AsyncBufRead`, `AsyncWrite`. Traits for byte-stream IO, essentially `no_std` compatible versions of `futures::io`. The primary reason for re-defining these traits is that the `futures::io` variant requires `std::io::Error`, which does not work in the `no_std` environment.
6* `embassy::time`: Time `Driver` trait that is implemented for different platforms. Time in Embassy is represented using the `Duration` and `Instant` types.
7
8These traits are implemented by the platform-specific crates, such as `embassy-nrf` or `embassy-stm32`.