Thank you. Blocking IPC is a very interesting approach but you have to carefully plan ahead, even before writing the first lines of code. I think the above art

Thank you. Blocking IPC is a very interesting approach but you have to carefully plan ahead, even before writing the first lines of code. I think the above article missed the "notifications" part. Without notifications, a blocking IPC wouldn't have sense in an RTOS: a task would not be able to process an interrupt because it's blocked while "sending". I guess the existence of notifications is there to provide methods for an UART driver/task that blocks waiting for interrupts. When the interrupt arrives, the driver deals with it and instead of sending the data directly to a listener, it just "notifies" incoming data to another task (pretty much the "usual" way of doing things). This makes "UART" to sit on its own task, setting the right priority for it, implement a circular buffer, etc. Complexity quickly escalates for a (for example) "sensor fusion" driver, which has to manage 3 other drivers (accelerometer, gyro and magnetometer drivers), each one on top of another drivers (SPI, I2C, etc.). But I guess that's a price to pay. > Users can't disable interrupts, they can only mask or unmask receiving notifications for said interrupts. Sorry. I interpreted that drivers were also tasks (or they live in tasks?), so being able to interface the hardware I guess setting PRIMASK=1 could be an option too. Perhaps battery-powered systems is not your application target, but I would be interested to see how __wfi() works within the Hubris context.