Lumen

1. Motivation: Forcing System State Onto the Desk

Lumen started from a simple failure mode: system and application state stayed trapped behind windows and logs. Nothing
on the desk moved, blinked, or sounded different when builds broke, power spiked, or motion changed. The workspace
stayed visually flat even when the machine was on fire.

The goal for Lumen was to clamp on that gap and build a desk-first, programmable hardware presence:

• Link software and system state to physical feedback: lights, motion, sound, display.
• Keep the device useful even when the host PC is detached.
• Avoid custom programmers and opaque tools so users don’t get blocked before the first boot.

That forced three constraints:

1. Fully open source, firmware-level programmable.
   No “vendor firmware” blob that can’t be rebuilt.

2. Straightforward build and flash flow.
   A user with a browser should be able to flash CI-produced binaries through WebUSB without installing a toolchain.

3. Long-term desktop value over peak performance.
   If a small performance win broke reproducibility or required special jigs, it got dropped.

These constraints shaped everything: the stack, the drivers, and how the CI pipeline was wired.

2. Project Framework Design

2.1 Hardware Platform and System Layout

The hardware (v2) locks in the capabilities and therefore the firmware structure:

• MCU: ESP32‑C3
• Sensors and IO:
  • LSM6DSO IMU
  • INA226 current sensor
  • Buzzer
  • Rotary encoder
• Display:
  • 240×240 panel, ST7789‑like, driven via esp_lcd
• Power and connectivity:
  • USB‑C
  • Power switch

This stack forced a design where display throughput, motion sampling, power monitoring, and host I/O all run
concurrently without clobbering each other, under FreeRTOS.

2.2 Firmware Stack: FreeRTOS Core, Layered Drivers

At the firmware level, Lumen runs on ESP‑IDF v5.5 with FreeRTOS. The project is structured in layers rather than one
monolithic main.c:

1. Hardware drivers (C/C++):

   • Display panel via esp_lcd
   • I2C plumbing for LSM6DSO and INA226
   • Rotary encoder and buzzer
   • USB serial‑JTAG interface

2. System integration and logic:

   • FreeRTOS task graph
   • Motion task
   • UI rendering pipeline
   • Host serial protocol

3. Rust no‑std component (main_app):

   • Sits only in the system integration layer.
   • Does not replace the C/C++ hardware drivers.
   • Avoids a split stack where half the drivers live in one language and half in another.

Rust was pulled in specifically where it helped structure higher‑level integration logic, not to rewrite vendor SDK
surfaces. That constraint prevented a steady stream of build and tooling failures from dual ecosystems fighting each
other.

2.3 UI Stack: Vision‑UI on u8g2 on ST7789

The display stack uses a layered approach to keep UI changes from breaking lower layers:

• Vision‑UI: a small embedded UI library.
• u8g2: provides a mono framebuffer and drawing primitives.
• Panel driver: ST7789‑like display, driven via esp_lcd APIs.

Implementation lives in main/src/ui_hardware_driver.cpp:

• A global PANEL handle ties into esp_lcd.
• The UI code only sees a framebuffer and a driver callback to “send buffer,” not the exact panel timing.

This wiring means:

• UI layout changes do not force display driver changes.
• Display driver swaps stay local to the esp_lcd layer.
• The top‑level logic doesn’t need to know about DMA allocations or RGB565 conversions.

2.4 Build and Release: CI‑First, Web Flash Second

The build system is pinned down in .github/workflows/build.yml:

• GitHub Actions installs:
  • ESP‑IDF v5.5
  • A minimal Rust toolchain
  • The RISC‑V target for ESP32‑C3
• CI runs idf.py build and produces firmware artifacts.

Those artifacts feed a web flashing flow:

• Browser + WebUSB grabs the CI artifact and flashes the board.
• No local ESP‑IDF or Rust installation is required for basic users.

This flow looked heavier than a one‑off local build, but it removed a constant failure mode: users blocked by toolchain
setup. All complexity is clamped into CI instead of onto every developer’s machine.

3. Overhead Balance and Tradeoffs

3.1 Reproducibility vs. Performance

Several design choices pulled away from “fastest possible” and toward “reproducible and survivable”:

• Using ESP‑IDF v5.5 and esp_lcd adds abstraction and some overhead vs. hand‑tuned register banging, but:

  • It keeps code aligned with upstream.
  • It avoids a fragile, undocumented display driver that breaks when the next board spin rearranges pins.

