Stm32World Wiki - User contributions [en]

Streamline Zephyr

2026-05-02T02:54:23Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]][[Category:Zephyr]][[Category:Work in progress]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

We also need to redirect the <code>st-flash</code> to use the STM32CubeIDE TCL scripts, to support the newer STM32 families, like STM32H5 and STM32C5. So

== Flashing ==
It is really difficult to get flashing to work reliably with new STM32 families, so I suggest the following;

# Download the [https://www.st.com/en/development-tools/stm32cubeprog.html STM32CubeProgrammer].
# Install it "somewhere", let's say ${HOME}/st
# Add a symlink of ${HOME}/st/STM32CubeProgrammer-2.22.0/bin/STM32_Programmer_CLI to a location which is on the PATH, such as ${HOME}/.local/bin

When flashing with <code>west</code> simply do

west flash --runner stm32cubeprogrammer

== Demo 1 ==

west build --pristine always --board streamline_mcu_stm32f407 ../zephyr/samples/basic/blinky
west flash --runner stm32cubeprogrammer

And any of the following boards can be substituted;

streamline_mcu_stm32f407
streamline_mcu_stm32h562
streamline_mcu_stm32c551
streamline_mcu_stm32l475

Streamline Zephyr

2026-05-01T09:26:21Z

Niclas: /* Installation */

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]][[Category:Zephyr]][[Category:Work in progress]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

We also need to redirect the <code>st-flash</code> to use the STM32CubeIDE TCL scripts, to support the newer STM32 families, like STM32H5 and STM32C5. So

cd streamline-demos/demo1
echo "set ST_SCRIPTS ${HOME}/st/stm32cubeide_2.1.1/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.300.202602021527/resources/openocd/st_scripts" >openocd_paths.cfg # or wherever your stm32cubeide directory is.

Unfortunately, I have not gotten the <code>west</code> build system to do the right thing with that.

== Demo 1 ==

west build --pristine always --board streamline_mcu_stm32f407 ../zephyr/samples/basic/blinky
st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

And any of the following boards can be substituted;

streamline_mcu_stm32f407
streamline_mcu_stm32h562
streamline_mcu_stm32c551
streamline_mcu_stm32l475

Streamline Zephyr

2026-05-01T05:42:57Z

Niclas: /* Demo 1 */

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]][[Category:Zephyr]][[Category:Work in progress]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Demo 1 ==
cd streamline-demos/demo1
west build --pristine always --board streamline_mcu_stm32f407 ../zephyr/samples/basic/blinky
west flash --runner openocd

And any of the following boards can be substituted;

streamline_mcu_stm32f407
streamline_mcu_stm32h562
streamline_mcu_stm32c551
streamline_mcu_stm32l475

Streamline Zephyr

2026-05-01T05:20:17Z

Niclas: /* Demo 1 */

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]][[Category:Zephyr]][[Category:Work in progress]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Demo 1 ==
cd streamline-demos/demo1
west build --pristine always --board streamline_mcu_stm32f407 ../zephyr/samples/basic/blinky
west flash --runner openocd

And any of the following boards can be substituted;

streamline_mcu_stm32f407
streamline_mcu_stm32h562
streamline_mcu_stm32c551
streamline_mcu_stm32l475 (not quite yet)

Streamline Zephyr

2026-05-01T05:18:50Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]][[Category:Zephyr]][[Category:Work in progress]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Demo 1 ==
cd streamline-demos/demo1
west build --pristine always --board streamline_mcu_stm32c551 ../zephyr/samples/basic/blinky
west flash --runner openocd

Streamline Zephyr

2026-04-30T11:57:19Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
cd demo1
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

Streamline Zephyr

2026-04-30T11:51:46Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
west init --local demo1
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

Streamline Zephyr

2026-04-30T11:49:07Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
mkdir demo1
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: demo1
">demo1/west.yml
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

Streamline Zephyr

2026-04-30T11:44:55Z

Niclas:

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline-demos
cd streamline-demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: .
">west.yml
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

Streamline Zephyr

2026-04-30T11:41:13Z

Niclas: Created page with "Category:STM32Category:StreamlineCategory:Streamline Software{{metadesc|Zephyr on Streamline boards}} = Installation = Let's see how we can easily setup a Zephyr..."

[[Category:STM32]][[Category:Streamline]][[Category:Streamline Software]]{{metadesc|Zephyr on Streamline boards}}

= Installation =
Let's see how we can easily setup a Zephyr development environment for some Streamline demos.

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl

mkdir streamline_demos
cd streamline_demos
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
echo "
# @copyright Copyright (c) 2026, CurrentMakers.com and the individuals that has contributed to this project.
#
# SPDX-License-Identifier: Apache-2.0

manifest:
projects:
- name: zephyr
revision: v4.4.0
url: https://github.com/zephyrproject-rtos/zephyr
west-commands: scripts/west-commands.yml
import:
name-allowlist:
- littlefs
- picolibc
- hal_stm32
- hal_st
- hal_nordic
- hal_rpi_pico
- cmsis_6
- name: zephyr-cm
url: https://github.com/currentmakers/zephyr-cm
revision: master
path: zephyr-cm
- name: zephyr-ws2812b-pwm
url: https://github.com/currentmakers/zephyr-ws2812b-pwm
revision: master
path: modules/lib/zephyr-ws2812b-pwm
self:
path: .
">west.yml
west init --local
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

Hardware Interconnect Buses

2026-04-29T02:40:14Z

Niclas: /* RS-485 */

[[Category:Electronics]]{{metadesc|Documenting various forms of hardware interconnect}}
'''NOTICE!''' This page is a [[Category:Work in progress]] Work in progress

There are literally hundreds - if not thousands - of different specifications for communications between different devices. Most of these are probably proprietary but this page will document the most common on an introductory level.

== Speed ==

When it comes to any kind of communication, the speed is often expressed as "bps" (bits per second) or faster rates in "kbps" (kilobits per second), "Mbps" (Meta-bits per second) or even "Gbps" (Giga-bits per second). Soon we'll probably begin to see "Tbps" but I am not sure that is available as of yet.

It is worth noticing that, since a byte is 8 bits, you can often divide the bit-rate by 8 to get the Bytes per second). Often, however, there are a few extra bits stuffed in the protocol, start, stop, parity, so this calculation really depends on the protocol.

