Before we jump into coding a peripheral driver that utilizes interrupts, let's take a quick look at how interrupts compare to FreeRTOS tasks.

There are many similarities between tasks and ISRs:

• Both provide a way of achieving parallel code execution.
• Both only run when required.
• Both can be written with C/C++ (ISRs generally no longer need to be written in assembly code).

But there are also many differences between tasks and ISRs:

• ISRs are brought into context by hardware; tasks gain context by the RTOS kernel: Tasks are always brought into context by the FreeRTOS kernel. Interrupts, on the other hand, are generated by hardware in the MCU. There are usually a few different ways of configuring the generation (and masking) of interrupts.
• ISRs must exit as quickly as possible; tasks are more forgiving: FreeRTOS tasks are often set up to run in a similar way to an infinite while loop—they will be synchronized with the system using primitives (such as queues and semaphores) and switched into context according to their priority. At the complete opposite end of the spectrum are ISRs, which should generally be coded so that they exit quickly. This quick exit ensures that the system can respond to other ISRs, which keeps everything responsive and ensures no interrupts are missed because a single routine was hogging the CPU.
• ISR functions do not take input parameters; tasks can: Unlike tasks, ISRs can never have input parameters. Since an interrupt is triggered because of a hardware state, the most important job of the ISR is to read the hardware state (through memory-mapped registers) and take the appropriate action(s). For example, an interrupt can be generated when a UART receives a byte of data. In this case, the ISR would read a status register, read (and store) the byte received in a static variable, and clear the interrupt.

• ISRs may only access a limited ISR-specific subset of the FreeRTOS API: FreeRTOS is written in a way that provides flexibility while balancing convenience, safety, and performance. Accessing data structures such as queues from a task is extremely flexible (for example, tasks making API calls to a queue can easily block for any period of time). There is an additional set of functions that are available to ISRs for operating on queues, but these functions have a limited subset of functionality (such as not being able to block—the call always immediately returns). This provides a level of safety since the programmer can't shoot themself in the foot by calling a function that blocks from inside an ISR. Calling a non-ISR API function from inside an ISR will cause FreeRTOS to trigger configASSERT.
• ISRs may operate completely independently of all RTOS code: There are many cases where an ISR operates on such a low level that it doesn't need access to any of the FreeRTOS API at all. In this case, the ISR simply executes as it normally would without an RTOS present. The kernel never gets involved (and no tasks will interrupt execution).  This makes it very convenient for creating flexible solutions that blend high-performing ISRs (operating completely underneath the RTOS) with extremely convenient tasks.
• All ISRs share the same system stack; each task has a dedicated stack: Each task receives a private stack, but all of the ISRs share the same system stack. This is noteworthy only because, when writing ISRs, you'll need to ensure you reserve enough stack space to allow them to run (possibly simultaneously) if they are nested.

Now that we've covered the differences between tasks and ISRs, let's take a look at how they can be used together to create very powerful event-driven code.