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.

I like tools that stay out of the way and are easy to inspect when something breaks. That is what pulled me toward Neovim in the first place, and at this point it has become the setup I reach for everywhere.

Neovim

Vim-style editing looks hostile at first, but once it clicks it is hard to go back. Moving around code, editing text, and jumping between files without leaving the keyboard feels much faster than the usual IDE workflow. Running inside a terminal also keeps the whole thing lightweight and responsive.

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.

I wanted a place to write down project notes without depending on Medium, Notion, or some other hosted platform. Most of my side projects already live on GitHub, so a simple static site felt like the right fit.

Why Hugo

Hugo is fast, simple, and close to the metal. It is written in Go and uses the standard html/template and text/template packages, so the whole system is straightforward once you look at a couple of templates.