Klipper Hardware Requirements: SBC, MCU, and Sensors

Klipper’s hardware list looks short until you try to buy it. The project documentation asks for a host computer, a supported microcontroller, and a way for the two to talk, then leaves the shopping to you. That gap is where most first installs go wrong: a control board whose chip Klipper does not build firmware for, an accelerometer with nowhere to plug in, or a host supply that browns out three hours into a print.

What follows is a parts-by-parts reading of what each component has to do, drawn from Klipper’s own installation and configuration documentation rather than from any particular build.

Klipper Splits the Job Across Two Machines

Klipper runs the kinematics and motion planning on a general purpose Linux host and sends precomputed step timings to the printer’s microcontroller, which does nothing but execute them at the right moments. That division is the reason the hardware list has two halves, and it is worth understanding before buying anything. The mechanics of the split are covered in Klipper firmware architecture and input shaper tuning.

The practical consequence: the host needs to be a real computer with a real operating system, and the control board needs to be a chip Klipper has a firmware target for. Neither substitutes for the other.

The Host Computer

Compute. The host runs an iterative solver and generates step schedules ahead of the print head, so it does continuous floating point work. Klipper’s installation guide is written around a Raspberry Pi running a Debian based image, and the project also documents running the host software on other Linux machines. A Raspberry Pi 3B+ or newer is comfortable. A Pi Zero 2 W will run Klipper but leaves little headroom once a web frontend, a camera stream, and a timelapse plugin are competing for the same cores.

Alternatives that are common in practice: Rockchip and Allwinner single board computers, the compute modules that drop directly into some control boards, or a retired mini PC or laptop running Debian. Klipper does not care which, so long as it is Linux and it stays up.

Storage. The most frequent host failure is not compute, it is a worn microSD card. Klipper writes logs continuously, and a cheap card in a machine that never gets cleanly shut down has a short life. Two mitigations are worth the effort up front: boot from a USB SSD if the board supports it, and keep printer.cfg in version control so a dead card costs an evening rather than a tuning campaign.

Power. The host needs its own clean 5V supply sized for the board, not a tap off whatever 5V rail the control board happens to expose. Undervoltage on a Pi shows up as filesystem corruption and mid-print host crashes, and it is easy to misdiagnose as a Klipper problem because the symptom is a lost connection to the microcontroller.

The Control Board

Two questions decide whether an existing board works. First, does Klipper build firmware for its chip? Klipper’s make menuconfig architecture list is the authority here, and it covers 8-bit AVR parts, a broad range of ARM Cortex-M families including STM32, LPC176x, SAM and RP2040, plus a “Linux process” target that turns the host itself into a limited microcontroller. Second, can you get the board into its bootloader to flash it? That is a board-specific question about jumpers, buttons, and whether the vendor left a DFU path intact.

How the board talks to the host. Three options, in increasing order of effort:

• USB serial. One cable, works everywhere, and the default in most guides.
• UART on the GPIO header. Frees a USB port and avoids USB enumeration races on boot, at the cost of disabling the host’s serial console.
• CAN bus. The reason to bother is toolhead wiring, covered below.

Stepper drivers. Klipper can drive plain step/dir modules, but TMC drivers wired for UART or SPI control unlock the features people actually want from Klipper: runtime current setting, stealthChop and spreadCycle switching, driver diagnostics, and sensorless homing on axes that support it. A board with drivers hardwired in standalone mode limits what the configuration can reach.

The Accelerometer

Resonance measurement is the feature that most justifies running Klipper, and it needs a sensor. Klipper’s resonance documentation supports several chips, with the ADXL345 as the reference part and MPU-9250 family, LIS2DW, and ICM-20948 devices also documented. Any of them will find the peaks; the ADXL345 simply has the most written about it.

Where it plugs in. Three usual paths: SPI to the host’s own GPIO header, using Klipper’s Linux process microcontroller so the host can read the chip directly; SPI to a spare header on the main control board; or onto a CAN toolhead board that already carries an accelerometer footprint. The first is the cheapest to try because it needs no free pins on the printer’s board.

