Frequently Asked Questions

By “machine”, we mean any device that has software logic in it and is not a conventional, general-purpose computer. When it comes to general-purpose computers—servers, desktops, laptops, and mobile devices—the software ecosystem is a solved problem: between Windows, Unix variants, macOS, iOS, and Android, there is stable equilibrium. However, this category accounts for only a small fraction of microprocessor use.

The majority of microprocessors run specific-purpose software within machines in various domains: Automotive, Consumer Electronics/IoTs, Industrial, Medical, Robotics, Aerospace, and so on. osdyne’s focus is these machines, for which it aims to provide a universal, unified software ecosystem.

Rust is the only modern programming language that is both safe and suitable for real-time systems. It eliminates an estimated 70% of security bugs through memory safety, type safety, and concurrency safety—without runtime overhead.

Microsoft is rewriting Windows internals in Rust. Google uses it in Android and Chrome. It’s in the Linux kernel. The NSA recommends it for memory-safe development. For nine consecutive years, Rust has been voted the most admired programming language in Stack Overflow’s developer survey.

osdyne isn’t just a conventional system re-implemented in Rust—we designed it from scratch to benefit architecturally in ways that are only possible with Rust.

Every “machine” is fundamentally the same: there are inputs (e.g. sensors), there is some logic that needs to be processed, and there are outputs (e.g. actuators). Whether you’re building a coffee machine, a robot, an EKG machine, or a car, you need low-level primitives like threads, synchronization, and fault isolation, and depending on the machine, higher-level features like networking, storage, cryptography, and so on. A well-designed architecture with rich, composable building blocks allows our unified platform to scale and span across industries without compromises.

What really differs between machines/industries is the application logic on top. osdyne provides the universal foundation and even industry-specific libraries; you build the machine-specific parts. The same isolation model that protects a medical device protects an industrial controller. The same networking stack that connects a consumer appliance connects a vehicle gateway.

The philosophy is the same as a platform like iOS or Android being an excellent host for a virtually limitless spectrum of applications.

osdyne is a complete ecosystem—OS, drivers, libraries, tools, cloud, component store—all integrated and designed to work together. The development philosophy is akin to a modern, mainstream, state-of-the art software platform: think iOS and Android.

Typical existing RTOSes give you scheduling and synchronization—you build everything else yourself. Need a filesystem or a TCP/IP stack? Call companies, sign NDAs, receive C tarballs, spend days integrating. Development feels like a highly-constrained gotcha-ridden test meant to exhaust developer bandwidth and patience. You unnecessarily have to deal with interrupt handlers, exception contexts, and MISRA-C subsets. Tooling is often decades old: ancient IDEs, debugging dongles, board support tarballs, or worse, having to stitch together your own toolchain.

There are other valuable Rust projects, but they have narrower scopes: some are cooperative-only, some lack real-time guarantees, some have very limited hardware support. osdyne provides hard real-time guarantees, broad hardware support, and fault isolation without requiring an MPU/MMU—with an integrated VS Code-based IDE, emulator, and visual editors to maximize developer efficiency in line with the best-case modern-day development methodologies.

osdyne supports ARM Cortex-M (M0 through M55), Cortex-R (R4, R5, R52), Cortex-A (AArch64), Intel x86_64, and RISC-V (RV32 and RV64).

Currently supported MCU families include STM32 (most series), Stellar SR6, NXP i.MX RT, TI TMS570, Nordic nRF52, Espressif ESP32-C3/C6/P4, and Raspberry Pi RP2040/RP2350. The same application code runs across all supported architectures with simple recompilation.

osdyne’s architecture is inherently portable—adding new MCU families requires minimal effort. Contact us to discuss support for new hardware—we can also enable you to do the porting yourself.

Just configuration files! Your application code doesn’t change! osdyne abstracts the hardware differences. As long as drivers exist for your peripherals on both targets, switching is a recompile.

We’ve invested heavily in developer tooling to make this seamless. Visual editors in the IDE let you configure clocks and pin assignments graphically—no manual register programming or datasheet diving. Select your target MCU from a dropdown, and the tooling handles the rest.

Supporting multiple MCUs from a single codebase is invaluable when you’re migrating a product to a new architecture/chipset/vendor while continuing to ship updates for devices already in the field.

osdyne achieves software-based fault isolation through Rust’s compile-time guarantees—memory safety, type safety, and concurrency safety—combined with our domain architecture.

Applications run in software-isolated domains. A crash or fault in one domain cannot affect others. The kernel enforces spatial isolation between domains. Domains can recover and restart independently, even preserving state when needed.

This gives you microkernel-like safety without the runtime overhead and without requiring MMU or MPU hardware.

When MPU or MMU are available, osdyne can also use them for an additional layer of protection. This is essential for workloads that integrate C codebases, where hardware-enforced isolation is the only way to guarantee fault containment.

Usually not. osdyne provides drivers for supported MCUs and common peripherals. External components like sensors, displays, and motor controllers are covered by our growing ecosystem and the osdyne Component Store.

When you do need a custom driver, you write it in high-level Rust against well-defined traits—no interrupt handlers, no exception contexts, no register bit-twiddling. Driver development feels like modern application development.