• Driving the display through a u8g2 mono framebuffer and then converting to RGB565 is not the fastest route:

  • A direct color framebuffer could shave steps.
  • But it would lock UI code into a specific panel format.
  • The chosen route makes assets and widgets less brittle when the panel or bus changes.

The README explicitly notes that squeezing the last bit of performance did not win over long‑term desktop usefulness and
reproducibility.

3.2 Independence from the Host PC

Another hard constraint: the device must hold value even when unplugged from any PC.

Two consequences:

• Core logic cannot depend on serial I/O:

  • The serial pack protocol (host interaction) is optional.
  • Motion processing, display updates, and protection logic run without any host.

• UI decoupled from top‑level logic:

  • Input handling and UI rendering can change without rewriting the control loop.
  • Firmware doesn’t stall if the serial channel drops or a host app misbehaves.

This avoids a failure mode where an absent or crashed host application bricks device usefulness.

3.3 Web Flashing Limitations

The web flashing path trades one class of problems for another:

• Dependency on WebUSB support:

  • Some browsers and platforms simply do not support it.
  • In those cases, the user is forced back to local tooling.

• No CI caching yet:

  • The current CI build workflow does not cache IDF or build artifacts.
  • Every build re‑does configuration and compilation.
  • Builds therefore take longer than necessary.

The README calls these out instead of hiding them. Build times can be improved later by inserting caching or diff
builds, but correctness and repeatability were prioritized first.

4. Display Pipeline: Double‑Buffered DMA Under Pressure

4.1 Design Constraint

The display needed to refresh a 240×240 panel without stalling the MCU or blocking other tasks. Direct full‑frame copies
would overflow time budgets and starve motion and serial tasks.

To avoid that, the implementation uses line‑based double buffering with DMA‑capable memory:

• Defined in main/src/ui_hardware_driver.cpp.
• Globals and constants:
  • S_LINES[2]: two DMA‑capable line buffers.
  • S_BUF_BUSY[2]: flags to track which buffer is in-flight.
  • PARALLEL_LINES: number of lines per chunk; set to 128.
  • PANEL: esp_lcd_panel_handle_t.

4.2 Pipeline Behavior

1. Initialization (displayInit):

   • Allocates S_LINES[0] and S_LINES[1] with heap_caps_malloc using MALLOC_CAP_DMA | MALLOC_CAP_INTERNAL.
   • Sets up the panel via esp_lcd, including a callback:
     • onColorTransDone: fires when DMA completes for a chunk.

2. Rendering (vision_ui_driver_buffer_send):

   • UI code provides a mono u8g2 framebuffer.
   • The driver:
     • Splits it into RGB565 blocks of PARALLEL_LINES height.
     • For each block:
       • Finds a non‑busy buffer (S_BUF_BUSY[i] == false).
       • Converts mono data into RGB565 into that buffer.
       • Calls esp_lcd_panel_draw_bitmap on PANEL for that chunk.
       • Marks buffer busy.

3. DMA completion (onColorTransDone):

   • Clears the corresponding S_BUF_BUSY[i].
   • Signals that chunk buffer is ready to be reused.

This design keeps the CPU from sitting on long blocking writes. Conversion and DMA transfer are overlapped: while one
buffer is in flight, the other can be filled.

4.3 Tradeoffs

• Pros:

  • Reduced stalls on the display path.
  • Predictable memory footprint via PARALLEL_LINES control.
  • Easier tuning for future panels.

• Cons:

  • Extra copy step: mono → RGB565.
  • More state to track (S_BUF_BUSY, callbacks).
  • Harder debugging when transfers misalign.

The double‑buffering logic is deliberately localized in ui_hardware_driver.cpp so that higher layers don’t need to
know about DMA or panel quirks.

5. Motion Processing: IMU Task and Filters

5.1 Motion Task Setup

Motion handling sits in its own FreeRTOS task to avoid blocking UI or serial operations.

Implementation: main/src/motion.cpp.

Key pieces:

• IMU: LSM6DSO
• I2C access: shared handle, with wrappers:
  • imuWrite
  • imuRead
  • imuWriteThenRead
• Task:
  • motionInit sets up IMU and spawns motionTask with xTaskCreate.
  • Target rate: roughly 25 Hz.

5.2 Orientation Estimation

