Skip to content

[WIP] Add STM32U585 support for Arduino UNO Q (3-axis CNC)#291

Closed
hoshigarasu wants to merge 1 commit into
grblHAL:masterfrom
hoshigarasu:stm32u585-arduino-uno-q
Closed

[WIP] Add STM32U585 support for Arduino UNO Q (3-axis CNC)#291
hoshigarasu wants to merge 1 commit into
grblHAL:masterfrom
hoshigarasu:stm32u585-arduino-uno-q

Conversation

@hoshigarasu
Copy link
Copy Markdown

@hoshigarasu hoshigarasu commented May 6, 2026

Overview

First grblHAL driver targeting STM32U585 (Cortex-M33) on the Arduino UNO Q board.

Hardware

  • MCU: STM32U585 (Arm Cortex-M33 @ 160MHz)
  • Linux side: Qualcomm QRB2210 (Debian)
  • Shield: Arduino CNC Shield V3 + A4988 stepper drivers
  • Axes: 3-axis (X/Y/Z), expandable toward 5-axis

Key changes

  • bitband_compat.h: BSRR/BRR-based replacements for BITBAND_PERI
    (Cortex-M33 has no bit-band region)
  • boards/uno_q_cnc_map.h: Pin map confirmed from Zephyr DTS
  • main.c: STM32U585 SystemClock_Config (MSIS→PLL1→160MHz,
    confirmed from arduino_uno_q-common.dtsi)
  • driver.h: #ifdef STM32U585xx guard for BITBAND macros

Status: WIP ⚠️

  • HAL/CMSIS library swap (STM32F4xx → STM32U5xx)
  • flash.c QUADWORD adaptation
  • Compile verification
  • Hardware test (Arduino UNO Q not yet in hand)

Hardware is on order. Will update to ready-for-review once compiled and verified.

@kojitokura-dev
Add STM32U585 support for Arduino UNO Q (3-axis CNC, WIP)
b9c0586 
Target: Arduino UNO Q (Qualcomm QRB2210 + STM32U585 Cortex-M33)
Shield: Arduino CNC Shield V3 + A4988 stepper drivers

Changes:
- Inc/driver.h: Wrap BITBAND_PERI/DIGITAL_IN/DIGITAL_OUT in
  #ifdef STM32U585xx, include bitband_compat.h for Cortex-M33.
  Add BOARD_UNO_Q_CNC board map entry.
- Inc/bitband_compat.h: New file. BSRR/BRR-based replacements for
  BITBAND_PERI macros (Cortex-M33 has no bit-band region).
- Inc/boards/uno_q_cnc_map.h: New board map for Arduino UNO Q.
  3-axis (X/Y/Z) pin assignments confirmed from Zephyr DTS
  (boards/arduino/uno_q/arduino_r3_connector.dtsi):
    X_STEP=PB3(D2), X_DIR=PA11(D5)
    Y_STEP=PB0(D3), Y_DIR=PB1(D6)
    Z_STEP=PA12(D4), Z_DIR=PB2(D7)
    EN=PB4(D8)
  STEP/DIRECTION outmode: GPIO_BITBAND (mixed GPIO ports require
  per-axis DIGITAL_OUT; DIGITAL_OUT is BSRR-based via bitband_compat.h)
- Src/main.c: Add STM32U585xx SystemClock_Config block with early
  return. MSIS(4MHz)->PLL1(M=1,N=80,R=2)->SYSCLK 160MHz.
  Parameters confirmed from arduino_uno_q-common.dtsi.
- Inc/main.h: Update HAL header to stm32u5xx_hal.h for U585 builds.

Status: WIP
  - HAL/CMSIS library swap (STM32F4xx->STM32U5xx) not yet done
  - flash.c QUADWORD adaptation pending
  - Compile and hardware verification pending (hardware not yet available)
  - USB CDC disabled (QRB2210 Linux side handles communication)

Architecture:
  grblHAL runs on STM32U585 (real-time step generation).
  QRB2210 (Debian Linux) handles G-code sending and process monitoring
  via bridge UART on D0/D1 (PB7/PB6 = USART1).
@hoshigarasu hoshigarasu marked this pull request as ready for review May 6, 2026 12:12
@hoshigarasu
Copy link
Copy Markdown
Author

hoshigarasu commented May 6, 2026 •
edited
Loading

Related project: rs274ngc-grbl-bridge

While working on this STM32U585 port, a broader architectural opportunity emerged
that I want to document here.

The problem: GRBL's loop limitation

GRBL and grblHAL support O-codes when streaming from local storage (SD card).
The rs274ngc-grbl-bridge approach adds network/SBC-side streaming
with host-integrated process control — complementary to, not a replacement
for, the existing SD card capability.

The solution: rs274ngc as a portable interpreter layer

LinuxCNC's rs274ngc interpreter is available as a standalone tool (rs274)
and library (librs274ngc). It handles the full RS274/NGC language including
O-codes, named parameters, expressions, and subroutines — and outputs
canonical machining function calls (STRAIGHT_FEED, ARC_FEED, etc.)
that are hardware-independent.

Proposed architecture:
G-code file (O-codes, variables, loops — full LinuxCNC dialect)
↓
rs274ngc interpreter (running on Linux host / SBC)
↓ canon calls: STRAIGHT_FEED, ARC_FEED, ...
Python canon backend ← the piece to build
↓ GRBL-compatible G-code stream
grblHAL (any board, any connection)

Why this matters for the grblHAL community

  • Any grblHAL machine gains full LinuxCNC G-code compatibility
    without firmware changes
  • rs274ngc runs on any Linux SBC (RPi, the Qualcomm QRB2210 on Arduino UNO Q, etc.)
  • The canon → GRBL translation layer is a bounded, well-defined problem
    (STRAIGHT_FEED → G1, ARC_FEED → G2/G3, etc.)
  • Custom M-codes on the Linux side enable process integration
    (e.g. synchronized control of spindle speed, coolant, or in my case,
    sputtering power and gas flow)

