DEV Community: Hedy

How to Use Piper on a Raspberry Pi?

Hedy — Mon, 09 Feb 2026 10:30:43 +0000

1. What Is Piper (and Why You’d Use It on a Raspberry Pi)

Piper is a graphical mouse configuration tool for Linux.
It works together with libratbag, a background service that talks directly to supported mice over USB or Bluetooth.

On a Raspberry Pi, Piper is commonly used to:

Remap mouse buttons
Adjust DPI (sensitivity) levels
Configure polling rate
Set profiles (for gaming, CAD, robotics UI, kiosks)
Store settings directly in the mouse firmware (for supported models)

Typical use cases on Raspberry Pi:

Gaming or retro-console setups
Industrial HMIs using programmable mice
Lab setups where precise pointer control matters

2. Check Before You Start (Very Important)
2.1 Mouse Compatibility

Piper does not support all mice.

It supports mice that work with libratbag, including many models from:

Logitech (G series)
SteelSeries
Roccat
Corsair (limited models)

If Piper opens but shows “No devices found”, the mouse is likely unsupported.

3. Install Piper on Raspberry Pi OS
3.1 Update Your System

sudo apt update
sudo apt upgrade -y

3.2 Install Piper and libratbag

sudo apt install piper libratbagd -y

This installs:

piper → graphical configuration tool
libratbagd → background daemon that communicates with the mouse

4. Enable and Start the libratbag Service

Piper will not work unless the service is running.

sudo systemctl enable libratbagd
sudo systemctl start libratbagd

Check status:

systemctl status libratbagd

You should see:

Active: active (running)

5. Launch Piper

From the desktop:

Menu → Preferences → Piper

Or from terminal:

piper

If your mouse is supported, it will appear immediately.

6. Using Piper: Core Functions Explained
6.1 Button Mapping

In Piper, click any mouse button and assign:

Left / Right / Middle click
Keyboard keys
Media controls
Disabled (useful for kiosks)

Example
Map a side button to:

Ctrl + C for copy
Ctrl + V for paste
Shift for CAD navigation

➡ Engineering tip:
Button remapping is stored either in software or mouse firmware, depending on the model.

6.2 DPI (Sensitivity) Settings

Most gaming mice support multiple DPI stages.

In Piper you can:

Enable/disable DPI steps
Set exact DPI values (e.g. 400 / 800 / 1600 / 3200)
Choose DPI-switch behavior

Best practice on Raspberry Pi:

Desktop use: 800–1200 DPI
4K display or CAD: 1600–2400 DPI

6.3 Polling Rate

Polling rate defines how often the mouse reports position.

Typical options:

125 Hz
250 Hz
500 Hz
1000 Hz

➡ On Raspberry Pi:

500 Hz is usually the sweet spot
1000 Hz offers minimal benefit and more USB load

6.4 Profiles

Some mice allow multiple profiles:

Gaming
Desktop
CAD / 3D modeling

You can:

Switch profiles manually
Assign profiles to DPI buttons
Save profiles to mouse memory

7. Common Problems and How to Fix Them
Piper Opens but Shows “No Devices Found”

Causes

Mouse not supported
libratbag service not running
Insufficient permissions

Fix

sudo systemctl restart libratbagd

Try another USB port (avoid hubs).

DPI or Buttons Don’t Change

Causes

Mouse firmware doesn’t support onboard storage
Profile not applied

Fix

Click Apply or Save to Device
Replug mouse

Piper Crashes or Won’t Start

Fix

piper --debug

Check for missing GTK dependencies:

sudo apt install libgtk-3-0

8. Headless or Minimal Raspberry Pi (No GUI)

Piper requires a GUI.

If you are running:

Raspberry Pi OS Lite
Headless system

You must either:

Install a lightweight desktop (LXDE), or
Configure mouse via libratbag CLI (advanced, limited)

9. Performance and Stability Notes (Real-World Use)

Piper settings do not impact CPU load significantly
Mouse polling is handled in kernel space
Settings persist across reboot if stored in device

For industrial or kiosk deployments:

Test settings after power cycling
Avoid firmware-dependent profiles if reproducibility matters

10. When Piper Is the Right (or Wrong) Tool
Use Piper if:

You have a supported gaming/advanced mouse
You need DPI or button remapping
You want a GUI-based solution

Avoid Piper if:

Using generic office mice
Running headless Raspberry Pi only
Mouse not supported by libratbag

11. Final Takeaway

Using Piper on a Raspberry Pi is straightforward once you understand its dependency on libratbag and device support.

Workflow summary:

Install piper + libratbagd
Enable the service
Plug in a supported mouse
Configure DPI, buttons, and profiles
Save settings to device

How to change the VID / PID of an Arduino Nano?

Hedy — Tue, 03 Feb 2026 10:37:35 +0000

Changing the VID / PID of an Arduino Nano depends entirely on which USB interface chip your Nano uses. This is not a software setting you can change from a sketch; it is defined by the USB firmware of the USB-to-serial chip.

Below is a clear decision path → implementation steps → risks and procurement implications.

1. First: Identify which Arduino Nano you have (this decides everything)

There are three common Nano variants in the wild:

Nano type	USB chip	VID/PID changeable?	How
Original Nano	FT232RL	Yes	Reprogram EEPROM
Clone Nano (most common)	CH340 / CH341	No (practically)	Fixed in silicon
Newer Nano (ATmega328P + ATmega16U2)	ATmega16U2	Yes	Flash USB firmware

Most cheap Nano boards use CH340 → VID/PID cannot realistically be changed.

2. How to check which USB chip you have (don’t skip this)
On Windows

Plug in Nano
Open Device Manager → Ports (COM & LPT)
Check device name:
USB Serial Converter → FT232
USB-SERIAL CH340 → CH340
Arduino USB Serial → ATmega16U2

On Linux / macOS

lsusb

Example:

0403:6001  → FTDI (FT232)
1a86:7523  → CH340
2341:0043  → Arduino VID (16U2)

3. Case A — Nano with FT232RL (VID/PID CAN be changed)
What you need

FTDI drivers installed
FT_Prog (FTDI official utility, Windows)

Step-by-step

Install FT_Prog
Plug in Nano
Open FT_Prog → Scan and Parse
Navigate to:

USB Device Descriptor

Change:

Vendor ID
Product ID

Program device
Unplug and replug

Important warnings

Do NOT use a VID you do not own
Changing VID/PID may break drivers
Windows may require driver reinstallation

Procurement note

If you need custom VID/PID for a product, FT232 is acceptable only for low volume / internal tools. For shipping products, VID licensing matters.

4. Case B — Nano with CH340 / CH341 (VID/PID NOT changeable)
Reality check

VID/PID is hard-coded
No EEPROM
No official flashing tools
Internet “guides” claiming success are wrong or misleading

Your options

Option	Result
Try to flash	Impossible
Mask VID/PID in OS	Hacky
Replace USB chip	Not realistic
Use different Nano	Correct approach

