44 karma · joined December 14, 2015
And it of course depends what one means by "a OS." But, generally, if you are running multiple tasks that might depend on shared resources, you might want an OS---after all, an OS is just something that mediates shared resources among different applications.
You might prefer to use a microcontroller because of power constraints, security (generally easier to mitigate physical attacks and side channels in simpler hardware), or cost and you don't need more resources.
I don't know of a public announcement. Tock's license is acknowledged in Chromebook's licenses and those involved in Tock know simply because that team talks to us (a few of us interned on that team back when we were PhD students to help the effort at various stages as well).
It's not a secret, but it's also not something that seems to be high on anyone's todo list over there to announce.
Virtually anything with a radio these days (the MSPs were holdouts but mostly those are Cortex-M these days as well)
Oxide was involved with Tock before building Hubris. They are similar in some ways with somewhat different "visions" for the end use case. Hubris compiles all "applications" into the "kernel", and relies exclusively on the type system for isolation---in this sense it is a much more traditional RTOS, just written in Rust (and well designed!). Whereas Tock targets applications that are not just in Rust, and may be dynamically load/replaced/removed separately from the kernel---in this sense it is much more similar to a traditional desktop/server OS but designed for significantly lower resourced settings. This also makes Tock more robust to applications that are actually untrusted or unreliable.
There is also of course a difference in development and evolution. Hubris is developed by Oxide and released open source, while Tock is more community based and, thus, more open to supporting a variety of use cases. This is both bad and good. If your use case is exactly Oxide's use case, it's likely Hubris is better than Tock (there is just no design decision baggage for other use cases). If you're use case is a bit different, Tock starts to be more appropriate.
A side note that I think the Hubris-Tock relationship is a real positive case for open source development. Oxide was very transparent and forthcoming when they decided to switch away and offered a lot of useful feedback. I hope they took some ideas from Tock and I think we took some ideas from following Hubris.
The cannonical thing is an environment sensor (so a temperature et al sensor). Unfortunately, often a larger HVAC system will integrate with sensors through some proprietary protocol (even Thread based systems like Nest don't necessarily work with just any thread-based sensor, but you could of course hack something with Home assistant).
One of the maintainers has been using it on the side for a plan monitoring system.
All of these require some sensors beyond just the dev kit, which are typically pretty bare bones.
You can build a two factor auth device with the nrf52840 dongle (OpenSK is built with Tock), which requires basically no extra peripherals.
I've used the nrf52840dk to control a garage door, which similarly only need a couple wires.
For some context, Tock has been around for a number of years now (we first built it in 2015). Beyond it's intended original purpose (naval gazing academic research) it runs the Chromebook embedded controller, has similar other similar applicatioms in data center root-of-trust, Microsoft's Pluton (rumor has it, for some future version anyway), and others.