---
title: "STM32F4xx grblHAL driver"
url: "https://maker.wiznet.io/matthew/projects/stm32f4xx-grblhal-driver/"
markdown_url: "https://maker.wiznet.io/matthew/projects/stm32f4xx-grblhal-driver/md"
type: "UCC: User Created Content"
author: "terjeio"
author_url: "https://github.com/grblHAL/STM32F4xx"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "terjeio"
original_url: "https://github.com/grblHAL/STM32F4xx"
published: "2026-03-20"
language: "en"
likes: 0
views: 697
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# STM32F4xx grblHAL driver

> STM32F4xx brings grblHAL to many STM32 CNC boards, mixing native lwIP Ethernet and W5500 options while staying highly reusable for real controller products.

Original author: terjeio (source: https://github.com/grblHAL/STM32F4xx)

## Article

Thumbnail: AI-generated image

## STM32F4xx: a grblHAL driver family for STM32F4 CNC controllers, with plugin expansion and both lwIP and W5500 networking paths

## Introduction

**STM32F4xx** is a **grblHAL driver repository** for STM32F4-based motion-control boards, not a standalone desktop CNC application and not a single-board firmware image. The public README presents it as a driver for **STM32F401, STM32F407, STM32F411, and STM32F446** processors, but the current repository snapshot goes further than that headline: the visible board metadata also includes **F412** and **F429**-based variants, along with board mappings for hobby, CNC-breakout, 3D-printer-derived, and more purpose-built controller hardware. The repository also declares a large set of submodules for the shared grblHAL core and plugins, including **networking**, **SD card**, **Trinamic**, **Bluetooth**, **laser**, **openpnp**, and others, which makes this a driver family inside a broader firmware ecosystem rather than a self-contained monolith.

That broader context matters because the repository is really about one central task: **binding grblHAL’s shared CNC control core to specific STM32F4 hardware**. Public grblHAL materials describe the overall project as a HAL-based 32-bit evolution of Grbl, where processor-specific drivers sit underneath a shared motion-control core. In other words, this repository is one hardware-facing branch of a wider grblHAL architecture, not an isolated fork or a one-off CNC board hack. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

## Quick background

To make sense of this repository, two short ideas help.

First, **Grbl** and **grblHAL** are not CAD tools or CAM packages. They are embedded controller firmware that interprets **G-code**, plans motion, and drives the machine electronics. Public grblHAL background material explains that grblHAL emerged because 8-bit Arduino-era Grbl had reached practical limits, and multiple 32-bit ports were starting to fragment. The solution was to split the system into a **hardware abstraction layer** and a **shared core**, so that motion-control logic could stay portable while hardware-specific timing, pins, serial ports, networking, and peripherals lived in separate drivers. That is why a repository like STM32F4xx exists in the first place. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

Second, a **driver repository** in grblHAL terms is not just a thin pinmap. It is a board-and-processor adaptation layer that decides what the firmware can expose on a particular MCU family. In the STM32F4xx tree, that includes axes, limit inputs, spindle modes, EEPROM/FRAM options, SD card support, networking, Trinamic drivers, auxiliary I/O, and board-specific boot or crystal assumptions. The visible `driver.json` makes that explicit by describing board capabilities as structured metadata, while `my_machine.h` exposes the larger compile-time feature model used to build a machine-specific firmware image.

For general readers, the simplest way to picture it is this: **the grblHAL core decides how a CNC machine should behave, while STM32F4xx tells that core how to behave on a specific STM32F4 board**. That is why the same codebase can target a minimal BlackPill board, a Nucleo breakout, a repurposed 3D-printer controller, or a more industrial-looking F407 board, while still staying inside one firmware family. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

## What this project is

![](https://maker.wiznet.io/upload/ckeditor5/221214559%5F1774861136%2Ejfif)

AI-generated image

The safest description is this: **STM32F4xx is a configurable grblHAL driver family for many STM32F4-based CNC controller layouts**. The repository README emphasizes common build routes such as **Web Builder**, **STM32CubeIDE**, and **PlatformIO**, while the visible board metadata shows support spanning BlackPill, Nucleo-based CNC breakouts, BigTreeTech SKR and Octopus-class boards, Flexi-HAL, SuperLongBoard, and even a preliminary **JZ-F407VET6 industrial control board** path. That mix is revealing. It shows that this repository is not built around one commercial controller SKU. It is a reusable firmware layer for a diverse set of controller hardware designs.

The visible `driver.json` also shows what “driver family” means in practice. At the top level, the repository advertises capabilities such as **USB CDC**, **UART**, **spindle PWM and sync**, **multiple serial ports**, **EEPROM**, **I2C strobe**, **ganged axes**, **auto-squaring**, **SD card**, **ethernet**, **wiznet**, **RGB output**, and a long plugin list including **bluetooth**, **networking**, **webui**, **modbus**, **fans**, **openpnp**, and more. That is not the profile of a minimal step/dir port. It is closer to a configurable CNC controller platform with a large optional surface area.

The code layout reinforces that reading. The repository declares the shared **grblHAL core** as a submodule, alongside optional submodules for networking, SD card, spindle plugins, keypad support, Trinamic support, and other functions. This means the STM32F4xx repo should be read as one layer in a stack: the shared motion-control logic lives elsewhere, while this repository adds **processor-family support, board maps, MCU peripheral handling, and machine-specific capability selection**.

The repository front page also undersells the hardware spread slightly. The README headline still names F401/F407/F411/F446, but the visible board metadata includes **STM32F412-based SuperLongBoard variants** and **STM32F429-based Octopus Pro variants**. So the current code snapshot is broader than the simplest one-line description suggests. That matters curatorially because English-language readers would otherwise assume this is only a BlackPill or Nucleo port.

## Author & public footprint

The public footprint around this repository points to a broader **grblHAL ecosystem**, not just one repo owner pushing one board. The current public organization page describes grblHAL as a HAL-based port available for many 32-bit processors and controllers, with shared core, plugins, networking options, SD support, and a web builder. The same organization also exposes separate public repositories for **core**, **drivers**, **plugins**, **controllers**, and **templates**, which shows that STM32F4xx is part of an organized firmware platform rather than a loose collection of forks. ([GitHub](https://github.com/grblHAL))

Within that ecosystem, the visible STM32F4xx source files repeatedly credit **Terje Io**, and the public grblHAL background page explicitly identifies him as the developer who split Grbl into a hardware abstraction layer and shared core to prevent the emerging 32-bit ports from fragmenting. That matters because it explains why the repository feels more architectural than many hobby CNC ports: it comes from a maintainer tradition focused on portability and long-term extensibility, not only on one controller board. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

That broader public footprint also includes **ioSender**, a separate G-code sender for Grbl and grblHAL. In practical terms, that means the same ecosystem is not only producing firmware drivers, but also a host-side control application. For English-speaking readers, that is useful context: grblHAL is not just “firmware that exists in a vacuum.” It sits inside a broader motion-control toolchain that includes board drivers, plugins, and sender software. ([GitHub](https://github.com/terjeio/ioSender))

A second public pattern is the repository’s relationship to external hardware makers. The `driver.json` file points to board URLs from **BigTreeTech**, **Sienci Labs**, **Expatria Technologies**, **Devtronic**, and other community or vendor projects. That suggests that the maintainers and contributors are not only making generic firmware abstractions; they are actively adapting grblHAL to a mix of community boards, printer-derived control boards, and more dedicated CNC hardware. In curator terms, this is a repository that sits at the intersection of **open CNC firmware**, **community board adaptation**, and **practical controller productization**.

## How it works

![](https://maker.wiznet.io/upload/ckeditor5/221214559%5F1774861155%2Ejfif)

AI-generated image

At architecture level, the project is easiest to understand as a pipeline:

**grblHAL core → STM32F4xx HAL driver → board map → compile-time feature selection → final machine firmware**

That flow is not theoretical. Public grblHAL background material explains that the core interacts only with the HAL, and the STM32F4xx tree shows exactly how that is expressed in practice: board macros in `my_machine.h`, structured board and capability metadata in `driver.json`, board-specific map headers in `boards/`, MCU peripheral code in `Src/`, and optional plugin dependencies declared through submodules and PlatformIO configuration. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

For developers, the important point is that a “board” here is not just a pin assignment. A board entry can change the MCU type, clock assumptions, bootloader layout, number of axes, I/O density, available serial ports, spindle capabilities, whether SD card or EEPROM are present, and whether the board has **native Ethernet**, **WIZnet Ethernet**, or neither. That is why the `driver.json` metadata is so central: it is the machine-readable summary of what the STM32F4xx driver can expose on each hardware variant.

For general readers, the practical result is simple: this repository produces firmware that lets many STM32F4 boards behave like serious CNC controllers rather than like generic development kits. The board may still be a Nucleo, a BlackPill, or even a repurposed 3D-printer mainboard, but once mapped into grblHAL’s model it can expose coordinated motion, real-time inputs, sender connectivity, storage, and optional networking or WebUI services. ([GitHub](https://github.com/grblHAL))

## Communications architecture and the WIZnet path

One of the most important technical findings in this repository is that the networking story is **not singular**. The STM32F4xx driver family supports **two distinct Ethernet directions**.

The first is a **native STM32 Ethernet path**, and the evidence for that is explicit. The repository contains `enet.c`, described in its own header comment as **“lwIP driver glue code for STM32F4xx processors,”** and that file is compiled only when `ETHERNET_ENABLE` is set **without** `_WIZCHIP_`. It includes `lwip/netif.h`, DHCP support, network service setup, and the grblHAL networking layer. The PlatformIO file also contains a dedicated `[eth_networking]` section that pulls in **lwIP** plus the networking plugin. That is a straightforward lwIP-based path for boards using native Ethernet hardware.

The second is a **WIZnet SPI Ethernet path**. That path becomes visible when `_WIZCHIP_` is set in `my_machine.h`, where the comments explicitly describe `_WIZCHIP_=5500` as enabling Ethernet via a **WIZnet breakout connected via SPI**. The same configuration file also turns on Telnet and WebSocket support when Ethernet or WebUI is enabled, and the board metadata marks several boards as `wiznet` capable, including Protoneer/Nucleo variants, Flexi-HAL, SuperLongBoard, SKR-2, and others. In other words, WIZnet support is real, but it is **board-specific**, not universal across the whole STM32F4xx driver family.

That board-specific nature is reinforced by the board maps themselves. `longboard32_map.h` explicitly errors if Ethernet is enabled without `_WIZCHIP_=5500`, and then assigns SPI CS, IRQ, and reset pins for the Ethernet chip. By contrast, the preliminary `stm32f407vet6_dev_board.h` explicitly warns that the board has an **RMII ethernet chip** and tells the user to **comment out **`**_WIZCHIP_**`. So the project does not treat all STM32F4 networking the same way. Some board variants are W5500-over-SPI designs, while at least one industrial-looking F407 board path is intended for native RMII Ethernet.

At the service level, the grblHAL networking plugin adds more context. Its public README describes support for **Telnet**, **WebSocket**, **FTP**, **HTTP**, **WebDAV**, **mDNS**, **SSDP**, and **MQTT**, and it lists STM32F4xx among the networking-capable drivers. So the Ethernet side here is not about generic ping-only connectivity. It is intended to carry **machine communication and service endpoints** such as raw Telnet-style CNC streaming, WebSocket-based connectivity, and WebUI-adjacent file or service access where the board and build enable it.

### TOE / ioLibrary Driver or lwIP?

For this repository, the most accurate answer is **both — depending on which Ethernet path is selected**.

For **native STM32 Ethernet builds**, the answer is clearly **lwIP**. The repository’s own `enet.c` file says so directly, and the PlatformIO `eth_networking` section also points to lwIP as the stack behind that route.

For the **WIZnet path**, the answer is different. The low-level W5x00 driver in `w5x00_ll_driver.c` is copyrighted by **WIZnet Co., Ltd.**, and it includes `socket.h` plus `W5500/w5500.h`. More importantly, the public networking submodule includes `wizchip_conf.h`, which is itself a WIZnet header that explicitly points developers to **WIZnet’s ioLibrary_Driver** and defines the W5500/W5100S chip families and callback model used by the offload library. That makes the WIZnet path in this repository best described as **TOE / ioLibrary-style WIZchip integration**, not as a pure lwIP-only path. The W5500 itself is a **hardwired TCP/IP controller** with SPI access, embedded MAC/PHY, and **8 hardware sockets**, so this direction matches the chip’s intended role closely. ([WIZnet Documentation](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

At the project level, then, the correct classification is:

**Native Ethernet boards:** lwIP-based

**WIZnet W5x00 boards:** WIZnet TOE / ioLibrary-style chip access

**Overall repository:** mixed networking architecture, because it supports both models depending on board and build choice.

That distinction is important for WIZnet Maker readers. It would be inaccurate to call the whole STM32F4xx repository “a W5500 driver,” because many builds do not use WIZnet at all. But it would also be inaccurate to call the whole networking story “just lwIP,” because the WIZnet path clearly binds to W5x00 chip-level APIs and official WIZnet headers. The available materials show a **dual networking strategy** rather than a single networking stack.

---

## Why it matters

![](https://maker.wiznet.io/upload/ckeditor5/221214559%5F1774861178%2Ejfif)

AI-generated image

STM32F4xx matters because it shows what grblHAL is supposed to do at its best: keep one shared motion-control core while letting many different controller boards expose very different hardware features through driver-layer adaptation. In this repository, that flexibility is visible not only in step/dir and spindle support, but also in storage, serial expansion, board-specific boot layouts, native Ethernet on some boards, and W5500-based Ethernet on others. That is exactly the kind of separation the grblHAL project was created to enable. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

It also matters because this is no longer just a “developer-board experiment” story. The board metadata points to real controller projects from makers and vendors such as BigTreeTech, Devtronic, Expatria, Sienci Labs, and others, and Sienci’s current SuperLongBoard documentation explicitly says the SLB runs **grblHAL**, supports **USB-C and Ethernet**, and exposes **RS485** for spindle/VFD control. That makes STM32F4xx relevant not only as source code, but as part of a firmware path that has already crossed into productized controller hardware. ([시엔시 리소스](https://resources.sienci.com/view/slb-manual/))

A second reason it matters is networking. The reviewed networking plugin supports services such as **Telnet**, **WebSocket**, **FTP**, **HTTP**, **WebDAV**, **mDNS**, **SSDP**, and **MQTT**, while the STM32F4xx driver family can reach those services either through native lwIP-based Ethernet or, on specific boards, through WIZnet W5x00 hardware over SPI. That makes the repository more than a local USB motion controller port. It is a foundation for CNC controllers that can move toward richer machine connectivity and WebUI-style workflows.

## Market and industry context

![](https://maker.wiznet.io/upload/ckeditor5/221214559%5F1774861191%2Ejfif)

AI-generated image

There is no clean public market-size figure for the narrow niche represented by this exact repository — an open, board-adaptation layer for CNC firmware on STM32F4 hardware. The safest market framing is therefore **adjacent context**, not a direct market-size claim. One recent Research and Markets release places the broader **motion control market** at **USD 14.61 billion** in 2026, projected to reach **USD 25.90 billion by 2035**, driven by industrial automation, robotics, and demand for more precise and programmable motion systems. That does not make STM32F4xx a “market leader” by itself, but it does show that the broader control layer it serves sits inside a growing category. ([GlobeNewswire](https://www.globenewswire.com/news-release/2026/03/13/3255334/0/en/25-Bn-Motion-Control-Markets-2035.html))

More useful than the market-report number is the product evidence around it. Sienci’s current SLB and SLB-EXT documentation describes commercial controller boards that run grblHAL firmware, document Ethernet and RS485 usage, and treat grblHAL as the active controller layer rather than as a lab-only prototype. The grblHAL organization also currently presents **46 public repositories**, with STM32F4xx listed as one of the active processor-driver lines. So the strongest market-context reading is that STM32F4xx sits inside a real, public, and already product-adjacent CNC firmware ecosystem. ([시엔시 리소스](https://resources.sienci.com/view/am-slb-ext-controller/?utm_source=chatgpt.com))

## External value and commercial relevance

STM32F4xx should not be framed as a turnkey CNC machine product. Its value is more foundational than that. It gives controller vendors, board makers, and advanced integrators a way to reuse the grblHAL core while differentiating on board hardware, I/O topology, spindle interfaces, networking, and plugins. That is commercially meaningful even when the repository itself is “just firmware,” because in embedded control markets the driver layer is often what turns generic silicon into a board that customers can actually deploy. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

The external value is also stronger because the ecosystem around it is not empty. Sienci’s documentation recommends **gSender** and also points users to **ioSender**, while the current ioSender repository describes itself as a G-code sender for Grbl and grblHAL and shows **273 stars** and **85 forks** on GitHub. That does not prove industrial adoption in the factory-automation sense, but it does show that the firmware family is supported by an active host-side toolchain rather than relying on one obscure uploader or one vendor-locked front end. ([시엔시 리소스](https://resources.sienci.com/view/slb-manual/))

## SPE applicability and future-fit

![](https://maker.wiznet.io/upload/ckeditor5/221214559%5F1774861425%2Ejfif)

AI-generated image

The first conclusion is straightforward: **SPE is not present in this repository today.** The reviewed STM32F4xx tree supports either native STM32 Ethernet with **lwIP** or WIZnet W5x00-based Ethernet over SPI, and the W5500 itself is a **10/100 Ethernet** hardwired TCP/IP controller with an embedded Ethernet MAC/PHY and SPI interface. That is conventional Ethernet, not Single Pair Ethernet. So any statement that this driver already “supports SPE” would be inaccurate. ([WIZnet Documentation](https://docs.wiznet.io/Product/Chip/Ethernet/W5500?utm_source=chatgpt.com))

At the architecture level, however, SPE is not irrelevant. The Ethernet Alliance describes SPE as a way to solve OT-network problems in industrial and building automation by simplifying network design and reducing the need for legacy protocol translation, while Microchip’s 10BASE-T1S material describes a **10 Mbps multidrop** medium with at least **eight nodes** on a shared segment. That means a future grblHAL-style controller architecture could plausibly use SPE for **distributed in-machine nodes** such as toolhead modules, remote I/O pods, pendant-like accessories, or smart spindle/auxiliary devices. That is an inference, but it is a grounded one. ([Ethernet Alliance](https://ethernetalliance.org/single-pair-ethernet/))

There is also a second SPE direction: **10BASE-T1L / Ethernet-APL**. The Single Pair Ethernet System Alliance describes APL as a two-wire, 10 Mbit/s long-reach variant with distances up to **1,000 m**, with SPE more broadly positioned for factory automation and building infrastructure. For a compact hobby or prosumer CNC controller, that is less natural than standard USB or RJ45 Ethernet. But for larger industrial machines, distributed cabinets, long cable runs, or plant-level machine networks, that long-reach Ethernet direction becomes more interesting. In other words, the **current repo is not an SPE product**, but its controller-and-plugin architecture is not opposed to an SPE future if the physical layer changes. ([Single Pair Ethernet System Alliance](https://singlepairethernet.com/en/apl/apl-principle/))

For the current grblHAL STM32F4xx market, though, SPE does not look like an immediate requirement. Sienci’s documentation notes that the SLB only needs around **1–2 Mbps** of bandwidth and is mainly positioned around **direct Ethernet communication from a computer to the board**, not around a larger OT field network. That suggests the current customer need is reliable controller connectivity, not yet a full SPE-style field-level Ethernet architecture. So the right conclusion is: **SPE is a credible future-fit idea for more distributed CNC or industrial machine designs, but not a present necessity for most of the boards represented in STM32F4xx today.** ([시엔시 리소스](https://resources.sienci.com/view/slb-manual/))

## Quick notes

One caveat is important when reviewing this repository: the uploaded ZIP snapshot is useful, but it does not fully replace the public GitHub tree because the project depends heavily on **submodules**. The `.gitmodules` file explicitly declares the shared grblHAL core, networking plugin, WebUI plugin, SD-card plugin, and many others as submodules. That means some of the strongest evidence for the WIZnet stack and service layer comes from the public repository plus its submodule structure, not from the ZIP alone.

A second caveat is that the README headline is narrower than the current tree. The front page still introduces STM32F4xx mainly as an F401/F407/F411/F446 driver, but the current `driver.json` and board maps show **F412** and **F429**-class assets as well, along with more mixed networking options than the front page alone suggests. So a careful curation should follow the visible code and board metadata, not just the one-line repo description.

Finally, WIZnet support should be described precisely. It is **real**, but it is **not universal** across every STM32F4xx build. Some board maps explicitly require `_WIZCHIP_=5500`, while the preliminary JZ-F407VET6 industrial board path explicitly warns that the board has **RMII ethernet** and tells users to disable `_WIZCHIP_`. So the correct description is a **mixed driver family** with both WIZnet-based and native-Ethernet variants, not a uniformly W5500-based platform.

### STM32F4xx (grblHAL) FAQ

Q. What is the STM32F4xx repository?

A. It is a hardware abstraction layer (HAL) driver family for the grblHAL CNC firmware. It acts as the bridge between the shared grblHAL motion-control core and a wide variety of STM32F4-based boards (like BlackPill, Nucleo, or custom 3D printer boards), allowing them to function as capable CNC controllers.

Q. Is this a standalone CNC software?

A. No. It is not a desktop CAD/CAM tool or a monolithic firmware image. It is a configurable hardware driver layer that gets compiled alongside the main grblHAL core and various plugins to create a machine-specific firmware file.

Q. How does this platform handle Ethernet connectivity?

A. It features a dual networking strategy depending on the board's hardware. It supports a native STM32 Ethernet path using an `lwIP` stack, as well as an SPI Ethernet path that utilizes WIZnet W5x00 chips (like the W5500) via a custom `ioLibrary`-style integration.

Q. What kind of networking features does the Ethernet connection enable?

A. When the networking plugin is enabled, the Ethernet path (whether native or WIZnet-based) supports rich machine communication services. This includes raw Telnet-style CNC G-code streaming, WebSockets, FTP, HTTP, WebDAV, and MQTT for WebUI workflows.

Q. Is this driver purely for DIY hobbyists?

A. While it supports DIY and maker boards, it is also highly commercially relevant. It is actively used in productized commercial CNC controllers (such as the Sienci Labs SuperLongBoard) and industrial-style hardware setups.

Q. Does it currently support Single Pair Ethernet (SPE)?

A. Not at this time. The existing networking paths rely on conventional 10/100 RJ45 Ethernet. However, because the networking architecture is built on standard OSI layers, SPE is a highly credible future-fit for larger, distributed CNC machines requiring long cable runs.

## References

The grblHAL project background and HAL design rationale are described on the GRBL Project site. ([The Grbl Project](https://www.grbl.org/what-is-grblhal))

The current public grblHAL organization page and repository list show the breadth of the ecosystem around STM32F4xx. ([GitHub](https://github.com/orgs/grblHAL/repositories?utm_source=chatgpt.com))

The reviewed STM32F4xx source snapshot includes the README, board metadata, lwIP glue path, W5x00 low-level driver, board maps, and machine configuration header.

The grblHAL networking plugin README provides the clearest public summary of the higher-level networking services used on top of lwIP or WIZnet-backed transports.

WIZnet’s current W5500 documentation supports the classification of the W5x00 path as a hardwired 10/100 Ethernet controller route rather than an SPE route. ([WIZnet Documentation](https://docs.wiznet.io/Product/Chip/Ethernet/W5500?utm_source=chatgpt.com))

Current commercial ecosystem examples around grblHAL include Sienci’s SuperLongBoard and SLB-EXT documentation, plus ioSender as a public host-side sender. ([시엔시 리소스](https://resources.sienci.com/view/slb-manual/))

For adjacent market context, the most defensible public comparison found here is the broader motion-control market rather than a niche “open-source CNC firmware driver” market. ([GlobeNewswire](https://www.globenewswire.com/news-release/2026/03/13/3255334/0/en/25-Bn-Motion-Control-Markets-2035.html))

For SPE and Ethernet-APL applicability, the most relevant public sources reviewed here are from Ethernet Alliance, Microchip, and the Single Pair Ethernet System Alliance. ([Ethernet Alliance](https://ethernetalliance.org/single-pair-ethernet/))

Reviewed source snapshot: STM32F4xx-master.zip

---

Source: https://maker.wiznet.io/matthew/projects/stm32f4xx-grblhal-driver/