Two filter paths run on the sensor data:

1. 2‑state Kalman filter (espp::KalmanFilter<2>, S_KF):

   • Tracks roll and pitch.
   • Smooths noisy accel/gyro inputs.

2. Madgwick filter (MADGWICK):

   • Provides full orientation (quaternion).
   • Fuses accelerometer and gyroscope data.

5.3 Mounting Fix and Accel Scaling

The physical mounting ended up upside‑down relative to the IMU’s default orientation. That broke orientation output
early on. The fix:

• Axis flip:
  • Y and Z axes are flipped.
  • Gyro axes are also flipped accordingly.

Without this correction, roll/pitch estimates were mirrored and drifted in unexpected ways.

To keep the acceleration magnitude sane:

• Adaptive accel scaling:
  • Normalizes magnitude to approximately 9.80665 m/s².
  • Prevents gravity from drifting away due to calibration offsets.

This scaling avoids overflow in the filters and reduces long‑term drift.

5.4 Runtime Behavior

The motion task:

• Samples the IMU at ~25 Hz.
• Runs the Kalman and Madgwick updates.
• Exposes motion/pose data internally (and via host protocol).

By isolating this in one task, any stalls in host communication or display updates do not directly block sensor reads.
If CPU load increases, sampling may drop somewhat, but the rest of the system keeps running.

6. Serial “Pack” Protocol: Host Integration Without Entanglement

6.1 Requirements

Host connectivity needed to:

• Support structured commands and payloads.
• Avoid a tangled binary protocol that blocks easy debugging.
• Stay optional: no hard dependency for core firmware behavior.

6.2 Protocol Structure

The serial pack protocol lives in main/src/serial_pack.cpp and runs over the USB serial‑JTAG interface.

Basic flow for each message:

1. Path:

   • ASCII string.
   • Terminated by newline (\n).
   • Example: motion/data\n.

2. Length:

   • 4‑byte little‑endian integer.
   • Specifies payload size.

3. Payload:

   • Binary blob of that length.

A handler table routes messages based on the path.

6.3 Implementation Details

Constants:

• K_MAX_HANDLERS = 2
  Small fixed table; keeps memory fixed and simple.
• K_MAX_DATA_LEN = 2048
  Hard clamp to prevent payloads from blowing up buffers.
• K_RX_TIMEOUT_US = 3 * 1000 * 1000
  3‑second receive timeout.

Main functions:

• serialPackInit
  Sets up state.

• serialPackAttachHandler
  Registers handler callbacks:

  • Up to K_MAX_HANDLERS.
  • Each handler keyed by path string.

• serialPackStart / serialPackTask
  Runs the read loop:

  • Reads the path until newline.
  • Parses the 4‑byte length.
  • If length > K_MAX_DATA_LEN, the message is effectively rejected.
  • Reads the payload in chunks:
    • Dispatches chunks incrementally to handlers.
    • Applies timeout via K_RX_TIMEOUT_US.
  • Optional logging/preview to help debugging.

6.4 Tradeoffs and Failure Modes

• Low handler count (K_MAX_HANDLERS = 2):

  • Forces consolidation of endpoints.
  • Prevents unbounded growth of handler registrations.

• Payload clamp (K_MAX_DATA_LEN = 2048):

  • Protects against memory blow‑ups if a host goes rogue.
  • Blocks large streaming use cases unless the protocol is extended.

• Timeout (K_RX_TIMEOUT_US = 3s):

  • Prevents the parser from hanging forever on partial messages.
  • Under poor USB conditions, packets might get dropped or truncated when the timeout triggers.

By keeping the protocol text‑framed on the path and length‑delimited on the payload, debugging is still manageable with
simple serial tools.

7. Features and Observed Results

7.1 Hardware Feature Set (v2)

From the README and hardware directory, v2 boards include:

• Display: 240×240 ST7789‑like panel.
• Motion: LSM6DSO IMU.
• Power: INA226 current sensor on USB‑C path.
• Interaction:
  • Rotary encoder.
  • Buzzer.
• Power control: physical power switch.

This combination gives enough axes—visual, motion, and sound—to map varied system state into desk‑visible behavior.

7.2 Implemented Firmware Capabilities

Firmware features visible in the repository:

• USB‑C power monitoring and protection:

  • INA226 sensor used for current/voltage measurements.
  • Protection logic clamps down on unsafe conditions (details wired into the system logic).