osdyne includes a VS Code-based IDE with full debugging support: breakpoints, single-stepping, watchpoints, variable inspection, and tracing.

You can develop and debug entirely without physical hardware using our custom ARM and RISC-V emulators. When you’re ready for hardware, the IDE auto-detects connected devices and flashes your code for seamless iteration. All debugging features work identically on both.

No expensive external debugger hardware is required. We support common debug probes including CMSIS-DAP, ST-Link (built into most STM32 development boards), J-Link, and ESP32’s built-in USB JTAG.

The IDE runs on Windows, macOS, and Linux.

It can restart without taking down the rest of the system.

osdyne lets you isolate components (services) into separate domains. A crash in one domain doesn’t affect others: the failing domain recovers independently, even preserving state when needed. How much isolation you configure depends on your system: on resource-constrained devices, you might group services together; on larger systems, you can isolate more aggressively.

Yes. osdyne is a clean-slate architecture, envisioned and designed specifically for the needs of machines. It’s architected for hard real-time systems with priority-based preemptive scheduling and deterministic behavior. The scheduler supports interrupt-free mode for timing-critical operations: bit-banging, precise signal generation, or tight control loops.

Timing specifications vary by hardware platform.

We plan to release detailed documentation down the road, but for now, contact us if you need to discuss your target MCU.

osdyne runs on resource-constrained MCUs with as little as 32 KB of flash and RAM.

Yes. osdyne supports symmetric multiprocessing on multi-core MCUs such as the RP2350. Threading and SMP work the way you’d expect. The scheduler supports core pinning for when you need it.

For heterogeneous multi-core systems, you can run multiple osdyne instances—one per core or core cluster—to make the most efficient use of your hardware. This doesn’t change how you write your code: domains are assigned to instances, and cross-instance communication is abstracted by the system just like communication between domains.

We are working on our open source strategy. We plan to make the core OS available under an open source license. Please stay tuned.

Yes. We believe OTA is a platform feature, and not something you should build yourself.

Implementing OTA properly is hard: A/B partitioning, atomic updates, automatic rollback, power-fail recovery, cryptographic signing, secure boot integration, server infrastructure… Getting any of this wrong can brick devices at scale. Most teams either build fragile in-house solutions or stitch together outsourced components that don’t quite fit.

With osdyne, you enable and configure OTA and the platform handles the rest. Secure delivery, verified installation, automatic rollback on failure, and cloud integration are built in.

Memory safety from Rust eliminates ~70% of vulnerabilities at compile time. Domain isolation contains the blast radius if something does go wrong at run time, as a compromised component can’t access other domains.

osdyne also handles supply chain security: automatic SBOM generation, vulnerability tracking for dependencies, and tooling for EU Cyber Resilience Act compliance.

Yes, osdyne supports mixed criticality. osdyne’s domain isolation and real-time scheduler ensure that safety-critical tasks (motor control, sensor monitoring) can never be disrupted by non-critical code (UI, logging, diagnostics), even if the non-critical code crashes.

This lets you consolidate onto one MCU instead of using separate processors for different safety levels, which means simpler hardware, fewer integration headaches, and you can certify each component independently.

osdyne is architected for safety-critical systems. Pre-certification for standards like ISO 26262 (automotive), IEC 61508 (industrial), and IEC 62304 (medical) is on our roadmap.

Domain-based fault isolation is designed to let you certify components independently: each domain is isolated as if running on its own processor.

A unified platform means you certify once: the burden shifts to us. A shared, comprehensively-tested codebase lets you focus on certifying your application logic, not the foundation underneath.

Contact us to discuss your certification requirements.

osdyne is not an AUTOSAR-compliant operating system. However, it’s designed to interoperate with existing AUTOSAR systems. If you have legacy ECUs running AUTOSAR-compliant software, osdyne-based ECUs can communicate with them seamlessly, supporting CAN, LIN, Automotive Ethernet, UDS diagnostics, and AUTOSAR Network Management.

Yes. osdyne supports the Rust standard library surface that’s useful for embedded, so most crates from crates.io just work, and not just no_std crates.

You get the full power of Cargo and the Rust ecosystem: we do not wish for osdyne to be a walled garden.

We also provide the osdyne Component Store, a curated source for commercial and certified packages with support contracts, vulnerability tracking, and compliance metadata.

Experienced C developers typically become productive in Rust within 1–2 months. Familiarity with memory management, pointers, and low-level concepts gives you a head start. The main adjustment is Rust’s ownership model and borrow checker—once that clicks, progress accelerates. For structured learning, Ferrous Systems offers excellent Rust and Embedded Rust training courses.

Beyond the language itself, osdyne’s modern tooling—VS Code-based IDE, integrated debugger, and emulator—makes embedded development accessible to a broader talent pool. Teams can now hire from the wider Rust developer pool rather than competing for scarce embedded C specialists.

Yes. osdyne supports gradual migration. Existing C code and libraries can be integrated via Rust’s FFI—you don’t have to rewrite everything at once. Familiar concepts (threads, semaphores, etc.) map to osdyne equivalents, and comprehensive hardware abstraction means you can start on one MCU and migrate to others.

Contact us for migration assistance.