Procurement implication

If you need VID/PID control, do not buy CH340-based Nanos.

5. Case C — Nano with ATmega16U2 (VID/PID fully programmable)

(Some “official-style” Nanos or custom boards)

What you need

ISP programmer (USBasp / AVRISP / another Arduino)
DFU or ISP flashing tools
Custom USB firmware

High-level steps

Put ATmega16U2 into DFU or ISP mode
Modify USB descriptors in firmware:

#define USB_VENDOR_ID  0xXXXX
#define USB_PRODUCT_ID 0xYYYY

Compile
Flash firmware
Replug device

Advantages

Full USB control
Can implement HID, CDC, composite devices

Risks

Easy to brick USB interface
Requires firmware + USB knowledge

6. Why Arduino sketches cannot change VID/PID

Your ATmega328P sketch never talks USB.

USB is handled by:

FT232 → external IC
CH340 → external IC
ATmega16U2 → separate MCU

So:

Serial.begin();

cannot affect VID/PID.

7. When do you actually NEED to change VID/PID?

Valid reasons:

Custom PC software binding
USB driver matching
Composite USB device
Product branding

Invalid reasons:

“Just curiosity”
Fixing driver problems
Bypassing OS permissions

8. Best practice recommendations (engineering + purchasing)
If you just want Arduino compatibility

Do NOT change VID/PID

If you need custom VID/PID

Use:

Arduino with ATmega16U2
Native USB MCU (ATmega32U4, RP2040, STM32, ESP32-Sx)

If you’re building a product

Do NOT ship with Arduino VID
Buy your own VID or use USB-IF PID programs

9. Quick decision summary

Your Nano has…	Can you change VID/PID?	Recommended action
FT232	Yes	Use FT_Prog carefully
CH340	No	Replace board
ATmega16U2	Yes	Flash custom firmware

Final takeaway

Changing Arduino Nano VID/PID is a hardware decision, not a software trick.

If VID/PID control matters:

Choose the right USB interface chip
Decide this before procurement
Don’t try to “fix it later in firmware”

How to activate/deactivate other circuits with higher voltage from a microcontroller?

Hedy — Fri, 30 Jan 2026 10:37:33 +0000

To switch (activate/deactivate) higher-voltage circuits from a microcontroller, you’re really choosing an isolation + switching method that matches:

Voltage & current of the load
AC vs DC
Switching speed (slow on/off vs PWM)
Isolation requirement (safety/EMC)
Failure mode you can tolerate (stuck ON is dangerous)

Below is a practical decision guide, then concrete wiring patterns and real part examples.

1) Decision logic: pick your switching “class”
A) DC load, low/medium current, want efficiency → MOSFET switch

Best for: 12V/24V solenoids, LED strips, DC motors (on/off), heaters
Pros: efficient, cheap, fast (PWM capable)
Cons: needs correct MOSFET + gate drive + protection

Choose low-side vs high-side

Low-side (N-MOSFET): easiest, cheapest
High-side (P-MOSFET or high-side driver): needed when load must stay referenced to ground or for automotive conventions

B) AC mains load (110/230VAC) → Relay or Triac SSR

Best for: lamps, heaters, mains pumps
Pros: simple, isolation is common, safe when done right
Cons: mechanical relays wear; triac SSRs leak current and aren’t for DC

C) Need galvanic isolation or noisy environment → Optocoupler + switch

Best for: industrial systems, long cables, high EMI, safety isolation
Pros: strong noise immunity, safety barrier
Cons: slower, extra BOM, layout/creepage rules

D) Need to switch “anything” including unknown loads → Relay

Best for: prototypes, universal switching, low frequency
Pros: load-agnostic, real isolation
Cons: size, coil power, lifetime, contact arcing

2) The most common (and safest) patterns
Pattern 1 — DC load with low-side N-MOSFET (most common)

Use when: DC loads where switching the return (ground) is acceptable.

Wiring

Load + → +V (e.g., 12V)
Load − → MOSFET Drain
MOSFET Source → GND
MCU GPIO → gate resistor → MOSFET Gate
Gate pulldown to GND
Flyback diode across load if inductive (relay/solenoid/motor)

Typical values

Gate resistor: 33–220 Ω
Gate pulldown: 100 kΩ
Flyback diode: Schottky/fast diode sized for current

Part selection

MOSFET: logic-level N-MOSFET (low Rds(on) at 3.3V/5V gate)
If PWM or large MOSFET: consider a gate driver

Example parts (no vendor preference, just common families)

N-MOSFETs: IRLZ44N (older but common), AO3400A (small loads), AOD4184A (mid power)
Flyback diode: SS34, 1N5819 (small), UF4007 (faster than 1N4007)

Procurement impact: MOSFET selection changes thermal design and heatsink needs; diode selection changes EMI and reliability.

Pattern 2 — DC load with high-side switch (safer ground, common in automotive)

Use when: you can’t “lift” the load ground, or you need the load referenced to chassis ground.

Options:

P-MOSFET high-side (simple for low current)
Dedicated high-side switch IC (best for robustness)
N-MOSFET + driver/charge pump (for high current, low losses)

Recommended for products: High-side switch IC

Built-in current limit, thermal shutdown, diagnostics (depends on part)
Much more tolerant of shorts and hot-plug

Example part families

High-side switch ICs: BTS/PROFET-style, TPS1H/TPS2H-style, VNQ/VND-style
(choose by voltage/current/channel count)

Procurement impact: IC high-side switches reduce field failures and simplify safety compliance, but cost more than a discrete MOSFET.

Pattern 3 — Relay module (universal on/off, slow switching)

Use when: AC mains, unknown load type, or you need real isolation.

MCU cannot drive relay coil directly (usually).
Use:

NPN transistor or N-MOSFET coil driver
Flyback diode across coil
Separate supply for the coil (often 5V or 12V)

Example driver parts

NPN: 2N2222, S8050
Coil diode: 1N4148 (small relays) or 1N4007
Relay: SRD-05VDC-SL-C class modules (for learning), or industrial relays for products

Procurement impact: Relays have lifecycle (mechanical), contact ratings, and sourcing variability; specify contact type and derate.

Pattern 4 — Solid-state relay (SSR)
For AC loads: Triac SSR

Pros: silent, long life, easy isolation
Cons: leakage current, heat at high current, not for DC

Examples

SSR modules: SSR-xxDA style (AC output, DC input control)
Prefer “zero-cross” for heaters/lamps, “random turn-on” for phase control

For DC loads: MOSFET SSR

Pros: isolation + DC switching
Cons: higher cost, on-resistance causes heat

3) Protection you should almost always add (affects success rate)
Inductive loads (relays, solenoids, motors)

Flyback diode (DC) or RC snubber / MOV (AC)
Optional: TVS diode on the supply rail to clamp spikes

MCU pin protection

If the switch driver is off-board / long cable:

series resistor (100–1k)
ESD diode/TVS near connector

Procurement impact: Adding protection parts is cheap insurance—dramatically reduces returns and “random reset” complaints.

4) Quick “choose this” table

Your load	Best default	Notes
12V LED strip (on/off or PWM)	Low-side N-MOSFET	Add fuse if long strip
24V solenoid	Low-side N-MOSFET + flyback	Diode must handle current
DC motor (on/off)	N-MOSFET + flyback/TVS	For direction control use H-bridge
AC heater/lamp	Relay or AC SSR	SSR leaks; relay clicks
Automotive load	High-side switch IC	Handles faults better
High noise/industrial	Optocoupler + MOSFET/relay	Layout & creepage matter

5) Two common failure modes (and fixes)

1. MCU resets when load switches
Cause: supply dip / ground bounce / EMI
Fix: separate power rails, star ground, bulk cap (≥470 µF) near load, diode/TVS, shorten high-current loop.

2. MOSFET runs hot
Cause: wrong MOSFET (not logic-level), high Rds(on), inadequate gate drive
Fix: choose MOSFET specified at your gate voltage, reduce switching losses, add driver or heatsinking.

How to program STM32 microcontroller?

Hedy — Mon, 26 Jan 2026 09:47:22 +0000

Programming an STM32 is a pipeline of four layers:

1. Write firmware (source code)
You write C/C++ (sometimes Rust) that configures peripherals (GPIO, UART, timers, ADC, etc.) and implements your application logic.

2. Build (compile + link) into a binary
Your toolchain (GCC/Clang/IAR/Keil) turns code into:

.elf (debuggable output)
.bin / .hex (flashable image)

3. Program (flash) the binary into on-chip Flash
STM32 stores your firmware in internal Flash. You load it using one of the supported programming paths:

SWD (Serial Wire Debug) via ST-LINK/J-LINK (most common)
ROM bootloader (UART/I2C/SPI/USB DFU depending on chip) for “no debugger” flashing
Mass storage drag-and-drop (on boards with built-in ST-LINK)

4. Reset + boot sequence runs your app
On reset, the MCU fetches the reset vector from Flash and starts executing. BOOT pins (e.g., BOOT0) decide whether it boots from Flash or jumps to ROM bootloader.

Key concept: SWD vs Bootloader

SWD = best for development (debugging, breakpoints, “connect under reset”, fastest iteration)
Bootloader = best for production updates or rescue when SWD isn’t available

Practical paths (the 3 common ways)
A) SWD programming (recommended for engineering work)

Hardware: ST-LINK/V2 (or onboard ST-LINK on Nucleo/Discovery)

Signals you need (typical):

SWDIO
SWCLK
GND
3V3 (VTref, recommended)
NRST (optional but very helpful)

Why it’s the best

You can flash + debug in one click
You can recover chips with “connect under reset”
Works even if your firmware breaks clocks/peripherals

B) ROM bootloader (no debugger required)

Most STM32 families include a factory ROM bootloader.

Typical boot entry logic

Set BOOT0 = 1
Reset
MCU runs the ROM bootloader and waits for UART/USB DFU/etc.

Why it’s used

Production line flashing
Field firmware update
“My SWD pins are not accessible” scenarios

C) Drag-and-drop (only on some dev boards)

Boards with ST-LINK often expose a “USB drive”. Copy .bin → it flashes.
Good for beginners, but SWD debugging is still the real workflow.

Example 1: STM32F103C8T6 (“Blue Pill”) via ST-LINK (SWD)
What you use

MCU/Board: STM32F103C8T6 (Blue Pill)
Programmer: ST-LINK/V2
IDE: STM32CubeIDE (or CubeProgrammer for pure flashing)

Wiring (most common)

ST-LINK SWDIO → Blue Pill PA13
ST-LINK SWCLK → Blue Pill PA14
ST-LINK GND → GND
ST-LINK 3V3 (VTref) → 3V3
(Optional) ST-LINK NRST → NRST

Workflow

Create a project in STM32CubeIDE for STM32F103C8T6.
Configure GPIO for an LED pin (many Blue Pills use PC13 LED).
Build → get .elf and .bin.
Click Debug (or Run). CubeIDE flashes via ST-LINK and starts debugging.
Verify by toggling the LED in a loop.

Why this works well: F103 + SWD is simple, stable, and very common.

Example 2: STM32F401RE (Nucleo-F401RE) “one cable” programming + debug
What you use

Board: Nucleo-F401RE (STM32F401RE)
Tool: The board’s onboard ST-LINK
Connection: USB cable only

Workflow

Plug the Nucleo into PC via USB.
Build your project in CubeIDE.
Click Debug → it flashes and debugs automatically.

Best part: No external programmer wiring needed.

Example 3: STM32G030F6P6 (or similar) via UART bootloader (no ST-LINK)
What you use

MCU: STM32G030F6P6 (common low-cost STM32G0)
Tool: USB-to-UART adapter (3.3V logic)
Software: STM32CubeProgrammer

Typical steps (conceptual)

Wire UART:

MCU USART_RX ↔ adapter TX
MCU USART_TX ↔ adapter RX
GND ↔ GND

Pull BOOT0 high (how you do this depends on your PCB/board).
Reset the MCU.
In CubeProgrammer: choose UART, select COM port → Connect.
Program .bin/.hex.
Set BOOT0 low again and reset → app boots from Flash.

Why this matters: You can program a bare chip even without SWD access.

Common “it won’t program” reasons (fast diagnosis)

No common ground between programmer and target
BOOT0 left high → MCU stuck in bootloader
Wrong voltage / unstable power
SWD pins reused / noisy wiring → lower SWD speed, use short wires
Need NRST for “connect under reset” recovery

Quick rule-of-thumb for choosing the programming method

Developing firmware + debugging → SWD with ST-LINK
Factory flashing / field updates → ROM bootloader (UART/USB DFU)
Learning on Nucleo → onboard ST-LINK is easiest

How to pause FPGA based digital clock through buttons on FPGA?

Hedy — Fri, 23 Jan 2026 10:15:07 +0000

1) what “pause” means in an FPGA digital clock

A typical FPGA digital clock has at least two parts:

1. Time base (tick generator)

Creates a clean 1 Hz (or 100 Hz) “tick” from the FPGA system clock (e.g., 50 MHz / 100 MHz).
This tick drives seconds/minutes/hours counters.

2. Timekeeping counters + display driver

Counters update time on each tick.
Display driver (7-segment / LCD / VGA) continuously refreshes.

To “pause the clock” with a button, the safest approach is:

Best practice: freeze timekeeping, not the whole FPGA clock

Keep the FPGA system clock running normally (display scanning still works).
Pause only the time update by using a run enable (run=1) / pause (run=0) flag.
When paused, you stop consuming the 1 Hz tick (or stop incrementing counters).

Why?

You avoid glitchy clock gating.
Timing closure stays clean.
Display remains stable and readable.

2) Button theory: why you must condition button signals

A push button is:

Asynchronous to the FPGA clock → can cause metastability
Bouncy → a single press can generate many transitions

