
Explore interrupt driven embedded applications by examining how microcontrollers and their interrupt controllers work, and learn to set up interrupt handling across platforms with practical examples.
Explore the interrupt driven approach to handling input and output in embedded applications. Learn how interrupts work and glimpse the hardware and software engineering behind this technique.
Compare input output handling methods, define input output handling, and explore options with analog and digital input-output ports, peripherals like GPIO, ADC, serial ports, and networks, using practical analogies.
Learn how polling uses a program loop to continuously read an input device without extra hardware. Applications include a garage door radio receiver, a microwave keypad, and a stopwatch.
Explore interrupts as a computer architecture technique, learn how hardware supports microcontrollers, and examine mouse, keyboard, real time clock, and TV remote examples for efficient event handling.
You'll see how Interrupts resemble baking a cake.
We set modeling assumptions to compare approaches in interrupt driven embedded applications. We specify timing: five-minute calls, one-minute overhead, a 10-minute trip, and unknowns at 57 and 65 minutes.
Use polling to handle events in interrupt-driven embedded applications, and examine how repeated checks create excessive overhead; only some checks prove worthwhile, guiding option comparisons.
The lecture explains solving a problem with interrupts, using a courier who texts when the package is delivered to show how this method reduces overhead and avoids wasted visits.
Watch out for abuse polling, an inefficient polling method that repeatedly checks an input device, wasting significant time and reducing productivity compared to interrupt-driven embedded applications.
Compare polling, interrupt-driven, and abuse balding approaches in task timing and efficiency; the interrupt-driven method delivers the best overall efficiency at 87%.
Examine the best-case time efficiency of polling versus the interrupt-driven approach, using steady-state behavior and the formula working time over the main loop period, with examples around 75–80 percent.
Explore how the hotel analogy maps to code execution. It links the main thread, reading the register as front desk, and input‑output requests to interrupt service routines and signals.
You'll see how Interrupts resemble the way we (should) handle incoming cellphone calls.
Examine timing data to show how polling affects embedded performance, revealing a 1.2-second main loop and a 0.2-second display refresh.
Explore interrupt driven version, where interrupt routines trigger when devices need attention, keeping the main loop at 200 ms per iteration and refreshing the display at five times per second.
Explore the hardware elements that enable interrupt handling—the global, the mask, the vectors, the service routines, and the stack. These pieces will be united in the next sequence.
Explore the global interrupt mask, a one-bit register that enables or disables most interrupts, note that some non-maskable interrupts remain unmasked, and learn architecture-specific enable/disable instructions and macros.
Examine local interrupt enable bits for each source, such as port B, via memory-mapped registers; they are enabled bits with opposite logic to masks—zero disables, one enables.
Identify local interrupt flags, the bits that initiate and signal pending interrupts. Clear them via platform-dependent procedures after servicing the interrupt; a logical one signals pending.
Understand interrupt service routines, or interrupt handlers, which have no parameters or return values, and how they briefly increment a counter and clear the interrupt mask.
This lecture contrasts polling and interrupt driven embedded applications that read touch screen data, fuel level, velocity, and temperature, update the door enabled cabin light, and refresh the display.
Examine how a touch screen interrupt service routine and a refresh routine share variables via a critical section, updating a frame buffer and the display within a ~300 ms cycle.
A runtime example shows a touch screen interrupt preempting the main loop; the CPU pushes to the stack, executes the interrupt service routine from the vector, and returns.
The running instruction either completes or is aborted, depending on the microcontroller, and the return address is calculated to resume the aborted instruction or the next one after an interrupt.
Push the processor state onto the stack, including general purpose and flag registers and the calculated return address for the program counter, to support conditional branches and avoid overflow.
Explore how the interrupt service routine is retrieved from the vector table, using interrupt request identifiers to index into ISR addresses, including reset vector and non-maskable interrupts.
Execute the interrupt service routine quickly; it should do one thing, clear the flag, avoid loops, be void with no parameters, and balance the stack by pushing and popping.
Pop the CPU state from the stack on interrupt exit to restore the SPEWS state, and ensure any data pushed in the ISR is popped before exit.
Execution resumes where it left off after an interrupt service routine, unless nesting or a higher priority interrupt preempts it; the step may wait or repeat depending on implementation-specific restrictions.
Explore the benefits of using interrupts and how they make applications more responsive, efficient, scalable, portable, and energy efficient, and show how interrupts outperform by far.
This analogy on the logistics of a grocery store makes it obvious when to use blocking functions and when not to.
See a live demo on interrupt-driven vs polling embedded apps using Arduino, showing attach interrupt, an interrupt service routine, and how a switch and pullup affect responsiveness.
View a live demo of the GD32V microcontroller on a Seed Studio board, showcasing USB programming, non-volatile memory, push buttons, three LEDs, and an optional high-resolution touch screen.
Explore an interrupt-driven embedded setup with two parallel processes: a top levee blinking at 0.5 Hz and a bottom levee controlled by a key, and demonstrate polling with blocking delays.
Demonstrates a blocking polling approach that uses a button on port 0 to toggle an LCD and blink another LCD with delay-based timing, highlighting poor responsiveness at different frequencies.
Examine why a polling-based embedded app becomes unresponsive as blink rates drop, showing how the bottom display lags until the top changes state; highlights the need for interrupt-driven design.
Configure timer one with timer and channel data structures, setting channel zero to generate an interrupt every millisecond on an eight megahertz core clock with a fifty percent duty cycle.
Handle timer one interrupts with a void interrupt service routine, check channel zero flag, increment a millisecond counter, toggle the LED every 1000 ms, then clear the flag and exit.
In this third part of the Beyond Arduino series, you'll learn why single-threaded applications are inefficient and perform so bad when handling input/output requests.
You'll learn about the Interrupt-Driven approach to handling asynchronous events and most of its advantages over the traditional approach to do everything inside a loop, which you aren't always aware of because of the immense body of elements that conceal the details in many beginner platforms, like the Arduino, for the sake of simplicity.
You'll learn theoretical, proven facts about the advantages of Interrupts, and you'll also get to try it with your own microcontroller platform on several optional projects that are presented to you as challenges. So this is not exactly a hands-on course, not if you don't want it to be. There are no promises on the projects you’ll make because we won’t force you to build something you didn’t choose to. However, we strongly recommend that you code along. Several microcontroller development platforms are showcased, but you should follow the examples with your own microcontroller.
After grasping this knowledge, we expect you to think differently when designing your embedded applications in the future. By adding this technique to your bag of tricks, you'll get one step closer to making embedded applications like a professional, and hopefully you'll feel less like a beginner.