Stm32World Wiki - User contributions [en]

Colibri Runtime

2026-05-09T09:35:23Z

Niclas:

The Colibri Runtime is the custom firmware that is running on Colibri MCUs, an application in [[Colibri Zephyr]] orchestrating the hardware resources, WebAssembly engines with I/O drivers and user programs.

== Development ==
[[Colibri EEPROM Layout]]

[[Colibri WebAssembly Notes]]

Colibri Runtime

2026-05-09T09:35:12Z

Niclas:

Colibri EEPROM Layout

2026-05-09T09:32:26Z

Niclas: /* Memory Layout */

All the Colibri I/O modules come with a 1Mbit EEPROM on board, that serves to store a few different things;

* Vendor, Model and Revision of 'this' board.
* Calibration parameters needed to compensate for hardware tolerances.
* Test report (if any) from factory.
* The ''driver(s)'' (i.e. code) of the board, to be executed in the MCU module on behalf of the board.
* Any additional parameters, configuration that should survive over time.
* Any storage space an on-module co-MCU needs.

= Memory Layout =

{| class=wikitable
|-
! Address
! Length
! Description
|-
| 0x0000
| 4
| Contains the value 0xdeadbabe to indicate that it has been initialized.
|-
| 0x0004
| 4
| Serial Number
|-
| 0x0008
| 8
| Reserved for future use.
|-
| 0x0010
| 4
| Vendor ID, according to table below.
|-
| 0x0014
| 4
| Vendor Model identifier. This is specific to each vendor. Vendors are encouraged to add their tables on this page.
|-
| 0x0018
| 4
| Vendor Hardware Revision, where revision 'A' is written as 0x00000041 and revision 'AC' is 0x00004341
|-
| 0x001c
| 4
| Reserved for future use.
|-
| 0x0020
| 4
| Pointer to Vendor name, in ASCII.
|-
| 0x0024
| 4
| Length of Vendor name
|-
| 0x0028
| 4
| Pointer to Model name, in ASCII.
|-
| 0x002c
| 4
| Length of Model name.
|-
| 0x0030
| 4
| Pointer to Product Link
|-
| 0x0034
| 4
| Length of Product Link
|-
| 0x0038
| 4
| Pointer to Documentation Link
|-
| 0x003c
| 4
| Length of Documentation Link
|-
| 0x0040
| 4
| Size of ARM PIC (Position Independent Code).
|-
| 0x0044
| 60
| Reserved for future use.
|-
| 0x0080
| 128
| Calibration data, see each I/O module for details
|-
| 0x0100
| 256
| Test Reports, see each I/O module for details
|-
| 0x0200
| 2048
| Text area. Links points to here, i.e. Vendor name, model name, documentation link and product link.
|-
| 0x0A00
| 1536
| Reserved for future use.
|-
| 0x1000
| 12288
| Vendor area
|-
| 0x4000
| 8192
| Driver software/code. ARM PIC
|-
| 0x6000
| 40960
| Reserved for future use.
|-
| 0x10000
| 65536
| Reserved for co-MCU on I/O module, or vendor defined.
|}

= Vendor ID =
Contact us at info@currentmakers.com if you have products you want added.

{| class=wikitable
|-
! ID
! Company
! Webpage
|-
| 1
| CurrentMakers
| https://currentmakers.com
|}

Colibri EEPROM Layout

2026-05-09T09:16:24Z

Niclas: /* Memory Layout */

Colibri EEPROM Layout

2026-05-09T07:08:13Z

Niclas: /* Memory Layout */

All the Colibri I/O modules come with a 1Mbit EEPROM on board, that serves to store a few different things;

* Vendor, Model and Revision of 'this' board.
* Calibration parameters needed to compensate for hardware tolerances.
* Test report (if any) from factory.
* The ''driver(s)'' (i.e. code) of the board, to be executed in the MCU module on behalf of the board.
* Any additional parameters, configuration that should survive over time.
* Any storage space an on-module co-MCU needs.

= Memory Layout =

