After more than 2 years of development, we are pleased to announce Drone, an
Embedded Operating System for writing real-time applications in Rust. Drone is a
free software, dual licensed under MIT and Apache 2.0. This is the first public
release, following many iterations of experimentation. Drone's key highlights:
Supports ARM Cortex-M3/-M4. Also for STM32F1, STM32L4, and STM32L4+ there are
generated register and interrupt bindings from vendor-provided SVD files.
Native async/await syntax is enabled and is a preferred way for
concurrency.
Integrated dynamic memory allocator enables use of String, Vec, Box, Rc, Arc, and more. Still perfectly suitable for low-cost MCUs with 20 KB
of RAM.
Rich tooling: generate a new project with drone new, configure the memory
layout in Drone.toml, drone-ld saves you from manually writing linker
scripts.
print!, eprint! and similar macros are mapped to Cortex-M's ITM channels 0
and 1 out of the box.
If using Black Magic Probe, drone bmp itm
captures the ITM output and displays it in the console. Also there are drone bmp flash and drone bmp gdb commands.
To me they are very different. Tock OS runs separate compiled applications in any language. While Drone OS is a library OS, and it is linked statically with the application.
As an outsider, with a limited understanding of both Tock OS, and Drone I'd like to try and expand on this:
Tock OS has both hardware based memory protection layer, and a language based memory protection (Rust), while Drone is providing realtime guarantees about scheduling.
While the Tock kernel can interrupt a user space process, it supports running arbitrary safe rust code inside the kernel without violating the kernel's memory guarantees. I don't see any indication that Tock can enforce a realtime schedule upon untrusted in-kernel code. Which would require the kernel to be able to interrupt itself etc.
Tock is really pushing the boundaries of what has been done in it's niche. But Drone seems to target a very different one as you say.
Thanks for the addition. Also I think Drone has more similarities with RTFM framework than with Tock OS. I checked RTFM long ago, so I can miss something, but here are some differences:
Drone spawns tasks dynamically, while RTFM needs to statically predefine them. This results in dramatically different API and dataflow.
RTFM uses critical sections as a main synchronization approach, while Drone uses atomics. Drone never disable the interrupts, so the processor is always ready to handle a prioritized event.
This looks great! Very interesting. I really love the async focus as a first-class scheduling structure.
I've read through the book, but not yet looked over the rest of the repo at additional examples or other material; sorry if this is already answered clearly there.
I've played a bit with (and rather like) RTFM. Another possible point of comparison is the handling and allocation of peripherals. As you note, RTFM has static task definitions (and gets a lot of compiler checking work out of that, including of peripherals access). From what I gather of drone, all peripherals are handed to the root task, and need to be passed as owned values to the various tasks on (potentially repeated?) invocation. Could you elaborate a little more (here, and/or eventually in the book) on the management of peripherals and ownership? Some more examples and discussion of patterns for taking and passing hardware resources around would be a great next step for documentation!
As you note, RTFM has static task definitions (and gets a lot of compiler checking work out of that, including of peripherals access).
Drone also does compile-time checks. But unlike RTFM, it does them in a way similar to libstd. That is, Drone relies on Send, Sync, and 'static trait bounds.
From what I gather of drone, all peripherals are handed to the root task, and need to be passed as owned values to the various tasks on (potentially repeated?) invocation.
Initially all peripherals are handed to the root task. Then in the root task they may be passed to other tasks. However not on invocation, but on task spawning. In a similar way as you move values into a Thread::spawn closure in the std context.
Could you elaborate a little more (here, and/or eventually in the book) on the management of peripherals and ownership? Some more examples and discussion of patterns for taking and passing hardware resources around would be a great next step for documentation!
Sure, the current documentation has only a bare minimum to get started. I will be extending it gradually.
I can add that if you share a peripheral across threads, you can do only atomic operations on the registers. You can convert to unsynchronized register access, but then you can't share the peripheral across threads. Also peripherals are represented as zero-sized token types with move semantics by default. So if you own the token, you can be sure that no other threads can access the peripheral (at least without unsafe).