Why this matters for the LinuxCNC community

  • Extends LinuxCNC's reach to the entire GRBL ecosystem.
    Any GRBL/grblHAL machine paired with a Linux SBC becomes a first-class
    citizen of the LinuxCNC G-code world — without modifying firmware.
    This potentially brings millions of low-cost GRBL devices under the
    LinuxCNC framework.
  • Lowers the barrier to LinuxCNC adoption.
    LinuxCNC traditionally requires a real-time kernel and dedicated HAL
    drivers — a significant hurdle for newcomers. This bridge offers a new
    entry point: use rs274ngc's full G-code power on any Linux SBC, with
    motion delegated to an off-the-shelf GRBL device. No RT kernel,
    no HAL configuration.

Connection to this PR

The Arduino UNO Q (target of this port) has a Qualcomm QRB2210 running
Debian Linux alongside the STM32U585. The intended deployment is:
QRB2210 (Debian): rs274ngc interpreter + canon bridge + web UI
STM32U585: grblHAL — real-time step generation only

The 7ms bridge latency between the two chips is irrelevant because
all real-time motion stays on the STM32 side. The Linux side only
sends pre-processed motion commands, not time-critical pulses.

Current status

Hardware (Arduino UNO Q) is on order.
Development and testing will use an RPi4 (LinuxCNC already installed) + existing GRBL pen plotter as the initial debug target.

Will open a separate repository rs274ngc-grbl-bridge once the
basic canon parser and GRBL streamer are functional.

@hoshigarasu hoshigarasu closed this May 6, 2026
@hoshigarasu hoshigarasu reopened this May 6, 2026
@terjeio
Copy link
Copy Markdown
Contributor

terjeio commented May 6, 2026

GRBL and grblHAL lack O-code support

grblHAL supports O-code etc. when streaming from local storage (SD card).

BTW a support for a new processor family needs a separate driver. Or is the STM32U585 fully compatible with the F4 family?

@hoshigarasu
Copy link
Copy Markdown
Author

hoshigarasu commented May 6, 2026

Thank you for the correction and the question.

On O-code support:

Apologies for the inaccurate statement. I was not aware that grblHAL
supports O-codes when streaming from local storage. That changes the
picture significantly.

The rs274ngc-grbl-bridge concept I described is still relevant, but for
a different reason: enabling network/SBC-side streaming with the full
LinuxCNC G-code dialect — including integration with host-side process
control (in my case, a magnetron sputtering apparatus where motion must
be synchronized with vacuum, gas flow, and power supply parameters).
The value is in the host-side integration, not O-code support per se.
I'll correct the project description accordingly.

On STM32U585 / F4 compatibility:

The STM32U585 (Cortex-M33) is not fully compatible with the F4 family.
The key differences that required changes in this PR are:

  • No bit-band region (Cortex-M33): BITBAND_PERI causes a Hard Fault.
    Replaced with BSRR/BRR-based macros in bitband_compat.h,
    guarded by #ifdef STM32U585xx.
  • HAL/CMSIS library: STM32F4xx → STM32U5xx (not yet done — hardware
    is on order).
  • SystemClock_Config: completely different PLL structure
    (MSIS → PLL1 → 160MHz).
  • Flash write API: QUADWORD (16 bytes) instead of WORD (4 bytes).
  • GPIO on AHB2 instead of AHB1 (handled transparently by HAL macros).

I used #ifdef STM32U585xx guards within the F4xx driver as a starting
point to minimize the diff and keep the grblHAL core untouched. However,
if a separate driver is the preferred approach for a new processor
family, I am happy to restructure accordingly. Please let me know what
direction you would prefer before I proceed further.

@terjeio
Copy link
Copy Markdown
Contributor

terjeio commented May 8, 2026

if a separate driver is the preferred approach for a new processor family, I am happy to restructure accordingly.

Yes it is. I would prefer that you (or somebody else) take care of maintaining the driver since I do not have the bandwidth (or the boards) to do it myself. The STM32H7xx driver is an example of one not maintained by me - derived from the STM32F7xx driver.

@hoshigarasu
Copy link
Copy Markdown
Author

hoshigarasu commented May 8, 2026 •
edited
Loading

Thank you - this is very clear.

I will create a separate repository hoshigarasu/STM32U5xx,
following the same model as dresco/STM32H7xx derived from STM32F7xx.

My Arduino UNO Q hardware arrived today and active development
is starting now. I am happy to maintain the driver.

I will close PR #291 once the new repository is in place.

@hoshigarasu
Copy link
Copy Markdown
Author

hoshigarasu commented May 17, 2026

Thank you for your feedback on this PR.

Following your suggestion, I have moved the STM32U585 (Arduino UNO Q) port to its own dedicated repository rather than merging it into the STM32F4xx driver:

The port is now fully functional — grblHAL runs on the STM32U585, settings persist to internal flash, and motor movement has been verified via the CNC Shield V3. The companion bridge translates rs274ngc canon calls (canned cycles, subroutines, coordinate transforms) to grblHAL commands over the board's internal UART (ttyHS1), with no Mesa card and no real-time kernel required on the Linux side.

I am closing this PR accordingly. I hope the work documented in the new repositories is useful to others exploring the STM32U5 family with grblHAL.

@terjeio
Copy link
Copy Markdown
Contributor

terjeio commented May 17, 2026

The repositories mentioned above are not available, are they set as private?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@hoshigarasu @terjeio @kojitokura-dev