So the standard chain is:

2-FF synchronizer (bring button into clk domain)
Debounce filter (counter or shift register)
Edge detect (make a one-clock “pressed” pulse)
Toggle run flag (run <= ~run on each press)

This ensures one press = one toggle, reliably.

3) Architecture for a pauseable FPGA digital clock

Signals

tick_1hz_pulse — one-cycle pulse each second (generated from sysclk)
run — 1 = running, 0 = paused
sec, min, hour counters

Update rule

If run==1 and tick_1hz_pulse==1 → increment time
Else → hold time steady

Display rule

Display driver runs continuously (always refresh)
It reads sec/min/hour and shows them

4) Real example (Artix-7 FPGA digital clock paused by a button)
Example target hardware

FPGA family: Xilinx Artix-7
Typical dev board: Basys 3 (XC7A35T) or Nexys A7 (XC7A100T)
System clock: 100 MHz (common on these boards)
Inputs: btn_pause
Outputs: 7-segment display (HH:MM) or LEDs

Below is a Verilog reference design showing:

Button conditioning
1 Hz tick generator
Time counters (HH:MM:SS internally)
Pause via run enable

A) Button conditioner (sync + debounce + press pulse)

module button_conditioner #(
    parameter integer CLK_HZ = 100_000_000,
    parameter integer DEBOUNCE_MS = 20
)(
    input  wire clk,
    input  wire rst,
    input  wire btn_async,
    output wire pressed_pulse
);
    // 1) Synchronize
    reg [1:0] sync;
    always @(posedge clk) begin
        if (rst) sync <= 2'b00;
        else     sync <= {sync[0], btn_async};
    end
    wire btn_sync = sync[1];

    // 2) Debounce
    localparam integer COUNT_MAX = (CLK_HZ/1000)*DEBOUNCE_MS;
    reg [$clog2(COUNT_MAX+1)-1:0] cnt;
    reg btn_stable;

    always @(posedge clk) begin
        if (rst) begin
            cnt        <= 0;
            btn_stable <= 1'b0;
        end else begin
            if (btn_sync == btn_stable) begin
                cnt <= 0;
            end else begin
                if (cnt == COUNT_MAX[$clog2(COUNT_MAX+1)-1:0]) begin
                    btn_stable <= btn_sync;
                    cnt <= 0;
                end else begin
                    cnt <= cnt + 1'b1;
                end
            end
        end
    end

    // 3) Rising-edge detect
    reg btn_d;
    always @(posedge clk) begin
        if (rst) btn_d <= 1'b0;
        else     btn_d <= btn_stable;
    end
    assign pressed_pulse = btn_stable & ~btn_d;
endmodule

B) 1 Hz tick generator (from 100 MHz)

module tick_1hz #(
    parameter integer CLK_HZ = 100_000_000
)(
    input  wire clk,
    input  wire rst,
    output reg  tick_pulse
);
    localparam integer DIV = CLK_HZ; // 100M cycles -> 1 second
    reg [$clog2(DIV)-1:0] c;

    always @(posedge clk) begin
        if (rst) begin
            c <= 0;
            tick_pulse <= 1'b0;
        end else begin
            tick_pulse <= 1'b0;
            if (c == DIV-1) begin
                c <= 0;
                tick_pulse <= 1'b1; // one-cycle tick
            end else begin
                c <= c + 1'b1;
            end
        end
    end
endmodule

C) Digital clock core with pause (HH:MM:SS)

module digital_clock_pause (
    input  wire clk,          // 100 MHz
    input  wire rst,
    input  wire btn_pause_async,
    output reg  run_led,        // shows running/paused
    output reg [5:0] sec,
    output reg [5:0] min,
    output reg [4:0] hour
);
    wire pause_press;
    button_conditioner #(.CLK_HZ(100_000_000), .DEBOUNCE_MS(20))
    u_btn (.clk(clk), .rst(rst), .btn_async(btn_pause_async), .pressed_pulse(pause_press));

    // run flag toggles on each press
    reg run;
    always @(posedge clk) begin
        if (rst) run <= 1'b1;
        else if (pause_press) run <= ~run;
    end

    always @(posedge clk) begin
        if (rst) run_led <= 1'b1;
        else     run_led <= run;
    end

    wire tick_1s;
    tick_1hz #(.CLK_HZ(100_000_000)) u_tick (.clk(clk), .rst(rst), .tick_pulse(tick_1s));

    // Timekeeping: only updates when run==1 AND tick arrives
    always @(posedge clk) begin
        if (rst) begin
            sec  <= 0;
            min  <= 0;
            hour <= 0;
        end else if (run && tick_1s) begin
            if (sec == 59) begin
                sec <= 0;
                if (min == 59) begin
                    min <= 0;
                    if (hour == 23) hour <= 0;
                    else            hour <= hour + 1'b1;
                end else begin
                    min <= min + 1'b1;
                end
            end else begin
                sec <= sec + 1'b1;
            end
        end
        // else paused: hold sec/min/hour
    end
endmodule

How “pause” works here

The 1 Hz tick keeps being generated.
When paused, the counters simply ignore the tick.
Your display logic can keep refreshing uninterrupted.

5) How to connect this to a 7-segment display (concept)

On boards like Basys 3, the 7-segment is multiplexed:

You run a scan timer (e.g., 1 kHz–10 kHz)
Cycle through digits and drive segment lines
Convert hour/min/sec to BCD digits

Important: don’t pause the scan timer, only pause timekeeping.

6) Practical model examples (real FPGA targets)
Xilinx examples (common)

Basys 3 (XC7A35T, 100 MHz clock) — ideal for button + 7-seg digital clock demos
Nexys A7 (XC7A100T, 100 MHz clock) — similar approach, more resources

Intel examples

DE10-Lite (MAX 10) — same RTL idea (sync/debounce + run enable), just different pin constraints.

7) Common mistakes (and quick fixes)

Mistake: Button causes multiple pause toggles
Fix: Debounce + edge detect (as above)
Mistake: Trying to gate the clock with the button
Fix: Use run enable on counters instead
Mistake: Display goes blank when paused
Fix: Keep display scan logic always running
Mistake: Multi-clock designs pause only one domain
Fix: Synchronize run into each clock domain (or centralize timekeeping to one domain)

How to Use printf() on STM32 via Serial (UART)?

Hedy — Thu, 22 Jan 2026 10:30:44 +0000

Below is a practical, step-by-step guide to using printf() on an STM32 via a serial (UART) wire, written for real projects (CubeIDE / HAL style).
This is the most common and reliable debugging method on STM32.

1. Theory: How printf() Works on STM32

printf() does not magically know where to print.
On STM32, you must redirect the standard output (stdout) to a UART peripheral.

Data flow

printf()
  ↓
_putchar() / _write()
  ↓
UART TX register
  ↓
USB-UART adapter
  ↓
PC serial terminal

So the core steps are:

Initialize UART
Retarget printf() to UART
Connect UART TX to a PC

2. Hardware Setup (Serial Wire)
2.1 Required Hardware

STM32 board (e.g. Nucleo, Black Pill, Blue Pill)
USB-to-UART adapter (3.3 V logic!)
PC with serial terminal

2.2 Typical Wiring

USB-UART	STM32
TX	RX (e.g. PA10 for USART1)
RX	TX (e.g. PA9 for USART1)
GND	GND

Do NOT connect 5 V to STM32 UART pins

3. Configure UART (STM32CubeIDE / HAL)
Example: USART1 @ 115200 baud

Mode: Asynchronous
Word length: 8 bits
Parity: None
Stop bits: 1
Flow control: None

CubeIDE will generate:

UART_HandleTypeDef huart1;

4. Retarget printf() to UART (HAL)
4.1 Add this code (GCC / CubeIDE)

In main.c or a separate retarget.c:

#include <stdio.h>
#include "stm32f4xx_hal.h"

extern UART_HandleTypeDef huart1;

int _write(int file, char *ptr, int len)
{
    HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, HAL_MAX_DELAY);
    return len;
}

This redirects all printf() output to USART1.

4.2 Use printf() normally

printf("Hello STM32!\r\n");
printf("ADC value = %d\r\n", adc_value);
printf("Voltage = %.2f V\r\n", voltage);

5. PC Side: Serial Terminal

Use any terminal:

PuTTY
Tera Term
Arduino Serial Monitor
minicom (Linux)

Settings

Baud rate: 115200
Data bits: 8
Parity: None
Stop bits: 1
Line ending: CR+LF recommended

6. Common Problems & Fixes
Nothing prints

TX/RX swapped
Wrong UART instance
Baud rate mismatch
Forgot \r\n

Output is garbled

Wrong baud rate
Clock configuration incorrect
USB-UART is 5 V logic

printf() causes huge flash usage

printf() pulls in heavy formatting code.

Fix

Enable newlib-nano
Avoid floats if possible

CubeIDE:

Project → Properties → C/C++ Build → Settings
→ MCU Settings → Use newlib-nano

7. Lightweight Alternatives (Recommended for Production)
7.1 sprintf() + HAL_UART_Transmit()

char buf[64];
sprintf(buf, "Temp=%d\r\n", temp);
HAL_UART_Transmit(&huart1, (uint8_t*)buf, strlen(buf), 100);

7.2 puts() (very small footprint)

puts("System started\r\n");

8. Performance Tips (Important!)

printf() is blocking
Avoid calling it in:
- Interrupts
- High-frequency loops
Use DMA for high-speed logging
Throttle output frequency

9. Example: STM32 Black Pill (STM32F401/F411)

UART

USART1
TX = PA9
RX = PA10

Code

printf("Black Pill ready\r\n");

Terminal

115200 baud
CRLF

Key Engineering Takeaway

On STM32, printf() is a debugging tool, not a logging system.
Use it wisely, retarget it properly, and never trust it inside interrupts.

How to Overclock a Raspberry Pi?

Hedy — Wed, 21 Jan 2026 09:28:26 +0000

Overclocking a Raspberry Pi means running the CPU, GPU, and memory at higher frequencies than default to gain extra performance. It’s popular for media centers, light servers, emulation, and development work—but it must be done carefully.

Below is a step-by-step, engineering-oriented guide, including limits, cooling, and recovery.

1. Before You Overclock (Very Important)
Supported Models

Overclocking works best on:

Raspberry Pi 3B / 3B+
Raspberry Pi 4 Model B
Raspberry Pi 5 (more advanced cooling required)

What You Need

Proper cooling (heatsink + fan strongly recommended)
Stable power supply
- Pi 4: ≥ 5V / 3A
- Pi 5: ≥ 5V / 5A
Updated OS

sudo apt update && sudo apt upgrade -y

2. Check Current Frequencies & Temperature
CPU Frequency

vcgencmd measure_clock arm

Temperature

vcgencmd measure_temp

Throttling starts at 80°C.

3. Overclocking Method (config.txt)

Raspberry Pi overclocking is done via:

/boot/config.txt

Open the file

sudo nano /boot/config.txt

4. Safe Overclock Settings (By Model)
Raspberry Pi 4 (Recommended Starting Point)

arm_freq=1800
gpu_freq=600
over_voltage=4

More Aggressive (Requires Good Cooling)

arm_freq=2000
gpu_freq=750
over_voltage=6

Typical defaults:

CPU: 1500 MHz
GPU: 500 MHz

Raspberry Pi 3B+

arm_freq=1400
gpu_freq=400
over_voltage=2

Raspberry Pi 5 (Advanced)

arm_freq=2600
over_voltage=4

Pi 5 must have an active cooler.

5. Save & Reboot

sudo reboot

After reboot, verify:

vcgencmd measure_clock arm

6. Stress Test (Do NOT Skip)

Install stress tool:

sudo apt install stress -y

Run CPU stress test:

stress --cpu 4 --timeout 300

Monitor temperature:

watch -n 1 vcgencmd measure_temp

If you see:

sudden reboots
throttling messages
temperature > 80°C

→ Reduce frequency or improve cooling.

7. Throttling & Stability Check

Check throttling flags:

vcgencmd get_throttled

0x0 → No throttling
Other values → Power or thermal issues

8. Cooling Strategies (Critical for Engineers)

Cooling Method	Suitable For
Passive heatsink	Mild overclock
Heatsink + fan	Most setups
Active cooler (Pi 5)	Heavy overclock
Metal case (heat spreader)	Silent builds

Cooling matters more than voltage.

9. Power Stability Tips

Use short, thick USB-C cables
Avoid cheap power adapters
Check undervoltage warning:

vcgencmd get_throttled

10. How to Recover from a Failed Overclock

If your Pi won’t boot:

Method A: Edit SD Card on Another PC

Insert SD card into another computer
Open config.txt
Remove overclock lines
Save and reinsert

Method B: Safe Mode (Pi 4/5)

Hold SHIFT during boot (HDMI connected).

11. Does Overclocking Void Warranty?

Old models: yes (historically)
Newer models: Raspberry Pi firmware no longer permanently flags overclocking Still:
Physical damage from heat not covered

12. When Overclocking Makes Sense

✅ Emulation
✅ Media encoding
✅ Compiling code
✅ Light servers

❌ 24/7 mission-critical systems
❌ High-temperature environments

Recommended Safe Rule of Thumb

Moderate frequency + excellent cooling + stable power
beats extreme overclocking every time.

How to turn on an Arduino LED in Tinkercad?

Hedy — Tue, 20 Jan 2026 09:14:24 +0000

Here’s the simplest, step-by-step way to turn on an Arduino LED in Tinkercad, perfect for beginners.

Step 1: Open Tinkercad Circuits

Go to Tinkercad
Click Circuits
Click Create new Circuit

You’ll see an empty workspace.

Step 2: Add Components

From the components panel (right side), drag in:

Arduino Uno
LED
Resistor (220 Ω or 330 Ω is ideal)