It should also be mentioned that in the early days the term "baud" was often used ([https://en.wikipedia.org/wiki/Baud Wikipedia article on baud). Baud is defined as a symbol rate and is typically equivalent of the bit-rate. However, later generation modems could use various forms of encoding to transfer multiple bits in one symbol which is why the term is rarely seen today.

== Asynchronous ==

=== RS-232 ===
[[File:PDP-11-70.jpeg|thumb|300px|PDP-11 with a serial terminal in the center]]
RS-232 can be considered the granddad of [[Hardware Interconnect Bus]]es. It is a point-to-point bus which will connect exactly two devices with each other. RS-232 would operate at speeds from around 150 bps, through 300, 4800, 9600 and 19200 bps.

RS-232 was first introduced in 1960 and up through the 70s and even 80s it was widely used. Early computers (see image on the right) were monstrous and were often operated through multiple serial terminals. The communication between the central computer and those terminals were almost always (if not always) RS-232.

Early PC's always had at least one RS-232 port which was often used to attach a modem. Modems were common up until the late 90s and again - exclusively used RS-232.

[[File:RS-232_POTS_DTE_DCE.svg|450px]]

[[File:uart-tx-rx-cross-768x466.png|thumb|300px]]
Today, [[#RS-232|RS-232]] have all but vanished in consumer and professional equipment and is almost exclusively replaced by [[#USB|USB]]. The basic signalling are still commonly used for short distance communication.

These connections will typically operate and a voltage level depending on the actual equipment - typically either 3.3V or 5V.

[https://en.wikipedia.org/wiki/RS-232 Wikipedia article on RS-232]

{{clear}}

=== RS-422 / RS 423 ===
RS-422 and RS-423 are serial communication standards that work with differential voltages, rather than absolute voltage levels like RS-232, and using 2 twisted pairs. This means that much longer cables can be used and the data will not get corrupted on the way. These are rarely used nowadays, and have essentially been superseded by more modern communication systems, such as CAN and Ethernet. The RS-485 sibling has survived until present day, see below.

RS-422 is (i.e. was) the point-to-point variant, with full duplex in both directions. RS-423 is (i.e. was) the multi-drop variant, with one master that "owned" one pair and all the slaves shared the other pair, and higher level protocols would ensure that only one slave would respond at any given time.

[[File:RS-422_Network.svg|600px]]

[https://en.wikipedia.org/wiki/RS-422 Wikipedia article on RS-422]

=== RS-485 ===
Wikipedia claims that RS-485 was introduced in 1983. I think that is when it formalized as a standard (TIA-485/EIA-485), because I worked with RS-485 in 1984 with equipment that was way older than just 1 year. Modicon introduce Modbus in 1979, which was a serial protocol on top of RS-485. Nevertheless, RS-485 quickly became a favorite in industrial automation, and is still very popular, especially thanks to Modbus.

RS-485 was originally a single twisted pair, differential voltage interface with maximum 30 devices on one segment, something like ~1000 feet (~300 meters) and 1 Mbit/s maximum communication speed. This has been revised over the years, as silicon vendors have improved performance, and the current standard (1998 & 2012) has been updated to reflect this. Faster speeds, more devices and longer cables. Only in-the-field tests can determine the maximum cable lengths at a given speed.

Connecting an MCU to a RS-485 transceiver is very simple. The UART/USART Tx and Rx are connected to "D" (drive) and "R" (receive) pins on the transceiver chip. There are dozens (or more) RS-485 transceivers on the market, and most of the SOIC-8 variants, which are the majority, are pin compatible. Additionally, there are "RE" (receive enable) and "DE" (drive enable) on the transceivers, which the MCU needs to control. They are electrically inverted, so in most cases, we only need a single MCU pin for (direction) and it gos to both RE and DE.

[[File:RS-485_Network.png|800px]]

[https://en.wikipedia.org/wiki/RS-485 Wikipedia article on RS-485]

== {{I2C}} (Inter-Integrated Circuit) ==
[[File:I²C_bus_logo.svg|thumb|250px]]
{{I2C}} is a communication bus originally invented by Philips Semiconductors (now NXP) in 1980. Today, it is widely used for communication between [[MCU]]s and various peripheral devices.

Originally the speed was defined as 100 Kbps or 400 Kbps but faster options were possible and today a newer I3C option is emerging.

[[File:i2c_bus.svg|600px]]

[https://en.wikipedia.org/wiki/I2C Wikipedia article on {{I2C}}]
{{clear}}

== SPI (Serial Peripheral Interface) ==

[[File:SPI_8-bit_circular_transfer.svg|thumb|400px]]

[[File:SPI_single_slave.svg|400px]]

[[File:SPI_three_slaves.svg|400px]]

[[File:SPI_three_slaves_daisy_chained.svg|400px]]

[https://en.wikipedia.org/wiki/Serial_Peripheral_Interface Wikipedia article on SPI]

{{clear}}

== CAN ==

The CAN bus was developed by Bosch in the early 1980s.

[[File:CAN_ISO11898-3_Network.png|600px]]

[https://en.wikipedia.org/wiki/CAN_bus Wikipedia article on CAN]

== USB ==
[[File:USB_icon.svg|thumb|200px]]
USB have today almost completely replaced the original RS-232 for device to device communication.

[https://en.wikipedia.org/wiki/USB Wikipedia article on USB]

{{clear}}

== Ethernet ==
[[File:PC_Network.svg|thumb|200px]]

[https://en.wikipedia.org/wiki/Ethernet Wikipedia article on Ethernet]
{{clear}}

== Miscellaneous Links ==

* [https://en.wikipedia.org/wiki/Serial_communication Wikipedia article on Serial Communications]

Hardware Interconnect Buses

2026-04-29T02:22:51Z

Niclas: /* RS-422 / RS 423 */

[[Category:Electronics]]{{metadesc|Documenting various forms of hardware interconnect}}
'''NOTICE!''' This page is a [[Category:Work in progress]] Work in progress

There are literally hundreds - if not thousands - of different specifications for communications between different devices. Most of these are probably proprietary but this page will document the most common on an introductory level.

== Speed ==

When it comes to any kind of communication, the speed is often expressed as "bps" (bits per second) or faster rates in "kbps" (kilobits per second), "Mbps" (Meta-bits per second) or even "Gbps" (Giga-bits per second). Soon we'll probably begin to see "Tbps" but I am not sure that is available as of yet.

It is worth noticing that, since a byte is 8 bits, you can often divide the bit-rate by 8 to get the Bytes per second). Often, however, there are a few extra bits stuffed in the protocol, start, stop, parity, so this calculation really depends on the protocol.

It should also be mentioned that in the early days the term "baud" was often used ([https://en.wikipedia.org/wiki/Baud Wikipedia article on baud). Baud is defined as a symbol rate and is typically equivalent of the bit-rate. However, later generation modems could use various forms of encoding to transfer multiple bits in one symbol which is why the term is rarely seen today.

== Asynchronous ==

=== RS-232 ===
[[File:PDP-11-70.jpeg|thumb|300px|PDP-11 with a serial terminal in the center]]
RS-232 can be considered the granddad of [[Hardware Interconnect Bus]]es. It is a point-to-point bus which will connect exactly two devices with each other. RS-232 would operate at speeds from around 150 bps, through 300, 4800, 9600 and 19200 bps.

RS-232 was first introduced in 1960 and up through the 70s and even 80s it was widely used. Early computers (see image on the right) were monstrous and were often operated through multiple serial terminals. The communication between the central computer and those terminals were almost always (if not always) RS-232.

Early PC's always had at least one RS-232 port which was often used to attach a modem. Modems were common up until the late 90s and again - exclusively used RS-232.

[[File:RS-232_POTS_DTE_DCE.svg|450px]]

[[File:uart-tx-rx-cross-768x466.png|thumb|300px]]
Today, [[#RS-232|RS-232]] have all but vanished in consumer and professional equipment and is almost exclusively replaced by [[#USB|USB]]. The basic signalling are still commonly used for short distance communication.

These connections will typically operate and a voltage level depending on the actual equipment - typically either 3.3V or 5V.

[https://en.wikipedia.org/wiki/RS-232 Wikipedia article on RS-232]

{{clear}}

=== RS-422 / RS 423 ===
RS-422 and RS-423 are serial communication standards that work with differential voltages, rather than absolute voltage levels like RS-232, and using 2 twisted pairs. This means that much longer cables can be used and the data will not get corrupted on the way. These are rarely used nowadays, and have essentially been superseded by more modern communication systems, such as CAN and Ethernet. The RS-485 sibling has survived until present day, see below.

RS-422 is (i.e. was) the point-to-point variant, with full duplex in both directions. RS-423 is (i.e. was) the multi-drop variant, with one master that "owned" one pair and all the slaves shared the other pair, and higher level protocols would ensure that only one slave would respond at any given time.

[[File:RS-422_Network.svg|600px]]

[https://en.wikipedia.org/wiki/RS-422 Wikipedia article on RS-422]

=== RS-485 ===

[[File:RS-485_Network.png|800px]]

[https://en.wikipedia.org/wiki/RS-485 Wikipedia article on RS-485]

== {{I2C}} (Inter-Integrated Circuit) ==
[[File:I²C_bus_logo.svg|thumb|250px]]
{{I2C}} is a communication bus originally invented by Philips Semiconductors (now NXP) in 1980. Today, it is widely used for communication between [[MCU]]s and various peripheral devices.

Originally the speed was defined as 100 Kbps or 400 Kbps but faster options were possible and today a newer I3C option is emerging.

[[File:i2c_bus.svg|600px]]

[https://en.wikipedia.org/wiki/I2C Wikipedia article on {{I2C}}]
{{clear}}

== SPI (Serial Peripheral Interface) ==

[[File:SPI_8-bit_circular_transfer.svg|thumb|400px]]

[[File:SPI_single_slave.svg|400px]]

[[File:SPI_three_slaves.svg|400px]]

[[File:SPI_three_slaves_daisy_chained.svg|400px]]

[https://en.wikipedia.org/wiki/Serial_Peripheral_Interface Wikipedia article on SPI]

{{clear}}

== CAN ==

The CAN bus was developed by Bosch in the early 1980s.

[[File:CAN_ISO11898-3_Network.png|600px]]

[https://en.wikipedia.org/wiki/CAN_bus Wikipedia article on CAN]

== USB ==
[[File:USB_icon.svg|thumb|200px]]
USB have today almost completely replaced the original RS-232 for device to device communication.

[https://en.wikipedia.org/wiki/USB Wikipedia article on USB]

{{clear}}

== Ethernet ==
[[File:PC_Network.svg|thumb|200px]]

[https://en.wikipedia.org/wiki/Ethernet Wikipedia article on Ethernet]
{{clear}}

== Miscellaneous Links ==

* [https://en.wikipedia.org/wiki/Serial_communication Wikipedia article on Serial Communications]

Colibri Zephyr

2026-04-29T01:25:46Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The [https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single workspace, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_BASE=`pwd`/zephyr" >>.venv/bin/activate
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

To build [[Colibri Runtime]], go to the directory created on the first step above (<code>cd colibri-zephyr/</code>).

After opening a new shell/terminal/konsole you will need to initialize the virtual Python environment.
source .venv/bin/activate

And thereafter the build can be executed,

west build -b colibri_mcu3 --shield colibri_carrier colibri-runtime

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

It seems that Zephyr disables the SWD interface by default, hence the <code>--connect-under-reset</code>.

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-28T09:01:34Z

Niclas: /* Developing with Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The [https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single workspace, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

To build [[Colibri Runtime]], go to the directory created on the first step above (<code>cd colibri-zephyr/</code>).

After opening a new shell/terminal/konsole you will need to initialize the virtual Python environment.
source .venv/bin/activate

And thereafter the build can be executed,

west build -b colibri_mcu3 --shield colibri_carrier colibri-runtime

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

It seems that Zephyr disables the SWD interface by default, hence the <code>--connect-under-reset</code>.

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri

2026-04-28T06:15:07Z

Niclas: /* Programming */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3] or [https://github.com/bytecodealliance/wasm-micro-runtime WAMR]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| MCU module
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| MCU module
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| MCU module
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| MCU module
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| MCU module
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Early Access
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:24:22Z

Niclas: /* Modules & Carriers */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| MCU module
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| MCU module
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| MCU module
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| MCU module
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| MCU module
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Early Access
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:23:34Z

Niclas: /* Planned Boards */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Early Access
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:23:15Z

Niclas: /* Planned Boards */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Early Access
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:22:51Z

Niclas: /* Modules & Carriers */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Early Access
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:21:47Z

Niclas: /* Modules & Carriers */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Early Access
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:21:22Z

Niclas: /* Modules & Carriers */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Active
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:20:56Z

Niclas: /* Modules & Carriers */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Active
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-28T04:19:30Z

Niclas: /* Boards */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Modules & Carriers ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Prototypes
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri Zephyr

2026-04-28T01:32:37Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The [https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single workspace, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

To build [[Colibri Runtime]], go to the directory created on the first step above (<code>cd colibri-zephyr/</code>) and run

west build -b colibri_mcu3 --shield colibri_carrier colibri-runtime

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-28T01:31:44Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The [https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

To build [[Colibri Runtime]], go to the directory created on the first step above (<code>cd colibri-zephyr/</code>) and run

west build -b colibri_mcu3 --shield colibri_carrier colibri-runtime

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-28T01:26:07Z

Niclas: /* Developing with Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

To build [[Colibri Runtime]], go to the directory created on the first step above (<code>cd colibri-zephyr/</code>) and run

west build -b colibri_mcu3 --shield colibri_carrier colibri-runtime

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-28T01:22:28Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-28T01:20:21Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-27T23:54:06Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
echo "export CMAKE_ASM_COMPILER=$HOME/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-27T23:53:38Z

Niclas:

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
echo "export ZEPHYR_TOOLCHAIN_VARIANT=zephyr" >>.venv/bin/activate
echo "export ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyr-sdk-1.0.1" >>.venv/bin/activate
echo "export CMAKE_ASM_COMPILER=/home/niclas/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc" >>.venv/bin/activate
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi
west config zephyr.toolchain-variant zephyr
west config zephyr.sdk-install-dir $HOME/zephyr-sdk-1.0.1

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-27T05:47:33Z

Niclas:

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. I have found this to be the most straight forward, although you can probably set up with a single `zephyr/` for multiple projects, but since our target here is for only a single binary, I am ok to occupy a lot of disk space for this.

mkdir colibri-zephyr # or whatever name you want
cd colibri-zephyr

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xz
mv * wasi-sdk
python3 -m venv .venv
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t arm-zephyr-eabi

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-27T05:33:04Z

Niclas:

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Setting up Zephyr development is somewhat confusing. The https://docs.zephyrproject.org/latest/develop/getting_started/index.html official documentation] is in my opinion somewhat misleading. At least it misled me for quite a while. Do this;

mkdir colibri-zephyr # or whatever name you want

sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 curl
mkdir wasi-sdk
curl -sSL https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-29/wasi-sdk-29.0-$(uname -m | sed s/aarch64/arm64/)-linux.tar.gz | tar xf
mv * wasi-sdk
python3 -m venv .venv
source .venv/bin/activate
pip install west
west init -m https://github.com/currentmakers/colibri-runtime
west update
west zephyr-export
west packages pip --install
west sdk install -t -zephyr-eabi

== Developing with Zephyr ==

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-24T05:25:36Z

Niclas: /* Colibri Runtime */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html Zephyr's Getting Started documentation].

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES="${HOME}/dev/currentmakers/zephyr-cm;${HOME}/dev/currentmakers/zephyr-ws2812b-pwm" # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
export ZEPHYR_SDK_INSTALL_DIR=${HOME}/zephyr-sdk-1.0.1
export ZEPHYR_TOOLCHAIN_VARIANT=zephyr

source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

== Developing with Zephyr ==

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime development =
The [[Colibri Runtime]] (if you are only interested in USING the Colibri Runtime, go to that page) project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-24T05:24:00Z

Niclas:

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html Zephyr's Getting Started documentation].

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES="${HOME}/dev/currentmakers/zephyr-cm;${HOME}/dev/currentmakers/zephyr-ws2812b-pwm" # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
export ZEPHYR_SDK_INSTALL_DIR=${HOME}/zephyr-sdk-1.0.1
export ZEPHYR_TOOLCHAIN_VARIANT=zephyr

source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

== Developing with Zephyr ==

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

= Colibri Runtime =
The [[Colibri Runtime]] project is [https://github.com/currentmakers/colibri-runtime available on Github] and after [https://docs.zephyrproject.org/latest/develop/getting_started/index.html setting up Zephyr], checking out the [https://github.com/currentmakers/zephyr-ws2812b-pwm WS2812B PWM driver] and the [https://github.com/currentmakers/zephyr-cm Colibri device tree], with the paths set up correctly as described above, you should be able to build it.

Currently we have the following directory structure of the project, ignoring the build directory(ies).

├── app.overlay
├── CMakeLists.txt
├── prj.conf
├── README.md
└── src
├── fs
│   ├── fs.h
│   ├── littlefs.c
│   └── nvs.c
├── leds
│   ├── leds.c
│   ├── leds.h
│   └── neopixels.c
├── main.c
└── slots
├── slotcount.c
├── slotctrl.c
└── slotctrl.h

Colibri Zephyr

2026-04-24T05:16:49Z

Niclas: /* Developing with Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html Zephyr's Getting Started documentation].

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES="${HOME}/dev/currentmakers/zephyr-cm;${HOME}/dev/currentmakers/zephyr-ws2812b-pwm" # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
export ZEPHYR_SDK_INSTALL_DIR=${HOME}/zephyr-sdk-1.0.1
export ZEPHYR_TOOLCHAIN_VARIANT=zephyr

source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

= Developing with Zephyr =

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_carrier

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

Colibri Zephyr

2026-04-24T05:15:58Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html Zephyr's Getting Started documentation].

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES="${HOME}/dev/currentmakers/zephyr-cm;${HOME}/dev/currentmakers/zephyr-ws2812b-pwm" # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
export ZEPHYR_SDK_INSTALL_DIR=${HOME}/zephyr-sdk-1.0.1
export ZEPHYR_TOOLCHAIN_VARIANT=zephyr

source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

= Developing with Zephyr =

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_8

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

Streamline

2026-04-21T01:59:40Z

Niclas: /* Miscellaneous */

[[Category:STM32]][[Category:Streamline]][[Category:CurrentMakers]][[Category:Work in progress]]{{metadesc|Streamline Development Boards Home}}
[[File:Streamline Backplane with 2 blades - top right 3.jpg|300px|thumb|Streamline Backplane with 2 blades - 1 Connect and 1 MCU]]
This page documents the new [[CurrentMakers]] [[Streamline]] series of [[Green]] development boards. If you are looking for the previous series, that is document here: [[STM32World Legacy]].

[[Streamline]] boards are available here: [https://currentmakers.com/products/streamline/ Streamline on CurrentMakers]

{{clear}}
== Rationale ==
[[File:3 STM32World Modules stacked.jpg|300px|thumb]]
A number of [[STM32World Legacy]] boards have been developed, and produced, and in general the "system" worked very well. It did however have one fatal flaw which was the sole cause of it never being considered for more widespread production. This flaw was the board to board connector.

The original boards used a 2x20 standard pin header on each side giving a result of 80 pins. In terms of connectivity this was a pretty good solution. It did however present some issues:

# Cost - the long pin 2x20 connectors are fairly expensive - around $0.80 each - so $1.60 per board. This may not sound that high but when producing a lot it becomes a serious cost.
# Manufacturing - the headers can not be manufactured with traditional SMD technologies but require a manual step or hand soldering.
# Fragile - when shipping or disconnecting boards it is hard not to bend one or more pins and once bend it becomes extremely difficult to reconnect them.

To get around this flaw a new "connector" was considered and after a long search the best solution was the standard PCI-E X8 connector.

== Videos ==

{{#ev:youtube|5xQqV7BhYxM}}

Receiving the first prototypes ever:

{{#ev:youtube|YS1w_8ghCf4}}

== Backplane ==

The overall idea is to base [[StreamLine]] around a passive backplane. The backplane contains a number of PCI connectors with 2 x 49 pins (98) that is simply connected in a parallel bus.

<div class="res-img">
[[File:Sl bp 5 top left.png|1000px]]
</div>

In each end of the bus all the A and B signals are broken out into regular pin headers.

=== Backplane rendering ===

<gallery>
File:Backplane top render.png
File:Backplane front render.png
File:Backplane front left render.png
File:Sl bp 5 top.png
File:Sl bp 5 top left.png
File:Sl bp 5 top right.png
</gallery>

== Modules ==

=== [[Backplane]]s ===

{| class="wikitable"
|-
! Name
! Image
! Description
! Status
|-
| [[Streamline Backplane 5]]
| [[File:sl_bp_5_top_left.png|80px]]
| Basic 5 position backplane
| [https://currentmakers.com/products/streamline/streamline_backplane_5/ Available]
|}

=== [[Blade]]s ===

==== STM32 ====

{| class="wikitable"
|-
! Name
! Image
! Description
! Status
|-
| [[Streamline Connect]]
| [[File:Sl prog top left render.png|80px]]
| Streamline Programmer & Debugger. This module is essentially identical to [[Jolt Connect]]
| [https://currentmakers.com/products/streamline/streamline_connect/ Available]
|-
| [[Streamline MCU STM32F407]]
| [[File:Sl mcu stm32f407 top left render.png|80px]]
| Streamline MCU board including a [[STM32F407]]
| [https://currentmakers.com/products/streamline/streamline_mcu_stm32f407/ Available]
|-
| [[Streamline MCU STM32H562]]
| [[File:Sl mcu stm32h562 top left render.png|80px]]
| Streamline MCU board including a [[STM32H562]]
| [https://currentmakers.com/products/streamline/streamline_mcu_stm32h562/ Available]
|-
| [[Streamline MCU STM32L475]]
| [[File:Sl mcu stm32l475 top left render.png|80px]]
| Streamline MCU board including a [[STM32L475]]
| [https://currentmakers.com/products/streamline/streamline_mcu_stm32l475/ Available]
|-
| [[Streamline MCU STM32C511]]
| [[File:Sl_mcu_stm32c551_top_left_render.png|80px]]
| Streamline MCU board including a [[STM32C511]]
| [https://currentmakers.com/products/streamline/streamline_mcu_stm32c511/ Available]
|}

==== Miscellaneous ====

{| class="wikitable"
|-
! Name
! Image
! Description
! Status
|-
| [[Streamline Neopixel 8x8]]
| [[File:Sl neopixel 8x8 top left render.png|80px]]
| Module with an 8x8 matrix of Neopixel WS2812 LEDs
| [https://currentmakers.com/products/streamline/streamline_neopixel_8x8/ Available]
|-
| [[Streamline Storage SD]]
| [[File:Sl storage sd top left render rev A.png|80px]]
| Module with Micro-SD slot
| [https://currentmakers.com/products/streamline/streamline_sd/ Available]
|-
| [[Streamline Storage Flash]]
| [[File:Sl storage flash top left render.png|80px]]
| Module with 16 MB Flash storage ([[W25q128]])
| [https://currentmakers.com/products/streamline/streamline_flash/ Available]
|-
| [[Streamline Storage EEPROM]]
| [[File:Sl storage eeprom top left render.png|80px]]
| Module with 512kB EEPROM storage ([[M24M01]])
| [https://currentmakers.com/products/streamline/streamline_eeprom/ Available]
|-
| Streamline Real Time Clock
|
| Real time clock with on board coin cell battery (or supercap) backup
| Idea
|-
| Streamline ESC
|
| Electronic speed control for BLDC motors
| Idea
|-
| Streamline HS USB
|
| HS USB blade using [[USB3300]]
| Idea
|-
| Streamline CAN-FD
|
| CAN-FD bus interface
| Idea
|-
| Streamline Ethernet
|
| Ethernet interface for STM32F407
| Prototype
|-
| Streamline RS485
|
| Non-isolated RS485 interface
| Prototype
|-
| Streamline WiFi
|
| WiFi interface
| Idea
|}

== Standard Pinout ==

The pinout table is based on a [[MCU]] board with a 100 pin STM32F407. Boards using [[STM32]] [[MCU]]s with less pins will leave some of the pins unused.

{{Streamline Pinout}}

== Prototype Photos ==

<gallery>
File:Streamline Backplane with 2 blades - top right 3.jpg
File:Streamline Backplane with 2 blades - top right 2.jpg
File:Streamline Backplane with 2 blades - top right.jpg
File:Streamline Backplane with 2 blades - top left.jpg
File:Streamline Backplane with 2 blades - front.jpg
File:Streamline Multiple Blades.jpg
File:Streamline MCU STM32L475 - top view.jpg
File:Streamline MCU STM32L475 - bottom view.jpg
File:Streamline MCU STM32H562 - top view.jpg
File:Streamline MCU STM32H562 - bottom view.jpg
File:Streamline MCU STM32F407 - top view.jpg
File:Streamline MCU STM32F407 - bottom view.jpg
File:Streamline Connect - top view.jpg
File:Streamline Connect - bottom view.jpg
</gallery>

== Miscellaneous Links ==

[https://currentmakers.com CurrentMakers main site]

Colibri Zephyr

2026-04-20T11:15:27Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html Zephyr's Getting Started documentation].

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES=${HOME}/dev/currentmakers/zephyr-cm # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

= Developing with Zephyr =

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_8

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

Colibri Zephyr

2026-04-20T11:14:39Z

Niclas: /* Setting up Zephyr */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

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 [https://en.wikipedia.org/wiki/WebAssembly ''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 <code>tick(slot_number)</code> 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 [https://autonomylogic.com/runtime 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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 [https://docs.zephyrproject.org/latest/introduction/index.html 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.

= Supported Boards =
* [[Streamline MCU STM32F407]]
* [[Colibri MCU3]]
* [[Colibri 3a]]
* [[Colibri 8]]

= Colibri Integration =
Colibri carrier boards and Colibri MCU modules are being integrated with Zephyr.

= Setting up Zephyr =
Follow the installation instructions on [https://docs.zephyrproject.org/latest/develop/getting_started/index.html]

You will end up with a <code>${HOME}/zephyrproject</code> directory. If you chose to place that elsewhere, the instructions below must be adjusted.

Check out [https://github.com/currentmakers/zephyr-cm https://github.com/currentmakers/zephyr-cm]

Create a <code>${HOME}/.zephyrrc</code> with the following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr/ # Maybe change this
export ZEPHYR_EXTRA_MODULES=${HOME}/dev/currentmakers/zephyr-cm # <--- CHANGE THIS

Create a file <code>init-zephyr</code> and place somewhere you easily remember how to access it. Let's assume it is in <code>${HOME}</code>. Following content;
export ZEPHYR_BASE=${HOME}/zephyrproject/zephyr
source ${ZEPHYR_BASE}/../.venv/bin/activate
source ${ZEPHYR_BASE}/zephyr-env.sh

= Developing with Zephyr =

After opening the terminal to compile, remember to run
. ${HOME}/init-zephyr
to enable the Python environment and set up the paths.

For any given Zephyr project, for instance the ones in [https://github.com/currentmakers/zephyr-examples] you build like this

west build -b colibri_mcu3 -- -DSHIELD=colibri_8

and the <code>.elf</code> and <code>.bin</code> output files are in <code>build/zephyr</code> and can be flashed as usual with

st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x8000000

(I have seen the <code>st-flash</code> failed to access without the <code>connect-under-reset</code>.)

Colibri Zephyr

2026-04-20T10:53:52Z

Niclas:

Colibri Zephyr

2026-04-20T10:53:25Z

Niclas:

File:Colibri Architecture-1.svg

2026-04-20T04:37:22Z

Niclas: Niclas uploaded a new version of File:Colibri Architecture-1.svg

== Summary ==
One architectural conceptual view of the Colibri system.

File:Colibri Architecture-1.svg

2026-04-20T01:04:38Z

Niclas: Niclas uploaded a new version of File:Colibri Architecture-1.svg

== Summary ==
One architectural conceptual view of the Colibri system.

File:Colibri Architecture-1.svg

2026-04-19T23:53:24Z

Niclas: Niclas uploaded a new version of File:Colibri Architecture-1.svg

== Summary ==
One architectural conceptual view of the Colibri system.

Colibri

2026-04-19T16:00:13Z

Niclas: /* Architecture Overview */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|240px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Prototypes
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-19T15:59:53Z

Niclas: /* Architecture Overview */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
<div class="res-img">
[[File:Colibri_Architecture-1.svg|2400px]]
</div>

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Prototypes
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

Colibri

2026-04-19T15:58:44Z

Niclas: /* Programming */

[[Category:Colibri]][[Category:Work in progress]]{{metadesc|Colibri Automation System}}

<div class="thumb tright">
<div class="thumbinner" style="width: 250px;">
<div style="width: 250px; height: 150px; overflow: hidden; position: relative; background: #000;">
<div style="position: absolute; top: -20px; left: -15px;">
[[File:Colibri_8_photo1.jpg|250px|link=File:Colibri_8_photo1.jpg|alt=Colibri 8 PCB]]
</div>
</div>
</div>
</div>
[[File:Colibri-3-6.jpg|thumb|250px]]
[[File:Colibri_3a_photo1.jpg|thumb|250px]]
[[File:Colibri rs485u-2.jpg|180px|thumb]]
[[File:Colibri aic-RevA-2.jpg|180px|thumb]]

Check out the [[Colibri Videos]] on Youtube.

Colibri is a low-cost automation system, primarily intended for building automation, home automation, energy supervision, agriculture supervision and similar systems. Main features beside costs are;
* Flexible I/O system, via MCU modules and I/O modules in M.2 Key E sockets. Many types already developed.
* Power supply of 9-36 Volt, either AC or DC (some I/O cards won't work with DC supply, and some not with AC supply)
* Each I/O slot can be powered-up/down individually from the MCU.
* Each I/O slot is addressable individually.
* MCU communicates with each I/O slot via I2C and/or SPI. The I2C bus is multiplexed to avoid address collision. SPI uses one Chip Select per I/O slot and 2 additional Chip Select if multi SPI devices are on a single I/O module.
* Each I/O module has an 1Mbit EEPROM with calibration parameters and a WebAssembly program for the MCU module to execute.
* Some I/O modules have on-board secondary processors for time-critical or other reasons, for instance RS-485 communication, digital inputs (pulse counting) and PID regulator.

== Architecture Overview ==
[File:Colibri_Architecture-1.svg]

Colors in this view represents who creates the software for each part.

== Programming ==
The Colibri system is designed around two main external projects, [[Colibri Zephyr|Zephyr]] and WebAssembly ([https://github.com/wasm3/wasm3 wasm3]).

Zephyr provides a lot of ''operating system'' type of features, like task scheduling, concurrency data types, timers, peripheral drivers and cross-platform compatibility to be able to support STM32, RP2354 and possibly other MCU families. And combining that with a WebAssembly environment, we should be able to have a lot of platform independence.

The WebAssembly approach is to allow for;
* I/O modules that are unknown to the MCU module to be installed without re-flashing the firmware,
* Uploading of user programs, without flashing the firmware,
* Sandboxed execution to limit issues that user programs can create,
* Simplified tool chain,
* Deferring the choice of programming languages,
* Future-proofing for programming evolution, option to create our own language.

== Carrier Boards ==
* ''Colibri 3a'' has 2 I/O slots and one MCU slot, one USB-C port to the MCU slot, Jolt Connect pin header for programming.
* ''Colibri 8'' is like the ''Colibri 3a'', but with 7 I/O slots and an isolated RS-485 port to the MCU slot.
* Planned; ''Colibri 8pi'' is like the ''Colibri 8'' but with a full-fledged Raspberry Pi Compute Module 5. 1 Colibri MCU slot and 7 I/O slots,
* Planned; ''Colibri 16pi'' is like the ''Colibri 8pi'', but with 15 I/O slots rather than 7.

== MCU Modules ==
There is a choice, and more will follow;

* ''[[Colibri MCU1]]'' - MCU module with a STM32WLE5, 256kB Flash, 64kB RAM, on-chip LoRa and LoraWAN protocol available in STM32CubeMX.
* ''[[Colibri MCU2]]'' - MCU module with a STM32H562RG, 1024kB Flash, 640kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU3]]'' - MCU module with a STM32F405RG, 1MB Flash, 192kB+4kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU4]]'' - MCU module with a STM32L475RG, 1MB Flash, 128kB RAM and a 16MB external flash memory.
* ''[[Colibri MCU5]]'' - (deprecated) MCU module with a STM32F103RE, 512kB Flash and 64kB RAM. No external flash memory.
* ''[[Colibri MCU6]]'' - MCU module with a RP2354B, 2MB Flash, 192kB+4kB RAM and a 16MB external flash memory.

== I/O Modules ==
The Colibri system is based around the M.2 connector and a non-standard bus for I2C and SPI communications. Each I/O module has an [[Colibri_EEPROM_Layout|EEPROM memory]] available to identify which module is present in each I/O slot, links to documentation, calibration parameters, testing results and (up to) 16kB of WebAssembly for the MCU module to execute.

== [[Colibri Form Factor|Form Factor]] ==

Both Colibri I/O modules and MCU modules are 22x42mm and has an edge connector called M.2 Key E, '''but it doesn't follow the M.2 specification for Key E'''. The distance between the I/O slots are specified to 23.5mm,
theoretically making it possible for multi-slot I/O modules (none are planned).

<span style="color:#FF4444">'''WARNING!!! Do NOT plug Colibri I/O modules nor any MCU module into other equipment. Do NOT plug any M.2 card into a Colibri system, unless that card/board is specifically made for Colibri.'''</span>

== Boards ==

{| class=wikitable
|-
! Name
! Type
! Description
! Status
|-
| ''[[Colibri 3a]]''
| Colibri Carrier
| Minimal Colibri carrier board with 2 I/O slots and one MCU slot. MCU slot is to be populated with any of the MCU variants available.
| Active
|-
| ''[[Colibri 8]]''
| Colibri Carrier
| Colibri carrier board with Colibri MCU slot and 7 Colibri I/O slots.
| Early Access
|-
| ''[[Colibri 1dp]]''
| Colibri Carrier
| Minimal Colibri Host with a single MCU slot and 0-500Pa air pressure sensor.
| Prototypes
|-
| ''[[Colibri MCU1]]''
| Host MCU
| MCU module with a STM32WLE5CC, for LoraWAN applications.
| Prototyping
|-
| ''[[Colibri MCU2]]''
| Host MCU
| MCU module with a STM32H562RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU3]]''
| Host MCU
| MCU module with a STM32F405RG and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU4]]''
| Host MCU
| MCU module with a STM32L475RGTx and a 16MB flash memory.
| Prototyping
|-
| ''[[Colibri MCU6]]''
| Host MCU
| MCU module with a Raspberry Pi RP2354B and a 16MB flash memory.
| Prototyping
|-
| ''[[M.2 E Breakout]]''
| M.2 breakout board
| Generic breakout board for M.2 E key boards.
| Prototypes
|-
| ''[[Colibri AIC]]''
| I/O module
| Two analog 0-20mA inputs
| Prototypes
|-
| ''[[Colibri AIV]]''
| I/O module
| Two analog 0-10V inputs
| Prototypes
|-
| ''[[Colibri AQV]]''
| I/O module
| Two analog 0-10V outputs
| Active
|-
| ''[[Colibri DII]]''
| I/O module
| Two ISOLATED digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DIO1]]''
| I/O module
| IEC 61131-2 compliant, 4-channels digital inputs and outputs.
| Prototypes
|-
| ''[[Colibri DIU]]''
| I/O module
| Four digital inputs, for state, counter, pulsewidth measurement. On-board STM32F030 for ability to count very fast pulses and high accuracy PWM measurements.
| Prototypes
|-
| ''[[Colibri DP1]]''
| I/O module
| A 0-500Pa air pressure sensor mounted on I/O module.
| Prototyping
|-
| ''[[Colibri FET]]''
| I/O module
| Four digital outputs, FET outputs sinking to GND. Max 1 Amp per channel.
| Prototypes
|-
| ''[[Colibri PID1]]''
| I/O module
| PID regulator, with a PT1000 input and a 0-10V analog output. On-board STM32F030 for host-independent operation.
| Active
|-
| ''[[Colibri Pt1000]]''
| I/O module
| Two PT1000 temperature sensor inputs.
| Active
|-
| ''[[Colibri RS485I]]''
| I/O module
| Isolated RS-485 port. On-board STM32G431KB to implement protocols, such as Modbus RTU.
| Prototyping
|-
| ''[[Colibri RS485U]]''
| I/O module
| Two non-isolated RS-485 ports. On-board STM32F030 implementing Modbus protocol, either as master or slave device.
| Prototypes
|-
| ''[[Colibri SSR]]''
| I/O module
| Two Solid State Relays, ON/OFF.
| Prototypes
|-
| ''[[Colibri TRIAC1]]''
| I/O module
| Four Triac outputs, driving 24V AC.
| Prototyping
|}

== Planned Boards ==

{| class=wikitable
|-
!
! Name
! Type
! Description
! Status
|-
| ''[[Colibri-8pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 7 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|-
| ''[[Colibri-16pi]]''
| Carrier board
| Colibri carrier board with Raspberry Pi CM5, Colibri MCU slot, 15 Colibri I/O slots, two Ethernet ports, 3 USB ports and SDcard connector.
| Planned
|}

= License =
All Schematics are licensed with the GPLv3, meaning that you are free to make your own designs or manufacture devices using these. We expect that if you derive new design, that you publish these, preferably on this website.

The software will also be published with GPLv3, when something is workable.

= Resources =

File:Colibri Architecture-1.svg

2026-04-19T15:57:57Z

Niclas: Niclas uploaded a new version of File:Colibri Architecture-1.svg

== Summary ==
One architectural conceptual view of the Colibri system.

File:Colibri Architecture-1.svg

2026-04-19T15:56:43Z

Niclas: One architectural conceptual view of the Colibri system.

== Summary ==
One architectural conceptual view of the Colibri system.

Colibri MCU3

2026-04-17T04:55:00Z

Niclas:

[[Category:Components and Modules]][[Category:Modules]][[Category:Colibri]]{{metadesc|Colibri MCU3 module}}
[[File:Colibri_mcu3_rev-B_front.jpg|125px|thumb]]
[[File:Colibri_mcu3_rev-B_back.jpg|125px|thumb]]
[[File:Colibri_mcu3_top_right_render.png|250px|thumb]]
[[File:Colibri_mcu3_bot_render.png|250px|thumb]]

[[Colibri]] MCU3 is a processor board for the [[Colibri]] carrier boards. It is an STM32F405RG to be used as the MCU for a Colibri system. Primarily intended for battery operated applications.

= Hardware =
The MCU3 is a relatively simple MCU module, on an M.2 board with the size 22x42mm and the Key E configuration.

Besides the [[STM32F405|STM32F405RG]] MCU there are also
* 128 Mbits (16MB) flash memory for application use.
* a dual-colored (Green/Red) LED
* 16MHz HSE crystal
* 32768 Hz LSE crystal, intended for calendar functions in the STM32.

'''NOTE: All modules in Colibri are NOT electrically compatible with the M.2 connector standard. DO NOT plug Colibri modules into any M.2 socket other than Colibri (or compatible) ones. And DO NOT plug any M.2 modules (Key E is typically WiFi/BLE) into a Colibri carrier board.

= Programming =
STM32CubeMX file [[Media:Mcu3.ioc|MCU3.ioc template file]] for Colibri carrier boards. (Right-click, "Save link as..." on the link)

== Low Level ==
The standard SWDIO/SWCLK pins are available in the pin header together with USART2 for effective low level development environment.

== C/C++ ==
The standard SWDIO/SWCLK pins are available on the M.2 connector, as well as BOOT0 + USART1 for effective development environment. We recommend the use of the STM32CubeMX to set up the MCU correctly, and then your favorite IDE for the edit-compile-flash-run cycle.

Use the STM32CubeMX [[File:Mcu3.ioc|mcu.ioc template file]] to get the pinout right from the beginning. (Right-click, "Save link as..." to download it)

== Zephyr ==
Zerphyr is an MCU-independent embedded OS, with a very modular approach to software, which fits quite well with the modular support of Streamline and Colibri products.

Read more about how [[Colibri Zephyr]] is intended (work in progress) to operate on the [[Colibri]] family.

== Schematics ==

<div class="res-img">
[[File:Colibri_mcu3.svg|2400px]]
</div>

== Gallery ==

<gallery>
File:Colibri_mcu3_top_render.png
File:Colibri_mcu3_bot_render.png
File:Colibri_mcu3_top_right_render.png
File:Colibri_mcu3_top_left_render.png
</gallery>