Skip to content

feat/stm32: NemaGFX (Neochrom GPU) basic screen-drawing support - #6626

Draft
leftger wants to merge 19 commits into
embassy-rs:mainfrom
leftger:feat/stm32-neochrom
Draft

feat/stm32: NemaGFX (Neochrom GPU) basic screen-drawing support#6626
leftger wants to merge 19 commits into
embassy-rs:mainfrom
leftger:feat/stm32-neochrom

Conversation

@leftger

@leftger leftger commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

This is merely a draft PR until I figure out how stm32-bindings will generate the NemaGFX driver bindings that this proposed crate addition will then make use of. The intent is the following:

  • Define the supported color formats NemaGFX ingests
  • Setup the basic API calls that allow for rectangles, triangles, circles, and screen blitting
  • Provide Errors for NemaGFX
  • Implement a bridge driver between GPU2D and the NemaGFX bindings

A set of examples is provided with stub driver initialization and a basic screen-drawing example.

leftger added 17 commits July 22, 2026 01:13
Introduce embassy-stm32-neochrom as the Embassy integration layer over
stm32-bindings NemaGFX FFI, with chip presets, GPU2D stub bring-up, and
a minimal NeoChrom clear API.
Wire embassy-stm32-neochrom into the N6 examples with a minimal GPU clear
loop so local bring-up can validate linking and the command-list path.
on_interrupt() was a no-op, unlike every other peripheral driver in this
crate. Give it the standard pattern used elsewhere (e.g. jpeg.rs): mask at
the NVIC level (CLC/ER have no separate interrupt-enable field per
gpu2d_v1.yaml, so there's nothing finer-grained to disable) and wake a
static AtomicWaker. Add Gpu2d::wait_command_list_complete() as the async
counterpart, re-arming the interrupt once the flag is consumed.
Adds gpu2d_bridge, implementing the C ABI hal_gpu2d_shim.h expects
(HAL_GPU2D_ReadRegister/WriteRegister/PollCompletion) backed by
embassy_stm32::gpu2d::Gpu2d instead of the CI-only stub. NeoChrom::new()
splits into a stub-gpu2d variant (unchanged) and a real variant that takes
the GPU2D peripheral + IRQ binding and constructs the real driver.

Verified against STM32U5F9/U5G9, where the driver builds end-to-end.
STM32N6/H7RS remain on the stub path for now — stm32-data is missing the
RCC clock-enable/reset mapping for GPU2D on those chip families (present
for U5 only), which embassy-stm32's Gpu2d driver requires regardless of
this bridge.

Only command-list-complete/error status is bridged; HAL_GPU2D_ReadRegister/
WriteRegister return 0/no-op for anything else, and hardware SystemError is
drained without surfacing through NeoChrom::Error yet.
…missing local path

The embedded-graphics integration commit pointed embedded-graphics-core
at a nonexistent ../../embedded-graphics/core path, which broke dependency
resolution for the whole crate regardless of enabled features.
@embassy-bot

embassy-bot Bot commented Jul 26, 2026

Copy link
Copy Markdown

This pull request is a draft, so it isn't in the review queue yet. Mark it as ready for review when you'd like someone to look at it.

@bugadani bugadani added the e-stm32 Issues for the STM32 family of chips label Jul 27, 2026
leftger added 2 commits July 27, 2026 23:55
…nd expose Icache::invalidate

Adds cache coherency handling and a dedicated GPU2D command module for the
NeoChrom driver, extends FrameBuffer with ExternalFrameBuffer/GpuSurface,
and exposes a standalone icache invalidate() usable without an Icache
driver instance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

e-stm32 Issues for the STM32 family of chips

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants