// 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()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.
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.
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.
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.
#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
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.
02
Simulator
Virtual controls and displays in the SDK stand in for hardware your computer does not have.
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.
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
Implemented and tuned to use as few resources as possible.
APPLE FRAMEWORK WRAPPERS
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
// build on exos

