Michael T. RichterSep 26

Most of the #embedded systems I've worked with over the last few years have been based on an #RTOS, #COROS, of my own design that I started working on ages ago, persuaded my boss to use, and then kind of lapsed on making my personal version public.

This week I started a huge push on releasing my personal version of COROS out to the public and it is ready for release, minus a few issues (like documentation being an aspirational WIP).

https://gitee.com/ACleverDisguise/coros

🧵 (1/n)

ACleverDisguise/COROS: COROS is a CORoutine-based real-time OS kernel written in C and suited to a wide variety of embedded software systems where the complexity and non-determinism of pre-emptive scheduling is not desired.

ACleverDisguise/COROS: COROS is a CORoutine-based real-time OS kernel written in C and suited to a wide variety of embedded software systems where the complexity and non-determinism of pre-emptive scheduling is not desired.

Gitee
Show threadMichael T. Richter

So what does #COROS bring to the table that any other #RTOS among millions doesn't?

For starters it's based on #coroutines for concurrency, not pre-emptive threads. Coroutines fit better for small- to mid-sized MCU projects, in my experience, than do pre-emptive kernels. They're smaller, faster, time-deterministic, and as such far easier to reason about.

COROS lets you use coroutines raw, but that is not the overall system's approach.

🧵 (2/n)

Sep 26 at 5:29amWeb
Show threadMichael T. RichterSep 26

The second piece of the puzzle in the #COROS design is a segmented #EventQueue that applies a disciplined wrapper around the usual "one massive for loop testing and calling" that is the hallmark of #RealTime designs that don't use pre-emptive kernels. Event queues are chained and grouped in ways that allow any downstream queue to service events from any upstream queue, but not vice versa. Event handlers can be callback functions or #coroutines, depending on needs and complexity.

🧵 (3/n)

Show threadMichael T. RichterSep 26

The third piece of the #COROS puzzle is a #component system that assists in doing, in effect, Kay-style OOP: independent software entitites that communicate by messages.

A component consists of a coroutine-based message pump, an event queue that can be transparently plugged into the system queue, and a set of primitive operations. The component can then expose an API with simple functions, setter/getter functions, or full-blown message-based functions at need behind the scenes.

🧵 (4/n)

Show threadMichael T. RichterSep 26

And that covers the basics of #COROS and already, in my opinion, provides a better platform than most #RTOS implementations for small to mid-sized systems.

Then there's the advanced stuff. Note that events can pass *any* data type. And that an #EventQueue is a first-class data type. This means you can pass event queues around, π-calculus style, making it possible to provide subscribe/publish-style component connections, proxies, and other such systems with relative ease.

🧵 (5/n)

Show threadMichael T. RichterSep 26

Currently #COROS has only its kernel released. **Some** documentation is also released, but that is an aspirational work in progress. That being said, the three header files contain detailed reference documentation.

There is a test suite supplied that runs in the IAR EWARM simulator, as well as on two pieces of hardware from Artery. There's also a Makefile for arm-non-eabi GCC on Linux or MinGW that will build the COROS library, as well as a Makefile for the two hardware projects.

🧵 (6/n)

Show threadMichael T. RichterSep 26

I plan to write new chunks of documentation as frequently as I can until I have documentation that satisfies me. By the end of October I think the documentation will be complete, and it will be usable for experienced developers long before that.

It was a bit quirky to begin the hardware support with Artery's AT32 MCUs, but that's the boards I had within reach when I started this push. I will be adding more boards for more popular MCUs (like the STM32 line) over my upcoming holiday.

🧵 (7/n)

Show threadMichael T. RichterSep 26

Finally I will also be starting to port the "standard component library" from my professional version (which uses a different API) to this personal version both to illustrate how to wrap peripherals and subsystems in components, and to provide a useful set of same. You can expect to see a USART component, an SPI component, etc. as well as, probably, an LFS wrapper component and the like.

I hope you have some fun with this.

🧵 (8/8)