Skip to content
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions mdbook/src/15-interrupts/nvic-and-interrupt-priority.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,10 @@ Preemption allows processors to respond very quickly to critical events. For ex

If an equal-priority or lower-priority interrupt occurs during an ISR, it will be "pended": the NVIC will remember the new interrupt and run its ISR sometime after the current ISR completes. When an ISR function returns the NVIC looks to see if, while the ISR was running, other interrupts have happened that need to be handled. If so, the NVIC checks the interrupt table and calls the highest-priority ISR vectored there. Otherwise, the CPU returns to the running program.

Note that in most Cortex-M-based systems, *higher-priority* interrupts will be pended by the NVIC
*even* if all interrupts are disabled by a critical section (discussed later in this chapter),
though their execution will be delayed until the critical section ends.

In embedded Rust, we can program the NVIC using the [`cortex-m`] crate, which provides methods to
enable and disable (called `unmask` and `mask`) interrupts, set interrupt priorities, and trigger
interrupts from software. Frameworks such as [RTIC] can handle NVIC configuration for you, taking
Expand Down
4 changes: 2 additions & 2 deletions mdbook/src/15-interrupts/sharing-data-with-globals.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,8 @@
> *[Interrupts Is Threads]* by James Munns, which contains more discussion about this
> topic.

As I mentioned in the last section, when an interrupt occurs we aren't passed any arguments and
cannot return any result. This makes it hard for our program interact with peripherals and other
As I mentioned previously, when an interrupt occurs we aren't passed any arguments and
cannot return any result. This makes it hard for our program to interact with peripherals and other
main program state. Before worrying about this bare-metal embedded problem, it is likely worth
thinking about threads in "std" Rust.

Expand Down
2 changes: 1 addition & 1 deletion mdbook/src/15-interrupts/the-challenge.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Let's make the MB2 into a siren! But not just any siren — an
interrupt-driven siren. That way we can turn the siren on
and the rest of our program can run on, ignoring it.

Make your siren sweep the pitch from 220Hz to 440Hz and back
Make your siren sweep the pitch from 440Hz to 660Hz and back
over a one-second period. The main program should start the
siren, then print a ten-second countdown from 10 to 1, then
stop the siren and print "launch!". The main program should
Expand Down