The problem was not unusual. I needed to send small state and command messages between C++, Rust, and Python processes at around 500 Hz. I wanted clear interfaces, reasonable latency, and a system that could be built and deployed without much ceremony.

That should have been a normal software-engineering problem.

Instead, it immediately turned into a discussion about DDS implementations, QoS profiles, executors, callback groups, ROS distributions, Ubuntu versions, message packages, ament, colcon, rosdep, workspace overlays, setup scripts, and Docker images.

When I first wrote about Eerie, it was still mostly an experiment. The goal was to build Rust bindings around IREE and see whether the compiler/runtime stack could fit naturally into a Rust project.

FFI calls compiling only proved that the C API was reachable from Rust. The harder part was deciding which parts should become safe Rust APIs and which parts should stay behind an unsafe boundary.

Eerie v0.5 is a checkpoint for that design. It is not complete, and I still expect the API to change. The main boundaries are clearer now: where Rust owns the abstraction, where IREE owns global state, and where the unsafe parts need to stay contained.

Most motor-control codebases are glued directly to one MCU, one timer layout, one ADC scheme, and one bring-up sequence. That is fine until you want to change boards, add a calibration routine, or test a controller without touching hardware. Then everything is entangled at once: control law, interrupt ownership, sampling timing, logging, board support, and whatever half-finished bench setup you currently have.

Fluxkit is my attempt to attack that problem directly. It is a no_std Rust toolkit for BLDC / PMSM field-oriented control that tries to keep the control stack portable, testable, and explicit about ownership. The core library covers the pieces I actually care about in real actuator projects: current loop, velocity loop, position loop, open-loop voltage mode, calibration routines, actuator-side friction compensation, and a narrow HAL surface for hardware integration.

In robotics, simulation usually starts long before the hardware is finished. A lot of those early parts are 3D-printed, and in practice they often get dropped into URDF or SDF files with guessed mass properties or no mass properties at all.

That shortcut is fine until it is not. Bad estimates for mass, center of mass (COM), and inertia can show up as:

• unstable controllers that seem correct in simulation,
• mis‑tuned balance algorithms in legged or mobile platforms,
• gripper payload limits that differ from reality.

That was the motivation for PrintDynamic, a small Rust-to-WASM tool that parses G-code and estimates the actual dynamic properties of an extruded part.

Getting Eerie Running on #![no_std]

I started adding #![no_std] support to Eerie expecting the usual embedded cleanup work. Instead, most of the time went into linker issues and missing C runtime pieces that desktop targets quietly provide for you.

First blocker: linker errors

The first real problem showed up when linking Rust and C code on an embedded target. The error looked like this:

rust-lld: error: undefined symbol: ceilf
>>> referenced by ops.h:551 (/Users/gmmyung/Developer/eerie/iree-sys/iree/runtime/src/iree/vm/ops.h:551)
>>> dispatch.c.obj:(vm_ceil_f32) in archive /Users/gmmyung/Developer/eerie-embedded/target/thumbv7em-none-eabihf/debug/build/iree-sys-a5c1d2279731491b/out/runtime_build/build
/lib/libiree.a
>>> referenced by elementwise.c:173 (/Users/gmmyung/Developer/eerie/iree-sys/iree/runtime
/src/iree/modules/vmvx/elementwise.c:173)
>>> elementwise.c.obj:(iree_uk_generic_x32u_op) in archive /Users/gmmyung/Developer/eerie-embedded/target/thumbv7em-none-eabihf/debug/build/iree-sys-a5c1d2279731491b/out/runtime_build/build/lib/libiree.a

This was a libm problem. On non-embedded targets, a lot of this gets pulled in for free. On bare metal, it does not.

Where this came from

While working on Eerie, I ran into a C API that lets the caller pass in an allocator:

// Creates a new session forced to use the given |device|.
// This bypasses any device enumeration performed by the loaded modules but
// the loaded modules will still verify that the device matches their
// requirements.
//
// A base set of modules may be added by the runtime during creation based on
// |options| and users may load additional modules - such as the one containing
// their user code - by using the iree_vm_context_t provided by
// iree_runtime_session_context.
//
// |host_allocator| will be used to allocate the session and any associated
// resources. |out_session| must be released by the caller.
IREE_API_EXPORT iree_status_t iree_runtime_session_create_with_device(
    iree_runtime_instance_t* instance,
    const iree_runtime_session_options_t* options, iree_hal_device_t* device,
    iree_allocator_t host_allocator, iree_runtime_session_t** out_session);

At first glance, the obvious answer is to hand it the default C allocator:

What is Eerie?

Eerie is a Rust binding for IREE, a compiler and runtime stack built on MLIR. The short version is that you can take models from frameworks like PyTorch, TensorFlow, or JAX, lower them through MLIR, compile them with IREE, and run the result through a fairly small runtime.

If you are not deep into ML compiler tooling, IREE is worth thinking of as infrastructure rather than a framework. It gives you a way to move from model code to something that can actually run on the target you care about.