Fix a couple of typos (#91)

README.md

@@ -3,7 +3,7 @@
 ## Development
 
 The entire webpage is built with [zola](https://www.getzola.org/) which is based on statically compiled Markdown and [tera](https://github.com/Keats/tera) templates.
-You can run the file watcher & compiler with `zola serve` during development. The webpage will automatically be reloaded everytime you change any involved file.
+You can run the file watcher & compiler with `zola serve` during development. The webpage will automatically be reloaded every time you change any involved file.
 
 Currently, zola version 0.14 or higher is used.
 

content/authors/_index.md

@@ -5,7 +5,7 @@ date = 2021-04-01T08:00:00+00:00
 updated = 2021-04-01T08:00:00+00:00
 draft = false
 
-# If add a new author page in this section, please add a new item,
+# If you add a new author page in this section, please add a new item,
 # and the format is as follows:
 #
 # "author-name-in-url" = "the-full-path-of-the-author-page"

content/blog/release-0.11.0.md

@@ -48,7 +48,7 @@ We have a whole error/hint catalogue and try to expand this. This feature can ea
 cargo-embed got two big quality of life improvements:
 
 - RTT and the GDB server can now run concurrently. Previously this was not possible at all. Now you can enable RTT and GDB at the same time. Make sure to put `RUST_LOG=off` such that the GDB server does not print into the RTT UI. This is of course a bit suboptimal and we are working better ways to use RTT unhindered.
-- Typos or non-existant config flags are now spotted and reported to the user, such that things like `enable` vs `enabled` do not cost you hours of debugging anymore.
+- Typos or non-existent config flags are now spotted and reported to the user, such that things like `enable` vs `enabled` do not cost you hours of debugging anymore.
 
 ## Ongoing Work & Behind the Scenes
 

content/docs/introduction/state-of-the-art.md

@@ -22,7 +22,7 @@ To understand why we need another tool, we describe existing tools in the next p
 
 **Positive**
 
-+ Supports an extreme amount of targes.
++ Supports an extreme amount of targets.
 + Includes a lot of features and gets new chip additions frequently.
 + The tools are very stable.
 + Integrated into many IDEs and manufacturer tooling.
@@ -34,13 +34,13 @@ To understand why we need another tool, we describe existing tools in the next p
 - The J-Link is quite expensive (200$+) for non-educational purposes though you can get a lesser version for 50$ if you use it for educational purposes.
 - GDB based tooling; more on why this is bad, see [GDB](/guide/introduction/state-of-the-art/#gdb).
 - Tooling has nineties UI and UX.
-- The libary is not free to use.
+- The library is not free to use.
 
 ## OpenOCD
 
 **Positive**
 
-+ Supports an extreme amount of targes.
++ Supports an extreme amount of targets.
 + Supports a lot of probes.
 + Integrated into many IDEs and manufacturer tooling.
 + Exists for a long time and has a lot of contributors.

content/docs/knowledge-base/cmsis-packs.md

@@ -114,7 +114,7 @@ flash_algorithms:
       program_page_timeout: number
       # How long a sector erase procedure can take.
       erase_sector_timeout: number
-      # The sectors this piece of flash consists of. A sector is the eraseable unit.
+      # The sectors this piece of flash consists of. A sector is the erasable unit.
       sectors:
         # The size of the sectors starting form the address below.
         - size: number

content/docs/knowledge-base/troubleshooting.md

@@ -1,6 +1,6 @@
 +++
 title = "Troubleshooting"
-description = "Troubleshooting problems that may arrise during use"
+description = "Troubleshooting problems that may arise during use"
 date = 2023-04-28T08:00:00+00:00
 updated = 2023-04-28T08:00:00+00:00
 draft = false
@@ -24,7 +24,7 @@ More info on DEFMT filtering levels [here](https://defmt.ferrous-systems.com/fil
 This can be set multiple ways:
 - If using `cargo run` on a probe-rs based runner:
   - `ENV VAR` at build time: `DEFMT_LOG=trace cargo build ...`
-  - In `.cargo/config.toml` **Note:** there is a bug in cargo that does not automatically recognise changes when rebuilding.
+  - In `.cargo/config.toml` **Note:** there is a bug in cargo that does not automatically recognize changes when rebuilding.
     ```toml
     [env]
     DEFMT_LOG = "trace"
@@ -65,7 +65,7 @@ This can be set multiple ways:
     ``` toml
     runner = "probe-rs-cli run --chip STM32L451RCTx"
     ```
-- If using VSCode plugin in `launch.json` confgurations/chip
+- If using VSCode plugin in `launch.json` configurations/chip
     ```json
     "configurations": [
         {
@@ -88,4 +88,4 @@ use defmt_rtt as _;
 
 **Make sure tooling is up to date:**
 
-As with any set of tools being activly developed and improved, sometimes if one part is updated and there is a breaking change, the other tools must be updated as well in order to function.
+As with any set of tools being actively developed and improved, sometimes if one part is updated and there is a breaking change, the other tools must be updated as well in order to function.

content/docs/library/basics.md

@@ -47,7 +47,7 @@ let session = probes[0].attach("nRF52")?;
 ```
 
 Now we have got our [Session](https://docs.rs/probe-rs/*/probe_rs/struct.Session.html) ready to conduct further business.
-Take a closer look at the [::attach()](https://docs.rs/probe-rs/*/probe_rs/struct.Probe.html#method.attach) call. Appart from passing a chip name, you can also pass various other arguments for selecting the chip.
+Take a closer look at the [::attach()](https://docs.rs/probe-rs/*/probe_rs/struct.Probe.html#method.attach) call. Apart from passing a chip name, you can also pass various other arguments for selecting the chip.
 
 ## The Session struct
 
@@ -71,7 +71,7 @@ The [Core](https://docs.rs/probe-rs/*/probe_rs/struct.Core.html) is probably the
 With the core struct you can manipulate the CPU and it's accessible memories.
 
 In the previous sections we have learned how we attach to a core. 
-Someties you want to access the core operations in quick fashion. 
+Sometimes you want to access the core operations in quick fashion. 
 This is what [Session::auto_attach()](https://docs.rs/probe-rs/*/probe_rs/struct.Session.html#method.auto_attach) is for. 
 It lets you attach to the Core without first opening a Probe. 
 It will try to open a connected prbe, and select the Core as best as it can
@@ -137,7 +137,7 @@ core.set_hw_breakpoint(address)?;
 core.clear_hw_breakpoint(address)?;
 ```
 
-Of course manipulating the CPU alone is not enough. Therefore it's also possible to access the memories that are phyiscally accessible by the CPU.
+Of course manipulating the CPU alone is not enough. Therefore it's also possible to access the memories that are physically accessible by the CPU.
 
 ```rs
 // We can read a single word for the convenience of reading registers.

content/docs/library/crosscompiling.md

@@ -80,4 +80,4 @@ You now have a statically built `cargo-flash` binary inside the `target/<archite
 
 ## Using LLVM
 
-As using `LLVM` for cosscompiling can go out of the scope of just generating a `cargo-flash` binary, please follow the instructions on how to crosscompile in the **LLVM** [guide](https://www.llvm.org/docs/HowToCrossCompileLLVM.html).
+As using `LLVM` for crosscompiling can go out of the scope of just generating a `cargo-flash` binary, please follow the instructions on how to crosscompile in the **LLVM** [guide](https://www.llvm.org/docs/HowToCrossCompileLLVM.html).

content/docs/library/quickstart.md

@@ -42,7 +42,7 @@ Want to do
 * automatic WCET analysis?
 * automatic firmware downloads in your project?
 
-**probe-rs** was designed with such usecases in mind.
+**probe-rs** was designed with such use-cases in mind.
 
 Read more about [the structure](/guide/basics#structure).
 

content/docs/tools/cargo-embed.md

@@ -292,7 +292,7 @@ figure it when you examine channel two ;)
 
 On the host side it looks like
 
-![Output of chree channels](/img/cargo-embed.png)
+![Output of three channels](/img/cargo-embed.png)
 
 As you can observe, we see all three up channels. You can switch to and from them with the F-keys.
 The down channel will automatically be associated with the corresponding up channel and an input field will

content/docs/tools/vscode.md

@@ -275,7 +275,7 @@ Adding DEFMT_LOG to `tasks.json`
 
 - [x] **Launch**: Start a debug session on the target by (optionally) flashing the target firmware.
 - [x] **Attach**:
-- [x] By default, VSCode will manage (start/stop) the `probe-rs dap-server` process to facilite a debug session against a target process. It is also possible for the user to manage the `probe-rs dap-server` as a standalone process, and then use TCIP/IP port to connect to from VSCode.
+- [x] By default, VSCode will manage (start/stop) the `probe-rs dap-server` process to facilitate a debug session against a target process. It is also possible for the user to manage the `probe-rs dap-server` as a standalone process, and then use TCIP/IP port to connect to from VSCode.
 - [x] **Connect** to the target with `probe-rs`
   - [x] Supports `connect-under-reset` for select targets.
   - [x] Tested against the following architectures:
@@ -295,12 +295,12 @@ Adding DEFMT_LOG to `tasks.json`
   - [x] In VSCode `Source view`, breakpoint locations will automatically be adjusted to code boundaries that lie safely between function prologues and epilogues.
   - [x] In VSCode `Disassembly view`, breakpoints are set at, and stepping works at, 'instruction level'
 - [x] **UPDATED: Stepping** through executing code during debug:
-  - [x] Supports stepping at 'statement' level with `Step Over`, `Step Into`, `Step Out`. Stepping desitnations will automatically be adjusted to code boundaries that lie safely between function prologues and epilogues.
+  - [x] Supports stepping at 'statement' level with `Step Over`, `Step Into`, `Step Out`. Stepping destinations will automatically be adjusted to code boundaries that lie safely between function prologues and epilogues.
   - [x] While VSCode 'Disassembly view` is open, all stepping automatically happens at 'instruction' granularity, and will allow the user to step to any target location, including instructions in a function prologue or epilogue.
 - [x] **Variables View**
   - [x] View values of core **Registers**, and changes during code execution
   - [x] View values of **Locals** and **Statics** variables, and update values during code execution.
-    - [x] Shows datatypes and values for the following Rust datatypes.
+    - [x] Shows data types and values for the following Rust data types.
       - [x] Base types, including &str
       - [x] Enumerations
       - [x] Structures
@@ -316,7 +316,7 @@ Adding DEFMT_LOG to `tasks.json`
     - [x] Use the `View Binary Data` command in VSCode to perform binary memory edits on the target device.
 - [x] **Call Stack View**
   - [x] Supports a single thread, for a single core of the chip, but will **allow selection of any frames** that are in the current thread
-  - [x] Supports the VSCode `Dissambly` view, and `SetInstructionBreakpoints`
+  - [x] Supports the VSCode `Disassembly` view, and `SetInstructionBreakpoints`
   - [ ] TODO: Support multiple threads
   - [ ] TODO: Support chips with multiple cores
 - [x] **Watch View** Monitor values of selected variables.
@@ -501,9 +501,9 @@ This options available in `launch.json` are based on the configuration options o
                         "type": "string",
                         "description": "The path (relative to `cwd` or absolute) to the ESP-IDF bootloader."
                     },
-                    "idf_partion_table": {
+                    "idf_partition_table": {
                         "type": "string",
-                        "description": "The path (relative to `cwd` or absolute) to the ESP-IDF partion table."
+                        "description": "The path (relative to `cwd` or absolute) to the ESP-IDF partition table."
                     }
                 }
             }
@@ -586,7 +586,7 @@ This options available in `launch.json` are based on the configuration options o
   "properties": {
       "server": {
           "type": "string",
-          "description": "Optionally onnect to an existing `probe-rs-debugger` session on IP and Port, e.g. '127.0.0.1:50000'",
+          "description": "Optionally connect to an existing `probe-rs-debugger` session on IP and Port, e.g. '127.0.0.1:50000'",
           "default": "127.0.0.1:50000"
       },
       "consoleLogLevel": {