Step 3: Wire the LED Correctly

LEDs are polarized, so direction matters.

Correct wiring

Arduino pin 13 → Resistor
Resistor → LED long leg (Anode +)
LED short leg (Cathode −) → Arduino GND

Why the resistor?

It limits current and prevents the LED from burning out.

Step 4: Write the Arduino Code

Click Code → Text and paste this:

void setup() {
  pinMode(13, OUTPUT);   // Set pin 13 as output
}

void loop() {
  digitalWrite(13, HIGH); // Turn LED ON
}

This turns the LED on continuously.

Step 5: Start the Simulation

Click Start Simulation

The LED should light up immediately.

Common Beginner Mistakes (and Fixes)

Problem	Fix
LED doesn’t turn on	Flip the LED (polarity matters)
LED very dim	Wrong resistor value (use 220–330 Ω)
Nothing happens	Make sure simulation is running
Wired to wrong pin	Code and wiring pin numbers must match

Bonus: Blink the LED (Optional)

Replace loop() with this:

void loop() {
  digitalWrite(13, HIGH);
  delay(1000);            // 1 second ON
  digitalWrite(13, LOW);
  delay(1000);            // 1 second OFF
}

Now the LED will blink every second.

Pro Tip (Tinkercad shortcut)

Arduino pin 13 already has a built-in LED.
You can skip all wiring and just run:

void setup() {
  pinMode(13, OUTPUT);
  digitalWrite(13, HIGH);
}
void loop() {}

The tiny LED on the Arduino board will turn on.

How to simulate microcontroller output with maximum current and high voltage?

Hedy — Mon, 19 Jan 2026 10:30:03 +0000

A microcontroller (MCU) pin can’t directly output “maximum current + high voltage.” In theory, an MCU GPIO is a logic-level signal source (3.3 V / 5 V, limited current), and any “high voltage / high current output” is created by an external power stage that the GPIO controls.

What you’re really doing is simulating a “power output” that is commanded by a microcontroller:

MCU GPIO (logic) → level shift / gate drive → power switch (MOSFET/IGBT/high-side switch) → external HV supply → load

Below: theory first, then real, concrete part-number examples (no vendor names needed in your final article if you prefer, but I’m using well-known model numbers here so it’s actionable).

1) Theory: model the MCU output correctly
1.1 GPIO is not a power source

A GPIO pin behaves roughly like:

A voltage source (VDD, e.g., 3.3 V)
With finite output resistance (so voltage droops as current increases)
With strict absolute max limits (overcurrent can cause latch-up, permanent damage)

So you should never “maximize” current from the pin. Instead you use it as a control signal.

1.2 High voltage and high current come from the external supply

To simulate an MCU “power output,” you provide:

HV supply (12 V / 24 V / 48 V / 60–400 V, depending on your target)
Current capability (amps to tens of amps)
A switch (MOSFET/IGBT) that connects/disconnects the load
Protection (flyback diode, TVS, current limiting, fusing)

1.3 Two switching topologies

Low-side switching (most common, simplest)

Load to +HV
Switch to ground
Best for: solenoids, motors, heaters, LED strips, relays

High-side switching (when load must stay at ground)

Switch connects +HV to load
Best for: automotive-style wiring, grounded loads, “sourcing” outputs

1.4 “Maximum current” is a power-stage problem

If you want “max current simulation,” you control it by:

A bench supply current limit (simple)
A sense resistor + current limiter (accurate)
A high-side/low-side current monitor and firmware control
An electronic fuse / hot-swap controller for safety

1.5 If you need analog high-voltage outputs

For 0–10 V: PWM/DAC → op-amp (powered from higher rail) → 0–10 V
For 4–20 mA: PWM/DAC → current-loop driver → loop supply (often 24 V)

2) Practical simulation recipes (what engineers actually do)
Recipe A — High-voltage ON/OFF (DC loads): MOSFET low-side

Goal: MCU pin “simulates” switching a 24 V load at several amps.

Blocks

MCU GPIO → gate resistor + pulldown
Logic-level N-MOSFET (or gate driver + MOSFET for bigger loads)
Flyback diode if inductive
TVS on supply for transient suppression

Why it works: MCU only charges/discharges a gate (microamps average); the MOSFET and supply deliver amps.

Recipe B — High-side “sourcing” output (automotive/industrial)

Goal: Simulate a PLC/ECU output that sources 24 V to a load.

Use either:

A high-side switch IC (easiest + protections)
Or P-MOSFET + driver (good for moderate voltage/current)

Recipe C — High voltage (tens to hundreds of volts): isolated gate drive + MOSFET/IGBT

Goal: Simulate an MCU controlling a 100–400 V power stage (e.g., DC bus).

You typically need:

Isolation (digital isolator or optocoupler)
Gate driver (often isolated)
MOSFET/IGBT with correct voltage/current ratings
Snubbers/TVS, creepage/clearance rules, and safe probing

3) Real-world example builds (with actual model numbers)
Example 1: “STM32 outputs 24 V / 5 A ON/OFF” (industrial load)

MCU (logic source): STM32F103C8T6 (3.3 V GPIO)

Power stage (low-side):

MOSFET: IRLZ44N (easy-to-find logic-level MOSFET; fine for learning/low-frequency switching)
Gate resistor: 33 Ω
Gate pulldown: 100 kΩ
Flyback diode (inductive loads): SS54 or 1N5822 (Schottky, choose current/voltage margin)
Supply protection: SMBJ33A TVS (for 24 V-ish rails; pick TVS rating based on your system)
Add a fuse on the 24 V input

How to “simulate maximum current” safely:

Use a bench supply at 24 V
Set current limit to 0.5 A first, verify switching
Increase limit gradually to your target (e.g., 5 A)
Start with a dummy load: a power resistor (e.g., 4.7 Ω / 50 W) or an electronic load

Notes:

IRLZ44N is not a “modern best-in-class” MOSFET, but it’s a classic demonstration part.
For faster PWM, higher efficiency, or tight thermal limits, you’d select a newer MOSFET with lower RDS(on) at VGS=2.5–4.5 V.

Example 2: “Arduino-like GPIO simulates a 12 V relay driver”

*MCU: *ATmega328P (5 V GPIO)

Driver stage (because relay coils are inductive):

Transistor: 2N2222 (or similar BJT) or a small logic MOSFET like AO3400A
Flyback diode: 1N4148 (small relay) or 1N4007 (general) / SS14 (fast Schottky)
Base/gate resistor: BJT base ~1 kΩ; MOSFET gate ~33 Ω
Pull-down: 100 kΩ (MOSFET)

Why this is a good “simulation”:
It mimics what a real MCU-controlled output stage does: logic controls a switch, and the external supply drives the coil.

Example 3: “3.3 V MCU simulates a 24 V high-side output with protections”

MCU: STM32G0 series (3.3 V GPIO)

High-side switch IC: BTS500xx / VNQxxx-style high-side switch families (automotive protected high-side switches)

These parts typically include:

current limit
thermal shutdown
short-circuit protection
diagnostic output (optional)

How to test:

GPIO drives the enable/input
Put load between output and ground
Use supply current limit + fuse for safety
Scope the output during switching; watch inrush

(Exact suffix depends on your current rating/channel count; choose according to your “max current” target.)

Example 4: “MCU simulates high voltage (e.g., 200–400 V) switching”

MCU: STM32F4 series (timers for PWM)

Isolation + driver:

Digital isolator: ADuM1100 (or similar)
Isolated gate driver: ACPL-332J (optocoupler driver) or transformer/isolated driver module

Power switch:

MOSFET: choose 600 V class for 400 V bus (part depends heavily on current and switching frequency)
Add RC snubber + TVS as needed

Safety reality check:
At these voltages, simulation becomes a high-energy power electronics build. Use isolation, creepage/clearance, proper probing, and staged bring-up.

4) Measurement and “simulation credibility”

To claim you are simulating an MCU “max current / high voltage output,” you should measure:

Load current (shunt + amplifier, or a Hall sensor)
MOSFET temperature (IR camera / thermocouple)
Switching waveform (VDS/VCE, gate voltage, ringing)
Supply dips and transients

Useful current-sense examples (real parts)

High-side current monitor: INA219 (simple I²C), INA226
Hall sensor (isolated current): ACS712 / ACS758

5) A simple selection checklist (so you don’t smoke boards)

Define Vload (12/24/48/… V) and Iload (A).
Pick topology:

low-side MOSFET (default)
high-side switch (if needed)

Choose switch ratings:

VDS ≥ 2× supply (more if inductive/noisy)
Id ≥ load current with thermal margin

Add protections:

flyback diode (inductive)
fuse
TVS
current limit (bench supply or eFuse)

Validate with a dummy load, then real load.

How to use FPGA to implement PID?

Hedy — Wed, 14 Jan 2026 08:45:56 +0000

Implementing a PID on an FPGA is very doable—and usually better than a microcontroller when you need high sample rate, low jitter, and deterministic latency. The key is to implement a discrete-time PID using fixed-point math, with proper saturation/anti-windup, and a clean sample tick.

Below is a practical, FPGA-friendly way to do it.

1) Pick a discrete PID form that’s FPGA-friendly
Standard (position) form

Works, but the integral sum can grow large and you’ll spend effort managing overflow.

FPGA-friendly (incremental / velocity) form (recommended)

This form reduces accumulator range issues and is easy to pipeline:

𝑢[𝑛]=𝑢[𝑛−1]+𝐴(𝑒[𝑛]−𝑒[𝑛−1])+𝐵𝑒[𝑛]+𝐶(𝑒[𝑛]−2𝑒[𝑛−1]+𝑒[𝑛−2])

Where typically:

𝐴=𝐾𝑝
𝐵=𝐾𝑖𝑇𝑠
𝐶=𝐾𝑑/𝑇𝑠

Why it’s great on FPGA

Uses only a few differences + multiplies + adds each sample
One state register for output (u[n-1]) + small history (e[n-1], e[n-2])
Easy saturation at the end

2) Build the FPGA PID datapath (what blocks you implement)

At each sample tick:

Error

e = setpoint - measurement

Differences

de = e - e1
dde = e - 2*e1 + e2

Multiply

p_term = A * de
i_term = B * e
d_term = C * dde

Accumulate output

u = u_prev + p_term + i_term + d_term

Saturation + anti-windup

Clamp u to actuator limits
If saturated, optionally stop/limit integral contribution (details below)

Update history registers

e2 <= e1
e1 <= e
u_prev <= u_sat

3) Fixed-point design (the “make it work in hardware” part)
Choose a Q format

Example starting point:

Error e: signed 16-bit
Coefficients A,B,C: signed 18-bit (fits nicely with DSP slices)
Internal products: 34–36-bit
Accumulator/output: 32–40-bit, then truncate/round to actuator width

Typical formats:

Signals: Q1.15 (16-bit signed)
Coeffs: Q3.14 or Q5.12 depending on your gain range
Accumulator: keep extra headroom: Q8.24 or similar

Scaling workflow (practical)

Decide actuator output range (e.g., PWM duty 0…65535)
Decide measurement and setpoint scaling (ADC counts? physical units scaled?)
Pick Q formats so products don’t overflow at worst-case error
Add:

rounding when shifting back down
saturation after add/accumulate

4) Sample tick and determinism

Your PID should update at a fixed rate 𝑓𝑠=1/𝑇𝑠.

Common FPGA approach:

A hardware timer/counter generates pid_tick every Ts
On pid_tick, latch inputs (setpoint, measurement) and run the PID pipeline
Pipeline latency might be a few FPGA clocks, but the update interval stays exact

Tip: If your ADC sample rate is the master clock, use “ADC data valid” as pid_tick.

5) Derivative filtering (important in real systems)

Raw derivative amplifies noise. A common FPGA-safe solution:

Compute derivative on measurement instead of error, or
Apply a 1st-order low-pass to derivative:

𝑑𝑓[𝑛]=𝑑𝑓[𝑛−1]+𝛼(𝑑[𝑛]−𝑑𝑓[𝑛−1])

That’s just an extra multiply + accumulator (very FPGA-friendly).

6) Anti-windup (don’t let the integrator explode)

Even with incremental form, the “I contribution” can drive output into saturation and keep integrating.

Simple anti-windup options:

Option A: Conditional integration (easy)

Only apply the I term when not saturated or when error would move output back toward range.

If u saturated high and e > 0 → skip I
If u saturated low and e < 0 → skip I

Option B: Back-calculation (more control)

Adjust integrator based on saturation difference:

𝐼←𝐼+𝐾𝑎𝑤(𝑢𝑠𝑎𝑡−𝑢)

(also FPGA-friendly, one extra multiply)

7) Resource mapping tips (Xilinx/Intel FPGAs)

Use DSP slices for the multiplies (3 multiplies for P/I/D, plus optional derivative filter)
Use pipelining to meet timing:
- Stage 1: compute e,de,dde
- Stage 2: multiply
- Stage 3: sum + saturate
If you need many PID loops (multi-axis), you can:
- Fully parallel: best performance, more DSP usage
- Time-multiplex: reuse multipliers across channels with scheduling (cheaper DSP)

8) How PID connects to the outside world on FPGA

Typical chain:

ADC / sensor capture → scaling → PID → output scaling → PWM / DAC / motor driver

Examples:

Motor control: PID output drives PWM duty or current reference
Temperature control: PID output drives PWM to heater + SSR
Position control: PID output drives torque/current loop setpoint

9) Verification workflow (fast and reliable)

Validate your PID gains in Python/MATLAB (floating point)
Quantize to fixed point (same Q formats)
Simulate HDL with a testbench using recorded signals
Hardware test with step response + logging (ILA/SignalTap)

What do I need to learn to build a robot with Nucleo-F401RE?

