Smoothieware: G-code firmware for LPC17xx CNC boards

Smoothieware's LPC17xx controller scope

Smoothieware solves a narrow embedded control problem: running a G-code interpreter and CNC controller directly on an LPC17xx microcontroller. The README identifies an ARM Cortex M3 architecture and names an mBed, LPCXpresso, SmoothieBoard, R2C2, and other LPC17xx-based boards as possible targets. Its intended users are CNC builders, firmware developers, and owners of compatible controller hardware.

This boundary is more important than the general description of the project as a CNC controller. The documentation does not present Smoothieware as a desktop application or as portable firmware for unrelated processors. Someone using a controller based on another chip family cannot infer support merely because the software accepts G-code. Hardware compatibility comes first.

Smoothieware is also modular and written in Object-Oriented C++. The repository layout supports that description through separate directories for source, configuration samples, bootloaders, build support, firmware binaries, and upload tools. The motion-control portion is described as a port of grbl, which places part of its design in an existing open source CNC lineage.

The README does not provide a feature comparison with grbl. It does not explain which capabilities were retained, extended, or left out. It also does not document a board support matrix. Consequently, an engineer can identify the intended hardware class and repository structure, but cannot select a board solely from the overview. The precise controller revision and its LPC17xx variant still need confirmation.

Smoothieware firmware structure and build flow

Based on the repository layout, Smoothie is a cross-compiled embedded firmware project. Native C++ code resides under `src/`, while directories such as `mbed/`, `mri/`, and `bootloader/` isolate parts of the build or target environment. Root files named `makefile`, `rakefile.defaults.example`, and `build/` provide the visible build entry points. The README identifies `LPC1768/main.bin` as a generated firmware output.

The documented build begins by cleaning previous output and compiling all targets:

make clean
make all

These commands must be run from the repository root. The README does not document expected compiler output, individual target names, or a build matrix covering every supported board. A source builder therefore needs more than the short command sequence if a build fails or if a non-default target is required.

Compilation and deployment are separate operations. The README says that prebuilt binaries are available and that building is unnecessary unless the user wants to compile the firmware. This makes the firmware image useful to users without an embedded development environment, provided that the image matches their board and expected startup method.

The Object-Oriented C++ implementation is also a maintenance consideration. Developers changing control behavior must account for the target toolchain and embedded build setup rather than treating the repository as a conventional host C++ library. No library API or standalone embedding instructions are documented.

Installing Smoothieware's host dependencies

The README provides separate installation scripts for Windows, macOS, and Linux. It calls the latter two `mac_install` and `linux_install`, and does not document a single command that works across all platforms. The scripts are repository files, so a user would select one according to the host operating system.

After running the appropriate script, the repository creates a `BuildShell` script. According to the README, this script configures the `PATH` environment variable to point to the required ARM GCC version installed by the installer. Developers can edit `BuildShell` when they need additional changes to the development environment.

That mechanism makes `BuildShell` part of the actual build setup, not merely a convenience launcher. The README does not say whether the generated file must be sourced in every shell, whether it works with PowerShell, or how to inspect the selected compiler. It also does not list exact host package dependencies. Those omissions mean the quick-start sequence is sufficient for starting the documented setup, but incomplete as a troubleshooting reference.

For a first source build, the sequence is therefore clear at a high level: clone the project, run the installer for the host platform, use the generated `BuildShell`, enter the repository root, and build with `make clean` followed by `make all`. Any exact behavior of the generated environment must be checked in the installer and `BuildShell` files for the selected platform.

Uploading firmware with dfu-util

The README offers `make upload` as one deployment method:

make upload

This command is available when `dfu-util` is installed. The documentation associates the upload route with flashing a built firmware image to a compatible controller, but it does not describe device-selection flags, boot mode entry, USB permissions, timeout handling, or verification output. It would be unsafe to invent those details.

A source user must therefore confirm that the controller supports this upload path before treating `make upload` as a complete installation procedure. The README does not say whether every named board uses the same mechanism. That omission matters because Smoothieware supports several LPC17xx-based platforms rather than one documented board revision.

