-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
- Loading branch information
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
How does one safely abstract a register? | ||
- well, read this [chapter][rust-embedded-book-peripherals-chapter]. | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
[rust-embedded-book-peripherals-chapter]: undone_add_link |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,33 @@ | ||
- exception attribute with re-entrancy guarantees | ||
- exception attribute with re-entrancy guarantees | ||
- zero-cost abstractions? | ||
|
||
|
||
### What should our rules be when dealing with peripherl registers? | ||
|
||
How can we reliably interact with these peripherals? | ||
|
||
- Always use volatile methods to read or write to peripheral memory, as it can change at any time | ||
- In software, we should be able to share any number of read-only accesses to these peripherals | ||
- If some software should have read-write access to a peripheral, it should hold the only reference to that peripheral | ||
|
||
We cannot use global mutable variables because they expose our peripheral to every software. We just want one software to have the mutable reference to a single peripheral. Every other software should have read_references. | ||
|
||
There should ONLY BE ONE mutable instance of a peripheral. | ||
|
||
That is why we use the Singleton. | ||
|
||
### Pointer manipulations | ||
Be afraid of implicit copies. Just use ONE value assignation and multiple references when dealing with pointers that point to ONE physical memory address. | ||
|
||
As you can see below, x and y have different addresses. | ||
```rust | ||
let x = 10; | ||
let y = x; | ||
|
||
println!("Address of x = {}", (&x as *const i32) as usize); // Address of x = 140735333354256 | ||
println!("Address of y = {}", (&y as *const i32) as usize); // Address of y = 140735333354260 | ||
``` | ||
|
||
|
||
ONE ASSIGNATION, the rest should be references. | ||
TWO ASIGNATIONS result in two different raw addresse.... |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,17 +1,17 @@ | ||
# Probing | ||
|
||
Probing is the act of interacting with the microcotroller via a debug adapter with the aim of doing at least one of the following... | ||
1. Flashing a compiled program onto the RAM or ROM of the microcontroller. | ||
2. Performing some In-system programming | ||
3. Debugging the running program | ||
Probing is the act of interacting with the microcotroller with the aim of doing at least one of the following... | ||
1. Flashing a compiled program onto the RAM or ROM of the microcontroller. ie. writing your code into the RAM or ROM... breathing life into the machine. | ||
|
||
2. Performing some In-system programming ie. literally manipulating the values found in the processor's registers and occasionaly reading and writing to memory. | ||
|
||
3. Debugging the running program : Observing the how the program state changes in a step by step fashion. | ||
|
||
4. Testing the functionality of the microcrontroller | ||
|
||
This chapter walks through the first 3 tasks while assuming that... | ||
- Your host machine is a linux box | ||
This chapter walks through the theory behind first 3 tasks while assuming that... | ||
- Your host machine is a linux box | ||
- Your target machine is an esp32c3 SoC. | ||
|
||
This chapter has also been divided into two : | ||
- The theory behind probing | ||
- The practicals | ||
|
||
You choose how you'd like to read through it. | ||
The practicals will be covered in a later chapter. | ||
<!-- undone: Specify the actua chapter --> |