• Motion tracking:

  • IMU readout with Kalman and Madgwick filters.
  • Mounting fix applied for orientation correctness.

• UI rendering via Vision‑UI:

  • Framebuffer driven UI.
  • Display assets embedded in firmware:
    • ui_assets_provider.cpp provides embedded images/fonts for Vision‑UI.

• Host communication:

  • Serial pack protocol over USB serial‑JTAG.
  • Structured path + length framing.

• Web quick flashing:

  • CI‑produced artifacts used directly by the web flasher.
  • No local toolchain needed for basic flashing.

7.3 Runtime Behavior and Observations

In combined operation, the system:

• Refreshes the 240×240 panel with double‑buffered DMA without starving FreeRTOS tasks.
• Samples motion at ~25 Hz while filtering orientation in real time.
• Streams motion and state over the serial pack protocol when a host is present.
• Continues to function (UI, motion, basic behavior) without any serial host connected.

Overhead is clearly present: layered UI, filters, serial protocol, CI scaffolding. But each layer was added in response
to a concrete failure mode—tooling blockage, display stalls, incorrect orientation, unsafe power behavior—rather than as
abstract design.

Lumen ends up as a reproducible, firmware‑level programmable desk companion that ties system state into light, motion,
and sound without depending on a constant host tether.

Vision-UI

Introduction

On most small embedded displays I’ve worked with, the hardware is fast enough, but the motion still doesn’t feel right.
Animations often look choppy or patched together.

I wanted to see whether a basic MCU — for example, an STM32F1 driving a 128×64 display — could produce motion that feels
more natural while staying lightweight enough for small devices.

This eventually became Vision UI.
But the goal wasn’t to “build a UI framework.”
It was mainly an attempt to understand what makes smooth motion and consistent visual behavior possible on tiny
hardware.

On small devices, smoothness doesn’t come for free.
Every animation curve, frame, and pixel shift has to contend with timing jitter, limited RAM, SPI bandwidth, and a
strict per-frame time budget. Vision UI is just the structure that formed while working through those constraints.

Positioning

Where Vision UI sits among existing embedded UI options

Note
Vision UI fills a specific gap between “handwritten drawing code” and “full GUI stacks”:

• If you only need a couple of static menus, handwritten u8g2 code is often enough.
• For complex touch interfaces, LVGL is the obvious choice.
• Vision UI lives in between: small OLED/TFT screens that mainly show lists or simple layouts, but still benefit from
  consistent, smooth motion, and swift development.

System Design

The constraints that shaped the design were straightforward:

• ~64 KB usable RAM
• 128×64 / 240×240 displays with partial/full buffers
• SPI/I2C bandwidth ceilings
• Unstable tick timing on MCU boards
• ~3–4 ms per frame
• Font rendering cost and limited caching

The constraints drove most of the decisions.
The framework grew as I worked through the hardware limits, rather than from a big upfront design.

Animation

Easing curves often look fine on isolated transitions, but they fall apart once you interrupt them.
Velocity doesn’t carry over, motions don’t combine well, and the transitions feel arbitrary.

A second-order ODE works better in this environment:

• continuous velocity
• natural-looking acceleration
• smooth interruption behavior
• single-parameter responsiveness
• intuitive to tune

Critically damped (no overshoot)

Lightly under-damped (with overshoot)

Interrupting animations and handling unstable dt required a few fixes (clamping, integration limits, etc.), but once
stable, the ODE motion system made the rest of the UI logic much simpler.

Challenges

A few issues took more time than expected:

• Keeping animation stable under variable frame times
• Making the motion system interrupt-friendly without breaking state
• Tuning motion parameters for responsiveness without losing natural behavior
• Keeping layout and animation logic consistent across driver backends
• Balancing smooth motion against a tight per-frame time budget

Performance

On a 240x240 OLED, Vision UI reaches around 220 FPS with the motion system active.
CPU usage stays under ~30% in my tests (at a fixed 80 FPS).

Conclusion

Working on this made me realize how little room small systems give you.
You end up keeping only what’s necessary.

If I were starting over, I’d probably build the motion system first, since it influences most of the other pieces.

I’m already using Vision UI in a few side projects, and I’ll keep adjusting it as new use cases show up.