{| class=wikitable
|-
! Address
! Length
! Description
|-
| 0x0000
| 4
| Contains the value 0xdeadbabe to indicate that it has been initialized.
|-
| 0x0004
| 12
| Reserved for future use.
|-
| 0x0010
| 4
| Vendor ID, according to table below.
|-
| 0x0014
| 4
| Vendor Model identifier. This is specific to each vendor. Vendors are encouraged to add their tables on this page.
|-
| 0x0018
| 4
| Vendor Hardware Revision, where revision 'A' is written as 0x00000041 and revision 'AC' is 0x00004341
|-
| 0x001c
| 4
| Reserved for future use.
|-
| 0x0020
| 4
| Pointer to Vendor name, in ASCII.
|-
| 0x0024
| 4
| Length of Vendor name
|-
| 0x0028
| 4
| Pointer to Model name, in ASCII.
|-
| 0x002c
| 4
| Length of Model name.
|-
| 0x0030
| 4
| Pointer to Product Link
|-
| 0x0034
| 4
| Length of Product Link
|-
| 0x0038
| 4
| Pointer to Documentation Link
|-
| 0x003c
| 4
| Length of Documentation Link
|-
| 0x0040
| 4
| Size of ARM PIC (Position Independent Code).
|-
| 0x0044
| 60
| Reserved for future use.
|-
| 0x0080
| 128
| Calibration data, see each I/O module for details
|-
| 0x0100
| 256
| Test Reports, see each I/O module for details
|-
| 0x0200
| 2048
| Text area. Links points to here, i.e. Vendor name, model name, documentation link and product link.
|-
| 0x0A00
| 1536
| Reserved for future use.
|-
| 0x1000
| 12288
| Vendor area
|-
| 0x4000
| 8192
| Driver software/code. ARM PIC
|-
| 0x6000
| 40960
| Reserved for future use.
|-
| 0x10000
| 65536
| Reserved for co-MCU on I/O module, or vendor defined.
|}

Colibri EEPROM Layout

2026-05-09T06:57:13Z

Niclas: /* Memory Layout */

All the Colibri I/O modules come with a 1Mbit EEPROM on board, that serves to store a few different things;

* Vendor, Model and Revision of 'this' board.
* Calibration parameters needed to compensate for hardware tolerances.
* Test report (if any) from factory.
* The ''driver(s)'' (i.e. code) of the board, to be executed in the MCU module on behalf of the board.
* Any additional parameters, configuration that should survive over time.
* Any storage space an on-module co-MCU needs.

= Memory Layout =

{| class=wikitable
|-
! Address
! Length
! Description
|-
| 0x0000
| 4
| Contains the value 0xdeadbabe to indicate that it has been initialized.
|-
| 0x0004
| 12
| Reserved for future use.
|-
| 0x0010
| 4
| Vendor ID, according to table below.
|-
| 0x0014
| 4
| Vendor Model identifier. This is specific to each vendor. Vendors are encouraged to add their tables on this page.
|-
| 0x0018
| 4
| Vendor Hardware Revision, where revision 'A' is written as 0x00000041 and revision 'AC' is 0x00004341
|-
| 0x001c
| 4
| Reserved for future use.
|-
| 0x0020
| 4
| Pointer to Vendor name, in ASCII.
|-
| 0x0024
| 4
| Length of Vendor name
|-
| 0x0028
| 4
| Pointer to Model name, in ASCII.
|-
| 0x002c
| 4
| Length of Model name.
|-
| 0x0030
| 4
| Pointer to Product Link
|-
| 0x0034
| 4
| Length of Product Link
|-
| 0x0038
| 4
| Pointer to Documentation Link
|-
| 0x003c
| 4
| Length of Documentation Link
|-
| 0x0040
| 4
| Size of ARM PIC (Position Independent Code).
|-
| 0x0044
| 60
| Reserved for future use.
|-
| 0x0080
| 128
| Calibration data, see each I/O module for details
|-
| 0x0100
| 256
| Test Reports, see each I/O module for details
|-
| 0x0200
| 1536
| Text area. Links points to here, i.e. Vendor name, model name, documentation link and product link.
|-
| 0x0800
| 2048
| Reserved for future use.
|-
| 0x1000
| 12288
| Vendor area
|-
| 0x4000
| 8192
| Driver software/code. ARM PIC
|-
| 0x6000
| 40960
| Reserved for future use.
|-
| 0x10000
| 65536
| Reserved for co-MCU on I/O module, or vendor defined.
|}

Colibri Programming Languages

2026-05-09T06:33:40Z

Niclas: /* zeptoforth */

= zeptoforth =

[[zeptoforth]] is a possible programming language for the Colibri family. Each I/O module will contain the source code for its own usage, meaning that the MCU's firmware doesn't need updating when new I/O modules are available and installed.

Forth is a unique programming language and some people are very unhappy with it, and hence we will try to support additional programming languages to the best of our abilities.

= MicroPython =
[[MicroPython]] is a rather large environment, and it will be challenging (or even impossible) to squeeze it into some of the MCUs (such as MCU1 with the LoraWAN stack).

= Lua =
[[Lua]] is a neat little language that is easily embeddable in any C hosted (and other) environment. The flash memory footprint is said to be in the 100-200kB range.

