diff --git a/.vscode/launch.json b/.vscode/launch.json
index 43a8c5ecb14f606ba69ffe1b7fc8e7028467111a..19c3088ec87671ea1b8e7480b93c2fa9351a4aea 100644
--- a/.vscode/launch.json
+++ b/.vscode/launch.json
@@ -81,6 +81,88 @@
},
"cwd": "${workspaceRoot}"
},
+ {
+ "type": "cortex-debug",
+ "request": "launch",
+ "servertype": "openocd",
+ "name": "panic 16Mhz (debug)",
+ "preLaunchTask": "cargo build --example panic",
+ "executable": "./target/thumbv7em-none-eabihf/debug/examples/panic",
+ "configFiles": [
+ "interface/stlink.cfg",
+ "target/stm32f4x.cfg"
+ ],
+ "postLaunchCommands": [
+ "b rust_begin_unwind",
+ "monitor arm semihosting enable"
+ ],
+ "swoConfig": {
+ "enabled": true,
+ "cpuFrequency": 16000000,
+ "swoFrequency": 2000000,
+ "source": "probe",
+ "decoders": [
+ {
+ "type": "console",
+ "label": "ITM",
+ "port": 0
+ }
+ ]
+ },
+ "cwd": "${workspaceRoot}"
+ },
+ {
+ "type": "cortex-debug",
+ "request": "launch",
+ "servertype": "openocd",
+ "name": "exception_itm 16Mhz (release)",
+ "preLaunchTask": "cargo build --example exception_itm --release",
+ "executable": "./target/thumbv7em-none-eabihf/release/examples/exception_itm",
+ "configFiles": [
+ "interface/stlink.cfg",
+ "target/stm32f4x.cfg"
+ ],
+ "swoConfig": {
+ "enabled": true,
+ "cpuFrequency": 16000000,
+ "swoFrequency": 2000000,
+ "source": "probe",
+ "decoders": [
+ {
+ "type": "console",
+ "label": "ITM",
+ "port": 0
+ }
+ ]
+ },
+ "cwd": "${workspaceRoot}"
+ },
+ {
+ "type": "cortex-debug",
+ "request": "launch",
+ "servertype": "openocd",
+ "name": "exception_itm_raw 16Mhz (debug)",
+ "preLaunchTask": "cargo build --example exception_itm_raw",
+ "executable": "./target/thumbv7em-none-eabihf/debug/examples/exception_itm_raw",
+ "configFiles": [
+ "interface/stlink.cfg",
+ "target/stm32f4x.cfg"
+ ],
+ "swoConfig": {
+ "enabled": true,
+ "cpuFrequency": 16000000,
+ "swoFrequency": 2000000,
+ "source": "probe",
+ "decoders": [
+ {
+ "type": "console",
+ "label": "ITM",
+ "port": 0
+ }
+ ]
+ },
+ "cwd": "${workspaceRoot}"
+ },
{
"type": "cortex-debug",
"request": "launch",
@@ -130,7 +212,7 @@
"request": "launch",
"servertype": "openocd",
"name": "device (debug)",
- "preLaunchTask": "cargo build --example device",
+ "preLaunchTask": "cargo build --example device --features pac",
"executable": "./target/thumbv7em-none-eabihf/debug/examples/device",
// uses local config files
"configFiles": [
diff --git a/.vscode/tasks.json b/.vscode/tasks.json
index 69ff234a8ba91128fdf0eef24e118908c3d824f5..db1e20156d78c951c233e3b80949689fa3b148f3 100644
--- a/.vscode/tasks.json
+++ b/.vscode/tasks.json
@@ -41,8 +41,8 @@
},
{
"type": "shell",
- "label": "cargo build --example crash --release",
- "command": "cargo build --example crash --release",
+ "label": "cargo build --example itm",
+ "command": "cargo build --example itm",
"problemMatcher": [
"$rustc"
],
@@ -53,8 +53,44 @@
},
{
"type": "shell",
- "label": "cargo build --example itm",
- "command": "cargo build --example itm",
+ "label": "cargo build --example panic",
+ "command": "cargo build --example panic",
+ "problemMatcher": [
+ "$rustc"
+ ],
+ "group": {
+ "kind": "build",
+ "isDefault": true
+ }
+ },
+ {
+ "type": "shell",
+ "label": "cargo build --example exception_itm --release",
+ "command": "cargo build --example exception_itm --release",
+ "problemMatcher": [
+ "$rustc"
+ ],
+ "group": {
+ "kind": "build",
+ "isDefault": true
+ }
+ },
+ {
+ "type": "shell",
+ "label": "cargo build --example exception_itm_raw",
+ "command": "cargo build --example exception_itm_raw",
+ "problemMatcher": [
+ "$rustc"
+ ],
+ "group": {
+ "kind": "build",
+ "isDefault": true
+ }
+ },
+ {
+ "type": "shell",
+ "label": "cargo build --example crash --release",
+ "command": "cargo build --example crash --release",
"problemMatcher": [
"$rustc"
],
@@ -90,7 +126,7 @@
{
"type": "shell",
"label": "cargo build --example rtfm_blinky",
- "command": "cargo build --example rtfm_blinky --features \"hal rtfm\"",
+ "command": "cargo build --example rtfm_blinky --features \"pac rtfm\"",
"problemMatcher": [
"$rustc"
],
@@ -222,7 +258,7 @@
{
"type": "shell",
"label": "cargo build --example bare6",
- "command": "cargo build --example bare6 --features \"hal\"",
+ "command": "cargo build --example bare6 --features \"pac\"",
"problemMatcher": [
"$rustc"
],
diff --git a/Cargo.toml b/Cargo.toml
index 5608221182020d6843e4731b08b360a558d13ff5..3089f34742470f03ec9cda4ed1a5aa5db3bef303 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -12,11 +12,12 @@ version = "0.1.0"
[dependencies]
cortex-m-rt = "0.6.7"
cortex-m-semihosting = "0.3.2"
-panic-halt = "0.2.0"
-# panic-abort = "0.3.1" # requires nightly toolchain
+# panic-abort = "0.3.1" # requires nightly toolchain
+panic-halt = "0.2.0"
panic-semihosting = "0.5.1"
panic-itm = "0.4.0"
+
bare-metal = "0.2.4"
nb = "0.1.1"
heapless = "0.4.1"
@@ -27,7 +28,7 @@ optional = true
[dependencies.cortex-m]
version = "0.5.8"
-features = ["inline-asm"] # <- currently requires nightly compiler
+# features = ["inline-asm"] # <- currently requires nightly compiler
# Uncomment for the allocator example.
# alloc-cortex-m = "0.3.5"
@@ -45,7 +46,7 @@ optional = true
[features]
pac = ["stm32f4"]
-hal = ["stm32f4", "stm32f4xx-hal"]
+hal = ["stm32f4xx-hal"]
rtfm = ["cortex-m-rtfm"]
rtfm-tq = ["cortex-m-rtfm/timer-queue"]
diff --git a/README.md b/README.md
index 9644279ac8d7d1720a26122dd102466272ca5378..9a1470188bf290edeabe7840f89bef53c1c9381b 100644
--- a/README.md
+++ b/README.md
@@ -135,7 +135,7 @@ Hello, world!
Under the hood there is much less overhead, the serial transfer rate is set to 2MBit in between the ITM (inside of the MCU) and `stlink` programmer (onboard the Nucleo devkit). So in theory we can transmit some 200kByte/s data over ITM. However, we are limited by the USB interonnection and `openocd` to recieve and forward packages.
-The `stlink` programmer, buffers packages but has limited buffer space. Hence in practise, you should keep tracing to short messages, else the buffer will overflow (and the programmer might crash). See trouble shooting section if you run into trouble.
+The `stlink` programmer, buffers packages but has limited buffer space. Hence in practise, you should keep tracing to short messages, else the buffer will overflow. See trouble shooting section if you run into trouble.
---
@@ -170,7 +170,7 @@ Alternatively we can trace the panic message over `semihosting` (comment out `ex
The `openocd` console should now show:
-``` consolse
+``` console
Info : halted: PC: 0x080011a0
panicked at 'Oops', examples/panic.rs:27:5
```
@@ -202,7 +202,7 @@ In case the execution of an intstruction fails, a `HardFault` exception is raise
### Device Crates and System View Descriptions (SVDs)
-Besides the ARM provided *core* peripherals the STM32F401re/STM32F411re MCUs has numerous vendor specific peripherals (GPIOs, Timers, USARTs etc.). The vendor provides a System View Description (SVD) specifying the register block layouts (fields, enumerated values, etc.). Using the `svd2rust` tool we can derive a `Device Crate` providing an API that allow us to access each register according to the vendors specification. The `device.rs` example showcase how a `Device Crate` for the STM32F401re/STM32F411re MCUs can be added. (These MCUs have the same set of peripherals, only the the maximum clock rating differs.)
+Besides the ARM provided *core* peripherals the STM32F401re/STM32F411re MCUs has numerous vendor specific peripherals (GPIOs, Timers, USARTs etc.). The vendor provides a System View Description (SVD) specifying the register block layouts (fields, enumerated values, etc.). Using the `svd2rust` tool we can derive a `Peripheral Access Crate` (PAC) providing an API for the device that allow us to access each register according to the vendors specification. The `device.rs` example showcase how a PAC for the STM32F401re/STM32F411re MCUs can be added. (These MCUs have the same set of peripherals, only the the maximum clock rating differs.) Here we use the STM32F413 as that covers the STM32F401/411/413 devices.
The example output a `.` each second over `semihosting` and `ITM`.
@@ -217,27 +217,45 @@ name = "app"
version = "0.1.0"
[dependencies]
-cortex-m = "0.5.8"
cortex-m-rt = "0.6.7"
cortex-m-semihosting = "0.3.2"
-panic-halt = "0.2.0"
-# panic-abort = "0.3.1" # requires nightly toolchain
+# panic-abort = "0.3.1" # requires nightly toolchain
+panic-halt = "0.2.0"
panic-semihosting = "0.5.1"
panic-itm = "0.4.0"
+
bare-metal = "0.2.4"
+nb = "0.1.1"
+heapless = "0.4.1"
+
+[dependencies.cortex-m-rtfm]
+version = "0.4.0"
+optional = true
+
+[dependencies.cortex-m]
+version = "0.5.8"
+# features = ["inline-asm"] # <- currently requires nightly compiler
# Uncomment for the allocator example.
# alloc-cortex-m = "0.3.5"
[dependencies.stm32f4]
version = "0.5.0"
-features = ["stm32f411", "rt"]
+features = ["stm32f413", "rt"]
+optional = true
+
+[dependencies.stm32f4xx-hal]
+git = "https://github.com/stm32-rs/stm32f4xx-hal.git"
+version = "0.2.8"
+features = ["stm32f413", "rt"]
optional = true
-[[example]]
-name = "device"
-required-features = ["stm32f4"]
+[features]
+pac = ["stm32f4"]
+hal = ["stm32f4xx-hal"]
+rtfm = ["cortex-m-rtfm"]
+rtfm-tq = ["cortex-m-rtfm/timer-queue"]
# this lets you use `cargo fix`!
[[bin]]
@@ -245,32 +263,14 @@ name = "app"
test = false
bench = false
-[profile.dev]
-panic = "abort"
-
[profile.release]
+incremental = false # disable incremental build to allow lto on nightly
codegen-units = 1 # better optimizations
debug = true # symbols are nice and they don't increase the size on Flash
lto = true # better optimizations
-panic = "abort"
-```
-
-Of particular interest here is the *optional* dependency to [dependencies.stm32f4], where `"stm32f4"` is a `required-feature` for the example `"device"`. In effect, you need to compile `device` as:
-
-``` console
-cargo build --example device --features stm32f4
```
-In turn:
-
-``` toml
-[dependencies.stm32f4]
-version = "0.5.0"
-features = ["stm32f411", "rt"]
-optional = true
-```
-
-Compiles `stm32f4` (a generic library for all STMF4 MCUs) with `features = features = ["stm32f411", "rt"]`, which indicates the specific MCU with `rt` (run-time support) enabled. By having the `Device Crate` as an optional dependency, we did not need to compile it (unless we need it, and as you might have experienced already compiling the `Device Crate` takes a bit of time initially). (An SVD file is typically > 50k lines, amounting to the same (or more) lines of Rust code.)
+We compile `stm32f4` (a generic library for all STMF4 MCUs) with `features = ["stm32f413", "rt"]`, which indicates the specific MCU with `rt` (run-time support) enabled. By having the PAC as an optional dependency, we did not need to compile it (unless we need it, and as you might have experienced already compiling the PAC takes a bit of time to compile initially). (An SVD file is typically > 50k lines, amounting to the same (or more) lines of Rust code.)
---
@@ -289,25 +289,26 @@ Why is this important you may ask? Well, this *pattern* allows the compiler to c
Similarly, we `split` the `GPIOA` into its parts (pins), and select the operating mode to `af7` for `tx` (the transmit pin `pa2`), and `rx` (the receive pin `pa3`). For details see, RM0368, figure 17 (page 151), and table 9 in STM32F401xD STM32F401xE. The GPIO pins `pa2` and `pa3` are (by default) connected to the `stlink` programmer, see section 6.8 of the Nucleo64 user manual `UM1724`. When the `stlink` programmer is connected to a linux host, the device `\dev\ttyACM0` appears as a *virtual com port* (connected to `pa2`/`pa3` by default).
-Now we can call `Serial::usart2` to setup the serial communication, (according to table 9 in STM32F401xD STM32F401xE it is USART2).
+Now we can call `Serial::usart2` to setup the serial communication, (according to table 9 in STM32F401xD STM32F401xE documentation it is USART2).
Following the *singleton* pattern it consumes the `USART2` peripheral (to ensure that only one configuration can be active at any time). The second parameter is the pair of pins `(tx, px)` that we setup earlier.
-The third parameter is the USART configuration. By defualt its set to 8 bit data, and one stop bit. We set the baudrate to 115200. We also pass the `clocks` (holding information about the MCU clock setup).
+The third parameter is the USART configuration. By defualt its set to 8 bit data, and one stop bit. We set the baudrate to 115200. We also pass the `clocks` (holding information about the MCU clock setup).
At this point `tx` and `rx` is owned by `serial`. We can get access to them again by `serial.split()`.
In the loop we match on the result of `block!(rx.read())`. `block!` repeatedly calls `rx.read()` until ether a byte is received or an error returned. In case `rx.read()` succeeded, we trace the received byte over the ITM, and echo it by `tx.write(byte)`, ignoring the result (we just assume sending will always succeed). In case `rx.read` returned with an error, we trace the error message.
-As the underlying hardware implementation buffers only a single byte, the input buffer may ofverlow (resulting in `tx.read` returning an error).
+As the underlying hardware implementation buffers only a single byte, the input buffer may overflow (resulting in `tx.read` returning an error).
-You can now compile and run the example. Start `moserial` (or some other serial communication tool), connect to `/dev/ttyACM0` with 115200 8N1). Now write a single character `a` in the `Outgoing` pane, followed by pressing <Enter>. You should receive back an `a` from the target. In the ITM trace output you should see,
+You can now compile and run the example. Start `moserial` (or some other serial communication tool), connect to `/dev/ttyACM0` with 115200 8N1). Now write a single character `a` in the `Outgoing` pane, followed by pressing <Enter>. You should receive back an `a` from the target. In the ITM trace output you should see:
-```
+``` console
[2019-01-08T10:31:36.867Z] Ok 97.
```
+
Depending if <Enter> was encoded as CR+LF, CR, LF, TAB, ... you will get additional bytes sent (and received). Try sending multiple characters at once, e.g. `abcd`, you will see that the you well get a buffer overflow.
-the `read` is a method on the `rx`,
+This is an example of a bad programming pattern, typically leading to serious problems in (real-time) embedded programming (so it takes more than just Rust to get it right). Later in the exercises we will see how better patterns can be adopted.
---
@@ -373,15 +374,15 @@ const APP: () = {
};
```
+---
-
-# Trouble Shooting
+## Trouble Shooting
Working with embedded targets involves a lot of tooling, and many things can go wrong.
---
-## `openocd` fails to connect
+### `openocd` fails to connect
If you end up with a program that puts the MCU in a bad state.
@@ -390,12 +391,15 @@ If you end up with a program that puts the MCU in a bad state.
- However even a reset might not help you. In that case you can erase the flash memory. `st-flash` connects to the target directly (bypassing `gdb` and `openocd`) and hence more likely to get access to the target even if its in a bad state.
``` console
-$ st-flash erase
+> st-flash erase
```
+- Make sure that the `st-link` firmare is up to date, you can use the java application: https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link007.license=1549034381973.product=STSW-LINK007.version=2.33.25.html, to check/update the firmware. (Current verison is 2.33.25)
+
+
---
-## `gdb` fails to connect
+### `gdb` fails to connect
`openocd` acts as a *gdb server*, while `gdb` is a *gdb client*. By default they connect over port `:3333` (: indicates that the port is on the *localhost*, not a remote connection). In cases you might have another `gdb` connection blocking the port.
@@ -421,7 +425,7 @@ $ killall -9 arm-none-eabi-g
Notice, the process name is truncated for some reason...
-If this did not help you can check if some other client has aquired the port, and kill the intruder accordingly.
+If this did not help you can check if some other client has aquired the port, and kill the intruder accordingly. (In this case it was the gdb process so the above method would have worked, but in general it could be another process blocking the port.)
``` console
$ lsof -i :3333
@@ -434,7 +438,7 @@ $ kill -9 7825
---
-## `itmdump` no tracing or faulty output
+### `itmdump` no tracing or faulty output
There can be a number of reasons ITM tracing fails.
@@ -528,9 +532,11 @@ In case the ITM buffer is saturated, ITM tracing stops working (and might be har
This ensures 1) the program will not yet again overflow the ITM buffer, 2) the faulty program is gone (and not restarted accidently on a `RESET`), 3) the programmer firmware is restarted and does not carry any persistent state, notice a `RESET` applies only to the target, not the programmer, so if the programmer crashes it needs to be power cycled), 4) the FIFO `/tmp/itm.log`, `openocd` and `gdb` will have fresh states.
+- Check/udate the Nucleo `st-link` firmware (as mentioned above).
+
---
-# Visual Studio Code
+## Visual Studio Code
`vscode` is highly configurable, (keyboard shortcuts, keymaps, plugins etc.) There is Rust support through the `rls-vscode` plugin (https://github.com/rust-lang/rls-vscode).
@@ -540,12 +546,12 @@ For general informaiton regarding debugging in `vscode`, see https://code.visual
Some useful (default) shortcuts:
-- `CTRL+m` compilation tasks, (e.g., compile all examples `cargo build --examples`). Cargo is smart and just re-compiles what is changed.
+- `CTRL+SHIFT+b` compilation tasks, (e.g., compile all examples `cargo build --examples`). Cargo is smart and just re-compiles what is changed.
-- `CTRL+d` debug launch configurations, enter debug mode to choose a binary (e.g., `itm 64MHz (debug)`)
+- `CTRL+SHIFT+d` debug launch configurations, enter debug mode to choose a binary (e.g., `itm 64MHz (debug)`)
- `F5` to start. It will open the `cortex_m_rt/src/lib.rs` file, which contains the startup code. From there you can continue `F5` again.
-- `F6` to break. The program will now be in the infinite loop.
+- `F6` to break. The program will now be in the infinite loop (for this example). In general it will just break wherever the program counter happens to be.
- You can view the ITM trace in the `OUTPUT` tab, choose the dropdown `SWO: ITM [port 0, type console]`. It should now display:
``` txt
@@ -556,7 +562,7 @@ Some useful (default) shortcuts:
You may step, view the current context `variables`, add `watches`, inspect the `call stack`, add `breakpoints`, inspect `peripherals` and `registers`. Read more in the documentation for the plugin.
-## Caveats
+### Caveats
Visual Studio Code is not an "IDE", its a text editor with plugin support, with an API somewhat limiting what can be done from within a plugin (in comparison to Eclipse, IntelliJ...) regarding panel layouts etc. E.g., as far as I know you cannot view the `adapter output` (`openocd`) at the same time as the ITM trace, they are both under the `OUTPUT` tab. Moreover, each time you re-start a debug session, you need to re-select the `SWO: Name [port 0, type console]` to view the ITM output. There are some `hax` around this:
@@ -604,11 +610,11 @@ adapter speed: 8000 kHz
---
-## Vscode Launch Configurations
+### Vscode Launch Configurations
-The first three lauch configurations in the `.vscode/launch.json` file:
+Some example launch configurations from the `.vscode/launch.json` file:
-``` txt
+``` json
{
"type": "cortex-debug",
"request": "launch",
@@ -688,33 +694,6 @@ We see some similarities to the `openocd.gdb` file, we don't need to explicitly
---
-# GDB Advanced Usage
+## GDB Advanced Usage
There are numerous ways to automate `gdb`. Scripts can be run by the `gdb` command `source` (`so` for short). Scripting common tasks like setting breakpoints, dumping some memory region etc. can be really helpful.
-
-
-# License
-
-This template is licensed under either of
-
-- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or
- http://www.apache.org/licenses/LICENSE-2.0)
-
-- MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
-
-at your option.
-
-## Contribution
-
-Unless you explicitly state otherwise, any contribution intentionally submitted
-for inclusion in the work by you, as defined in the Apache-2.0 license, shall be
-dual licensed as above, without any additional terms or conditions.
-
-## Code of Conduct
-
-Contribution to this crate is organized under the terms of the [Rust Code of
-Conduct][CoC], the maintainer of this crate, the [Cortex-M team][team], promises
-to intervene to uphold that code of conduct.
-
-[CoC]: https://www.rust-lang.org/policies/code-of-conduct
-[team]: https://github.com/rust-embedded/wg#the-cortex-m-team
diff --git a/examples/bare0.rs b/examples/bare0.rs
index 8358e63420c73b20ec2326d2c84c786ee6fc8207..eef66f54ef142f84629473b2677374a48b2da98b 100644
--- a/examples/bare0.rs
+++ b/examples/bare0.rs
@@ -42,6 +42,9 @@ fn main() -> ! {
// 0. Compile/build the example in debug (dev) mode.
//
+// > cargo build --example bare0
+// (or use the vscode build task)
+//
// 1. Run the program in the debugger, let the program run for a while and
// then press pause. Look in the (Local -vscode) Variables view what do you find.
//
@@ -58,14 +61,14 @@ fn main() -> ! {
//
// ** place your answer here **
//
-// commit your answers (bare0_1)
+// Commit your answers (bare0_1)
//
// 2. Alter the constant X_INIT so that `x += 1` directly causes `x` to wrap
// what happens when `x` wraps
//
// ** your answer here **
//
-// commit your answers (bare0_2)
+// Commit your answers (bare0_2)
//
// 3. Place a breakpoint at `x += 1`
//
@@ -76,7 +79,7 @@ fn main() -> ! {
// Now continue exectution, what happens
// ** your answer here **
//
-// commit your answers (bare0_3)
+// Commit your answers (bare0_3)
//
// (If the program did not succeed back to the breakpoint
// you have some fault in the program and go back to 3.)
@@ -85,7 +88,7 @@ fn main() -> ! {
//
// ** place your answer here **
//
-// commit your answers (bare0_4)
+// Commit your answers (bare0_4)
//
// 5. Remove the assertion and implement "safe" functions for
// reading and writing X and Y
@@ -94,7 +97,7 @@ fn main() -> ! {
// Rewrite the program to use ONLY "safe" code besides the
// read/write functions (which are internally "unsafe")
//
-// commit your solution (bare0_5)
+// Commit your solution (bare0_5)
//
// 6. *Optional
// Implement a read_u32/write_u32, taking a reference to a
@@ -102,5 +105,5 @@ fn main() -> ! {
//
// Rewrite the program to use this abstraction instead of "read_x", etc.
//
-// commit your solution (bare0_6)
+// Commit your solution (bare0_6)
//
diff --git a/examples/bare1.rs b/examples/bare1.rs
index 04405f0a8573f7b9a9ddd68890b47b502174b970..94b99d08183c8f821584434c8a3cd02f15efcb80 100644
--- a/examples/bare1.rs
+++ b/examples/bare1.rs
@@ -45,6 +45,10 @@ fn main() -> ! {
// If you change toolchain, exit and re-start `vscode`.
//
// 1. Build and run the application
+//
+// > cargo build --example bare1
+// (or use the vscode build task)
+//
// Look at the `hello.rs` and `itm.rs` examples to setup the tracing.
//
// When debugging the application it should get stuck in the
@@ -56,37 +60,44 @@ fn main() -> ! {
// What is the output in the semihosting (openocd) console
// ** your answer here **
//
-// commit your answers (bare1_1)
+// Commit your answers (bare1_1)
//
// 2. Inspecting the generated assembly code
// If in `vcsode` the gdb console in DEBUG CONSOLE
+//
// What is the output of:
// (gdb) disassemble
//
// ** your answer here **
//
-// commit your answers (bare1_2)
+// Commit your answers (bare1_2)
//
// 3. Now remove the comment for `cortex_m::asm::nop()`.
// Rebuild and debug, pause the program.
+//
// What is the output of:
// (gdb) disassemble
//
// ** your answer here **
//
-// commit your answers (bare1_3)
+// Commit your answers (bare1_3)
//
// 4. Now remove the comment for `cortex_m::asm::bkpt()`
// Rebuild and debug, let the program run until it halts.
+//
// What is the output of:
// (gdb) disassemble
//
// ** your answer here **
//
-// commit your answers (bare1_4)
+// Commit your answers (bare1_4)
//
// 5. Release mode (optimized builds).
// Rebuild `bare1.rs` in release (optimized mode).
+//
+// > cargo build --example bare1 --release
+// (or using the vscode build task)
+//
// Compare the generated assembly for the loop
// between the dev (unoptimized) and release (optimized) build.
//
diff --git a/examples/bare10.rs b/examples/bare10.rs
index 78c993e662bea6130f963886905f7f527a68926c..5d3882e8dbfceb0a8babcc4218f30e3872f5dc54 100644
--- a/examples/bare10.rs
+++ b/examples/bare10.rs
@@ -79,7 +79,7 @@ const APP: () = {
}
}
- #[task(priority = 1, resources = [ITM],capacity = 4)]
+ #[task(priority = 1, resources = [ITM])]
fn trace_data(byte: u8) {
let stim = &mut resources.ITM.stim[0];
iprintln!(stim, "data {}", byte);
@@ -132,10 +132,14 @@ const APP: () = {
// 0. Compile and run the project at 16MHz in release mode
// make sure its running (not paused).
//
+// > cargo build --example bare9 --features "hal rtfm" --release
+// (or use the vscode build task)
+//
// Connect a terminal program.
// Verify that it works as bare9.
//
-// 1. Comment out the loop in `trace_data`
+// 1. Now, comment out the loop in `trace_data`.
+// The loop is just there to simulate some workload...
//
// Try now to send a sequence `abcd`
//
@@ -147,19 +151,26 @@ const APP: () = {
//
// ** your answer here **
//
-// Why did you loose data?
+// Why did you loose trace information?
//
// ** your asnwer here **
//
// Commit your answers (bare10_1)
//
// 2. Read the RTFM manual (book).
-// Figure out a way to accomdate for 4 outstanding messages to the `trac_data` task.
+// Figure out a way to accomdate for 4 outstanding messages to the `trace_data` task.
//
// Verify that you can now correctly trace sequences of 4 characters sent.
//
-// Commit your answers (bare10_2)
+// Can you think of how to determine a safe bound on the message buffer size?
+// (Safe meaning, that message would never be lost due to the buffer being full.)
+//
+// What information would you need?
+//
+// ** your answer here **
//
+// Commit your answers (bare10_2)
+//
// 3. Implement a command line interpreter as a new task.
// It should:
// - have priority 1.
diff --git a/examples/bare2.rs b/examples/bare2.rs
index 6d1178b5a256aeb3c0b80f7938a29afb16b08df3..c039a6ef1e8ff1ed8d164f6c4ecdb1155684126a 100644
--- a/examples/bare2.rs
+++ b/examples/bare2.rs
@@ -65,12 +65,18 @@ fn main() -> ! {
// Read the API docs.
//
// 1. Build and run the application (debug build).
+//
+// > cargo build --example bare2
+// (or use the vscode build task)
+//
// What is the output in the ITM console?
//
// ** your answer here **
-
+//
// Rebuild and run in release mode
//
+// > cargo build --example bare2 --release
+//
// ** your answer here **
//
// Compute the ratio between debug/release optimized code
diff --git a/examples/bare3.rs b/examples/bare3.rs
index f40073c4d5fd54c5ae4f931e730d0a8597595f18..a52a2f5988101b4b69c287082f40912f9ba5180e 100644
--- a/examples/bare3.rs
+++ b/examples/bare3.rs
@@ -46,6 +46,9 @@ fn main() -> ! {
}
// 0. Build and run the application (debug build).
+//
+// > cargo build --example bare3
+// (or use the vscode build task)
//
// 1. What is the output in the `openocd` (Adapter Output) console?
//
@@ -71,11 +74,11 @@ fn main() -> ! {
//
// ** your answer here **
//
-// commit your answers (bare3_1)
+// Commit your answers (bare3_1)
//
// 2. Make types of `s`, `bs`, `c`, `a`, `i` explicit.
//
-// commit your answers (bare3_2)
+// Commit your answers (bare3_2)
//
// 3. Uncomment line `let mut a = [0u8; 4];
//`
@@ -83,17 +86,17 @@ fn main() -> ! {
//
// ** your answer here **
//
-// commit your answers (bare3_3)
+// Commit your answers (bare3_3)
//
// 4. Alter the program so that the data from `bs` is copied byte by byte into `a`.
//
// Test that it works as intended.
//
-// commit your answers (bare3_4)
+// Commit your answers (bare3_4)
//
// 5. Look for a way to make this copy done without a loop.
// https://doc.rust-lang.org/std/primitive.slice.html
//
// Implement and test your solution.
//
-// commit your answers (bare3_5)
+// Commit your answers (bare3_5)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index d3ac6257e7883370bba1fa63717cec45b92c840b..75fec4e08efcd477b35fd17df4e5acb38e74071a 100644
--- a/examples/bare4.rs
+++ b/examples/bare4.rs
@@ -79,20 +79,23 @@ fn main() -> ! {
// 0. Build and run the application (debug build).
//
+// > cargo build --example bare4
+// (or use the vscode build task)
+//
// 1. Did you enjoy the blinking?
//
// ** your answer here **
-//fn wait(i: u32) {
-//fn wait(i: u32) {each section referred,
-//fn wait(i: u32) {
-//fn wait(i: u32) {
-//fn wait(i: u32) { by the appropriate section in the
-//fn wait(i: u32) {
-//fn wait(i: u32) {
-//fn wait(i: u32) {
-//fn wait(i: u32) {
-//fn wait(i: u32) {e 41 (essentially omitting the `unsafe`)
-//fn wait(i: u32) {
+//
+// Now lookup the data-sheets, and read each section referred,
+// 6.3.11, 8.4.1, 8.4.7
+//
+// Document each low level access *code* by the appropriate section in the
+// data sheet.
+//
+// Commit your answers (bare4_1)
+//
+// 2. Comment out line 40 and uncomment line 41 (essentially omitting the `unsafe`)
+//
// //unsafe { core::ptr::read_volatile(addr as *const _) }
// core::ptr::read_volatile(addr as *const _)
//
@@ -105,7 +108,7 @@ fn main() -> ! {
//
// ** your answer here **
//
-// commit your answers (bare4_2)
+// Commit your answers (bare4_2)
//
// 3. Volatile read/writes are explicit *volatile operations* in Rust, while in C they
// are declared at type level (i.e., access to varibles declared volatile amounts to
@@ -128,4 +131,4 @@ fn main() -> ! {
//
// ** your answer here **
//
-// commit your answers (bare4_3)
+// Commit your answers (bare4_3)
diff --git a/examples/bare5.rs b/examples/bare5.rs
index d1258aaf366750fccdcc6690a32eb407603d9bf5..96f9f8160cdbddeed9bbd5c446e65d3651fcf416 100644
--- a/examples/bare5.rs
+++ b/examples/bare5.rs
@@ -50,6 +50,13 @@ mod stm32f40x {
}
}
+ // modify (reads, modifies a field, and writes the volatile cell)
+ //
+ // parameters:
+ // offset (field offset)
+ // width (field width)
+ // value (new value that the field should take)
+ //
// impl VolatileCell<u32> {
// #[inline(always)]
// pub fn modify(&self, offset: u8, width: u8, value: u32) {
@@ -152,7 +159,7 @@ fn wait(i: u32) {
// // 000011000
// assert!(t.read() == 0b011 << 3);
-// if << is used, your code will panic in dev, but not in release mode
+// if << is used, your code will panic in dev (debug), but not in release mode
// t.modify(32, 3, 1);
//}
@@ -177,39 +184,42 @@ fn idle(rcc: &mut RCC, gpioa: &mut GPIOA) {
let r = gpioa.MODER.read() & !(0b11 << (5 * 2)); // read and mask
gpioa.MODER.write(r | 0b01 << (5 * 2)); // set output mode
- // and alter the data output through the BSRR register
- // this is more efficient as the read register is not needed.
-
loop {
// set PA5 high
- //gpioa.BSRRH.write(1 << 5); // set bit, output hight (turn on led)
- gpioa.ODR.write(gpioa.ODR.read() | (1 << 5));
+ gpioa.BSRRH.write(1 << 5); // set bit, output hight (turn on led)
+ // gpioa.ODR.write(gpioa.ODR.read() | (1 << 5));
wait(10_000);
// set PA5 low
- // gpioa.BSRRL.write(1 << 5); // clear bit, output low (turn off led)
- gpioa.ODR.write(gpioa.ODR.read() & !(1 << 5));
+ gpioa.BSRRL.write(1 << 5); // clear bit, output low (turn off led)
+ // gpioa.ODR.write(gpioa.ODR.read() & !(1 << 5));
wait(10_000);
}
}
// 0. Build and run the application.
//
+// > cargo build --example bare5
+// (or use the vscode build task)
+//
// 1. C like API.
// In C the .h files are used for defining interfaces, like function signatures (prototypes),
-// structs and macros (but usually not the functions themselves)
-// here is a peripheral abstraction quite similar to what you would find in the .h files
+// structs and macros (but usually not the functions themselves).
+//
+// Here is a peripheral abstraction quite similar to what you would find in the .h files
// provided by ST (and other companies). Actually, the file presesnted here is mostly a
// cut/paste/replace of the stm32f40x.h, just Rustified.
//
-// In this case we pass mutable pointers of the peripherals to the `idle`.
+// In this case we pass mutable pointers of the peripherals to the `idle` function.
//
-// Rewrite the accesses in the loop to use the data register directly (and make a read/modify/write).
+// In the loop we access PA5 through bit set/clear operations.
+// Comment out those opertations and uncomment the the ODR accesses.
+// (They should have the same behavior, but is a bit less efficient.)
//
// Run and see that the program behaves the same.
//
-// commit your answers (bare5_1)
+// Commit your answers (bare5_1)
//
// 2. Extend the read/write API with a modify for u32, taking the
// - address (&mut u32),
@@ -223,7 +233,7 @@ fn idle(rcc: &mut RCC, gpioa: &mut GPIOA) {
//
// Run and see that the program behaves the same.
//
-// commit your answers (bare5_2)
+// Commit your answers (bare5_2)
//
// Discussion:
// As with algebraic operations, defalut semantics differ in between
diff --git a/examples/bare6.rs b/examples/bare6.rs
index f00bc505e04031de718441b8dc2332a6d20ce611..bda939160cc3cbcb37c4063fca60611ed98f5f05 100644
--- a/examples/bare6.rs
+++ b/examples/bare6.rs
@@ -103,6 +103,23 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
// 0. Compile and run the example, in 16Mhz
//
+// > cargo build --example bare6 --features "pac"
+// (or use the vscode build task)
+//
+// The "pac" feature enables the optional dependency "stm32f4"
+//
+// Cargo.toml:
+//
+// [dependencies.stm32f4]
+// version = "0.5.0"
+// features = ["stm32f413", "rt"]
+// optional = true
+//
+// [features]
+// pac = ["stm32f4"]
+//
+// Notice, we use the stm32f413 API, since it covers stm32f401/f411/f413.
+//
// 1. The processor SYSCLK defaults to HCI 16Mhz
// (this is what you get after a `monitor reset halt`).
//
@@ -134,7 +151,7 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
// Make a screen dump or photo of the oscilloscope output.
// Save the the picture as "bare_6_16mhz_high_speed".
//
-// commit your answers (bare6_2)
+// Commit your answers (bare6_2)
//
// 3. Now run the example in 64Mz
// You can do that by issuing a `monitor reset init`
@@ -150,7 +167,7 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
//
// ** your answer here **
//
-// commit your answers (bare6_3)
+// Commit your answers (bare6_3)
//
// 4. Repeat experiment 2
//
@@ -169,7 +186,7 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
// Make a screen dump or photo of the oscilloscope output.
// Save the the picture as "bare_6_64mhz_high_speed".
//
-// commit your answers (bare6_4)
+// Commit your answers (bare6_4)
//
// 5. In the `clock_out` function, the setup of registers is done through
// setting bitpattens manually, e.g.
@@ -181,14 +198,14 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
//
// To view the API you can generate documentation for your crate:
//
-// > cargo doc --features "hal rtfm" --open
+// > cargo doc --features "pac" --open
//
// By searching for `mco2` you find the enumerations and functions.
// So here
// `w.mco2().bits{0b00}` is equivalent to
// `w.mco2().sysclk()` and improves readabiity.
//
-// Replace the bitpatterns used by the function name equivalents.
+// Replace all bitpatterns used by the function name equivalents.
//
// Test that the application still runs as before.
//
diff --git a/examples/bare6_nightly.rs b/examples/bare6_nightly.rs
deleted file mode 100644
index 6025e7ebe66cb38d547f6a7b463b814e480f1594..0000000000000000000000000000000000000000
--- a/examples/bare6_nightly.rs
+++ /dev/null
@@ -1,188 +0,0 @@
-//! bare6.rs
-//!
-//! Clocking
-//!
-//! What it covers:
-//! - using svd2rust generated API
-//! - setting the clock via script (again)
-//! - routing the clock to a PIN for monitoring by an oscilloscope
-//! - changing the clock using Rust code
-//!
-
-#![no_main]
-#![no_std]
-#![feature(uniform_paths)]
-#![feature(type_alias_enum_variants)]
-
-extern crate panic_halt;
-
-use cortex_m::{iprintln, peripheral::itm::Stim};
-use cortex_m_rt::entry;
-
-use stm32f4::stm32f413;
-use stm32f413::{DWT, GPIOA, GPIOC, RCC};
-
-#[entry]
-fn main() -> ! {
- let p = stm32f413::Peripherals::take().unwrap();
- let mut c = stm32f413::CorePeripherals::take().unwrap();
-
- let stim = &mut c.ITM.stim[0];
- iprintln!(stim, "Hello, bare6!");
-
- c.DWT.enable_cycle_counter();
- unsafe {
- c.DWT.cyccnt.write(0);
- }
- let t = DWT::get_cycle_count();
- iprintln!(stim, "{}", t);
-
- clock_out(&p.RCC, &p.GPIOC);
- // clock::set_84_mhz(rcc, flash);
- idle(stim, p.RCC, p.GPIOA);
-
- loop {}
-}
-
-// // user application
-fn idle(stim: &mut Stim, rcc: RCC, gpioa: GPIOA) {
- iprintln!(stim, "idle");
-
- // power on GPIOA, RM0368 6.3.11
- rcc.ahb1enr.modify(|_, w| w.gpioaen().set_bit());
-
- // configure PA5 as output, RM0368 8.4.1
- gpioa.moder.modify(|_, w| w.moder5().bits(1));
-
- // at 16 Mhz, 8_000_000 cycles = period 0.5s
- // at 64 Mhz, 4*8_000_000 cycles = period 0.5s
- // let cycles = 8_000_000;
- let cycles = 4 * 8_000_000;
-
- loop {
- iprintln!(stim, "on {}", DWT::get_cycle_count());
- // set PA5 high, RM0368 8.4.7
- gpioa.bsrr.write(|w| w.bs5().set_bit());
- wait_cycles(cycles);
-
- iprintln!(stim, "off {}", DWT::get_cycle_count());
- // set PA5 low, RM0368 8.4.7
- gpioa.bsrr.write(|w| w.br5().set_bit());
- wait_cycles(cycles);
- }
-}
-
-// uses the DWT.CYCNT
-// doc: ARM trm_100166_0001_00_en.pdf, chapter 9.2
-// we use the `cortex-m` abstraction, as re-exported by the stm32f40x
-fn wait_cycles(nr_cycles: u32) {
- let t = DWT::get_cycle_count().wrapping_add(nr_cycles);
- while (DWT::get_cycle_count().wrapping_sub(t) as i32) < 0 {}
-}
-
-// see the Reference Manual RM0368 (www.st.com/resource/en/reference_manual/dm00096844.pdf)
-// rcc, chapter 6
-// gpio, chapter 8
-fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
- // output MCO2 to pin PC9
-
- // mco2 : SYSCLK = 0b00
- // mcopre : divide by 4 = 0b110
- rcc.cfgr
- .modify(|_, w| unsafe { w.mco2().bits(0b00).mco2pre().bits(0b110) });
-
- // power on GPIOC, RM0368 6.3.11
- rcc.ahb1enr.modify(|_, w| w.gpiocen().set_bit());
-
- // MCO_2 alternate function AF0, STM32F401xD STM32F401xE data sheet
- // table 9
- // AF0, gpioc reset value = AF0
-
- // configure PC9 as alternate function 0b10, RM0368 6.2.10
- gpioc.moder.modify(|_, w| w.moder9().bits(0b10));
-
- // otyper reset state push/pull, in reset state (don't need to change)
-
- // ospeedr 0b11 = high speed
- // use stm32f4::stm32f413::gpiof::ospeedr::OSPEEDR9W;
- // use gpioc::ospeedr::OSPEEDR9W;
- // use stm32f4::stm32f413::gpiof as gpioc;
- // use stm32f4::stm32f413::gpiof::ospeedr::OSPEEDR9W::*;
- // gpioc.ospeedr.modify(|_, w| w.ospeedr9().bits(0b11));
- // gpioc.ospeedr.modify(|_, w| {
- // w.ospeedr9().variant(gpioc::ospeedr::OSPEEDR9W::HIGHSPEED)
- // });
-
- // gpioc.ospeedr.modify(|_, w| w.ospeedr9().low_speed())
- gpioc.ospeedr.modify(|_, w| w.ospeedr9().very_high_speed())
-}
-
-// 1. Compile and run the example, in 16Mhz
-// The processor SYSCLK defaults to HCI 16Mhz
-// (this is what you get after a `monitor reset halt`).
-//
-// Confirm that your ITM dump traces the init, idle and led on/off.
-// Make sure your TPIU is set to a system clock at 16Mhz
-//
-// What is the frequency of blinking?
-//
-// ** your answer here **
-//
-// commit your answers (bare6_1)
-//
-// 2. Now connect an oscilloscope to PC9, which is set to
-// output the MCO2.
-//
-// What is the frequency of MCO2 read by the oscilloscope?
-//
-// ** your answer here **
-//
-// Compute the value of SYSCLK based on the oscilloscope reading
-//
-// ** your answer here **
-//
-// What is the peak to peak reading of the signal?
-//
-// ** your answer here **
-//
-// Make a folder called "pictures" in your git project.
-// Make a screen dump or photo of the oscilloscope output.
-// Save the the picture as "bare_6_16mhz_high_speed".
-//
-// commit your answers (bare6_2)
-//
-// 3. Now run the example in 64Mz
-// You can do that by issuing a `monitor reset init`
-// which reprograms SYSCLK to 4*HCI.
-//
-//
-// Confirm that your ITM dump traces the init, idle and led on/off
-// (make sure your TPIU is set to a system clock at 64Mhz)
-//
-// Uncommnet: `let cycles = 4 * 8_000_000;
-//`
-// What is the frequency of blinking?
-//
-// ** your answer here **
-//
-// commit your answers (bare6_3)
-//
-// 4. Repeat experiment 2
-//
-// What is the frequency of MCO2 read by the oscilloscope?
-//
-// ** your answer here **
-//
-// Compute the value of SYSCLK based on the oscilloscope reading.
-//
-// ** your answer here **
-//
-// What is the peak to peak reading of the signal?
-//
-// ** your answer here **
-//
-// Make a screen dump or photo of the oscilloscope output.
-// Save the the picture as "bare_6_64mhz_high_speed".
-//
-// commit your answers (bare6_4)
-//
diff --git a/examples/bare7.rs b/examples/bare7.rs
index 4ebb86a3bcd442e8cef85e62968f3ab69fd7c362..ecf0fbb104a9443c9c469e8e5f985c6bb620f338 100644
--- a/examples/bare7.rs
+++ b/examples/bare7.rs
@@ -9,7 +9,6 @@
//! - USART polling (blocking wait)
#![deny(unsafe_code)]
-#![deny(warnings)]
#![no_main]
#![no_std]
@@ -40,6 +39,7 @@ fn main() -> ! {
let tx = gpioa.pa2.into_alternate_af7();
let rx = gpioa.pa3.into_alternate_af7(); // try comment out
+ // let rx = gpioa.pa3.into_alternate_af6(); // try uncomment
let serial = Serial::usart2(
p.USART2,
@@ -87,6 +87,35 @@ fn main() -> ! {
// PCLK2 - The clock driving the APB2 (<= 84 MHz)
// Timers on the APB2 bus will be triggered at PCLK2
//
+// Compliation:
+// > cargo build --example bare7 --features "hal"
+// (or use the vscode build task)
+//
+// The "hal" feature enables the optional dependency stm32f4xx-hal".
+//
+// Cargo.toml:
+//
+// [dependencies.stm32f4]
+// version = "0.5.0"
+// features = ["stm32f413", "rt"]
+// optional = true
+//
+// [dependencies.stm32f4xx-hal]
+// git = "https://github.com/stm32-rs/stm32f4xx-hal.git"
+// version = "0.2.8"
+// features = ["stm32f413", "rt"]
+// optional = true
+//
+// [features]
+// pac = ["stm32f4"]
+// hal = ["stm32f4xx-hal"]
+//
+// Notice, stm32f4xx-hal internally enables the dependency to stm32f4,
+// so we don't need to explicitly enable it.
+//
+// The HAL provides a generic abstraction over the whole stm32f4 family,
+// as previously we use the stm32f413, since it also covers stm32f401/stm32f411.
+//
// 1. The rcc.cfgr.x.freeze() sets the clock according to the configuration x given.
//
// rcc.cfgr.freeze(); sets a default configuration.
@@ -102,7 +131,7 @@ fn main() -> ! {
//
// ** your answer here **
//
-// commit your answers (bare7_1)
+// Commit your answers (bare7_1)
//
// Tip: You may use `stm32cubemx` to get a graphical view for experimentation.
// This is a good tool when designing your PCB (as pinouts are given).
@@ -128,7 +157,7 @@ fn main() -> ! {
// Make a screen dump or photo of the oscilloscope output.
// Save the the picture as "bare_6_84mhz_high_speed"
//
-// commit your answers (bare7_2)
+// Commit your answers (bare7_2)
//
// 3. Now reprogram the PC9 to be "Low Speed", and re-run at 84Mz.
//
@@ -143,7 +172,7 @@ fn main() -> ! {
// Make a screen dump or photo of the oscilloscope output.
// Save the the picture as "bare_6_84mhz_low_speed".
//
-// commit your answers (bare7_3)
+// Commit your answers (bare7_3)
//
// 4. Revisit the `README.md` regarding serial communication.
// start a terminal program, e.g., `moserial`.
diff --git a/examples/bare8.rs b/examples/bare8.rs
index ecc5ed31632839ccdc184055b921042884efc75e..b889d6c41671797308d5359078bf4141eb1d7230 100644
--- a/examples/bare8.rs
+++ b/examples/bare8.rs
@@ -90,6 +90,28 @@ const APP: () = {
// 0. Compile and run the example. Notice, we use the default 16MHz clock.
//
+// > cargo build --example bare7 --features "hal rtfm"
+// (or use the vscode build task)
+//
+// The "hal" feature enables the optional dependencies stm32f4xx-hal and rtfm".
+//
+// Cargo.toml:
+//
+// [dependencies.cortex-m-rtfm]
+// version = "0.4.0"
+// optional = true
+//
+// [dependencies.stm32f4xx-hal]
+// git = "https://github.com/stm32-rs/stm32f4xx-hal.git"
+// version = "0.2.8"
+// features = ["stm32f413", "rt"]
+// optional = true
+//
+// [features]
+// pac = ["stm32f4"]
+// hal = ["stm32f4xx-hal"]
+// rtfm = ["cortex-m-rtfm"]
+//
// 1. Our CPU now runs slower, did it effect the behavior?
//
// ** your answer here **
@@ -112,7 +134,7 @@ const APP: () = {
//
// 4. *Optional
// Compile and run the program in release mode.
-// If using vscode, look at the `.vscode` folder `task.json` and `lounch.json`,
+// If using vscode, look at the `.vscode` folder `task.json` and `launch.json`,
// and add a new "profile" (a bit of copy paste).
//
// How did the optimized build compare to the debug build (performance/lost bytes)
diff --git a/examples/bare9.rs b/examples/bare9.rs
index c675955d6e1cd228c1004e863bf911ca296b365a..ecb7aa9369ea5b6ff3b47f4b7553ea0a3f9476c6 100644
--- a/examples/bare9.rs
+++ b/examples/bare9.rs
@@ -123,6 +123,9 @@ const APP: () = {
// 0. Compile and run the project at 16MHz in release mode
// make sure its running (not paused).
+//
+// > cargo build --example bare9 --features "hal rtfm" --release
+// (or use the vscode build task)
//
// 1. Start a terminal program, connect with 15200 8N1
//
@@ -146,7 +149,10 @@ const APP: () = {
// Commit your answers (bare9_1)
//
// 2. Compile and run the project at 16MHz in debug mode.
-//
+//
+// > cargo build --example bare9 --features "hal rtfm"
+// (or use the vscode build task)
+//
// Try sending: "abcd" as a single sequence (set the option No end in moserial),
// don't send the quation marks, just abcd.
//
@@ -193,17 +199,17 @@ const APP: () = {
//
// 2. arguably the worlds fastest real time scheduler *
// + task invocation 0-cycle OH on top of HW interrupt handling
-// + 2 cycle OH for locking a shared resource (on claim entry)
-// + 1 cycle OH for releasineg a shared resoure (on claim exit)
+// + 2 cycle OH for locking a shared resource (on lock/claim entry)
+// + 1 cycle OH for releasineg a shared resoure (on lock/claim exit)
//
// 3. arguably the worlds most memory efficient scheduler *
-// + 1 byte stack memory OH for each (nested) claim
+// + 1 byte stack memory OH for each (nested) lock/claim
// (no additional book-keeping during run-time)
//
// * applies to static task/resource models with single core
// pre-emptive, static priority scheduling
//
-// in comparison "real-time" schedulers for threaded models like FreeRTOS
+// In comparison "real-time" schedulers for threaded models like FreeRTOS
// - CPU and memory OH magnitudes larger (100s of cycles/kilobytes of memory)
// - ... and what's worse OH is typically unbound (no proofs of worst case)
// - potential race conditions (up to the user to verify)
@@ -228,8 +234,8 @@ const APP: () = {
//
// The scheduler then needs to keep track of all threads and at some point choose
// to dispatch the awaiting thread. So reactivity is bottlenecked to the point
-// of scheduling by que management, context switching and other additional
+// of scheduling by queue management, context switching and other additional
// book keeping.
//
// In essence, the thread scheduler tries to re-establish the reactivity that
-// were there (interrupts), a battle that cannot be won...
\ No newline at end of file
+// were there from the beginning (interrupts), a battle that cannot be won...
\ No newline at end of file
diff --git a/examples/crash.rs b/examples/crash.rs
index 6904b3c883bf3ea33282d0aaf98453c2a0c2d98e..b72604d31b3ec83f6652805111e116202455bdf1 100644
--- a/examples/crash.rs
+++ b/examples/crash.rs
@@ -75,6 +75,13 @@ fn main() -> ! {
fn HardFault(ef: &cortex_m_rt::ExceptionFrame) -> ! {
// (gdb) p/x *ef
// prints the exception frame.
+ // (gdb) backrace
+ // will give you the calls leading up to the error
+ // (gdb) frame 3
+ // will put you in the main frame
+ // (gdb) disassemble
+ // will show the assembly instruction causing the fault
+
unsafe {
ptr::read_volatile(ef);
}
diff --git a/examples/exception_itm.rs b/examples/exception_itm.rs
index 01144a86e562a0346d0c786d23fe2d0ef0bbbf65..b49d10c761c96c9ef3db5b6f1eaec18fce7762be 100644
--- a/examples/exception_itm.rs
+++ b/examples/exception_itm.rs
@@ -13,13 +13,15 @@
extern crate panic_halt;
use cortex_m::peripheral::syst::SystClkSource;
-use cortex_m::{iprint, Peripherals};
+use cortex_m::{iprint, iprintln, Peripherals};
use cortex_m_rt::{entry, exception};
#[entry]
fn main() -> ! {
- let p = Peripherals::take().unwrap();
+ let mut p = Peripherals::take().unwrap();
let mut syst = p.SYST;
+ let stim = &mut p.ITM.stim[0];
+ iprintln!(stim, "exception_itm");
// configures the system timer to trigger a SysTick exception every second
syst.set_clock_source(SystClkSource::Core);
diff --git a/examples/exception_itm_raw.rs b/examples/exception_itm_raw.rs
index a4f7872c26fd45929b6b05e4ce5e365cb6822eac..e6d6131e47e6040dc984c4985ac5a1ff7278f3a1 100644
--- a/examples/exception_itm_raw.rs
+++ b/examples/exception_itm_raw.rs
@@ -4,8 +4,6 @@
//!
//! [1]: https://rust-embedded.github.io/cortex-m-rt/0.6.1/cortex_m_rt_macros/fn.exception.html
//!
-//! Notice, steal will panic! in debug mode, due to a `debug_assert` (ignored in release).
-//! ---
#![no_main]
#![no_std]
@@ -13,13 +11,15 @@
extern crate panic_halt;
use cortex_m::peripheral::{syst::SystClkSource, ITM};
-use cortex_m::{iprint, Peripherals};
+use cortex_m::{iprint, iprintln, Peripherals};
use cortex_m_rt::{entry, exception};
#[entry]
fn main() -> ! {
- let p = Peripherals::take().unwrap();
+ let mut p = Peripherals::take().unwrap();
let mut syst = p.SYST;
+ let stim = &mut p.ITM.stim[0];
+ iprintln!(stim, "exception_itm_raw");
// configures the system timer to trigger a SysTick exception every second
syst.set_clock_source(SystClkSource::Core);
diff --git a/examples/panic.rs b/examples/panic.rs
index 51ea8d164b0018724c18f61da59630833d6e1391..a32339641f2e4428dc2d8b36ee8cc6d2154272f2 100644
--- a/examples/panic.rs
+++ b/examples/panic.rs
@@ -10,11 +10,11 @@
// Pick one of these panic handlers:
// `panic!` halts execution; the panic message is ignored
-// extern crate panic_halt;
+extern crate panic_halt;
// Reports panic messages to the host stderr using semihosting
// NOTE to use this you need to uncomment the `panic-semihosting` dependency in Cargo.toml
-extern crate panic_semihosting;
+// extern crate panic_semihosting;
// Logs panic messages using the ITM (Instrumentation Trace Macrocell)
// NOTE to use this you need to uncomment the `panic-itm` dependency in Cargo.toml
diff --git a/examples/serial.rs b/examples/serial.rs
index 32c66c9b5805337c7331f86263f1d24e86a5d2f0..0b7015f35b6c727a236c54ce122bd99f83539afc 100644
--- a/examples/serial.rs
+++ b/examples/serial.rs
@@ -8,7 +8,6 @@
//! buffer may overflow.
#![deny(unsafe_code)]
-#![feature(uniform_paths)]
#![deny(warnings)]
#![no_main]
#![no_std]