# A Simple Scheduler via an Interrupt-driven Actor Model | Interrupt **URL:** \ **Category:** Blog\ **Created:** [September 14, 2023, 12:23am UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723 "2023-09-14T00:23:00Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![discobot](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/discobot/32/1_2.png) [@discobot](https://community.memfault.com/u/discobot)\ **Post date:** [September 14, 2023, 12:23am UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/1 "2023-09-14T00:23:01Z")
Using an RTOS is often a tradeoff between the ease of decomposing tasks, with the complexity of the scheduler itself. There exists a middle ground between highly complex systems that may require an RTOS, and simpler ones that can be easily modeled using a super loop.Since ARM is the most popular embedded CPU and almost every ARM processor has a hardware scheduler, it would be interesting to make a compact framework utilizing these features. The most popular approach to RTOS-less event-driven systems is super-loop consuming events produced by interrupts. This article discusses an alternative, more efficient approach in some circumstances. It has less overhead than an RTOS and also benefits event-driven systems. * * * This is a companion discussion topic for the original entry at [https://interrupt.memfault.com/blog/hardware-actor-scheduler](https://interrupt.memfault.com/blog/hardware-actor-scheduler) ---
**Author:** ![bora](https://avatars.discourse-cdn.com/v4/letter/b/e56c9b/32.png) [@bora](https://community.memfault.com/u/bora)\ **Post date:** [September 20, 2023, 9:23am UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/2 "2023-09-20T09:23:10Z")
Although the content is very interesting, I think the article is written poorly. The author jumps from theory to implementation details back and forth without a proper structure. In the end, we are left with some ideas but no practical conclusions. It feels like this should have been an academic paper draft instead of an Interrupt blog post. Is there a library implementing this concept? One project I know which uses hardware scheduling is the [RTIC framework](https://rtic.rs/2/book/en/) written in Rust, but I’m not sure if it is the same thing. ---
**Author:** ![discobot](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/discobot/32/1_2.png) [@discobot](https://community.memfault.com/u/discobot)\ **Post date:** [September 20, 2023, 9:23am UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/3 "2023-09-20T09:23:11Z")
---
**Author:** ![ramanf](https://avatars.discourse-cdn.com/v4/letter/r/b9bd4f/32.png) [@ramanf](https://community.memfault.com/u/ramanf)\ **Post date:** [September 25, 2023, 1:18pm UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/4 "2023-09-25T13:18:05Z")
Thanks for your reply! I have implemented the described concept in [C](https://github.com/romanf-dev/magnesium) and in [C++20](https://github.com/romanf-dev/magnesium-cpp) (with async/await) in my github. These still at alpha-stage due to lack of time, and they also lack some useful things like timers but I hope sometime I will implement it. However, my intent in the article was to show that this type of framework may be written for the specific task within 2-3 hours, with desired code style and other functionality. Also, the example in the article is the same cross-platform header as in my project with some renames. ---
**Author:** ![miro](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/miro/32/138_2.png) [@miro](https://community.memfault.com/u/miro)\ **Post date:** [March 19, 2024, 5:39pm UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/5 "2024-03-19T17:39:51Z")
This is a very nice idea and I’m glad that more engineers have discovered this way of utilizing the standard NVIC in the Cortex-M CPU. If anybody has trouble understanding this particular “Simple Scheduler” explanation, I have presented a similar subject at the [Embedded Online Conference (April 2023)](https://embeddedonlineconference.com/session/Super_Simple_Tasker_Hardware_RTOS_for_ARM_Cortex_M). The videos from that presentation entitled “Super-Simple Tasker - Hardware RTOS for ARM Cortex-M” are freely available on YouTube: - [Super-Simple Tasker Part-1](https://youtu.be/PTcauYl994A?si=ZHSzcVV4mQBKDT6s) - [Super-Simple Tasker Part-2](https://youtu.be/kEJ6QHerSro?si=gEcglc4Z5xNyFWHp) The presented SST kernel with examples is available from GitHub under a permissive open source license: - [Super-Simple Tasker (SST) GitHub repo](https://github.com/QuantumLeaps/Super-Simple-Tasker) ---
**Author:** ![tester](https://avatars.discourse-cdn.com/v4/letter/t/e274bd/32.png) [@tester](https://community.memfault.com/u/tester)\ **Post date:** [October 9, 2024, 12:00pm UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/6 "2024-10-09T12:00:11Z")
This is awful. Simply use cooperative scheduler and FSM until it’s not enough. Polling is always more deterministic than events. Which is more important quality of the product or sqeezing every last joule out? ---
**Author:** ![ramanf](https://avatars.discourse-cdn.com/v4/letter/r/b9bd4f/32.png) [@ramanf](https://community.memfault.com/u/ramanf)\ **Post date:** [December 20, 2024, 12:16pm UTC](https://community.memfault.com/t/a-simple-scheduler-via-an-interrupt-driven-actor-model-interrupt/723/7 "2024-12-20T12:16:59Z")
@tester Something went wrong with notifications and I didn’t see your comment. Preemptive multitasking isn’t about joules it is about scalability, latency and response time. If your application requires a response ASAP then loops aren’t an option. Another point is that some applications just cannot be implemented using loops. If loops work for someone - ok, I didn’t argue that loops and cooperative scheduling are bad. My point here is that if loops aren’t enough then there is another (simpler) option than full-fledged RTOS. That’s it.