Merge #1058

1058: Fix some errors in the documentation r=lulf a=johannesneyer



Co-authored-by: Johannes Neyer <johannes.neyer@gmail.com>

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.
 
 [source,rust]
 ----
-include::example$basic/src/main.rs[lines="11..12"]
+include::example$basic/src/main.rs[lines="10"]
 ----
 
 === 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="13..22"]
+include::example$basic/src/main.rs[lines="12..20"]
 ----
 
 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.
@@ -45,23 +45,10 @@ The `Spawner` is the way the main application spawns other tasks. The `Periphera
 
 [source,rust]
 ----
-include::example$basic/src/main.rs[lines="23..-1"]
+include::example$basic/src/main.rs[lines="22..-1"]
 ----
 
-`#[embassy_executor::main]` takes an optional `config` parameter specifying a function that returns an instance of HAL's `Config` struct. For example:
+What happens when the `blinker` task has 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:
-
-```rust
-fn embassy_config() -> embassy_nrf::config::Config {
-    embassy_nrf::config::Config::default()
-}
-
-#[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
 . Initializes the microcontroller HAL to get the `Peripherals`
@@ -76,7 +63,7 @@ The project definition needs to contain the embassy dependencies:
 
 [source,toml]
 ----
-include::example$basic/Cargo.toml[lines="8..9"]
+include::example$basic/Cargo.toml[lines="9..11"]
 ----
 
 Depending on your microcontroller, you may need to replace `embassy-nrf` with something else (`embassy-stm32` for STM32. Remember to update feature flags as well).

docs/modules/ROOT/pages/layer_by_layer.adoc

@@ -8,7 +8,7 @@ The application we'll write is a simple 'push button, blink led' application, wh
 
 == PAC version
 
-The PAC is the lowest API for accessing peripherals and registers, if you don't count reading/writing directly to memory addresses. It provide distinct types
+The PAC is the lowest API for accessing peripherals and registers, if you don't count reading/writing directly to memory addresses. It provides distinct types
 to make accessing peripheral registers easier, but it does not prevent you from writing unsafe code.
 
 Writing an application using the PAC directly is therefore not recommended, but if the functionality you want to use is not exposed in the upper layers, that's what you need to use.
@@ -20,13 +20,13 @@ The blinky app using PAC is shown below:
 include::example$layer-by-layer/blinky-pac/src/main.rs[]
 ----
 
-As you can see, there are a lot of code needed to enable the peripheral clocks, configuring the input pins and the output pins of the application.
+As you can see, a lot of code is needed to enable the peripheral clocks and to configure the input pins and the output pins of the application.
 
 Another downside of this application is that it is busy-looping while polling the button state. This prevents the microcontroller from utilizing any sleep mode to save power.
 
 == HAL version
 
-To simplify our application, we can use the HAL instead. The HAL exposes higher level APIs that handle details such
+To simplify our application, we can use the HAL instead. The HAL exposes higher level APIs that handle details such as:
 
 * Automatically enabling the peripheral clock when you're using the peripheral
 * Deriving and applying register configuration from higher level types
@@ -39,7 +39,7 @@ The HAL example is shown below:
 include::example$layer-by-layer/blinky-hal/src/main.rs[]
 ----
 
-As you can see, the application becomes a lot simpler, even without using any async code. The `Input` and `Output` hides all the details accessing the GPIO registers, and allow you to use a much simpler API to query the state of the button and toggle the LED output accordingly.
+As you can see, the application becomes a lot simpler, even without using any async code. The `Input` and `Output` types hide all the details of accessing the GPIO registers and allow you to use a much simpler API for querying the state of the button and toggling the LED output.
 
 The same downside from the PAC example still applies though: the application is busy looping and consuming more power than necessary.
 

docs/modules/ROOT/pages/stm32.adoc

@@ -4,9 +4,9 @@ The link:https://github.com/embassy-rs/embassy/tree/master/embassy-stm32[Embassy
 
 == The infinite variant problem
 
-STM32 microcontrollers comes in many families and flavors, and supporting all of them is a big undertaking. Embassy has taken advantage of the fact
+STM32 microcontrollers come in many families, and flavors and supporting all of them is a big undertaking. Embassy has taken advantage of the fact
 that the STM32 peripheral versions are shared across chip families. Instead of re-implementing the SPI
-peripheral for every STM32 chip family, embassy have a single SPI implementation that depends on
+peripheral for every STM32 chip family, embassy has a single SPI implementation that depends on
 code-generated register types that are identical for STM32 families with the same version of a given peripheral.
 
 === The metapac