Tip
I’ll keep adding details as the project moves forward.
If you’d like to follow along, you can find my Reddit and YouTube links under Relevant Links in the left menu.

[Foundation] Applied Electronics

1. Resistor

1.1 Voltage Division

Resistors can be connected in series to divide voltage, commonly used for ADC inputs or op-amp biasing.

• Consider the resistance ratio and ADC resolution when designing a divider.
• If low quiescent current is required, the divider’s output impedance increases, which affects accuracy:
  • The ADC’s internal sampling capacitor may not fully charge.
  • The measured voltage may have error due to the RC time constant.
• When measuring high currents, use a high-power resistor to handle heat dissipation.

1.2 Current Limiting

Used to limit current to safe levels.

• Typical use cases: LED current control, MOSFET gate protection, transistor base drive.

1.3 Pull-Up / Pull-Down

Used to define a stable logic level on floating pins (e.g., MCU inputs, I²C lines).

• Provides source current for open-drain/open-collector circuits.
• Typical resistance ranges:
  • I²C: 2.2k–400kΩ (commonly 4.7k–10kΩ)
  • MCU GPIO: ~10kΩ
• When low-power operation is critical, choose higher resistance to reduce quiescent current.

1.4 Stabilization / Damping

Used to isolate and stabilize signal lines.

• Known as isolation resistors or damping resistors.
• Reduces ringing, EMI, and cross-coupling on high-speed or sensitive traces.

2. Capacitor

2.1 Filtering / Decoupling

Used to smooth voltage and suppress high-frequency noise.

• Place as close as possible to IC power pins.
• Typical range: 0.01 µF – 100 µF.
• Pay attention to ESR (Equivalent Series Resistance) and stability.

2.2 Timing / Oscillator

Used in RC or LC timing and oscillator circuits.

• Time constant: τ = R × C
• Consider tolerance, temperature drift, and leakage current when selecting values.

2.3 Coupling / AC Blocking

Used to pass AC signals while blocking DC bias.

• Common in audio and amplifier stages.
• Choose capacitors with appropriate voltage ratings and low distortion.

2.4 Bypass / Noise Reduction

Used to shunt high-frequency noise and improve signal integrity.

• Small ceramic capacitors (e.g., 0.01 µF, 0.1 µF) are placed close to active components.
• Use multiple capacitors in parallel (e.g., 0.1 µF + 10 µF) to cover a wide frequency range.

2.5 Energy Storage / Pulsing

Used to store and release energy for short bursts.

• Common in power supplies and motor drivers.
• Use large electrolytics or supercapacitors with sufficient voltage and ripple current ratings.

2.6 Snubber / Damping

Used to suppress voltage spikes, ringing, and protect switches.

• Typically RC series networks.
• Values depend on transient energy, switching frequency, and load characteristics.

[Foundation] LCEDA

Quick Action

• Hide Selected Traces: Command+R
• Component Distributed By Region: Shift+P
• Select trace: selected tracing + Shift + W

Steps

1. Hide all traces.
2. Distribute component by region.
3. Hide all designators.
4. Import DXF board.
5. Start the layout.

[Foundation] PCB Layout Guidelines

1. Background

Trace Width vs Current (1 oz Copper)

For high-current paths, widen the trace, increase copper thickness, or apply solder coverage.

Additional Notes

• On compact boards, silkscreen reference designators can be omitted.
• Follow the 3W rule for high-speed signal integrity:
  → Distance between traces ≥ 3× trace width.

2. Layer Stack and Net Allocation

Two-Layer Board

• Bottom layer should be as continuous GND plane as possible.

Four-Layer Board Options

3. Layout Process

EMC Improvement

20H Rule

• Shrink the PWR plane by:
  • 20 mil → reduces electric field by ~70%
  • 100 mil → reduces electric field by ~98%

Recommended Workflow

1. Place mechanically constrained components first (USB, connectors, mounting holes).
2. Plan functional regions: power, digital, analog.
3. Route critical or high-speed signals first.
4. Add fanout vias for low-current power nets.
5. Complete all routing.
6. Optimize critical traces (short, direct, orthogonal).
7. Add teardrops and copper pour.
8. Refine and balance copper planes.
9. Run DRC checks, verify silkscreen and text orientation.
10. Export Gerber, Pick & Place, and BOM files.

4. Component Placement and Routing

General

• Align designators consistently (e.g., all facing same direction).

Quartz Crystal

