doc: add a tips and tricks section to the interrupt docs #378
Conversation
Signed-off-by: Christian Ege <ch@ege.io>
Signed-off-by: Christian Ege <ch@ege.io>
| When writing an interrupt handler you have to take care that your code does not block. This is important because the interrupt execution typically has higher priority than your regular code. This means in case your interrupt handler code needs to wait for anything it will wait forever. In general, it is good advice to avoid the following: | ||
|
|
||
| * Memory allocation, for details see [heap allocation]({{<ref "heap-allocation.md">}}). | ||
| * Blocking on channels, better use a select with a default clause to implement non-blocking send and receives. |
There was a problem hiding this comment.
It's stronger than this.
typically has higher priority than your regular code
This is always the case. An interrupt always runs instead of regular code, and unless you use very weird hacks you can't continue normal code. (This is true for all architectures I've looked at: Cortex-M, AVR, Xtensa, RISC-V). In fact, the runtime now checks for these things and if it is inside an interrupt handler when any of these things occur (blocking operations, memory allocations) it will simply panic.
The reason memory allocations are not allowed is a bit more subtle: if an interrupt happens while the GC is running, it will mess with the internal state of the heap. (I've looked for possible ways to fix this but couldn't find anything that was acceptable for TinyGo).
In general, it is good advice to avoid
I'd rather word this as something like "never use these things".
fmt.Printf
That falls under the general category of "too big for an interrupt". LEDs are a way to indicate things, and on some chips println will also work - but not on all (it will usually work when using UART, but USB-CDC is generally too complex to use inside an interrupt handler).
There was a problem hiding this comment.
Agreed, I ALWAYS avoid interrupts. Inconditionally. Unless you are writing real-time critical code down to the nanosecond, interrupts are a needless source of breakage.
There was a problem hiding this comment.
(Now realizing this has been merged by no one other than yours truly 🤦)
There was a problem hiding this comment.
Interrupts can also be useful to avoid polling and conserve battery life :)
But yeah, most users should not use interrupts. Instead, all that functionality should be hidden inside packages like the machine package.
3 participants
During the discussion of: tinygo-org/tinygo#3981 I brought up that there is some room for improving the interrupt documentation. This is my take on this.