|
| 1 | +--- |
| 2 | +title: "Interrupts" |
| 3 | +weight: 2 |
| 4 | +--- |
| 5 | + |
| 6 | +Interrupts are crucial if you want to do anything high-performance on microcontrollers. Unfortunately, the only close substitute in the Go language ([`os/signal.Notify`](https://godoc.org/os/signal#Notify)) is rather heavyweight. Therefore TinyGo uses a simpler way to work with interrupts. |
| 7 | + |
| 8 | +Note: in most cases, you shouldn't need to work directly with interrupts. The machine package tries to abstract it away to provide a simple interface to work with. However, this page is here if you want to work on the machine package or need to override an interrupt. |
| 9 | + |
| 10 | +## Basics |
| 11 | + |
| 12 | +Interrupts are a bit like threads, but without any real concurrency. You could see them as a kind of callbacks at the hardware level. |
| 13 | + |
| 14 | +Perhaps the most simple example of an interrupt is the UART (serial) interrupt on receiving a byte. Almost every microcontroller supports this. To use it, you generally will need to take the following steps: |
| 15 | + |
| 16 | + 1. You need to define an interrupt handler. This is a function like any other, but is somehow marked specially to function as an interrupt handler. It depends on the compiler and programming language how this is done exactly. |
| 17 | + 2. You need to configure the UART to enable receive interrupts. This is a setting in the UART peripheral itself, not in the interrupt handler. |
| 18 | + 3. Depending on the chip, you need to set a priority for the interrupt. Not all microcontrollers support interrupt priorities, but many (especially more advanced) do. You set this not in the peripheral but in a centralized interrupt controller. |
| 19 | + 4. Finally, you need to enable the interrupt. Some very simple chips (like the AVR) do not support this: you are expected to control the interrupt by enabling/disabling interrupt sources as in step 2. |
| 20 | + |
| 21 | +TinyGo abstracts most of the complications away, but it's good to be aware of what is going on behind the scenes. |
| 22 | + |
| 23 | +## Example |
| 24 | + |
| 25 | +The following is an example of how interrupts work: |
| 26 | + |
| 27 | +```go |
| 28 | +func (uart UART) Configure(config UARTConfig) { |
| 29 | + // [...] other configuration |
| 30 | + |
| 31 | + // Enable the receive interrupt (step 2). |
| 32 | + // What the below line does is that it enables exactly one interrupt source |
| 33 | + // in the UART: the RXDRDY (RX ready) source. Enabling this makes sure the |
| 34 | + // interrupt is triggered whenever a byte is received in the UART. |
| 35 | + nrf.UART0.INTENSET.Set(nrf.UART_INTENSET_RXDRDY_Msk) |
| 36 | + |
| 37 | + // Register a new interrupt handler (step 1). This is the TinyGo way of |
| 38 | + // saying to the compiler that the UART0.handleInterrupt function is |
| 39 | + // special and should be called whenever the UART0 interrupt is triggered. |
| 40 | + intr := interrupt.New(nrf.IRQ_UART0, UART0.handleInterrupt) |
| 41 | + |
| 42 | + // Now we have a handle to the interrupt. The default on this chip is the |
| 43 | + // highest possible priority. We'd like to set the UART to a lower |
| 44 | + // priority, which we do here. The magic constant here will in a future |
| 45 | + // version be replaced with a regular constant for a low-priority |
| 46 | + // interrupt. |
| 47 | + intr.SetPriority(0xc0) |
| 48 | + |
| 49 | + // Finally, the interrupt must be enabled. Without this, the interrupt will |
| 50 | + // still be triggered but the handler will never be called. |
| 51 | + intr.Enable() |
| 52 | +} |
| 53 | + |
| 54 | +// This is the function that will be called. As a convenience, the interrupt |
| 55 | +// handle is also provided as a parameter but you can usually ignore it. |
| 56 | +func (uart *UART) handleInterrupt(intr interrupt.Interrupt) { |
| 57 | + // Multiple interrupt sources are often mapped to a single interrupt |
| 58 | + // handler. Therefore, we need to differentiate between various events. |
| 59 | + // In this case, only one interrupt source has been configured so |
| 60 | + // technically we could avoid this check, but it's good practice (for |
| 61 | + // future changes) to check for the event anyway. |
| 62 | + if nrf.UART0.EVENTS_RXDRDY.Get() != 0 { |
| 63 | + // This particular chip won't retrigger the interrupt when this event |
| 64 | + // is not cleared, but it won't clear the event either. So if we want |
| 65 | + // to differentiate between events in the next interrupt (when this |
| 66 | + // interrupt was triggered by a hypothetical other interrupt source) we |
| 67 | + // need to manually clear it first. |
| 68 | + nrf.UART0.EVENTS_RXDRDY.Set(0x0) |
| 69 | + |
| 70 | + // And finally, we can receive the byte from the UART. This is done by |
| 71 | + // reading the RXD register, which also has the side effect of |
| 72 | + // informing the hardware that this byte has been read. |
| 73 | + b := byte(nrf.UART0.RXD.Get()) |
| 74 | + |
| 75 | + // Now do whatever you'd like with the just received byte. |
| 76 | + uart.Receive(b) |
| 77 | + } |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | + |
| 82 | +## Troubleshooting |
| 83 | + |
| 84 | +### The interrupt won't fire |
| 85 | + |
| 86 | + * Check that you have enabled the interrupt source in the peripheral (step 2). |
| 87 | + * Check that you have enabled the interrupt with the `intr.Enable()` call (step 4). |
| 88 | + * Check that you are listening for the correct interrupt and not for an interrupt for a different peripheral, for example (step 1). |
| 89 | + |
| 90 | +### The interrupt keeps firing |
| 91 | + |
| 92 | +Depending on the chip family, you may need to clear an interrupt source. This is for example the case in the Microchip SAM family of microcontrollers. If you don't do this, the interrupt will fire continuously thinking it still needs to be handled even though you have long since handled the interrupt. |
| 93 | + |
| 94 | +### I get a compile error |
| 95 | + |
| 96 | +You may get a compile error like the following: |
| 97 | + |
| 98 | +```text |
| 99 | +src/machine/machine_nrf.go:91:23: closures are not supported in interrupt.New |
| 100 | +``` |
| 101 | + |
| 102 | +This could mean several things: |
| 103 | + |
| 104 | + * If you're passing an inline function closure to `interrupt.New`, you are not allowed to use variables from the outer scope. However, global variables are fine. |
| 105 | + * If you're passing a bound method, make sure the method has a function receiver. That is, define the interrupt handler like so: |
| 106 | + |
| 107 | + ```go |
| 108 | + func (uart *UART) handleInterrupt(intr interrupt.Interrupt) { ... } |
| 109 | + ``` |
| 110 | + |
| 111 | + instead of like so: |
| 112 | + |
| 113 | + ```go |
| 114 | + // this won't compile |
| 115 | + func (uart UART) handleInterrupt(intr interrupt.Interrupt) { ... } |
| 116 | + ``` |
| 117 | + |
| 118 | + The reason is that the latter will actually make a copy of the UART variable to be stored with the interrupt, which is currently not supported in the compiler and will lead to reduced performance even when it becomes supported. |
| 119 | + |
| 120 | + Additionally, make sure the variable you're binding to is a global variable instead of a local variable. |
0 commit comments