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 kinematics and motion planning on a Linux host and sends scheduled commands to the printer’s microcontroller. The MCU produces step pulses, reads sensors, and controls outputs. That division gives the hardware list two halves; see how Klipper splits work between host and MCU for the architecture behind the requirements.

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. Klipper’s FAQ recommends Raspberry Pi Zero 2 W, Pi 3, Pi 4, and Pi 5 hosts. It also supports other Linux SBCs and x86 hardware. Those are supported starting points, not a promise that every combination of cameras, services, and printers fits the same host. Choose an operating system image that supports the exact board and its peripherals.

An existing Linux mini PC can supply the host half without a Raspberry Pi purchase. An alternative SBC needs its own supported Linux image; a Pi image is not interchangeable with it. Physical GPIO compatibility is a separate question from whether the Klipper host process runs.

Storage. Keep the operating system, configuration files, logs, and uploaded G-code on working persistent storage. A microSD card is one option; USB storage is another where the host supports booting from it. Back up printer.cfg and its included files separately from the host so replacing storage does not also mean reconstructing the printer configuration.

Power. Follow the host manufacturer’s supply specification, including connected USB devices. Raspberry Pi documents 5V/3A for Pi 4 and recommends its 27W USB-C supply for Pi 5. A board’s spare 5V pin is not evidence that it can power the host. Klipper’s FAQ includes inadequate power among the causes to investigate when a Pi reboots during printing.

Raspberry Pi models and host alternatives

The support status below follows the Klipper host FAQ. The connection notes distinguish running Klipper from attaching an accelerometer directly to the host.

The Pi Pico is a different category: its RP2040 can act as a Klipper microcontroller, including for an accelerometer, but it does not replace the Linux host. Buying a Pico and buying a Pi computer solve different parts of the hardware requirement.

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. A direct data cable on boards with a supported USB connection.
• 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.

Klipper supported-board compatibility table

Each board name links to the upstream configuration that identifies its MCU or flashing procedure. These are documented examples, not a complete support list. Confirm the printed board revision and chip marking before selecting firmware: a shared brand name does not establish matching pins or a matching bootloader.

The bootloader reference explains why a flash address and a firmware filename are not interchangeable instructions. A binary compiled with a bootloader offset belongs at that offset. The Spider example’s address must not be reused for a board retaining a different bootloader. Use the matching vendor procedure when the installed bootloader differs from the upstream example.

Run make menuconfig before make for the selected MCU, clock, bootloader, and communication interface. Here, make compiles firmware; it does not itself install it. For SD updates, copy the resulting file to the card’s root directory using the exact filename in the table, safely eject the card, and follow that board’s restart procedure. The host’s operating-system card and the controller’s firmware-update card serve separate roles.

A compatible MCU is only the first check. Inventory the printer’s stepper connections, heater outputs, thermistor inputs, endstops, probe, and fans against the example pin map. A configuration’s sample bed dimensions, motor currents, and temperature limits describe an example setup; they are not validated limits for your printer. Retain the board mapping only after checking the actual wiring.

Choosing an accelerometer connection

Automatic resonance measurement needs a supported accelerometer; normal Klipper operation does not. Klipper documents ADXL345, MPU-9250 family, LIS2DW, and other supported sensors in its resonance guide. Select a documented wiring example for the exact chip and board instead of assuming every breakout with an accelerometer label uses the same interface.

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 can carry communication over a twisted pair alongside its power wiring. Klipper’s CAN documentation sets out the requirements:

• 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. Choose CAN when that wiring arrangement serves the build; it is not a prerequisite for Klipper or input shaping.

The Software Stack

Klipper’s installation guide describes a common stack: Klipper itself, Moonraker as the API server, and Mainsail or Fluidd as the browser front end. OctoPrint is another documented interface option. Choose the installation instructions for the selected stack; neither Moonraker nor a particular browser interface is a universal hardware requirement. A physical touchscreen is optional.

Three Sensible Build Tiers

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.

First-boot hardware acceptance checks

After flashing, identify the controller from the host instead of copying a serial path from a tutorial. Klipper’s FAQ uses ls /dev/serial/by-id/* to locate a stable identifier. Put the actual result in the [mcu] section. If several boards lack unique identifiers, the FAQ describes /dev/serial/by-path/* as an alternative tied to the connection path. Recheck the identifier after changing hardware.

Follow the official configuration checks before starting a print. Confirm that temperature readings are plausible at room temperature and that the emergency stop works. Check heater behavior individually, then verify stepper motion and endstop reporting. These steps establish whether the configuration describes the connected hardware. A successful firmware upload cannot establish that a thermistor is plugged into the intended socket.

Use the result to decide what needs attention. A board that never appears on USB calls for a check of its cable, power, firmware interface, and bootloader state. A board that connects but reports an unknown configuration option calls for checking the configuration against the installed Klipper version. A reversed motor or incorrect endstop response needs wiring and configuration review before homing, rather than a larger host computer.

Keep a short hardware record with the printer backup: board model and revision, MCU marking, chosen bootloader offset, communication interface, and the source configuration used. Add the host model and operating-system image. This is a suggested maintenance record, not an extra software dependency. It makes a later controller replacement reviewable without guessing which of several similarly named binaries belongs to the machine.

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 the chosen Klipper stack and flash the controller. Follow the project’s upgrade instructions for later firmware updates; ordinary printer.cfg changes do not require a reflash.
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.