Hedy — Tue, 13 Jan 2026 08:54:16 +0000

The Nucleo-F401RE is perfect for a first “real” robot because it has ST-LINK built-in, plenty of timers for PWM + encoders, and Arduino-style headers for quick wiring.

Below is a practical “learn STM32 by building the robot” roadmap, with a solid hardware stack and the exact STM32 peripherals you’ll learn in the right order.

1) Pick a simple robot architecture (do this first)

Start with a 2-wheel differential drive (2 DC gear motors + 1 caster). It’s the easiest to control and debug.

Recommended BOM (robot base)

Core

Nucleo-F401RE
2× DC gear motors (6–12V) + wheels
1× motor driver board (dual H-bridge): TB6612FNG / DRV8833 / L298N (pick one)
Battery: 2S Li-ion/LiPo (7.4V) or 6×AA (simple)
5V/3.3V regulation:
- If using 2S battery: buck converter to 5V
- Nucleo can be powered by 5V on VIN/5V pin (board then makes 3.3V)
Wires + breadboard or perfboard

Sensors (add in phases)

Wheel encoders (quadrature) highly recommended
IMU (I2C): e.g., MPU-6050/ICM-series (any common I2C IMU)
Distance sensor: ultrasonic (HC-SR04) or ToF (I2C)

Debug tools (huge time saver)

Cheap logic analyzer (for UART/I2C/SPI)
Multimeter

2) Power rules (most robot bugs are power bugs)

Never power motors from the Nucleo 5V pin.
Power path should be:
- Battery → Motor driver (VM)
- Battery → Buck → 5V → Nucleo (5V/VIN)
Common ground is mandatory: Battery GND = motor driver GND = Nucleo GND
Add a bulk capacitor near motor driver VM: 220–1000 µF helps with brownouts.

3) Learning path that maps directly to robot features
Phase A — “It moves” (1–2 days)

Goal: Drive both motors open-loop.
You learn:

GPIO output (direction pins)
Timer PWM (speed control)

Motor driver signals you’ll typically use:

AIN1/AIN2 + PWMA
BIN1/BIN2 + PWMB
STBY/EN (enable)

CubeMX setup

Enable 2 PWM channels (e.g., TIM3 CH1/CH2)
Configure 2–4 GPIOs for direction
Start PWM and vary duty cycle

Phase B — “It moves straight” (2–5 days)

Goal: Read encoders and do speed control so both wheels match.
You learn:

Timer Encoder Interface mode (best)
Interrupt basics (optional)
PID speed loop

Why encoders matter: without them, the robot drifts and turns randomly because motors aren’t identical.

Phase C — “It goes where you tell it” (1–2 weeks)

Goal: Drive distance/angle commands.
You learn:

Differential drive kinematics
Closed-loop control (speed + heading)
IMU via I2C (optional but great)

Phase D — “It navigates” (ongoing)

Add:

Obstacle avoidance (distance sensor)
Line following (IR array)
Remote control (Bluetooth UART)

4) Wiring example (typical dual H-bridge)

This is generic and works for TB6612/DRV8833-type drivers:

STM32 → Motor Driver

PWM_A → PWMA
PWM_B → PWMB
DIR_A1, DIR_A2 → AIN1, AIN2
DIR_B1, DIR_B2 → BIN1, BIN2
EN/STBY → STBY/EN
GND → GND (must share)

Power

Battery + → VM (motor supply)
Battery – → GND
Buck 5V → Nucleo 5V/VIN
Buck GND → common GND

Encoders → STM32

Left encoder A/B → TIMx CH1/CH2 (encoder mode)
Right encoder A/B → TIMy CH1/CH2
Use pull-ups if encoder outputs are open collector.

Tip: Nucleo-F401RE exposes many timer pins; choose pins that support PWM outputs and encoder channels, and confirm in the Nucleo pinout.

5) CubeIDE/CubeMX peripheral “shopping list” for this robot

You’ll end up using these a lot:

TIM PWM: 2 channels (left/right speed)
TIM Encoder: 2 timers (left/right wheel)
UART: debug prints + later Bluetooth control
I2C: IMU / ToF sensor
ADC: battery voltage monitoring
(Optional) FreeRTOS: only after you’re comfortable without it

6) A proven firmware structure (simple, robust)

Run a fixed-rate control loop (no RTOS needed at first):

1 kHz (every 1 ms): read encoders, compute wheel speed
100–200 Hz: PID speed control update
20–50 Hz: navigation logic (distance/heading/obstacle)

A clean module split:

motor.c (set PWM + direction)
encoder.c (read counts, compute speed)
control.c (PID)
robot.c (drive commands: forward/turn)
comms.c (UART CLI)

7) Your first “robot milestone plan” (no guessing, just build)

PWM one motor forward/backward
PWM both motors, manual speed commands over UART
Read both encoders reliably
Implement wheel speed PID (robot drives straight)
Implement “drive X cm” and “turn Y degrees”
Add sensor-based stopping (distance sensor)
Add Bluetooth control (UART) or a simple command protocol

8) Quick parts choice advice (so you don’t get stuck)

If your motors are small (≤1A each typical): TB6612FNG / DRV8833 class drivers are great.
If motors are bigger: pick a higher-current driver and plan real heat dissipation.
Get encoders early. They make the project way more predictable.

Which Raspberry Pi can take 24v?

Hedy — Mon, 12 Jan 2026 09:01:51 +0000

Most Raspberry Pi “computer boards” do not accept 24 V directly. They are 5 V devices (powered via USB-C / micro-USB, or the 5 V pins on the GPIO header), so feeding 24 V into a normal Pi will damage it.

The one common “Pi” setup that can take 24 V (with a big caveat)

Raspberry Pi Compute Module 4 + official CM4 IO Board
The CM4 IO Board can be powered via its DC barrel jack and Raspberry Pi’s docs note it supports up to 26 V if PCIe is unused—so 24 V is OK in that specific configuration.

If you plan to use PCIe devices, Raspberry Pi emphasizes 12 V input for that use case.

Not 24 V

Compute Module 5 IO Board: requires an external +5 V USB-C PSU, not 24 V.
Raspberry Pi 5 / 4 / 3 / Zero / 400 / 500: powered from 5 V (Pi 5 typically via the official 5.1 V supply).

If you have 24 V available, the normal solution

Use a 24 V → 5.1 V (or 5.0 V) DC-DC buck converter sized for your Pi:

Pi 4 class: typically 5 V / 3 A supply guidance
Pi 5 class: official supply is 5.1 V / 5 A

Then feed the Pi via USB-C/micro-USB (preferred) or via the 5 V GPIO pins (only if you understand you’re bypassing some protection).

Related note: PoE is ~48 V, not 24 V

If your “24 V” is coming from PoE-like wiring, avoid 24 V passive PoE—it’s not standards-compliant and can cause damage.
Standards-based PoE/PoE+ is typically ~48 V and uses proper negotiation (e.g., PoE+ HAT).