Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision

Target

Select target project
  • Frappe/e7020e_2021
  • rognda-6/e7020e_2021
  • Klomega/e7020e_2021
  • pln/e7020e_2021
  • CarlOsterberg/e7020e_2021
  • jonjac-6/e7020e_2021
  • deux-babiri-futari/e7020e_2021
  • samgra-7/e7020e_2021
  • JosefUtbult/e7020e_2021
  • edwkll-7/e7020e_2021
10 results
Select Git revision
Show changes
Commits on Source (54)
Expand all Show whitespace changes
Inline Side-by-side
Showing
with 1281 additions and 1178 deletions
.cargo/config
View file @ bfd24e96
......@@ -18,6 +18,9 @@ rustflags = [
# LLD (shipped with the Rust toolchain) is used as the default linker
"-C", "link-arg=-Tlink.x",
# To get inline assembly at link time
"-C", "linker-plugin-lto",
# if you run into problems with LLD switch to the GNU linker by commenting out
# this line
# "-C", "linker=arm-none-eabi-ld",
......
.vscode/launch.json
View file @ bfd24e96
......@@ -19,7 +19,7 @@
"runToMain": true,
"svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",
"configFiles": [
"interface/stlink-v2-1.cfg",
"interface/stlink.cfg",
"target/stm32f4x.cfg"
],
"preRestartCommands": [
......@@ -41,7 +41,42 @@
}
]
},
"executable": "./target/thumbv7em-none-eabi/debug/examples/${fileBasenameNoExtension}",
"executable": "./target/thumbv7em-none-eabihf/debug/examples/${fileBasenameNoExtension}",
"cpu": "cortex-m4",
},
{
"type": "cortex-debug",
"request": "launch",
"name": "Cortex Debug 48Mhz",
"servertype": "openocd",
"cwd": "${workspaceRoot}",
"preLaunchTask": "cargo build --example",
"runToMain": true,
"svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",
"configFiles": [
"interface/stlink.cfg",
"target/stm32f4x.cfg"
],
"preRestartCommands": [
"load",
],
"postLaunchCommands": [
"monitor arm semihosting enable"
],
"swoConfig": {
"enabled": true,
"cpuFrequency": 48000000,
"swoFrequency": 2000000,
"source": "probe",
"decoders": [
{
"type": "console",
"label": "ITM",
"port": 0
}
]
},
"executable": "./target/thumbv7em-none-eabihf/debug/examples/${fileBasenameNoExtension}",
"cpu": "cortex-m4",
},
{
......@@ -54,7 +89,7 @@
"runToMain": true,
"svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",
"configFiles": [
"interface/stlink-v2-1.cfg",
"interface/stlink.cfg",
"target/stm32f4x.cfg"
],
"preRestartCommands": [
......@@ -76,20 +111,20 @@
}
]
},
"executable": "./target/thumbv7em-none-eabi/release/examples/${fileBasenameNoExtension}",
"executable": "./target/thumbv7em-none-eabihf/release/examples/${fileBasenameNoExtension}",
"cpu": "cortex-m4",
},
{
"type": "cortex-debug",
"request": "launch",
"name": "Cortex Nightly",
"name": "Cortex Release 48Mhz",
"servertype": "openocd",
"cwd": "${workspaceRoot}",
"preLaunchTask": "cargo build --example --release --nightly",
"preLaunchTask": "cargo build --example --release",
"runToMain": true,
"svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",
"configFiles": [
"interface/stlink-v2-1.cfg",
"interface/stlink.cfg",
"target/stm32f4x.cfg"
],
"preRestartCommands": [
......@@ -98,8 +133,21 @@
"postLaunchCommands": [
"monitor arm semihosting enable"
],
"executable": "./target/thumbv7em-none-eabi/release/examples/${fileBasenameNoExtension}",
"cpu": "cortex-m4",
},
"swoConfig": {
"enabled": true,
"cpuFrequency": 48000000,
"swoFrequency": 2000000,
"source": "probe",
"decoders": [
{
"type": "console",
"label": "ITM",
"port": 0
}
]
},
"executable": "./target/thumbv7em-none-eabihf/release/examples/${fileBasenameNoExtension}",
"cpu": "cortex-m4",
}
]
}.
\ No newline at end of file
.vscode/tasks.json
View file @ bfd24e96
......@@ -4,31 +4,31 @@
"version": "2.0.0",
"tasks": [
{
"type": "cargo",
"command": "build --example ${fileBasenameNoExtension}",
"problemMatcher": [
"$rustc"
"label": "cargo build --example",
"command": "cargo",
"args": [
"build",
"--example",
"${fileBasenameNoExtension}"
],
"group": "build",
"label": "cargo build --example"
},
{
"type": "cargo",
"command": "build --example ${fileBasenameNoExtension} --release",
"problemMatcher": [
"$rustc"
],
"group": "build",
"label": "cargo build --example --release"
},
{
"type": "cargo",
"command": "build --example ${fileBasenameNoExtension} --release --features nightly",
"label": "cargo build --example --release",
"command": "cargo",
"args": [
"build",
"--example",
"${fileBasenameNoExtension}",
"--release"
],
"problemMatcher": [
"$rustc"
],
"group": "build",
"label": "cargo build --example --release --nightly"
}
},
]
}
\ No newline at end of file
CHANGELOG.md 0 → 100644
View file @ bfd24e96
# Changelog
## 2021-03-19
- `examples/itm_rtic_hello_48MHz.rs`, example to trace ITM, when processor runs at 48MHz, useful to debug USB applications.
- `.vscode/launch.json`, added 48MHz itm tracing profiles. (Now consistenly using `stlink.cfg`.)
## 2021-03-18
- `examples/usb-mouse.rs`, a very small example using external hid library.
## 2021-03-07
- `examples/rtic_bare7.rs`, using embedded HAL.
- `examples/rtic_bare8.rs`, serial communication, bad design.
- `examples/rtic_bare9.rs`, serial communication, good design.
## 2021-03-05
- `examples/rtic_bare6.rs`, setup and validate the clock tree.
## 2021-02-28
- `examples/rtic_bare2.rs`, raw timer access.
- `examples/rtic_bare3.rs`, timing abstractions.
- `examples/rtic_bare4.rs`, a simple bare metal peripheral access API.
- `examples/rtic_bare5.rs`, write your own C-like peripheral access API.
## 2021-02-26
- `examples/bare1.rs`, bare metal 101!
## 2021-02-23
- `examples/rtic_blinky.rs`, added instructions to terminal based debugging
## 2021-02-22
- `memory.x`, reduced flash size to 128k to match light-weight target
- `Cargo.toml`, updated dependencies to latest `stm32f4xx-hal/pac`
Some experiments (wip):
- `examples/rtt_rtic_i2c.rs`, spi emulation over i2c
- `src/pwm3389e`, driver using emulated spi
## 2021-02-16
- `rtt_rtic_usb_mouse` updated
Notice, requires release build
## 2021-02-15
- Initial release for the e7020e course 2021
\ No newline at end of file
Cargo.toml
View file @ bfd24e96
......@@ -6,68 +6,60 @@ name = "app"
version = "0.1.0"
[dependencies]
cortex-m = "0.6.4"
cortex-m = { version = "0.7.1", features = ["linker-plugin-lto"] }
# cortex-m = { version = "0.7.1" }
cortex-m-rt = "0.6.13"
cortex-m-semihosting = "0.3.7"
cortex-m-rtic = "0.5.5"
# embedded-hal = { version = "0.2.4", features = ["unproven"] }
embedded-hal = "0.2.4"
usb-device = "0.2.7"
# Panic handlers, comment all but one to generate doc!
panic-halt = "0.2.0"
# Uncomment for the panic example.
#panic-itm = "0.4.2"
# Uncomment for the itm panic examples.
panic-itm = "0.4.2"
# Uncomment for the rtt-timing example.
#panic-rtt-target = { version = "0.1.1", features = ["cortex-m"] }
# Uncomment for the rtt-timing examples.
panic-rtt-target = { version = "0.1.1", features = ["cortex-m"] }
# Uncomment for the panic example.
#panic-semihosting = "0.5.6"
# Uncomment for the semihosting examples.
panic-semihosting = "0.5.6"
# Tracing
rtt-target = { version = "0.3.0", features = ["cortex-m"] }
rtt-target = { version = "0.3.1", features = ["cortex-m"] }
nb = "1.0.0"
usbd-hid = "0.5.0"
micromath = "1.1.0"
[dependencies.stm32f4]
version = "0.12.1"
version = "0.13.0"
features = ["stm32f411", "rt"]
# Uncomment for the allocator example.
# alloc-cortex-m = "0.4.0"
[dependencies.stm32f4xx-hal]
version = "0.8.3"
version = "0.9.0"
features = ["rt", "stm32f411", "usb_fs"]
git = "https://github.com/stm32-rs/stm32f4xx-hal"
# Enable to use the latest git version
# gitgit = "https://github.com/stm32-rs/stm32f4xx-hal"
# Enable to use your forked/cloned local repo
# path = "../stm32f4xx-hal"
# this lets you use `cargo fix`!
[[bin]]
name = "app"
test = false
bench = false
# [[bin]]
# name = "app"
# # test = false
# bench = false
[profile.dev]
incremental = false
codegen-units = 1
overflow-checks = false
[profile.release]
incremental = false
codegen-units = 1 # better optimizations
debug = true # symbols are nice and they don't increase the size on Flash
lto = true # better optimizations
# [features]
# nightly = ["cortex-m/inline-asm"]
# # this lets you use `cargo fix`!
# [[bin]]
# name = "app"
# test = false
# bench = false
# [profile.release]
# codegen-units = 1 # better optimizations
# debug = true # symbols are nice and they don't increase the size on Flash
# lto = true # better optimizations
README.md
View file @ bfd24e96
# App
# RTIC on the STM32F4xx Nucleo board
## Resources
All tooling have been developed and tested under Linux. Any modern Linux distro should work, we usually recommend Arch linux as it provides a great package manager with rolling releases. If you want to run Arch, but don't want to install everything from scratch, you may opt for [Manjaro](https://manjaro.org/) or [Endeavour](https://endeavouros.com/). You will get the best user experience by a native install, but you may run Linux under a VM like virtualbox, or vmware (the player is free). You should install the guest extensions, to get better graphics performance (and perhaps better USB forwarding). Since you will connect your Nucleo using USB, you must make sure that USB port forwarding works (the Nucleo stlink programmer is a USB2 device running in full speed 12MBit).
This repo will be updated with more information throughout the course so please check the `CHANGELOG.md` and recent commits to see what has changed. (You should `pull` the upstream to keep your repository updated.) If you have suggestions to further improvements, please raise an issue and/or create a merge/pull request.
## Rust
We assume Rust to be installed using [rustup](https://www.rust-lang.org/tools/install).
Additionally you need to install the `thumbv7em-none-eabi` target.
```shell
> rustup target add thumbv7em-none-eabi
```
You also need [cargo-binutils](https://github.com/rust-embedded/cargo-binutils), for inspecting the generated binaries. You install Rust applications through `cargo`
```shell
> cargo install cargo-binutils
```
There are a number of other useful [cargo subcommands](https://github.com/rust-lang/cargo/wiki/Third-party-cargo-subcommands), notably `cargo-bloat` (that gives you info on the size of different sections of the generated binary), `cargo-tree` (that list your dependency tree), etc.
## For RTT tracing
We assume the following tools are in place:
- [probe-run](https://crates.io/crates/probe-run)
## For programming and low level `gdb` based debugging
Linux tooling:
- `stlink`, this package will install programming utilities like `st-flash` (useful if you need to recover a bricked target by erasing the flash), and setup `udev` rules, allowing you to access the USB device without `sudo`. Install may require you to login/logout to have new `udev` rules applied.
- `openocd`, this tool allows the host to connect to the (stlink) programmer.
- `arm-none-eabi-gdb`, or `gdb-multiarch` (dependent on Linux distro). This tool allows you to program (flash) and debug your target.
## Editor
You may use any editor of choice. `vscode` supports Rust using the `rust-analyzer` plugin. You may also want to install the `Cortex Debug` plugin. In the `.vscode` folder, there are a number of configuration files (`launch.json` for target debugging, `tasks.json` for building, etc.).
## Useful Resources
- Nucleo 64
- [UM1724 - stm32 Nucleo-64](https://www.st.com/resource/en/user_manual/dm00105823-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf).
- [Nucleo 64 Schematics](https://www.st.com/resource/en/schematic_pack/nucleo_64pins_sch.zip) (The file MB1136.pdf is the schematics in pdf.)
- [stm32f4xx_hal](https://docs.rs/stm32f4xx-hal/0.8.3/stm32f4xx_hal/) documentation of the HAL API, and [git repository](https://github.com/stm32-rs/stm32f4xx-hal).
- STM32F01/FO11
- [RM0383 - F411 Reference Manual](https://www.st.com/resource/zh/reference_manual/dm00119316-stm32f411xce-advanced-armbased-32bit-mcus-stmicroelectronics.pdf)
- [RM0368 - F401 Reference Manual](https://www.st.com/resource/en/reference_manual/dm00096844-stm32f401xbc-and-stm32f401xde-advanced-armbased-32bit-mcus-stmicroelectronics.pdf)
......@@ -20,25 +59,150 @@
- General Embedded
- [Introduction to SPI](https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html#), a short introduction to the SPI interface.
---
## Examples
### VSCODE based debug and trace
Some simple bare metal examples for you to try out before starting to run your own code:
Using `vscode` just press F5 to launch and debug the program in the currently active vscode window.
- `rtic_hello.rs`, this example uses semihosting to print the output terminal. Open the `OUTPUT` pane, and select `Adapter Output` (which is the openocd console).
- `itm_rtic_hello.rs`, this examples uses the ITM trace to print to an output trace channel. Open the `OUTPUT` pane, and select `SWO:ITM[port:0, type:console]`.
- `rtic_panic.rs`, this example shows how to trace panic messages (in this case over semihosting). Open the `OUTPUT` pane, and select `Adapter Output` (which is the openocd console).
- `rtic_crash.rs`, this example shows how to trace a HardFault (an error raised by the ARM processor).
---
### Exercises
Bare metal programming:
- `examples/rtic_bare1.rs`, in this exercise you learn about debugging, inspecting the generated assembly code, inline assembly, and about checked vs. unchecked (wrapping) arithmetics. Provides essential skills and understanding of low level (bare metal) programming.
- `examples/rtic_bare2.rs`, in this exercise you learn how to measure execution time using raw timer access.
- `examples/rtic_bare3.rs`, here you learn more about RTIC timing semantics and timing abstractions.
- `examples/rtic_bare4.rs`, in this exercise you will encounter a simple bare metal peripheral access API. The API is very unsafe and easy to misuse.
- `examples/rtic_bare5.rs`, here you will write your own C-like peripheral access API. This API is much safer as you get control over bit-fields in a well defined way, thus less error prone.
- `examples/rtic_bare6.rs`, in this exercise you learn about clock tree generation and validation.
- `examples/rtic_bare7.rs`, here you learn more on using embedded HAL abstractions and the use of generics.
- `examples/rtic_bare8.rs`, in this exercise you will setup serial communication to receive and send data. You will also see that polling may lead to data loss in a bad design.
- `examples/rtic_bare9.rs`, here you revisit serial communication and implement a good design in RTIC leveraging preemptive scheduling to ensure lossless communication.
---
## Connections
### Console based debug and trace
- `rtt_rtic_hello.rs`, this example uses the RTT framework for tracing.
- [USB Cable]
```shell
> cargo run --example rtt_rtic_hello
```
---
## Nucleo Connections
---
| Signl | Color | Pin |
| ----- | ----- | ---- |
| V+ | Red | ---- |
| D- | White | PA11 |
| D+ | Green | PA12 |
| Gnd | Black | ---- |
Some of the examples need external connection to the Nucleo to work.
D+ used for re-enumeration
---
### USB example
| Signal | Color | Pin | Nucleo |
| ------ | ----- | ---- | --------- |
| V+ | Red | | |
| D- | White | PA11 | CN10 - 14 |
| D+ | Green | PA12 | CN10 - 12 |
| Gnd | Black | | CN10 - 9 |
D+ used for re-enumeration. You don't need to connect the V+ from the USB cable, as the NUCLEO is self powered.
---
### PWM example
| Signal | Pin | Nucleo |
| ------ | --- | ------- |
| PWM1 | PA8 | CN9 - 8 |
| PWM2 | PA9 | CN5 - 1 |
---
### I2C example
| Signal | Pin | Nucleo |
| -------- | --- | ------ |
| I2C1_SDA | PB9 | CN10-5 |
| I2C1_SCL | PB8 | CN10-3 |
| +3.3v | | CN7-16 |
| GND | | Gnd |
## Debug interface
- Serial Wire debugging uses pins PA13 and PA14.
- Serial Wire debugging uses pins PA13 and PA14. So refrain from using those unless absolutely necessary.
---
## Troubleshooting
---
### Fail to connect or program (flash) your target
- Make sure you have the latest version of the [stlink](https://www.st.com/en/development-tools/stsw-link007.html) firmware (2.37.27 or later).
- Check that your stlink nucleo programmer is found by the host.
```shell
> lsusb
...
Bus 003 Device 013: ID 0483:374b STMicroelectronics ST-LINK/V2.1
...
```
If not check your USB cable. Notice, you need a USB data cable (not a USB charging cable).
If the problem is still there, there might be a USB issue with the host (or VM if you run Linux under a VM that is).
- If you get a connection error similar to the below:
```shell
> openocd -f openocd.cfg
Open On-Chip Debugger 0.10.0+dev-01157-gd6541a811-dirty (2020-03-28-18:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.243627
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
```
- First thing to try is holding the reset button while connecting.
- If this does not work you can try to erase the flash memory (the program running on the STM32F401/F11).
``` shell
> st-flash erase
st-flash 1.7.0
2021-06-23T14:07:35 INFO common.c: F4xx (Dynamic Efficency): 96 KiB SRAM, 512 KiB flash in at least 16 KiB pages.
Mass erasing.......
```
- If this still does not work you can connect `Boot0` to `VDD` (found on CN7 pins 7, and 5 respectively). Unplug/replug the Nucleo and try to erase the flash as above.
- If this still does not work, the Nucleo might actually been damaged, or that the problem is the usb-cable or host machine related.
build.rs
View file @ bfd24e96
......@@ -8,12 +8,15 @@
//! updating `memory.x` ensures a rebuild of the application with the
//! new memory settings.
use core::f64::consts::PI;
use std::env;
use std::fs::File;
use std::io::Write;
use std::path::PathBuf;
use std::{
io::{Result, Write},
path::{Path, PathBuf},
};
fn main() {
fn main() -> Result<()> {
// Put `memory.x` in our output directory and ensure it's
// on the linker search path.
let out = &PathBuf::from(env::var_os("OUT_DIR").unwrap());
......@@ -28,4 +31,24 @@ fn main() {
// here, we ensure the build script is only re-run when
// `memory.x` is changed.
println!("cargo:rerun-if-changed=memory.x");
// generate a sine table
println!("cargo:rerun-if-changed=build.rs");
let out_dir = env::var("OUT_DIR").unwrap();
let dest_path = Path::new(&out_dir).join("sin_abs_const.rs");
let mut f = File::create(&dest_path).unwrap();
const SINE_BUF_SIZE: usize = 65536;
write!(f, "const SINE_BUF_SIZE: usize = {};\n", SINE_BUF_SIZE)?;
write!(f, "const SINE_BUF: [u8; SINE_BUF_SIZE] = [")?;
for i in 0..SINE_BUF_SIZE {
let s = ((i as f64) * 2.0 * PI / SINE_BUF_SIZE as f64).sin();
let v = (128.0 + 128.0 * s) as u8;
write!(f, " {},", v)?;
}
write!(f, "];\n")?;
Ok(())
}
examples/allocator.rs deleted 100644 → 0
View file @ 9540f6d2
//! How to use the heap and a dynamic memory allocator
//!
//! This example depends on the alloc-cortex-m crate so you'll have to add it to your Cargo.toml:
//!
//! ``` text
//! # or edit the Cargo.toml file manually
//! $ cargo add alloc-cortex-m
//! ```
//!
//! ---
#![feature(alloc_error_handler)]
#![no_main]
#![no_std]
extern crate alloc;
use panic_halt as _;
use self::alloc::vec;
use core::alloc::Layout;
use alloc_cortex_m::CortexMHeap;
use cortex_m::asm;
use cortex_m_rt::entry;
use cortex_m_semihosting::{hprintln, debug};
// this is the allocator the application will use
#[global_allocator]
static ALLOCATOR: CortexMHeap = CortexMHeap::empty();
const HEAP_SIZE: usize = 1024; // in bytes
#[entry]
fn main() -> ! {
// Initialize the allocator BEFORE you use it
unsafe { ALLOCATOR.init(cortex_m_rt::heap_start() as usize, HEAP_SIZE) }
// Growable array allocated on the heap
let xs = vec![0, 1, 2];
hprintln!("{:?}", xs).unwrap();
// exit QEMU
// NOTE do not run this on hardware; it can corrupt OpenOCD state
debug::exit(debug::EXIT_SUCCESS);
loop {}
}
// define what happens in an Out Of Memory (OOM) condition
#[alloc_error_handler]
fn alloc_error(_layout: Layout) -> ! {
asm::bkpt();
loop {}
}
examples/crash.rs deleted 100644 → 0
View file @ 9540f6d2
//! Debugging a crash (exception)
//!
//! Most crash conditions trigger a hard fault exception, whose handler is defined via
//! `exception!(HardFault, ..)`. The `HardFault` handler has access to the exception frame, a
//! snapshot of the CPU registers at the moment of the exception.
//!
//! This program crashes and the `HardFault` handler prints to the console the contents of the
//! `ExceptionFrame` and then triggers a breakpoint. From that breakpoint one can see the backtrace
//! that led to the exception.
//!
//! ``` text
//! (gdb) continue
//! Program received signal SIGTRAP, Trace/breakpoint trap.
//! __bkpt () at asm/bkpt.s:3
//! 3 bkpt
//!
//! (gdb) backtrace
//! #0 __bkpt () at asm/bkpt.s:3
//! #1 0x080030b4 in cortex_m::asm::bkpt () at $$/cortex-m-0.5.0/src/asm.rs:19
//! #2 rust_begin_unwind (args=..., file=..., line=99, col=5) at $$/panic-semihosting-0.2.0/src/lib.rs:87
//! #3 0x08001d06 in core::panicking::panic_fmt () at libcore/panicking.rs:71
//! #4 0x080004a6 in crash::hard_fault (ef=0x20004fa0) at examples/crash.rs:99
//! #5 0x08000548 in UserHardFault (ef=0x20004fa0) at <exception macros>:10
//! #6 0x0800093a in HardFault () at asm.s:5
//! Backtrace stopped: previous frame identical to this frame (corrupt stack?)
//! ```
//!
//! In the console output one will find the state of the Program Counter (PC) register at the time
//! of the exception.
//!
//! ``` text
//! panicked at 'HardFault at ExceptionFrame {
//! r0: 0x2fffffff,
//! r1: 0x2fffffff,
//! r2: 0x080051d4,
//! r3: 0x080051d4,
//! r12: 0x20000000,
//! lr: 0x08000435,
//! pc: 0x08000ab6,
//! xpsr: 0x61000000
//! }', examples/crash.rs:106:5
//! ```
//!
//! This register contains the address of the instruction that caused the exception. In GDB one can
//! disassemble the program around this address to observe the instruction that caused the
//! exception.
//!
//! ``` text
//! (gdb) disassemble/m 0x08000ab6
//! Dump of assembler code for function core::ptr::read_volatile:
//! 451 pub unsafe fn read_volatile<T>(src: *const T) -> T {
//! 0x08000aae <+0>: sub sp, #16
//! 0x08000ab0 <+2>: mov r1, r0
//! 0x08000ab2 <+4>: str r0, [sp, #8]
//!
//! 452 intrinsics::volatile_load(src)
//! 0x08000ab4 <+6>: ldr r0, [sp, #8]
//! -> 0x08000ab6 <+8>: ldr r0, [r0, #0]
//! 0x08000ab8 <+10>: str r0, [sp, #12]
//! 0x08000aba <+12>: ldr r0, [sp, #12]
//! 0x08000abc <+14>: str r1, [sp, #4]
//! 0x08000abe <+16>: str r0, [sp, #0]
//! 0x08000ac0 <+18>: b.n 0x8000ac2 <core::ptr::read_volatile+20>
//!
//! 453 }
//! 0x08000ac2 <+20>: ldr r0, [sp, #0]
//! 0x08000ac4 <+22>: add sp, #16
//! 0x08000ac6 <+24>: bx lr
//!
//! End of assembler dump.
//! ```
//!
//! `ldr r0, [r0, #0]` caused the exception. This instruction tried to load (read) a 32-bit word
//! from the address stored in the register `r0`. Looking again at the contents of `ExceptionFrame`
//! we see that the `r0` contained the address `0x2FFF_FFFF` when this instruction was executed.
//!
//! ---
#![no_main]
#![no_std]
use panic_halt as _;
use core::ptr;
use cortex_m_rt::entry;
#[entry]
fn main() -> ! {
unsafe {
// read an address outside of the RAM region; this causes a HardFault exception
ptr::read_volatile(0x2FFF_FFFF as *const u32);
}
loop {}
}
examples/device.rs deleted 100644 → 0
View file @ 9540f6d2
//! Using a device crate
//!
//! Crates generated using [`svd2rust`] are referred to as device crates. These crates provide an
//! API to access the peripherals of a device.
//!
//! [`svd2rust`]: https://crates.io/crates/svd2rust
//!
//! This example depends on the [`stm32f3`] crate so you'll have to
//! uncomment it in your Cargo.toml.
//!
//! [`stm32f3`]: https://crates.io/crates/stm32f3
//!
//! ```
//! $ edit Cargo.toml && tail $_
//! [dependencies.stm32f3]
//! features = ["stm32f303", "rt"]
//! version = "0.7.1"
//! ```
//!
//! You also need to set the build target to thumbv7em-none-eabihf,
//! typically by editing `.cargo/config` and uncommenting the relevant target line.
//!
//! ---
#![no_main]
#![no_std]
#[allow(unused_extern_crates)]
use panic_halt as _;
use cortex_m::peripheral::syst::SystClkSource;
use cortex_m_rt::entry;
use cortex_m_semihosting::hprint;
use stm32f3::stm32f303::{interrupt, Interrupt, NVIC};
#[entry]
fn main() -> ! {
let p = cortex_m::Peripherals::take().unwrap();
let mut syst = p.SYST;
let mut nvic = p.NVIC;
nvic.enable(Interrupt::EXTI0);
// configure the system timer to wrap around every second
syst.set_clock_source(SystClkSource::Core);
syst.set_reload(8_000_000); // 1s
syst.enable_counter();
loop {
// busy wait until the timer wraps around
while !syst.has_wrapped() {}
// trigger the `EXTI0` interrupt
NVIC::pend(Interrupt::EXTI0);
}
}
#[interrupt]
fn EXTI0() {
hprint!(".").unwrap();
}
examples/exception.rs deleted 100644 → 0
View file @ 9540f6d2
//! Overriding an exception handler
//!
//! You can override an exception handler using the [`#[exception]`][1] attribute.
//!
//! [1]: https://rust-embedded.github.io/cortex-m-rt/0.6.1/cortex_m_rt_macros/fn.exception.html
//!
//! ---
#![deny(unsafe_code)]
#![no_main]
#![no_std]
use panic_halt as _;
use cortex_m::peripheral::syst::SystClkSource;
use cortex_m::Peripherals;
use cortex_m_rt::{entry, exception};
use cortex_m_semihosting::hprint;
#[entry]
fn main() -> ! {
let p = Peripherals::take().unwrap();
let mut syst = p.SYST;
// configures the system timer to trigger a SysTick exception every second
syst.set_clock_source(SystClkSource::Core);
syst.set_reload(8_000_000); // period = 1s
syst.enable_counter();
syst.enable_interrupt();
loop {}
}
#[exception]
fn SysTick() {
hprint!(".").unwrap();
}
examples/hello.rs deleted 100644 → 0
View file @ 9540f6d2
//! Prints "Hello, world!" on the host console using semihosting
#![no_main]
#![no_std]
use panic_halt as _;
use cortex_m_rt::entry;
use cortex_m_semihosting::{debug, hprintln};
#[entry]
fn main() -> ! {
hprintln!("Hello, world!!").unwrap();
loop {}
}
examples/itm.rs deleted 100644 → 0
View file @ 9540f6d2
//! Sends "Hello, world!" through the ITM port 0
//!
//! ITM is much faster than semihosting. Like 4 orders of magnitude or so.
//!
//! **NOTE** Cortex-M0 chips don't support ITM.
//!
//! You'll have to connect the microcontroller's SWO pin to the SWD interface. Note that some
//! development boards don't provide this option.
//!
//! You'll need [`itmdump`] to receive the message on the host plus you'll need to uncomment two
//! `monitor` commands in the `.gdbinit` file.
//!
//! [`itmdump`]: https://docs.rs/itm/0.2.1/itm/
//!
//! ---
#![no_main]
#![no_std]
use panic_halt as _;
use cortex_m::{iprintln, Peripherals};
use cortex_m_rt::entry;
use stm32f4 as _; // to get interrupt vectors
#[entry]
fn main() -> ! {
let mut p = Peripherals::take().unwrap();
let stim = &mut p.ITM.stim[0];
iprintln!(stim, "Hello, world!");
loop {}
}
examples/itm_rtic_hello.rs 0 → 100644
View file @ bfd24e96
#![no_main]
#![no_std]
use cortex_m::iprintln;
use panic_halt as _;
use stm32f4;
#[rtic::app(device = stm32f4)]
const APP: () = {
#[init]
fn init(cx: init::Context) {
// Set up the system clock.
let rcc = ctx.device.RCC.constrain();
let _clocks = rcc.cfgr.sysclk(48.mhz()).require_pll48clk().freeze();
let mut p = cx.core;
let stim = &mut p.ITM.stim[0];
for a in 0..=10 {
iprintln!(stim, "RTIC Hello, world!! {}", a);
}
}
};
examples/itm_rtic_hello_48Mhz.rs 0 → 100644
View file @ bfd24e96
// itm_rtic_hello_48Mhz
//
// Use the vscode 48Mhz launch profiles
#![no_main]
#![no_std]
use cortex_m::iprintln;
use panic_halt as _;
use stm32f4xx_hal::prelude::*;
#[rtic::app(device = stm32f4xx_hal::stm32, peripherals = true)]
const APP: () = {
#[init]
fn init(ctx: init::Context) {
// Set up the system clock.
let rcc = ctx.device.RCC.constrain();
let _clocks = rcc.cfgr.sysclk(48.mhz()).require_pll48clk().freeze();
let mut p = ctx.core;
let stim = &mut p.ITM.stim[0];
for a in 0..=10 {
iprintln!(stim, "RTIC Hello, world!! {}", a);
}
}
};
examples/pmw3389.rs
View file @ bfd24e96
This diff is collapsed.
examples/rtic_bare1.rs 0 → 100644
View file @ bfd24e96
//! bare1.rs
//!
//! Inspecting the generated assembly
//!
//! What it covers
//! - Rust panic on arithmetics
//! - assembly calls and inline assembly
#![no_main]
#![no_std]
use cortex_m_semihosting::hprintln;
use panic_semihosting as _;
use stm32f4;
#[rtic::app(device = stm32f4)]
const APP: () = {
#[init]
#[inline(never)] // avoid inlining of this function/task
#[no_mangle] // to strip hash from symbols (easier to read)
fn init(_cx: init::Context) {
hprintln!("hello");
let mut x = core::u32::MAX - 1;
loop {
// cortex_m::asm::bkpt();
x += 1;
// cortex_m::asm::bkpt();
// prevent optimization by read-volatile (unsafe)
unsafe {
core::ptr::read_volatile(&x);
}
}
}
};
// 0. Setup
// Make sure that your repository is updated (pull from upstream).
//
// 1. Build in debug mode and run the application in vscode (Cortex Debug)
//
// Continue until you hit a breakpoint.
//
// Now select OUTPUT and Adapter Output.
//
// You should have encountered a Rust panic.
//
// Paste the error message:
//
// ** your answer here **
//
// Explain in your own words why the code panic:ed.
//
// ** your answer here **
//
// Commit your answer (bare1_1)
//
// 2. Inspecting what caused the panic.
//
// Under CALL STACK you find the calls done to reach the panic:
//
// You can get the same information directly from GDB
//
// Select the DEBUG CONSOLE and enter the command
//
// > backtrace
//
// Paste the backtrace:
//
// ** your answer here
//
// Explain in your own words the chain of calls.
//
// ** your answer here
//
// Commit your answer (bare1_2)
//
// 3. Now let's try to break it down to see what caused the panic.
//
// Put a breakpoint at line 24 (x += 1;)
// (Click to the left of the line marker, you get a red dot.)
//
// Restart the debug session, and continue until you hit the breakpoint.
//
// What is the value of `x`?
//
// ** your answer here **
//
// Explain in your own words where this value comes from.
//
// ** your answer here **
//
// Now continue the program, since you are in a loop
// the program will halt again at line 24.
//
// What is the value of `x`?
//
// Explain in your own words why `x` now has this value.
//
// ** your answer here **
//
// Now continue again.
//
// At this point your code should panic.
//
// You can navigate the CALL STACK.
// Click on rtic_bare::init@0x08.. (24)
//
// The line leading up to the panic should now be highlighted.
// So you can locate the precise line which caused the error.
//
// Explain in your own words why a panic makes sense at this point.
//
// ** your answer here **
//
// Commit your answer (bare1_3)
//
// 4. Now lets have a look at the generated assembly.
//
// First restart the debug session and continue to the first halt (line 24).
//
// Select DEBUG CONSOLE and give the command
//
// > disassemble
//
// The current PC (program counter is marked with an arrow)
// => 0x08000f18 <+20>: ldr r0, [sp, #0]
//
// Explain in your own words what this assembly line does.
//
// ** your answer here **
//
// In Cortex Registers (left) you can see the content of `r0`
//
// What value do you observe?
//
// ** your answer here **
//
// You can also get the register info from GDB directly.
//
// > register info
//
// Many GDB commands have short names try `i r`.
//
// So now, time to move on, one assembly instruction at a time.
//
// > stepi
// > disassemble
//
// Now you should get
// => 0x08000f1a <+22>: adds r0, #1
//
// Explain in your own words what is happening here.
//
// ** your answer here **
//
// We move to the next assembly instruction:
//
// > si
// > i r
//
// What is the reported value for `r0`
//
// ** your answer here **
//
// So far so good.
//
// We can now continue to the next breakpoint.
//
// > continue
// (or in short >c, or press the play button, or press F5, many options here ...)
// > disassemble
// (or in short >disass)
//
// You should now be back at the top of the loop:
//
// => 0x08000f18 <+20>: ldr r0, [sp, #0]
//
// and the value of `r0` should be -1 (or 0xffffffff in hexadecimal)
//
// Now we can step an instruction again.
//
// > si
// => 0x08000f1a <+22>: adds r0, #1
//
// So far so good, and another one.
//
// > si
// => 0x08000f1c <+24>: bcs.n 0x8000f28 <rtic_bare::init+36>
//
// lookup the arm instruction set: https://developer.arm.com/documentation/ddi0210/c/Introduction/Instruction-set-summary/Thumb-instruction-summary
//
// What does BCS do?
//
// ** your answer here **
//
// Now let's see what happens.
//
// > si
// => 0x08000f28 <+36>: movw r0, #6128 ; 0x17f0
// 0x08000f2c <+40>: movw r2, #6112 ; 0x17e0
// 0x08000f30 <+44>: movt r0, #2048 ; 0x800
// 0x08000f34 <+48>: movt r2, #2048 ; 0x800
// 0x08000f38 <+52>: movs r1, #28
// 0x08000f3a <+54>: bl 0x8000346 <_ZN4core9panicking5panic17h6c8437680724f6d0E>
//
// Explain in your own words where we are heading.
//
// ** your answer here **
//
// To validate that your answer, let's let the program continue
//
// > c
//
// Look in the OUTPUT/Adapter Output console again.
//
// Explain in your own words what the code
// 0x08000f28 .. 0x08000f38 achieves
//
// Hint 1, look at the error message?
// Hint 2, look at the call stack.
// Hint 3, the code is generated by the Rust compiler to produce the error message.
// there is no "magic" here, just a compiler generating code...
//
// ** your answer here **
//
// Commit your answer (bare1_4)
//
// 5. Now we can remove the break point (click the `Remove All Breakpoints`),
// and instead uncomment the two breakpoint instructions (on lines 23 and 25).
//
// Close the debug session and press F5 again to re-compile and launch the app.
//
// Continue until you hit the firs breakpoint.
//
// The disassembly should look like this:
//
//
// 0x08000f18 <+20>: bl 0x800103e <lib::__bkpt>
// => 0x08000f1c <+24>: ldr r0, [sp, #0]
// 0x08000f1e <+26>: adds r0, #1
// 0x08000f20 <+28>: bcs.n 0x8000f30 <rtic_bare::init+44>
// 0x08000f22 <+30>: str r0, [sp, #0]
// 0x08000f24 <+32>: bl 0x800103e <lib::__bkpt>
// 0x08000f28 <+36>: mov r0, r4
// 0x08000f2a <+38>: bl 0x8000fde <_ZN4core3ptr13read_volatile17hea5ef1c780562e1fE>
//
// In stable Rust we cannot currently write inline assembly, thus we do a "workaround"
// and call a function that that contains the assembly instruction.
//
// In this code:
// 0x08000f18 <+20>: bl 0x800103e <lib::__bkpt>
// and
// 0x08000f24 <+32>: bl 0x800103e <lib::__bkpt>
//
// In cases, this is not good enough (if we want exact cycle by cycle control).
// We can overcome this by letting the linker inline the code.
//
// Let's try this, build and run the code in release mode (Cortex Release).
// Continue until you hit the first assembly breakpoint.
//
// The disassembly now should look like this:
//
// => 0x0800024c <+12>: bkpt 0x0000
// 0x0800024e <+14>: adds r0, #1
// 0x08000250 <+16>: str r0, [sp, #4]
// 0x08000252 <+18>: bkpt 0x0000
// 0x08000254 <+20>: ldr r0, [sp, #4]
// 0x08000256 <+22>: b.n 0x800024c <rtic_bare::init+12>
//
// Now let's compare the two assembly snippets.
// We now see that the breakpoints have been inlined (offsets +12, +18).
//
// But something else also happened here!
//
// Do you see any way this code may end up in a panic?
//
// ** your answer here **
//
// So clearly, the "semantics" (meaning) of the program has changed.
// This is on purpose, Rust adopts "unchecked" (wrapping) additions (and subtractions)
// by default in release mode (to improve performance).
//
// The downside, is that programs change meaning. If you intend the operation
// to be wrapping you can explicitly express that in the code.
//
// Change the x += 1 to x = x.wrapping_add(1).
//
// And recompile/run/the code in Debug mode
//
// Paste the generated assembly:
//
// ** your answer here **
//
// Can this code generate a panic?
//
// ** your answer here **
//
// Is there now any reference to the panic handler?
// If not, why is that the case?
//
// ** your answer here **
//
// commit your answers (bare1_5)
//
// Discussion:
// In release (optimized) mode the addition is unchecked,
// so there is a semantic difference here in between
// the dev and release modes. This is motivated by:
// 1) efficiency, unchecked/wrapping is faster
// 2) convenience, it would be inconvenient to explicitly use
// wrapping arithmetics, and wrapping is what the programmer
// typically would expect in any case. So the check
// in dev/debug mode is just there for some extra safety
// if your intention is NON-wrapping arithmetics.
//
// The debug build should have additional code that checks if the addition
// wraps (and in such case call panic). In the case of the optimized
// build there should be no reference to the panic handler in the generated
// binary. Recovering from a panic is in general very hard. Typically
// the best we can do is to stop and report the error (and maybe restart).
//
// Later we will demonstrate how we can get guarantees of panic free execution.
// This is very important to improve reliability.
//
// 6. Now comment out the `read_volatile`.
//
// Rebuild and run the code in Release mode.
//
// Dump the generated assembly.
//
// ** your answer here **
//
// Where is the local variable stored?
// What happened, and why is Rust + LLVM allowed to optimize out your code?
//
// ** your answer here **
//
// Commit your answers (bare1_6)
//
//
// 7. *Optional
// You can pass additional flags to the Rust `rustc` compiler.
//
// `-Z force-overflow-checks=off`
//
// Under this flag, code is never generated for overflow checking even in
// non optimized (debug/dev) builds.
// You can enable this flag in the `.cargo/config` file.
//
// What is now the disassembly of the loop (in debug/dev mode):
//
// ** your answer here **
//
// commit your answers (bare1_7)
//
// Now restore the `.cargo/config` to its original state.
//
// 8. *Optional
// There is another way to conveniently use wrapping arithmetics
// without passing flags to the compiler.
//
// https://doc.rust-lang.org/std/num/struct.Wrapping.html
//
// Rewrite the code using this approach.
//
// What is now the disassembly of the code in dev mode?
//
// ** your answer here **
//
// What is now the disassembly of the code in release mode?
//
// ** your answer here **
//
// commit your answers (bare1_8)
//
// Final discussion:
//
// Embedded code typically is performance sensitive, hence
// it is important to understand how code is generated
// to achieve efficient implementations.
//
// Moreover, arithmetics are key to processing of data,
// so its important that we are in control over the
// computations. E.g. computing checksums, hashes, cryptos etc.
// all require precise control over wrapping vs. overflow behavior.
//
// If you write a library depending on wrapping arithmetics
// do NOT rely on a compiler flag. (The end user might compile
// it without this flag enabled, and thus get erroneous results.)
//
examples/rtic_bare2.rs 0 → 100644
View file @ bfd24e96
//! rtic_bare2.rs
//!
//! Measuring execution time
//!
//! What it covers
//! - Generating documentation
//! - Using core peripherals
//! - Measuring time using the DWT
#![no_main]
#![no_std]
use cortex_m::peripheral::DWT;
use cortex_m_semihosting::hprintln;
use panic_semihosting as _;
use stm32f4;
#[rtic::app(device = stm32f4)]
const APP: () = {
#[init]
fn init(mut cx: init::Context) {
cx.core.DWT.enable_cycle_counter();
// Reading the cycle counter can be done without `owning` access
// the DWT (since it has no side effect).
//
// Look in the docs:
// pub fn enable_cycle_counter(&mut self)
// pub fn get_cycle_count() -> u32
//
// Notice the difference in the function signature!
let start = DWT::get_cycle_count();
wait(1_000_000);
let end = DWT::get_cycle_count();
// notice all printing outside of the section to measure!
hprintln!("Start {:?}", start).ok();
hprintln!("End {:?}", end).ok();
hprintln!("Diff {:?}", end.wrapping_sub(start)).ok();
// wait(100);
}
};
// burns CPU cycles by just looping `i` times
#[inline(never)]
#[no_mangle]
fn wait(i: u32) {
for _ in 0..i {
// no operation (ensured not optimized out)
cortex_m::asm::nop();
}
}
// 0. Setup
//
// > cargo doc --open
//
// `cargo.doc` will document your crate, and open the docs in your browser.
// If it does not auto-open, then copy paste the path shown in your browser.
//
// Notice, it will try to document all dependencies, you may have only one
// one panic handler, so temporarily comment out all but one in `Cargo.toml`.
//
// In the docs, search (`S`) for DWT, and click `cortex_m::peripheral::DWT`.
// Read the API docs.
//
// 1. Build and run the application in vscode using (Cortex Debug).
//
// What is the output in the Adapter Output console?
// (Notice, it will take a while we loop one million times at only 16 MHz.)
//
// ** your answer here **
//
// Rebuild and run in (Cortex Release).
//
// ** your answer here **
//
// Compute the ratio between debug/release optimized code
// (the speedup).
//
// ** your answer here **
//
// commit your answers (bare2_1)
//
// 2. As seen there is a HUGE difference in between Debug and Release builds.
// In Debug builds, the compiler preserves all abstractions, so there will
// be a lot of calls and pointer indirections.
//
// In Release builds, the compiler strives to "smash" all abstractions into straight
// line code.
//
// This is what Rust "zero-cost abstractions" means, not zero execution time but rather,
// "as good as it possibly gets" (you pay no extra cost for using abstractions at run-time).
//
// In Release builds, the compiler is able to "specialize" the implementation
// of each function.
//
// Let us look in detail at the `wait` function:
// Place a breakpoint at line 54 (wait). Restart the (Cortex Release) session and
// look at the generated code.
//
// > disass
//
// Dump generated assembly for the "wait" function.
//
// ** your answer here **
//
// Under the ARM calling convention, r0.. is used as arguments.
// However in this case, we se that r0 is set by the assembly instructions,
// before the loop is entered.
//
// Lookup the two instructions `movw` and `movt` to figure out what happens here.
//
// Answer in your own words, how they assign r0 to 1000000.
//
// ** your answer here **
//
// Commit your answers (bare2_2)
//
// 3. Now add a second call to `wait` (line 42).
//
// Recompile and run until the breakpoint.
//
// Dump the generated assembly for the "wait" function.
//
// ** your answer here **
//
// Answer in your own words, why you believe the generated code differs?
//
// ** your answer here **
//
// Commit your answers (bare2_3)
examples/rtic_bare3.rs 0 → 100644
View file @ bfd24e96
//! rtic_bare3.rs
//!
//! Measuring execution time
//!
//! What it covers
//! - Reading Rust documentation
//! - Timing abstractions and semantics
//! - Understanding Rust abstractions
#![no_main]
#![no_std]
use cortex_m_semihosting::hprintln;
use panic_semihosting as _;
use rtic::cyccnt::Instant;
use stm32f4;
#[rtic::app(device = stm32f4)]
const APP: () = {
#[init]
fn init(mut cx: init::Context) {
cx.core.DWT.enable_cycle_counter();
let start = Instant::now();
wait(1_000_000);
let end = Instant::now();
// notice all printing outside of the section to measure!
hprintln!("Start {:?}", start).ok();
hprintln!("End {:?}", end).ok();
// hprintln!("Diff {:?}", (end - start) ).ok();
}
};
// burns CPU cycles by just looping `i` times
#[inline(never)]
#[no_mangle]
fn wait(i: u32) {
for _ in 0..i {
// no operation (ensured not optimized out)
cortex_m::asm::nop();
}
}
// 0. Setup
//
// > cargo doc --open
//
// In the docs, search (`S`) for `Monotonic` and read the API docs.
// Also search for `Instant`, and `Duration`.
//
// Together these provide timing semantics.
//
// - `Monotonic` is a "trait" for a timer implementation.
// - `Instant` is a point in time.
// - `Duration` is a range in time.
//
// By default RTIC uses the `Systic` and the `DWT` cycle counter
// to provide a `Monotonic` timer.
//
// 1. Build and run the application in vscode using (Cortex Release).
//
// What is the output in the Adapter Output console?
//
// ** your answer here **
//
// As you see line 31 is commented out (we never print the difference).
//
// Now uncomment line 31, and try to run the program. You will see
// that it fails to compile right as `Duration` does not implement `Debug`
// (needed for formatting the printout.)
//
// This is on purpose as `Duration` is abstract (opaque). You need to
// turn it into a concrete value. Look at the documentation, to find out
// a way to turn it into clock cycles (which are printable).
//
// What is now the output in the Adapter Output console?
//
// ** your answer here **
//
// Commit your answers (bare3_1)
//
// 2. Look at the `Instant` documentation.
//
// Alter the code so that you use `duration_since`, instead of manual subtraction.
//
// What is now the output in the Adapter Output console?
//
// ** your answer here **
//
// Commit your answers (bare3_2)
//
// 3. Look at the `Instant` documentation.
// Now alter the code so that it uses `elapsed` instead.
//
// What is now the output in the Adapter Output console?
//
// ** your answer here **
//
// Commit your answers (bare3_3)
//
// 4. Discussion.
//
// If you did implement the above exercises correctly you should get exactly the same
// result (in clock cycles) for all cases as you got in the bare2 exercise.
// (If not, go back and revise your code.)
//
// What this shows, is that we can step away from pure hardware accesses
// and deal with time in a more convenient and "abstract" fashion.
//
// `Instant` and `Duration` are associated with semantics (meaning).
// `Monotonic` is associated the implementation.
//
// This is an example of separation of concerns!
//
// If you implement your application based on Instant and Duration, your code
// will be "portable" across all platforms (that implement Monotonic).
//
// The implementation of Monotonic is done only once for each platform, thus
// bugs related to low level timer access will occur only at one place,
// not scattered across thousands of manually written applications.
//
// However, as you have already seen, the current time abstraction (API) is
// is rather "thin" (provided just a bare minimum functionality).
//
// We are working to further generalize timing semantics, by building
// on a richer abstraction `https://docs.rs/embedded-time/0.10.1/embedded_time/`.
//
// Support for embedded time is projected for next RTIC release.
examples/rtic_bare4.rs 0 → 100644
View file @ bfd24e96
//! rtic_bare4.rs
//!
//! Access to Peripherals
//!
//! What it covers:
//! - Raw pointers
//! - Volatile read/write
//! - Busses and clocking
//! - GPIO (a primitive abstraction)
#![no_std]
#![no_main]
extern crate cortex_m;
extern crate panic_halt;
use stm32f4;
// Peripheral addresses as constants
#[rustfmt::skip]
mod address {
pub const PERIPH_BASE: u32 = 0x40000000;
pub const AHB1PERIPH_BASE: u32 = PERIPH_BASE + 0x00020000;
pub const RCC_BASE: u32 = AHB1PERIPH_BASE + 0x3800;
pub const RCC_AHB1ENR: u32 = RCC_BASE + 0x30;
pub const GBPIA_BASE: u32 = AHB1PERIPH_BASE + 0x0000;
pub const GPIOA_MODER: u32 = GBPIA_BASE + 0x00;
pub const GPIOA_BSRR: u32 = GBPIA_BASE + 0x18;
}
use address::*;
// see the Reference Manual RM0368 (www.st.com/resource/en/reference_manual/dm00096844.pdf)
// rcc, chapter 6
// gpio, chapter 8
#[inline(always)]
fn read_u32(addr: u32) -> u32 {
unsafe { core::ptr::read_volatile(addr as *const _) }
// core::ptr::read_volatile(addr as *const _)
}
#[inline(always)]
fn write_u32(addr: u32, val: u32) {
unsafe {
core::ptr::write_volatile(addr as *mut _, val);
}
}
fn wait(i: u32) {
for _ in 0..i {
cortex_m::asm::nop(); // no operation (cannot be optimized out)
}
}
#[rtic::app(device = stm32f4)]
const APP: () = {
#[init]
fn init(_cx: init::Context) {
// power on GPIOA
let r = read_u32(RCC_AHB1ENR); // read
write_u32(RCC_AHB1ENR, r | 1); // set enable
// configure PA5 as output
let r = read_u32(GPIOA_MODER) & !(0b11 << (5 * 2)); // read and mask
write_u32(GPIOA_MODER, 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
write_u32(GPIOA_BSRR, 1 << 5); // set bit, output hight (turn on led)
wait(10_000);
// set PA5 low
write_u32(GPIOA_BSRR, 1 << (5 + 16)); // clear bit, output low (turn off led)
wait(10_000);
}
}
};
// 0. Build and run the application (Cortex Debug).
//
// 1. Did you enjoy the blinking?
//
// ** your answer here **
//
// 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 38 and uncomment line 39 (essentially omitting the `unsafe`)
//
// //unsafe { core::ptr::read_volatile(addr as *const _) }
// core::ptr::read_volatile(addr as *const _)
//
// What was the error message and explain why.
//
// ** your answer here **
//
// Digging a bit deeper, why do you think `read_volatile` is declared `unsafe`.
// (https://doc.rust-lang.org/core/ptr/fn.read_volatile.html, for some food for thought )
//
// ** your answer here **
//
// 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 variables declared volatile amounts to
// volatile reads/and writes).
//
// Both C and Rust (even more) allows code optimization to re-order operations, as long
// as data dependencies are preserved.
//
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
// ** your answer here **
//
// Give an example in the above code, where reordering might make things go horribly wrong
// (hint, accessing a peripheral not being powered...)
//
// ** your answer here **
//
// Without the non-reordering property of `write_volatile/read_volatile` could that happen in theory
// (argue from the point of data dependencies).
//
// ** your answer here **
//
// Commit your answers (bare4_3)