Prescaler: A practical development environment for embedded firmware

Embedded firmware engineers typically rely on a fragmented toolchain: a general-purpose editor, a terminal-based build system, separate flash and debug utilities, an external serial terminal, and datasheet references kept outside the development environment. Each component operates in isolation. Hardware context must be carried manually between tools.

Prescaler consolidates the firmware workflow into a single desktop application. The product integrates source editing, compilation, target programming, in-circuit debugging, serial I/O, and AI-assisted analysis against a shared project manifest. The current beta targets ARM Cortex-M microcontrollers on macOS, with initial support for STM32, nRF52, RP2040, SAMD21, and ESP32 device families.

Microcontroller software development has remained structurally unchanged for decades. While host-application tooling has converged on integrated environments, firmware workflows still depend on loosely coupled utilities that were not designed to share chip, memory, or debug state.

Vendor-specific IDEs reduce some of this fragmentation but introduce constraints on project portability, build transparency, and toolchain choice. Prescaler is intended for engineers who retain direct control over CMake or PlatformIO project structure while operating within a purpose-built embedded workbench.

This document describes the system architecture of Prescaler 1.0.0 beta, the integration model across build, debug, and AI subsystems, and the supported target matrix at initial release.

A conventional embedded setup requires at minimum: a code editor; a build invocation layer; a programming interface to the target; a debug server and client; a serial console; and peripheral documentation for register-level work. Context transfer between these systems is manual and error-prone.

Specific failure modes include: build diagnostics that do not resolve to editor locations; register values observed in a debugger that cannot be correlated with SVD field definitions; serial output that is disconnected from the active debug session; and general-purpose AI assistants that lack project, silicon, and runtime context.

Prescaler addresses these gaps by binding all workflow stages to a single manifest file, prescaler.json, which records the target MCU, debug probe configuration, memory layout, and SVD source path for the open project.

4.1 Application Layer

Prescaler is implemented as an Electron application. The renderer process hosts a React user interface with the Monaco editor and clangd language services for C and C++. The main process handles hardware-facing operations, including USB probe detection, OpenOCD orchestration, GDB session management, QEMU execution, and serial port I/O. Inter-process communication uses a typed IPC interface.

The workbench provides an explorer, integrated terminal, diagnostics panel, source control view, and dedicated panels for peripheral registers, RTOS inspection, linker map analysis, and datasheet reference material.

4.2 Build Subsystem

CMake with Ninja is the primary build backend. Projects remain portable standard CMake trees and may be compiled outside the IDE without modification. PlatformIO projects are supported viapio run through the same build entry point.

On successful link, the IDE reports flash and RAM utilization viaarm-none-eabi-size and provides access to linker map output for symbol-level memory analysis.

Prescaler does not ship a cross-compiler. At launch, the application scans the host system for arm-none-eabi-gcc, GDB, CMake, Ninja, QEMU, and OpenOCD. Missing dependencies are reported through a setup prompt. Tool paths may be overridden in application settings.

4.3 Flash and Debug Subsystem

Target programming and in-circuit debug are mediated by OpenOCD. Supported probe interfaces include ST-Link, J-Link, and CMSIS-DAP. USB-attached probes are enumerated automatically. Programming progress is surfaced in the IDE during transfer.

Debug control uses the GDB Machine Interface. Capabilities include breakpoint management, run control, stack inspection, local variable display, watch expressions, and memory examination. All debug surfaces are embedded in the primary workbench window.

QEMU simulation is available for STM32F405 targets using the netduino2 machine model. The reference demo project supports build, ELF load, GDB attach, and USART output routed to the integrated serial monitor over TCP. Other catalog devices require physical hardware in the current beta.

When FreeRTOS is present in the firmware image, a task inspector reads kernel structures from target memory through GDB while execution is halted. On QEMU sessions, task state may be polled during execution. Zephyr targets expose equivalent inspection at debug time. Zephyr west build integration is not included in the IDE build pipeline at this release.

4.4 Serial I/O Subsystem

The serial monitor attaches to USB-CDC devices on hardware targets and to the QEMU TCP serial endpoint during simulation. The implementation maintains a 100,000-line ring buffer with timestamping, ANSI escape sequence rendering, regular-expression filtering, transmit history, and session export. Following a QEMU programming operation, serial connection is established automatically.

HardwarePilot is the embedded AI subsystem. It operates in four modes: Ask for read-only technical queries; Plan for structured recommendations without file modification; Agent for source edits and build invocation subject to user approval; and Debug for register and memory operations during an active debug pause.

Each inference request is grounded in project-local context:

• Chip manifest and prescaler.json memory layout
• SVD register definitions loaded at project open
• Open source files, editor selection, and build diagnostics
• Debug halt location, call stack, locals, and peripheral register values
• Optional serial output tail and indexed datasheet excerpts

Model inference is routed through app.prescaler.ai for authenticated sessions. An unauthenticated session tracks a local, per-device trial allowance in the UI, but live inference requires sign-in; the shipping build does not perform live model calls for a signed-out user. Account authentication is provided through Supabase Auth with GitHub, Google, or email providers.

The current catalog contains fourteen MCU profiles, at varying levels of validation. STM32F405 is the primary reference platform, verified on real hardware: it includes a FreeRTOS demonstration project, a complete SVD register database, and QEMU simulation support. STM32F411 is QEMU-verified: a build-only demo project boots and runs its main loop under emulation (on the closest available machine model, not an exact match), but has not been run on real F411 silicon. STM32F103, STM32H743, nRF52840, STM32F746, STM32L476, STM32G031, nRF52832, and SAMD21 are build-verified: each compiles and links with the real toolchain, producing a real firmware image, confirmed both as a standalone demo and through the IDE's own wizard-generated output, but none has been booted under emulation or on real hardware yet (SAMD21's demo covers GPIO and clock gating only, no UART). Remaining ARM profiles provide OpenOCD target definitions, project wizard scaffolding, and a complete SVD register database each, but are not yet build-tested in-house. ESP32 provides register data for the Peripheral Browser and AI grounding, but its build and flash path is not wired into the IDE. The current catalog does not include AVR targets.

New projects may be created through the configuration wizard, imported from existing CMake, PlatformIO, or STM32CubeMX (.ioc) trees, or cloned from a remote Git repository. Import logic infers the target MCU from build metadata and generates prescaler.json when absent.

Planned capabilities for releases following the 1.0.0 beta include:

Prescaler 1.0.0 beta establishes an integrated firmware development environment in which editing, compilation, programming, debug, serial monitoring, and AI-assisted analysis operate against a unified hardware context. Subsequent releases will extend simulation coverage, peripheral data completeness, RTOS build integration, and host platform support while preserving the portable project formats that define the product's foundation.