ExOS

// embedded posix operating system

ExOS: the next-generation OS for microcontrollers. From hardware prototype to commercial product in no time.

// the film · 4:02

Write firmware like software.

The team behind ExOS explains why we built it, and shows the products we build: point-of-sale terminals, a video intercom, drones and the Xkuty electric vehicle.

talk_to_us()
▪ POSIX compatible▪ Hardware independent▪ 3 levels of hardware access▪ Static or dynamic memory▪ Xcode & Visual Studio▪ C · C++ · Objective-C

SEC 01 / why exos

From idea to prototype to product — without starting over.

We have designed our own hardware, and hardware for clients, for more than ten years. The hardest step is always the same: turning an idea into a prototype, and that prototype into a viable commercial product. Every platform we tried forced a trade-off.

ARDUINO / ARCHITECTURE SOFTWARE HARDWARE App Libs Peripherals Micro + simple− not portable− not for commercial products

01 / Easy platforms

Platforms like Arduino are quick to learn, but their own IDEs and libraries tie you to one platform. When you need more power or a cheaper micro for production, the code does not move with you.

LINUX / ARCHITECTURE SOFTWARE HARDWARE App App App POSIX kernel full OS Drivers Peripherals Micro + portable− complicated− expensive hardware

02 / Linux

POSIX and portable, with high-level networking out of the box. But it needs far more power and memory, raises the cost of every unit, and puts the OS between you and each pin of the micro.

EXOS / ARCHITECTURE SOFTWARE HARDWARE App POSIX Drivers Kernel ExOS Peripherals Micro DIRECT ACCESS + portable+ easy+ small hardware

03 / ExOS

The POSIX model and portability of Linux, at the size of a microcontroller kernel — with direct access to the hardware whenever you want it.

Today almost every device talks to a phone or a computer over USB, Wi-Fi or Bluetooth, and many run their own web server. Building that on bare micros is hard. On Linux it is easier, but you pay for it in power, memory and hardware cost, and you still have to write a driver for every resource the OS does not support.

Then there is the toolchain: the app is written in one IDE, the firmware in another, the code is not shared, and debugging on a micro is far more limited than on a computer. We created ExOS to change that, so you can focus on your device, not on learning new tools or testing hardware.

SEC 02 / key features

01

Start without hardware

ExOS is POSIX compatible, so you can write and test your device code on your computer. When it works, build the same code for the real board — a commercial prototype board or one you design.

02

Not tied to any hardware

Multi-platform support is built in. Choose the micro that suits you today, and change it tomorrow without rewriting your code again and again.

03

Static or dynamic memory

Every POSIX call has an ExOS counterpart that takes static memory by reference — essential on micros with tight resources. USB, sockets, threads and the rest work either way, and you can mix both in the same program.

04

Documentation you already know

POSIX is the standard behind Linux and macOS, and the internet is full of tutorials for it. The ExOS SDK adds its own complete documentation and tutorials.

SEC 03 / hardware and os services, all at once

Three levels of hardware access. Mix them freely.

ExOS is POSIX first, but it never locks you out of the hardware. Pick the level each line of code needs — inside the same function.

LEVEL 01

Direct access to the micro

GPIO, memory and registers, with no ExOS layer in between. Best for simple actions like toggling a pin; this code is specific to the micro.

GPIO · REGISTERS · MEMORY

LEVEL 02

Hardware abstraction layer

Multi-platform calls for the micro’s basic peripherals, in a few lines. The layer ExOS itself is built on.

RS232 · CAN · SPI · TIMERS · ADC

LEVEL 03

System services

Complex peripherals and protocol stacks, programmed exactly as on a desktop OS. A TCP server is the same POSIX code you would write on Linux.

SOCKETS · TCP/IP · USB · BLUETOOTH

Real code · LPC177x

A TCP server built with OS services receives a byte, forwards it on the CAN bus through the HAL, and lights an LED by writing the micro’s GPIO register directly while it works. All three levels, a few lines of code.

directHALOS services
#define LED1_MASK (1<<23) int main(){    // Initialize CAN bus through HAL API    hal_can_initialize(0, 250000, CAN_INITF_DISABLE_RETRANSMISSION);     int err;     // Create and set up sockets through OS Services API (dynamic, POSIX)    int server = socket(AF_INET, SOCK_STREAM, 0);    if (server >= 0)    {        struct sockaddr_in local = (struct sockaddr_in)        {            .sin_family = AF_INET,            .sin_addr.s_addr = INADDR_ANY,            .sin_port = htons(23)        };         if (-1 != bind(server, (struct sockaddr *)&local, sizeof(local)) &&            -1 != listen(server, 1))        {            while (1)            {                struct sockaddr_in remote;                socklen_t remote_len;                static unsigned char buffer;                 // Accept connection from network client (OS API)                int fd = accept(server, (struct sockaddr *)&remote, &remote_len);                if (fd == -1) break;                 // Activate GPIO3 pin on an LPC17xx micro (Direct access, no API)                LPC_GPIO3->DIR |= LED1_MASK;                 // Read value (1 byte)                size_t done = read(fd, &buffer, 1);                 // Send the same byte to the CAN bus (HAL API)                CAN_BUFFER data;                data.u8[0] = buffer;                hal_can_send((CAN_EP) { .Id = 0x200, .Bus = 0 }, &data, 1, CANF_PRI_ANY);                 close(fd);                 // Deactivate GPIO3 pin on an LPC17xx micro (Direct access)                LPC_GPIO3->DIR &= ~LED1_MASK;            }        }         err = errno;        close(server);    }}

SEC 04 / one environment

The app and the firmware, in the same project.

Why write the phone or desktop app in Xcode or Visual Studio and then switch to another IDE for the hardware? The ExOS SDK works inside Xcode and Visual Studio, so the application and the device code live in one solution.

Four ways to run and debug

  1. 01

    On your computer

    Code that uses OS services — sockets, serial ports, USB — runs as plain POSIX on your computer, then compiles for the device unchanged.

  2. 02

    Simulator

    Virtual controls and displays in the SDK stand in for hardware your computer does not have.

  3. 03

    Simulator + real board

    In master–slave mode the simulator reads and writes the real board’s peripherals — LEDs, ADC and more — while the logic runs on your computer.

  4. 04

    On the device

    When the hardware cannot be simulated, the IDE runs and debugs directly on the board.

The SDK also includes a board configuration assistant that generates the BSP, even for boards ExOS has never seen.

SEC 05 / libraries, drivers and services

Focus on your idea. The rest is already written.

The full POSIX API — sockets, timers, threads, semaphores, locks, mutexes, queues — plus a static-memory version of every call and extras like an event dispatcher. And when a driver is missing, adding one is straightforward.

USB

Keyboard, mouse, webcams, printers, flash drives, FTDI

File systems

FAT, FAT32, JFS, ext2, NFS

Buses

RS232, RS485, CAN, SPI, I²C

Codecs

NTSC, PAL, MP3, MP4, AMR

Peripherals

Touch screens, ADC

Communication

Bluetooth, Ethernet, Wi-Fi, ZigBee

NETWORK SERVICES

DHCPFTPHTTPSSHBonjourDNS

Implemented and tuned to use as few resources as possible.

APPLE FRAMEWORK WRAPPERS

CoreFoundationCoreNetworkCoreGraphicsCoreBluetooth

Reuse the same high-level C, C++ and Objective-C code from your macOS and iOS apps on the device.

Made for iPhone accessories

iAP built in.

ExOS includes the Apple accessory protocol (iAP) library. Open the protocol like a file, then read from and write to the iPhone, iPad or iPod. This example echoes back everything the iPhone sends.

int main(){    // Open the iAP connection as if it were a serial device    int fd = open("dev/iap/com.miolabs.test_protocol", O_RDWR);     if (fd > 0)    {        char buffer[1024];        // If it's open, read the value sent from the iPhone        int done = read(fd, buffer, sizeof(buffer));        // Write it back to the iPhone        write(fd, buffer, done);         // And close the connection        close(fd);    }}

SEC 06 / development kits

Three boards to start with. Or use your own.

These are the boards we use ourselves to build prototypes quickly. ExOS is not limited to them: any commercial board can run it.

KIT 01

Bluetooth kit

The TinyBLE: a small board with a Bluetooth 4.0 LE chip, expansion I/O, a coin-cell holder and a bus connector. Build iBeacons, remote controls and more.

  • TinyBLE board
  • I/O board: 2 relays, 6 digital/analog inputs, 2 RS232 ports
  • Sensor board: temperature and light

KIT 02

Main kit

A board with a large set of peripherals and a touch LCD, connectable to the Bluetooth kit boards.

  • RS232, RS485, CAN, USB, SPI, I²C
  • Bluetooth LE, Ethernet, Wi-Fi, 3G/GSM
  • Touch LCD and MFi* connector for Apple accessories

KIT 03

Video & audio kit

For intensive work such as video processing: captures and plays audio and video, and talks to the other kits.

  • Hardware compression and decompression
  • OSD support
  • PAL, NTSC and HDMI in/out, Ethernet

* The MFi chip is not included: it requires registration in Apple’s MFi program.

SEC 07 / good to know

Not a desktop OS — on purpose.

ExOS runs one application, not many side by side, and has no windows or general file browsing. It sits midway between programming on top of an OS and programming the bare hardware.

It even runs on Intel x86 machines. That makes sense when a single application needs every core — rendering a 3D scene, for example — because ExOS uses a fraction of the resources of a desktop OS and supports multi-core.

Languages today

CC++Objective-C

SEC 08 / in production

Already shipping in real products.

ExOS has been in development for years and runs in products already on the market — including the Xkuty One electric vehicle, whose firmware we wrote on ExOS.

ExOS development board
Xkuty One electric vehicle

// build on exos

Have a device in mind? We’ll build it with you.