# MuditaOS: a FreeRTOS mobile operating system for e ink phones > MuditaOS is a C operating system built on FreeRTOS for e ink devices, developed for the Mudita Pure minimalist phone, organised as a set of modules, and buildable either for the RT1051 hardware target or for a Linux host simulator. **mudita/MuditaOS** — Mobile operating system based on FreeRTOS™ optimized for E Ink displays - developed for Mudita Pure minimalist phone - Repository: https://github.com/mudita/MuditaOS - Website: https://mudita.com/products/pure/muditaos - Stars: 949 · Forks: 114 - Language: C - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mudita-muditaos ## An operating system shaped by one screen and one phone MuditaOS is described as a mobile operating system optimized for E Ink displays, built on FreeRTOS with the Mudita Pure minimalist phone in mind. That single sentence sets the scope of the whole project. FreeRTOS is a real-time kernel, not an operating system in the general-purpose sense, so what MuditaOS adds on top of it is the interesting part: the layers you would otherwise have to write for a connected device with a display, telephony and persistent storage. The repository layout shows that structure plainly. There is a `module-os/` for the operating system core, then `module-gui/`, `module-apps/`, `module-audio/`, `module-bluetooth/`, `module-cellular/`, `module-db/`, `module-vfs/`, `module-services/`, `module-sys/`, `module-utils/`, `module-bsp/` and `module-platform/`. That list is a summary of the product. A cellular module, a Bluetooth module, a database, a virtual filesystem, a GUI and a services layer are the pieces of a phone, not of a general embedded product. The GUI is where the e ink constraint shows: every screen redraw is slow and visible, so a GUI designed for a phone's display does not transfer. The audience is therefore narrow and specific: developers building phone-like software for e ink hardware, and contributors to the Mudita Pure product itself. The primary language is C, the topics recorded for the repository include e-ink, embedded-c, embedded-systems, freertos and mobile, and the source tree is organised for a large multi-module system rather than a single application. ## Two shipping products share one operating system The README states that there are two released products based on MuditaOS. The first is the PurePhone, a low distraction phone whose key features are documented in `products/PurePhone/ProductKeyFeatures.md`. The second is Mudita Harmony, described as an eink based distraction free alarm clock. Sharing an OS between a phone and an alarm clock is a constraint, not a convenience. The `products/` directory at the repository root is where the per-product composition lives, and the fact that the tree carries separate product configuration and separate changelogs, `pure_changelog.md` and `harmony_changelog.md`, shows that product differentiation happens at the configuration and release level rather than by forking the tree. That layout has a practical consequence for anyone evaluating the project. The two changelogs are the closest thing to a release history, and they are separate files at the repository root. The Pure changelog describes releases of the Pure's version of the OS, and the Harmony changelog does the same for Harmony. So the project is not a general mobile platform. It is the software behind two specific devices from one vendor, and the public repository is the development tree for that hardware. That is still valuable, but it changes what you are adopting. ## Build targets split between RT1051 hardware and a Linux host The build system is CMake with a per-target structure at the root of the repository. `Target_Linux.cmake` and `Target_RT1051.cmake` are the two obvious entry points, and the presence of `MIMXRT1052.svd` tells you what the hardware target is: an NXP RT1051 class MCU, with the SVD file there so debuggers can read the peripheral registers. The Linux target is the one that matters for day-to-day development, because it means the OS can be built and run on a desktop. Two scripts at the root support that: `run_release_simulator_on_image.sh` and `run.sh`. A simulator workflow changes the cost of iteration enormously, since you can exercise the GUI, the services layer and the applications without reflashing hardware. Hardware-level work has its own tooling. `StartJLinkServer.sh` and `OzoneJlink.jdebug` are for J-Link debugging, the `.gdbinit` family of files (including `.gdbinit-1051` and `.gdbinit_mati`) sets up GDB sessions against the target, and `flash_emmc_experimental_littlefs.sh` flashes an experimental littlefs image to eMMC. The word experimental is in the filename, which is a reasonable hint about how much to trust that path on a day when the phone will not boot. The containerised build is the other half of the story. The repository has a `docker/` directory, a `build_all_dockers.sh` script and an `in_docker.sh` script, and a `Jenkinsfile` at the root for continuous integration. A C project of this size with more than a dozen modules is exactly the kind of codebase that stops being buildable on a laptop without a hermetic toolchain. ## Contributing means reading four documents before you write code The contribution path is documented, which is unusual and useful for a project of this size. Pull requests are welcome, and the guidelines live in `CONTRIBUTING.md`. Before contributing or starting a discussion, the README asks that you read the `CODE_OF_CONDUCT.md`. Architecture questions and bugs have designated homes. Bugs and feature requests go on GitHub issues, and the README notes this is also a good place to discuss architecture decisions and things that are not yet covered by the documentation. General questions and ideas go to the Mudita Forum, in the MuditaOS section, and you are asked to check existing posts first so the same question is not asked twice. The workflow itself is spelled out in `doc/development_workflow.md`, and the environment setup guide is at `doc/quickstart.md` with a Quickstart section. Localisation has its own guide, `doc/i18n.md`, and the entry point for everything else is `doc/README.md`. A fully detailed documentation set can be built locally using Doxygen. The split of responsibilities is worth noting: a product changelog per device, a workflow guide, an environment guide, an internationalisation guide and a Doxygen build. For a project with no GitHub releases and a last push on 2026-06-13, the documentation is doing a lot of the work that release notes would otherwise do, and it is where a prospective contributor should start reading. ## Where the project is not a good fit There are several honest limits to what MuditaOS is, and they follow from the hardware and the product focus. First, the code is organised around a specific MCU family. The `board/` directory, the RT1051 target file, the J-Link scripts and the SVD all point one way. Adapting MuditaOS to a different e ink board means writing board support in `module-bsp/` and the platform layer, and that work is not documented in the README. Second, this is a phone operating system with a small display, not a general-purpose one. The feature set is what the Pure needs. If your product idea needs a browser, a video pipeline or a rich text editor, the e ink screen and the FreeRTOS scheduling model are both fighting you, and the README gives no indication that those use cases are supported. Third, the licensing. The licensing section states that MuditaOS is licensed under GNU GPLv3, and the licence field on the repository says it is a custom licence that GitHub cannot classify, with `LICENSE.md` at the repository root. A commercial product that cannot distribute GPLv3 source has to have a different plan, and the README does not describe a commercial licence option for MuditaOS the way some other vendor projects do. This is not legal advice; read `LICENSE.md` and have it reviewed. Finally, the maintenance signal is thin. The repository is not archived and the last push was on 2026-06-13, but there are no GitHub releases, so there is no tag, no release note and no upgrade path to follow. Adopting a tree like this means tracking a branch and reading the per-product changelog yourself. ## The alternative is a bare RTOS with a hand-built application layer The realistic alternative to MuditaOS is not another phone operating system, it is starting from the real-time kernel and writing the phone-like layers yourself. That approach gives you exactly the modules MuditaOS provides, in a shape you control. You get the GUI, the services, the database, the filesystem and the telephony stack, but you write them, and you decide how much of the abstraction layer you actually need. For a device that is a phone in name only, a single-purpose e ink appliance, this can be the better trade: you pay for only the parts you use. The difference in approach is architectural rather than feature-level. MuditaOS is a layered system with a services framework, a database, a virtual filesystem and a GUI that all assume phone-like semantics, developed against a real shipping product, which means the edge cases of a phone are already solved. Starting from the kernel means solving them, and the cost of solving them scales with how phone-like your device turns out to be. A third option sits inside MuditaOS itself: the Linux target and the simulator scripts let you develop most of the application layer on a desktop, with the RT1051 target reserved for the parts that need real hardware. That is the cheapest way to evaluate whether the module design fits your product before committing to the porting work, and it is the first thing to try. ## Conclusion MuditaOS makes sense for a team that is building phone-like software for e ink hardware and wants a FreeRTOS based system with phone concepts already modelled, rather than a bare real-time kernel plus a custom application framework. It is the wrong choice for a general phone or tablet product, for a project without RT1051 class hardware, and for a closed-source product, because the licensing section states GNU GPLv3. Before starting, read doc/quickstart.md and the per-product changelogs to see whether the Pure feature set you need exists, and check the last push, which was on 2026-06-13, against your own schedule. The repository has no GitHub releases, so there is no tag to pin to and the Pure changelog is where version history lives. ## FAQ ### What is MuditaOS built on? MuditaOS is a mobile operating system written in C and built on FreeRTOS, optimized for E Ink displays and developed with the Mudita Pure minimalist phone in mind. ### How do I set up a MuditaOS development environment? The README points contributors to the environment setup guide at doc/quickstart.md, with a Quickstart section, and to doc/README.md for the full documentation entry point. The build is CMake based, with Target_Linux.cmake and Target_RT1051.cmake at the repository root. ### Which products run MuditaOS? Two released products: the PurePhone, a low distraction phone, and Mudita Harmony, an eink based distraction free alarm clock. Each has its own changelog, pure_changelog.md and harmony_changelog.md. ### What license is MuditaOS released under? The licensing section states GNU GPLv3, while the licence field on the repository says it is a custom licence that GitHub cannot classify, and the LICENSE.md file sits at the repository root. ### Can I run MuditaOS without the Mudita phone hardware? The repository ships a Linux build target, Target_Linux.cmake, together with run.sh and run_release_simulator_on_image.sh, which together with the docker directory and build_all_dockers.sh provide a host based development path. ## Sources - [Issues](https://github.com/mudita/MuditaOS/issues) - [mudita/MuditaOS on GitHub](https://github.com/mudita/MuditaOS) - [Project website](https://mudita.com/products/pure/muditaos) - [README](https://github.com/mudita/MuditaOS/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mudita-muditaos