Colibri Zephyr

Colibri is intended to be used by systems integrators, makers, automation engineers, home automation enthusiasts and in general people how doesn't necessarily know how to write low-level programs or operate soldering iron. That means that "flashing an image" to the MCU is beyond what is expected by the potential customers.

Instead, we need an "operating system", where we can deploy user applications without low-level programming skills. With that comes two challenges;

1. How are those applications written?

2. How are they going to be executed on the Colibri MCUs?

TL;DR

• A user application will deployed in a so called Web Assembly runtime. The number and size of user applications are dependent on available RAM in the MCU.
• Each I/O module will contain its own Web Assembly driver that user applications will be able to interface with.
• I/O driver is (initially?) limited to 16kB in size and will run inside its own Web Assembly runtime and given time slots to execute, via a tick(slot_number) function call at a (per I/O slot) settable interval. I/O modules may also emit events that applications can subscribe to. The exact API is documented for each Colibri I/O module.

It could happen that domain-specific languages are to be developed for this environment. Or perhaps, we will managed to get OpenPLC running on Web Assembly. It is a little bit too early to tell in which direction this will be going.

What is Zephyr?

From Zephyr's website;

   The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained
   and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated 
   embedded controllers, smart watches, and IoT wireless applications.

Please read the entire introduction page.

Additionally to task scheduling, we also get cross-platform APIs for SPI and I2C peripherals, as well as access to many Zephyr libraries, such as Modbus/RTU, TCP/IP, MQTT and much more.