diff options
Diffstat (limited to 'docs/modules/ROOT/pages/basic_application.adoc')
| -rw-r--r-- | docs/modules/ROOT/pages/basic_application.adoc | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/docs/modules/ROOT/pages/basic_application.adoc b/docs/modules/ROOT/pages/basic_application.adoc index 6d0d04383..95792d5a0 100644 --- a/docs/modules/ROOT/pages/basic_application.adoc +++ b/docs/modules/ROOT/pages/basic_application.adoc | |||
| @@ -6,9 +6,11 @@ So you've got one of the xref:examples.adoc[examples] running, but what now? Let | |||
| 6 | 6 | ||
| 7 | The full example can be found link:https://github.com/embassy-rs/embassy/tree/master/docs/modules/ROOT/examples/basic[here]. | 7 | The full example can be found link:https://github.com/embassy-rs/embassy/tree/master/docs/modules/ROOT/examples/basic[here]. |
| 8 | 8 | ||
| 9 | NOTE: If you’re using VS Code and rust-analyzer to view and edit the examples, you may need to make some changes to `.vscode/settings.json` to tell it which project we’re working on. Follow the instructions commented in that file to get rust-analyzer working correctly. | ||
| 10 | |||
| 9 | === Bare metal | 11 | === Bare metal |
| 10 | 12 | ||
| 11 | The first thing you'll notice is a few declarations, two of which indicate that Embassy is suitable for bare metal development: | 13 | The first thing you’ll notice are two attributes at the top of the file. These tells the compiler that program has no access to std, and that there is no main function (because it is not run by an OS). |
| 12 | 14 | ||
| 13 | [source,rust] | 15 | [source,rust] |
| 14 | ---- | 16 | ---- |
| @@ -48,9 +50,9 @@ NOTE: Notice that there is no busy waiting going on in this task. It is using th | |||
| 48 | 50 | ||
| 49 | === Main | 51 | === Main |
| 50 | 52 | ||
| 51 | 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. | 53 | The main entry point of an Embassy application is defined using the `#[embassy_executor::main]` macro. The entry point is passed a `Spawner`, which it can use to spawn other tasks. |
| 52 | 54 | ||
| 53 | 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: | 55 | We then initialize the HAL with a default config, which gives us a `Peripherals` struct we can use to access the MCU’s various peripherals. In this case, we want to configure one of the pins as a GPIO output driving the LED: |
| 54 | 56 | ||
| 55 | [source,rust] | 57 | [source,rust] |
| 56 | ---- | 58 | ---- |
| @@ -60,7 +62,6 @@ include::example$basic/src/main.rs[lines="22..-1"] | |||
| 60 | 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_executor::main]` macro. The macro does the following: | 62 | 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_executor::main]` macro. The macro does the following: |
| 61 | 63 | ||
| 62 | . Creates an Embassy Executor | 64 | . Creates an Embassy Executor |
| 63 | . Initializes the microcontroller HAL to get the `Peripherals` | ||
| 64 | . Defines a main task for the entry point | 65 | . Defines a main task for the entry point |
| 65 | . Runs the executor spawning the main task | 66 | . Runs the executor spawning the main task |
| 66 | 67 | ||