Even in embedded land, there is code that manages IO devices. And, in much/most embedded systems, there is some separation of concerns, if only because such sy

Even in embedded land, there is code that manages IO devices. And, in much/most embedded systems, there is some separation of concerns, if only because such systems do multiple things. Data comes in. Via some combination of device configuration and device handling code, it gets put somewhere. Meanwhile, there's some other code that will process said data, but the system is doing lots of other things. There are two ways to know when to run said "other code". The code that handled the hardware can start said other code or something else in the system can ask "is there new data" periodically. One implementation of "can start" is waking up a thread. Note that the "interrupt vs polling" decision for the "handle hardware" code does not dictate which way is used to know when to run said other code.