Small firmware can organize work around a superloop: initialize the hardware once, then repeatedly execute a main loop.

initialize
while true:
    process pending events
    advance application state
    perform bounded periodic work

If each iteration completes quickly, several activities can share one processor cooperatively without a preemptive scheduler.

Long blocking delays are dangerous in this structure because no other loop work can proceed while the processor waits. Hardware timers, interrupts and nonblocking state machines let firmware start an operation and continue other work until a later event reports progress or completion.

An event-driven design records what happened—such as button_pressed or sample_ready—and lets ordinary code decide what the application state should do next.

A superloop is simple because there is only one ordinary execution context, but responsiveness depends on keeping each piece of foreground work bounded and returning to the loop promptly.