timing_resources, forgot to add file in 0e63e8b9

examples/timing_resources.rs

@@ -111,10 +111,27 @@ Tl;dr,
 // (gdb) x 0xe0001004
 //
 // [Your answer here]
+/*
+16
+*/
 //
 // (gdb) disassemble
 //
 // [Your answer here]
+/*
+Dump of assembler code for function timing_resources::APP::EXTI0:
+   0x08000232 <+0>:     movw    r1, #0
+   0x08000236 <+4>:     mrs     r0, BASEPRI
+=> 0x0800023a <+8>:     bkpt    0x0000
+   0x0800023c <+10>:    movt    r1, #8192       ; 0x2000
+   0x08000240 <+14>:    ldrd    r2, r3, [r1]
+   0x08000244 <+18>:    adds    r2, #1
+   0x08000246 <+20>:    adc.w   r3, r3, #0
+   0x0800024a <+24>:    strd    r2, r3, [r1]
+   0x0800024e <+28>:    msr     BASEPRI, r0
+   0x08000252 <+32>:    bx      lr
+End of assembler dump.
+*/
 //
 // You should see that we hit the breakpoint in `exti0`, and
 // that the code complies to the objdump EXTI disassembly.
@@ -122,10 +139,17 @@ Tl;dr,
 // What was the software latency observed to enter the task?
 //
 // [Your answer here]
+/*
+Basically nothing, after pending the interupt bit it's up to the hardware to notice the pending interupt.
+After that we only need two instructions to enter the task code.
+*/
 //
 // Does RTIC infer any overhead?
 //
 // [Your answer here]
+/*
+Yes, but very minimal. The only thing that needs to be infered is the changing of the priority ceiling.
+*/
 //
 // The debugger reports that the breakpoint was hit in the `run<closure>`.
 // The reason is that the RTIC implements the actual interrupt handler,