= C++ - Arduino =
Since we are using most STM32 MCUs, and practically every MCU marketed at the Maker community is supporting the Arduino approach. Now, the recent acquisition of Arduino by Qualcomm might lead to a decline in the platoform's popularity, and CurrentMakers is too small to invest resources in this uncertainty. The only reason to use Arduino software platform is because of its incredible popularity.

= C - STM32Cube HAL / Bare-metal =
It is of course very possible to implement a software stack for Colibri using C. Libraries for peripheral access is readily available, or it is quite easy to implement in bare metal programming, see STM32World's [[https://www.youtube.com/playlist?list=PLVfOnriB1RjUO4qv9lQcYVliGpt8T3gOR bare metal video series]].

= OpenPLC =
[https://autonomylogic.com/ OpenPLC] (from a company called Autonomy) is an interesting choice, especially for PLC professionals. It allows for [https://en.wikipedia.org/wiki/IEC_61131-3 IEC 61131-3 standard] programs to be compiled to C and flashed into MCUs. It supports some STM32, ESP32 and RP2350 (external Flash). It is quite likely it is not too difficult to make this work.

= WebAssembly =
WebAssembly is a kind of runtime sandbox with a well-defined instruction set and memory model. Many languages can be compiled to WebAssembly with the LLVM project. The main advantage to pull this off would be to have a stable runtime on the MCU and "upload" user programs without flashing a binary. What to compile ''from'' would still be up for debate.

Colibri WebAssembly Notes

2026-05-07T04:02:09Z

Niclas:

Various notes, investigations and other useful information that might be needed later.

= WASM3 peculiarity =
I am loading 8 different WASM binaries, and each are called its <code>event()</code> function every 10ms.

7 of the does the blinking of the RGB LEDs and the last one doesn't.

I changed the last one to be the same as the first one. And again the last one doesn't blink the LED. So, it is not the WASM code that is the issue.

I can single step through the wasm execution and there is nothing that stands out. However, since only the "if(next < now)" is executed, then there is not that much that is happening.

= Zephyr Mutexes =
I now have a case where the a zephyr mutex was set up in main(), and later called from a different Zephyr thread, and immediately crashes.

k_mutex_lock(&data->lock, K_FOREVER);

That is an inlined function of
__pinned_func
static inline int k_mutex_lock(struct k_mutex * mutex, k_timeout_t timeout)
{
compiler_barrier();
return z_impl_k_mutex_lock(mutex, timeout);
}

And <code>compiler_barrier()</code> expands to

do { __asm__ __volatile__ ("" ::: "memory"); }
while (0);

on the STM32.

I am now moving code around to ensure that it is always the same thread calling the mutex.

Hmmm... Now instead completely crashing, it is ending up in

void arch_system_halt(unsigned int reason){}

with a reason=4, which is <code>K_ERR_KERNEL_PANIC</code>

Call stack reveals nothing.

arch_system_halt fatal.c:30
k_sys_fatal_error_handler fatal.c:44
z_fatal_error fatal.c:119
z_arm_fatal_error fatal.c:93
z_arm_fault fault.c:1090
z_arm_usage_fault fault_s.S:103
assert_post_action assert.c:44
z_spinlock_validate_pre spinlock.h:132
k_spin_lock spinlock.h:192
z_unpend1_no_timeout sched.c:717
z_impl_k_timer_stop timer.c:276
z_log_msg_post_finalize log_core.c:195
msg_commit log_core.c:717
z_log_msg_commit log_core.c:723
z_log_msg_finalize log_msg.c:54
z_log_msg_simple_create log_msg.c:130
z_impl_z_log_msg_simple_create_1 log_msg.c:229
esf_dump fatal.c:67
z_arm_fatal_error fatal.c:76
z_do_kernel_oops fatal.c:141
z_arm_svc svc.S:158

Need more work here...
That was an unsolved PANIC, but after a bit more fiddling with memory settings, I got to a point where a very clear Stack Overflow occurred. And that was due to stack size for the I/O subsystem thread was set too small. 1024 wasn't enough to execute WASM3 and the stuff I had around it.

= CMake for I/O drivers =
It is crucial that the wasm binary is stripped of all meta data. This is an example of a reasonable <code>CMakeLists.txt</code> for the [[Colibri DIO1]] module.

cmake_minimum_required(VERSION 3.5)
set(CMAKE_LINK_DEPENDS_USE_LINKER FALSE)
project(io_dio1 C)

set(CMAKE_C_STANDARD 11)
set(CMAKE_C_COMPILER clang)

include_directories(colibri-sdk/)

add_executable(io_dio1 dio1.c)
set_target_properties(io_dio1 PROPERTIES SUFFIX ".wasm")

target_compile_options(io_dio1 PRIVATE
--target=wasm32
-Oz
-ffunction-sections
-fdata-sections
)

target_link_options(io_dio1 PRIVATE
--target=wasm32-unknown-unknown-wasm # or just =wasm
-nostdlib
-Wl,--no-entry
-Wl,--allow-undefined
-Wl,--gc-sections
-Wl,--strip-all

# Exports
-Wl,--export=event
-Wl,--export=init
-Wl,--export=loaded
-Wl,--export=unloading

# Memory Management
-Wl,--import-memory # Host provides the memory
-Wl,--initial-memory=65536 # Request 2 pages (required for standard compliance)
-Wl,--max-memory=65536 # Cap it at 2 pages
-Wl,-z,stack-size=512 # Shrink WASM-internal stack (Default is often 64KB!)
)

add_custom_command(
TARGET io_dio1 POST_BUILD
COMMAND xxd -i -n io_dio1 ${CMAKE_BINARY_DIR}/io_dio1/io_dio1.wasm | sed 's/unsigned /const unsigned /' >${CMAKE_BINARY_DIR}/io_dio1.h
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating io_dio1.h from io_dio1.wasm using xxd"
)

= Memory Allocations =
This was an investigation into how much RAM is used to instantiate WebAssembly runtimes. 8 wasm files were deployed, each blinking the LED for the respective slot.

---- Program to be loaded ----

#include "colibri.h"
#define export __attribute__((visibility("default")))

static int next = 0;
static int state = 0;

int tick(long time) {
if (next < time) {
if (state){
set_rgb_error();
next = time + 100;
}
else {
set_rgb_off();
next = time + 500;
}
}
return state;
}

export void event(int id, long value) {
tick(value);
}

export void init() {
set_rgb_ok_color(0x000400);
set_rgb_warning_color(0x040400);
set_rgb_error_color(0x080000);
}

export void loaded() {
set_rgb_off();
}

export void unloading() {
set_rgb_off();
}

Env Heap @ 0x10000000 112 bytes
wasm0 Heap @ 0x10000070 4960 bytes
wasm1 Heap @ 0x100013D0 4368 bytes
wasm2 Heap @ 0x100024E0 4368 bytes
wasm3 Heap @ 0x100035f0 4368 bytes
wasm4 Heap @ 0x10004700 4608 bytes
wasm5 Heap @ 0x10005900 4368 bytes
wasm6 Heap @ 0x10006a10 4368 bytes
wasm7 Heap @ 0x10007b20 5200 bytes
End Heap @ 0x10008F70

----- Once -----
NewEnvironment
M3Environment struct 0x20
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09

----- Per wasm ---

NewRuntime
M3Runtime struct 0x434
runtime->origStack 0x410 (stack + 4 32bit words)

ParseModule
M3Module module 0x78
io_module->functTypes 0x0c
AllocFuncType 0x08
Free
AllocFuncType 0x09
Free
AllocFuncType 0x0A
Free
PreAllocFunctions 0x154 (5 functions * 68 bytes?)
"env" 0x04
"memory" 0x07
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_off" 0x0C
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_ok_color" 0x11
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_warning_color" 0x16
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_error_color" 0x14
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
PreAllocFunctions 0x220
AddGlobal 0x20
"event" 0x06 (exports)
Free NULL (exported name)
"init" 0x05
Free NULL (exported name)
"loaded" 0x07
Free NULL (exported name)
"unloading" 0x0A
Free NULL (exported name)
Free NULL (one extra exported name)
M3DataSegments 0x20 (0 data segment)

LoadModule
NewCodePage 0x40
Free NULL
Free NULL
Free NULL
Free NULL
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x08 ("event")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x12 ("init")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x14

Colibri WebAssembly Notes

2026-05-06T08:42:00Z

Niclas: /* Zephyr Mutexes */

Various notes, investigations and other useful information that might be needed later.

= Zephyr Mutexes =
I now have a case where the a zephyr mutex was set up in main(), and later called from a different Zephyr thread, and immediately crashes.

k_mutex_lock(&data->lock, K_FOREVER);

That is an inlined function of
__pinned_func
static inline int k_mutex_lock(struct k_mutex * mutex, k_timeout_t timeout)
{
compiler_barrier();
return z_impl_k_mutex_lock(mutex, timeout);
}

And <code>compiler_barrier()</code> expands to

do { __asm__ __volatile__ ("" ::: "memory"); }
while (0);

on the STM32.

I am now moving code around to ensure that it is always the same thread calling the mutex.

Hmmm... Now instead completely crashing, it is ending up in

void arch_system_halt(unsigned int reason){}

with a reason=4, which is <code>K_ERR_KERNEL_PANIC</code>

Call stack reveals nothing.

arch_system_halt fatal.c:30
k_sys_fatal_error_handler fatal.c:44
z_fatal_error fatal.c:119
z_arm_fatal_error fatal.c:93
z_arm_fault fault.c:1090
z_arm_usage_fault fault_s.S:103
assert_post_action assert.c:44
z_spinlock_validate_pre spinlock.h:132
k_spin_lock spinlock.h:192
z_unpend1_no_timeout sched.c:717
z_impl_k_timer_stop timer.c:276
z_log_msg_post_finalize log_core.c:195
msg_commit log_core.c:717
z_log_msg_commit log_core.c:723
z_log_msg_finalize log_msg.c:54
z_log_msg_simple_create log_msg.c:130
z_impl_z_log_msg_simple_create_1 log_msg.c:229
esf_dump fatal.c:67
z_arm_fatal_error fatal.c:76
z_do_kernel_oops fatal.c:141
z_arm_svc svc.S:158

Need more work here...

= CMake for I/O drivers =
It is crucial that the wasm binary is stripped of all meta data. This is an example of a reasonable <code>CMakeLists.txt</code> for the [[Colibri DIO1]] module.

cmake_minimum_required(VERSION 3.5)
set(CMAKE_LINK_DEPENDS_USE_LINKER FALSE)
project(io_dio1 C)

set(CMAKE_C_STANDARD 11)
set(CMAKE_C_COMPILER clang)

include_directories(colibri-sdk/)

add_executable(io_dio1 dio1.c)
set_target_properties(io_dio1 PROPERTIES SUFFIX ".wasm")

target_compile_options(io_dio1 PRIVATE
--target=wasm32
-Oz
-ffunction-sections
-fdata-sections
)

target_link_options(io_dio1 PRIVATE
--target=wasm32-unknown-unknown-wasm # or just =wasm
-nostdlib
-Wl,--no-entry
-Wl,--allow-undefined
-Wl,--gc-sections
-Wl,--strip-all

# Exports
-Wl,--export=event
-Wl,--export=init
-Wl,--export=loaded
-Wl,--export=unloading

# Memory Management
-Wl,--import-memory # Host provides the memory
-Wl,--initial-memory=65536 # Request 2 pages (required for standard compliance)
-Wl,--max-memory=65536 # Cap it at 2 pages
-Wl,-z,stack-size=512 # Shrink WASM-internal stack (Default is often 64KB!)
)

add_custom_command(
TARGET io_dio1 POST_BUILD
COMMAND xxd -i -n io_dio1 ${CMAKE_BINARY_DIR}/io_dio1/io_dio1.wasm | sed 's/unsigned /const unsigned /' >${CMAKE_BINARY_DIR}/io_dio1.h
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating io_dio1.h from io_dio1.wasm using xxd"
)

= Memory Allocations =
This was an investigation into how much RAM is used to instantiate WebAssembly runtimes. 8 wasm files were deployed, each blinking the LED for the respective slot.

---- Program to be loaded ----

#include "colibri.h"
#define export __attribute__((visibility("default")))

static int next = 0;
static int state = 0;

int tick(long time) {
if (next < time) {
if (state){
set_rgb_error();
next = time + 100;
}
else {
set_rgb_off();
next = time + 500;
}
}
return state;
}

export void event(int id, long value) {
tick(value);
}

export void init() {
set_rgb_ok_color(0x000400);
set_rgb_warning_color(0x040400);
set_rgb_error_color(0x080000);
}

export void loaded() {
set_rgb_off();
}

export void unloading() {
set_rgb_off();
}

Env Heap @ 0x10000000 112 bytes
wasm0 Heap @ 0x10000070 4960 bytes
wasm1 Heap @ 0x100013D0 4368 bytes
wasm2 Heap @ 0x100024E0 4368 bytes
wasm3 Heap @ 0x100035f0 4368 bytes
wasm4 Heap @ 0x10004700 4608 bytes
wasm5 Heap @ 0x10005900 4368 bytes
wasm6 Heap @ 0x10006a10 4368 bytes
wasm7 Heap @ 0x10007b20 5200 bytes
End Heap @ 0x10008F70

----- Once -----
NewEnvironment
M3Environment struct 0x20
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09

----- Per wasm ---

NewRuntime
M3Runtime struct 0x434
runtime->origStack 0x410 (stack + 4 32bit words)

ParseModule
M3Module module 0x78
io_module->functTypes 0x0c
AllocFuncType 0x08
Free
AllocFuncType 0x09
Free
AllocFuncType 0x0A
Free
PreAllocFunctions 0x154 (5 functions * 68 bytes?)
"env" 0x04
"memory" 0x07
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_off" 0x0C
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_ok_color" 0x11
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_warning_color" 0x16
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_error_color" 0x14
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
PreAllocFunctions 0x220
AddGlobal 0x20
"event" 0x06 (exports)
Free NULL (exported name)
"init" 0x05
Free NULL (exported name)
"loaded" 0x07
Free NULL (exported name)
"unloading" 0x0A
Free NULL (exported name)
Free NULL (one extra exported name)
M3DataSegments 0x20 (0 data segment)

LoadModule
NewCodePage 0x40
Free NULL
Free NULL
Free NULL
Free NULL
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x08 ("event")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x12 ("init")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x14

Colibri WebAssembly Notes

2026-05-06T08:37:03Z

Niclas:

Various notes, investigations and other useful information that might be needed later.

= Zephyr Mutexes =
I now have a case where the a zephyr mutex was set up in main(), and later called from a different Zephyr thread, and immediately crashes.

k_mutex_lock(&data->lock, K_FOREVER);

That is an inlined function of
__pinned_func
static inline int k_mutex_lock(struct k_mutex * mutex, k_timeout_t timeout)
{
compiler_barrier();
return z_impl_k_mutex_lock(mutex, timeout);
}

And <code>compiler_barrier()</code> expands to

do { __asm__ __volatile__ ("" ::: "memory"); }
while (0);

on the STM32.

I am now moving code around to ensure that it is always the same thread calling the mutex.

Hmmm... Now instead completely crashing, it is ending up in

void arch_system_halt(unsigned int reason){}

with a reason=4, which is <code>K_ERR_KERNEL_PANIC</code>

Need more work here...

= CMake for I/O drivers =
It is crucial that the wasm binary is stripped of all meta data. This is an example of a reasonable <code>CMakeLists.txt</code> for the [[Colibri DIO1]] module.

cmake_minimum_required(VERSION 3.5)
set(CMAKE_LINK_DEPENDS_USE_LINKER FALSE)
project(io_dio1 C)

set(CMAKE_C_STANDARD 11)
set(CMAKE_C_COMPILER clang)

include_directories(colibri-sdk/)

add_executable(io_dio1 dio1.c)
set_target_properties(io_dio1 PROPERTIES SUFFIX ".wasm")

target_compile_options(io_dio1 PRIVATE
--target=wasm32
-Oz
-ffunction-sections
-fdata-sections
)

target_link_options(io_dio1 PRIVATE
--target=wasm32-unknown-unknown-wasm # or just =wasm
-nostdlib
-Wl,--no-entry
-Wl,--allow-undefined
-Wl,--gc-sections
-Wl,--strip-all

# Exports
-Wl,--export=event
-Wl,--export=init
-Wl,--export=loaded
-Wl,--export=unloading

# Memory Management
-Wl,--import-memory # Host provides the memory
-Wl,--initial-memory=65536 # Request 2 pages (required for standard compliance)
-Wl,--max-memory=65536 # Cap it at 2 pages
-Wl,-z,stack-size=512 # Shrink WASM-internal stack (Default is often 64KB!)
)

add_custom_command(
TARGET io_dio1 POST_BUILD
COMMAND xxd -i -n io_dio1 ${CMAKE_BINARY_DIR}/io_dio1/io_dio1.wasm | sed 's/unsigned /const unsigned /' >${CMAKE_BINARY_DIR}/io_dio1.h
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating io_dio1.h from io_dio1.wasm using xxd"
)

= Memory Allocations =
This was an investigation into how much RAM is used to instantiate WebAssembly runtimes. 8 wasm files were deployed, each blinking the LED for the respective slot.

---- Program to be loaded ----

#include "colibri.h"
#define export __attribute__((visibility("default")))

static int next = 0;
static int state = 0;

int tick(long time) {
if (next < time) {
if (state){
set_rgb_error();
next = time + 100;
}
else {
set_rgb_off();
next = time + 500;
}
}
return state;
}

export void event(int id, long value) {
tick(value);
}

export void init() {
set_rgb_ok_color(0x000400);
set_rgb_warning_color(0x040400);
set_rgb_error_color(0x080000);
}

export void loaded() {
set_rgb_off();
}

export void unloading() {
set_rgb_off();
}

Env Heap @ 0x10000000 112 bytes
wasm0 Heap @ 0x10000070 4960 bytes
wasm1 Heap @ 0x100013D0 4368 bytes
wasm2 Heap @ 0x100024E0 4368 bytes
wasm3 Heap @ 0x100035f0 4368 bytes
wasm4 Heap @ 0x10004700 4608 bytes
wasm5 Heap @ 0x10005900 4368 bytes
wasm6 Heap @ 0x10006a10 4368 bytes
wasm7 Heap @ 0x10007b20 5200 bytes
End Heap @ 0x10008F70

----- Once -----
NewEnvironment
M3Environment struct 0x20
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09

----- Per wasm ---

NewRuntime
M3Runtime struct 0x434
runtime->origStack 0x410 (stack + 4 32bit words)

ParseModule
M3Module module 0x78
io_module->functTypes 0x0c
AllocFuncType 0x08
Free
AllocFuncType 0x09
Free
AllocFuncType 0x0A
Free
PreAllocFunctions 0x154 (5 functions * 68 bytes?)
"env" 0x04
"memory" 0x07
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_off" 0x0C
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_ok_color" 0x11
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_warning_color" 0x16
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_error_color" 0x14
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
PreAllocFunctions 0x220
AddGlobal 0x20
"event" 0x06 (exports)
Free NULL (exported name)
"init" 0x05
Free NULL (exported name)
"loaded" 0x07
Free NULL (exported name)
"unloading" 0x0A
Free NULL (exported name)
Free NULL (one extra exported name)
M3DataSegments 0x20 (0 data segment)

LoadModule
NewCodePage 0x40
Free NULL
Free NULL
Free NULL
Free NULL
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x08 ("event")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x12 ("init")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x14

Colibri WebAssembly Notes

2026-05-06T05:04:09Z

Niclas:

Various notes, investigations and other useful information that might be needed later.

= CMake for I/O drivers =
It is crucial that the wasm binary is stripped of all meta data. This is an example of a reasonable <code>CMakeLists.txt</code> for the [[Colibri DIO1]] module.

cmake_minimum_required(VERSION 3.5)
set(CMAKE_LINK_DEPENDS_USE_LINKER FALSE)
project(io_dio1 C)

set(CMAKE_C_STANDARD 11)
set(CMAKE_C_COMPILER clang)

include_directories(colibri-sdk/)

add_executable(io_dio1 dio1.c)
set_target_properties(io_dio1 PROPERTIES SUFFIX ".wasm")

target_compile_options(io_dio1 PRIVATE
--target=wasm32
-Oz
-ffunction-sections
-fdata-sections
)

target_link_options(io_dio1 PRIVATE
--target=wasm32-unknown-unknown-wasm # or just =wasm
-nostdlib
-Wl,--no-entry
-Wl,--allow-undefined
-Wl,--gc-sections
-Wl,--strip-all

# Exports
-Wl,--export=event
-Wl,--export=init
-Wl,--export=loaded
-Wl,--export=unloading

# Memory Management
-Wl,--import-memory # Host provides the memory
-Wl,--initial-memory=65536 # Request 2 pages (required for standard compliance)
-Wl,--max-memory=65536 # Cap it at 2 pages
-Wl,-z,stack-size=512 # Shrink WASM-internal stack (Default is often 64KB!)
)

add_custom_command(
TARGET io_dio1 POST_BUILD
COMMAND xxd -i -n io_dio1 ${CMAKE_BINARY_DIR}/io_dio1/io_dio1.wasm | sed 's/unsigned /const unsigned /' >${CMAKE_BINARY_DIR}/io_dio1.h
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating io_dio1.h from io_dio1.wasm using xxd"
)

= Memory Allocations =
This was an investigation into how much RAM is used to instantiate WebAssembly runtimes. 8 wasm files were deployed, each blinking the LED for the respective slot.

---- Program to be loaded ----

#include "colibri.h"
#define export __attribute__((visibility("default")))

static int next = 0;
static int state = 0;

int tick(long time) {
if (next < time) {
if (state){
set_rgb_error();
next = time + 100;
}
else {
set_rgb_off();
next = time + 500;
}
}
return state;
}

export void event(int id, long value) {
tick(value);
}

export void init() {
set_rgb_ok_color(0x000400);
set_rgb_warning_color(0x040400);
set_rgb_error_color(0x080000);
}

export void loaded() {
set_rgb_off();
}

export void unloading() {
set_rgb_off();
}

Env Heap @ 0x10000000 112 bytes
wasm0 Heap @ 0x10000070 4960 bytes
wasm1 Heap @ 0x100013D0 4368 bytes
wasm2 Heap @ 0x100024E0 4368 bytes
wasm3 Heap @ 0x100035f0 4368 bytes
wasm4 Heap @ 0x10004700 4608 bytes
wasm5 Heap @ 0x10005900 4368 bytes
wasm6 Heap @ 0x10006a10 4368 bytes
wasm7 Heap @ 0x10007b20 5200 bytes
End Heap @ 0x10008F70

----- Once -----
NewEnvironment
M3Environment struct 0x20
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09

----- Per wasm ---

NewRuntime
M3Runtime struct 0x434
runtime->origStack 0x410 (stack + 4 32bit words)

ParseModule
M3Module module 0x78
io_module->functTypes 0x0c
AllocFuncType 0x08
Free
AllocFuncType 0x09
Free
AllocFuncType 0x0A
Free
PreAllocFunctions 0x154 (5 functions * 68 bytes?)
"env" 0x04
"memory" 0x07
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_off" 0x0C
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_ok_color" 0x11
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_warning_color" 0x16
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_error_color" 0x14
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
PreAllocFunctions 0x220
AddGlobal 0x20
"event" 0x06 (exports)
Free NULL (exported name)
"init" 0x05
Free NULL (exported name)
"loaded" 0x07
Free NULL (exported name)
"unloading" 0x0A
Free NULL (exported name)
Free NULL (one extra exported name)
M3DataSegments 0x20 (0 data segment)

LoadModule
NewCodePage 0x40
Free NULL
Free NULL
Free NULL
Free NULL
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x08 ("event")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x12 ("init")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x14

Colibri WebAssembly Notes

2026-05-06T04:54:38Z

Niclas: Created page with "Various notes, investigations and other useful information that might be needed later. = Meory Allocations = This was an investigation into how much RAM is used to instantia..."

Various notes, investigations and other useful information that might be needed later.

= Meory Allocations =
This was an investigation into how much RAM is used to instantiate WebAssembly runtimes. 8 wasm files were deployed, each blinking the LED for the respective slot.

---- Program to be loaded ----

#include "colibri.h"
#define export __attribute__((visibility("default")))

static int next = 0;
static int state = 0;

int tick(long time) {
if (next < time) {
if (state){
set_rgb_error();
next = time + 100;
}
else {
set_rgb_off();
next = time + 500;
}
}
return state;
}

export void event(int id, long value) {
tick(value);
}

export void init() {
set_rgb_ok_color(0x000400);
set_rgb_warning_color(0x040400);
set_rgb_error_color(0x080000);
}

export void loaded() {
set_rgb_off();
}

export void unloading() {
set_rgb_off();
}

Env Heap @ 0x10000000 112 bytes
wasm0 Heap @ 0x10000070 4960 bytes
wasm1 Heap @ 0x100013D0 4368 bytes
wasm2 Heap @ 0x100024E0 4368 bytes
wasm3 Heap @ 0x100035f0 4368 bytes
wasm4 Heap @ 0x10004700 4608 bytes
wasm5 Heap @ 0x10005900 4368 bytes
wasm6 Heap @ 0x10006a10 4368 bytes
wasm7 Heap @ 0x10007b20 5200 bytes
End Heap @ 0x10008F70

----- Once -----
NewEnvironment
M3Environment struct 0x20
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09
AllocFuncType 0x09

----- Per wasm ---

NewRuntime
M3Runtime struct 0x434
runtime->origStack 0x410 (stack + 4 32bit words)

ParseModule
M3Module module 0x78
io_module->functTypes 0x0c
AllocFuncType 0x08
Free
AllocFuncType 0x09
Free
AllocFuncType 0x0A
Free
PreAllocFunctions 0x154 (5 functions * 68 bytes?)
"env" 0x04
"memory" 0x07
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_off" 0x0C
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_ok_color" 0x11
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_warning_color" 0x16
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
"env" 0x04
"set_rgb_error_color" 0x14
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
Free NULL (freeing import, module name)
Free NULL (freeing import, field name)
PreAllocFunctions 0x220
AddGlobal 0x20
"event" 0x06 (exports)
Free NULL (exported name)
"init" 0x05
Free NULL (exported name)
"loaded" 0x07
Free NULL (exported name)
"unloading" 0x0A
Free NULL (exported name)
Free NULL (one extra exported name)
M3DataSegments 0x20 (0 data segment)

LoadModule
NewCodePage 0x40
Free NULL
Free NULL
Free NULL
Free NULL
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
AllocFuncType 0x09
Free
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x08 ("event")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x12 ("init")
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
NewCodePage 0x40
CompileFunction 0x14

Colibri Runtime

2026-05-06T04:49:46Z

Niclas: Created page with "The Colibri Runtime is the custom firmware that is running on Colibri MCUs, an application in Colibri Zephyr orchestrating the hardware resources, WebAssembly engines with..."

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]