max/embassy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rewrite documentation using correct module names

Browse Source 
* Remove traits section now that we have embedded-hal-async and refer to
  it.
* Explanation that embassy is multiple things.
* Bootloader description image
This commit is contained in:
Ulf Lilleengen
2022-08-16 11:23:04 +02:00
parent 68931a36d5
commit d769e562c0
9 changed files with 43 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/modules/ROOT/pages/basic_application.adoc
View File

@ -21,7 +21,7 @@ Then, what follows are some declarations on how to deal with panics and faults.
[source,rust]
----
include::example$basic/src/main.rs[lines="5..6"]
include::example$basic/src/main.rs[lines="11..12"]
----
=== Task declaration
@ -30,7 +30,7 @@ After a bit of import declaration, the tasks run by the application should be de
[source,rust]
----
include::example$basic/src/main.rs[lines="18..27"]
include::example$basic/src/main.rs[lines="13..22"]
----
An 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
=== Main
The 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.
The 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.
The `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:
The `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:
[source,rust]
----
include::example$basic/src/main.rs[lines="28..-1"]
include::example$basic/src/main.rs[lines="23..-1"]
----
`#[embassy::main]` takes an optional `config` paramter specifying a function that returns an instance of HAL's `Config` struct. For example:
`#[embassy_executor::main]` takes an optional `config` parameter specifying a function that returns an instance of HAL's `Config` struct. For example:
```rust
fn embassy_config() -> embassy_nrf::config::Config {
embassy_nrf::config::Config::default()
}
#[embassy::main(config = "embassy_config()")]
async fn main(_spawner: embassy::executor::Spawner, p: embassy_nrf::Peripherals) {
#[embassy_executor::main(config = "embassy_config()")]
async fn main(_spawner: Spawner, p: embassy_nrf::Peripherals) {
// ...
}
```
What 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:
. Creates an Embassy Executor instance
. Initializes the microcontroller to get the `Peripherals`
. Creates an Embassy Executor
. Initializes the microcontroller HAL to get the `Peripherals`
. Defines a main task for the entry point
. Runs the executor spawning the main task