• Guard crystal traces with a 10 mil GND ring.
• Do not route as differential pairs.
• Place as close as possible to MCU pins.
• Maintain a solid GND plane beneath.

USB 2.0 Interface

• D+/D− are differential pairs (~90 Ω differential impedance).
• No copper pour or vias underneath pair.
• Add bidirectional TVS diode across D+/D−.
• Add unidirectional TVS diode across VBUS and GND.
• Ensure trace widths and planes handle expected VBUS current.

Ground Domains

• Separate AGND, DGND, and PGND to minimize interference.
• Connect via:
  • Single point (star ground), or
  • Capacitive coupling between domains.

DC-DC Converter

• Keep SW and FB traces as short as possible.
• Isolate inductor from analog and high-speed regions.
• Surround with GND via fence to confine EMI.
• Place input/output capacitors close to pins — from bulk → ceramic.
• Check chip’s thermal resistance (°C/W) and ensure adequate copper area or vias for heat dissipation.

SDRAM Design

Single SDRAM

• Point-to-point routing.
• Place close to MCU/BGA (600–800 mil without resistors; 800–1000 mil with).
• Decoupling capacitors must be adjacent to power pins.

Dual SDRAM

• Place symmetrically relative to CPU.
• Prefer both on the same layer if space allows; otherwise, top/bottom mirrored.
• Maintain same routing length as single SDRAM layout.

Routing Notes

• Target impedance ≈ 50 Ω.
• Keep each 9-bit group (D0–D7 + LDQM, D8–D15 + HDQM) on one layer.
• Maintain ≥3W spacing or 20 mil between data, address, and clock lines.
• Add GND guard traces (15–30 mil) where possible.
• Length-match tolerances:
  • Data lines: ±50 mil
  • Addr/Ctrl/Clock: ±100 mil

TF (MicroSD) Card

Setup CLion with STM32CubeMX project for STM32 Development on macOS

Keil is very easy to handle for embedded development but might not have some functionalities such as code completion and inlay hint. This would trouble you especially when you want to conduct a big project.

IDEs by Jetbrains like Intellij and Pycharm are very popular in the market. They have many advantages including charming UIs, good usability, safe refactoring. Doubtlessly, their IDEs could greatly assist your coding works. CLion is a cross-platform IDE for C/C++ development by Jetbrains, and I will guide you to setup a basic development environment for STM32 with CLion in this tutorial.

Tools

Software

• A computer with macOS(for sure)
• CLion
• STM32CubeMX
• Homebrew

Hardware

• STM32 MCU
• ST-Link/J-Link

Installations

Prerequisites

CLion

The version should be higher than 2019.2.

STM32CubeMX

Downloading requires email verification.

• After you unzip the downloaded file, right-click the STM32CubeMX package and click Show Package Contents and right click to open the executable file inside the package.

• There will be an error window popped up. Click Cancel.

• Open Security & Privacy in System Preferences and click Allow Anyway.

• Open STM32CubeMX executable file again in the package and click Open.

• Install STM32CubeMX.

Homebrew

Validate the installation brew -v.

You should have installed these tools above before you continue the next step.

ARM Toolchain

• Run brew tap ArmMbed/homebrew-formulae and brew install arm-none-eabi-gcc in the terminal.

Validate the installation: arm-none-eabi-gcc -v.

OpenOCD

brew install open-ocd

Validate the installation: openocd -v.

CLion Configurations

OpenOCD & STM32CubeMX Paths

• Generally, both of your OpenOCD and CubeMX locations should be as same as me. Remember to test your paths by clicking Test.

Toolchains

• Set build tools, C/C++ compilers and debuggers. You should use Bundled GDB or like me, manually set another GDB path for Debugger option.

• Create a new STM32CubeMX project.

• Here, you can either click Use to choose a board type or click Skip to choose one later.

• Click Open with STM32CubeMX to open the application.

• The default MCU is STM32F030F4Px.

• You can use STM32CubeMX like what you do everyday.

• You have to select STM32CubeIDe in Toolchain / IDE setting, and the Project Name should be kept as same as the project name in CLion.

• After you generate code and overwrite the old project files, click Assist and choose a board type in Run/Debug Configurations.

• You also need to edit the board config file in accordance to the version of your ST-Link.

Congrats! You can now build, upload, and debug in CLion.

This blog has been established

Blog establishment