The build output also needs consideration. The SD-card instructions identify `LPC1768/main.bin`, while the upload command does not spell out which output file it passes to `dfu-util`. Inspecting `makefile` or `build/` would be necessary to trace that internal wiring. The README alone does not document it.

For a board owner, the decisive question is whether that board's established flashing procedure matches Smoothieware's `make upload` route. The command is concise, but the README does not provide enough board-state instructions to configure a device solely from this page.

Installing firmware.bin from an SD card

The README documents a second deployment route that does not require `make upload`. It says to copy `LPC1768/main.bin` to the SD card under the filename `firmware.bin`, then reset the board. The source filename and destination filename are therefore different parts of the operation.

This method may be convenient for a compatible LPC1768-based controller that reads firmware from its SD card at startup. However, the README does not state the required SD-card format, directory layout, capacity, firmware update indicator, or failure behavior. It also does not explain whether prebuilt `firmware.bin` should be copied directly or renamed on the card.

There is another documentation gap. The README names an LPC1768 output, while its hardware description includes an mBed, LPCXpresso, SmoothieBoard, R2C2, and other LPC17xx-based boards. The SD-card procedure cannot safely be generalized to those targets based on the README alone. Firmware images may differ by board, and no compatibility table is included.

The correct first check is consequently the controller's own firmware-loading procedure. If that procedure expects an SD-card file named `firmware.bin`, a user can copy the applicable binary and reset. If it expects another mechanism, the `make upload` path or board-specific documentation is the relevant route. The README does not resolve which method applies to every listed target.

Configuration samples and documentation limits

The repository includes a `ConfigSamples/` directory, which establishes configuration samples as part of the project. That is useful for an engineer looking for concrete machine profiles, but the README does not reproduce any sample, key, module name, or override rule. It therefore cannot support a complete configuration tutorial without adding facts that are not documented.

The claim that Smoothieware is modular also raises a practical question about how modules are selected. The README does not say whether modules are enabled through the configuration file, the build process, or both. It does not document module dependencies or behavior when a required module is absent. Those points should be checked in the applicable sample files and source tree before configuring motion or tool behavior.

External documentation is part of the documented path. The README links to `smoothieware.org` for general documentation and compilation instructions. It also links to coding standards, a developer guide, and contribution guidelines. This is useful for deeper work, but the overview page alone does not document supported configurations for a particular machine.

For adoption, `ConfigSamples/` is a point of entry rather than proof of compatibility. An engineer must match a sample to the controller board, motors, firmware image, and intended machine. Without that mapping, copying an arbitrary configuration risks encoding assumptions that the README does not explain.

Smoothieware maintenance and GPL-3.0 obligations

The repository is not archived, and its last push was on 2026-08-07. That supports the narrow statement that repository activity occurred relatively recently. It does not establish a formal release schedule because GitHub has no releases for this repository. Maintenance planning must therefore consider changes on the default `edge` branch and the status of the linked stable binary separately.

An upgrade can involve more than replacing code. A controller may have an SD-card firmware file, a bootloader, board-specific configuration samples, and upload utilities within the repository. The README does not document rollback, automatic configuration migration, or a compatibility policy between firmware versions. None of those capabilities should be assumed.

Smoothieware is released under the GNU GPL v3. The repository includes `COPYING` and links to the GPL v3 license text. This identifies the stated licensing model for the firmware. Anyone redistributing or incorporating the code may need to review that license for their specific use, although this article does not provide legal advice.

Overall, Smoothieware is most appropriate for a builder committed to LPC17xx hardware who can follow platform-specific firmware deployment. It is unsuitable for an adopter who requires documented support for arbitrary boards, a desktop controller, a formal release history, or a complete configuration guide in the README.

Editorial conclusion

Smoothieware fits builders who already have an LPC17xx-based controller and need firmware that interprets G-code locally. It does not fit users seeking portable firmware for arbitrary hardware or a self-contained board configuration guide. Verify the exact board, firmware-loading method, sample configuration, and `LPC1768/main.bin` compatibility first.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. Smoothieware/Smoothieware on GitHub