Mounting matters more than the part. The sensor has to be rigidly attached to the mass whose resonance you want to measure. A dangling sensor on a soft mount measures the mount. Machines with a bed that moves in Y need a second measurement position on the bed, not just the toolhead.

Host software. The analysis scripts need numpy and matplotlib installed on the host. This trips people up because the wiring is finished and the sensor answers queries, but the calibration script exits on an import error. The full procedure, including the commands and the failure modes, is in Klipper input shaper setup with an ADXL345.

An accelerometer is also a tool you can borrow rather than own. Once the shaper values are saved, the sensor does nothing until the moving mass or frame stiffness changes.

CAN Bus Toolheads

A CAN toolhead replaces a thick umbilical of individual wires with power plus a twisted pair. On a fast CoreXY that drag is real, and it is the main reason to take on the extra complexity. Klipper’s CAN documentation sets out the requirements plainly:

• A CAN interface at the host end. Either a dedicated adapter, or a supported microcontroller running in CAN bridge mode so a single USB cable carries the bus.
• A toolhead board with a CAN transceiver.
• 120 ohm termination at the two physical ends of the bus, and only there. Extra terminators are a common cause of intermittent faults.
• One bitrate, matched on every node and in every config file.

Each node is addressed by a UUID that you discover with Klipper’s query script before writing it into the configuration. On a bed slinger with a short cable run, none of this pays for itself.

The Software Stack

Klipper alone has no user interface. The working set is three pieces: Klipper itself (host process plus microcontroller firmware), Moonraker as the API server, and either Mainsail or Fluidd as the browser front end. Prebuilt images ship all three together. On a plain Debian install, the community installer scripts pull and update the set. A physical touchscreen is an optional fourth piece and is not required to print.

Three Sensible Build Tiers

Tier	Host	Control board	Accelerometer	What it buys you
Reuse what you have	Any Pi 3B+ class SBC	Existing board, if Klipper builds for its chip	Borrowed, on host SPI	Full motion feature set, pressure advance, input shaping, macros. Zero board spend.
Mainstream upgrade	Pi 4 or equivalent, SSD boot	32-bit board with UART or SPI TMC drivers	Owned, on the board’s SPI header	Sensorless homing, driver diagnostics, headroom for a camera and web UI.
CAN toolhead	Pi 4 or equivalent, SSD boot	Main board plus CAN toolhead board	On the toolhead board	Thin umbilical, fewer wires to fatigue, sensor permanently mounted where it should be.

Nothing above the first tier improves print quality on its own. Belts, frame rigidity, and extruder calibration set the ceiling; the electronics only decide how much of that ceiling the firmware can reach.

What You Do Not Need

• A new printer. Klipper’s value is mostly in motion planning, and that applies to an old machine as readily as a new one.
• A 32-bit board, if your 8-bit one is supported. Step timings are computed on the host, so an ATmega is not doing the hard work. The real limits on an old board are available pins and maximum step rate.
• A touchscreen. Convenient, not required.
• Better drivers before better mechanics. Resonance compensation reduces the visible effect of vibration; it does not fix a loose belt.

Build Order

1. Confirm Klipper builds firmware for your control board’s chip, and confirm you can reach its bootloader.
2. Get the host running Linux, on storage you trust, with a supply that holds 5V under load.
3. Install Klipper, Moonraker, and a web front end. Flash the board from the same source tree as the host, and reflash it whenever you update the host, or the front end will keep reporting a version mismatch.
4. Verify kinematics and motor directions before anything else. A mirrored axis invalidates every measurement that follows.
5. Calibrate rotation distance and extruder flow.
6. Tune pressure advance.
7. Wire the accelerometer, measure resonance, and set the shaper. Use the input shaper and acceleration sizer to sanity-check what a given resonant frequency implies for acceleration before you commit a value.

If you are still deciding whether the project is worth it at all, Klipper vs Marlin compares the two firmware options on architecture, configuration workflow, and what each one costs you in hardware and attention.