Problem
The client needed more than firmware for a mouse. The product had to expose a polished configuration workflow, store user profiles on the device, support rich button/control behavior, and keep the mouse usable when the desktop software was not running.
The public Hedgehog site describes a gaming mouse with 23 programmable buttons, onboard profile memory, RGB+W lighting, joystick-style and WASD-style slide-control behavior, a PixArt 3389 sensor, and software that is optional after configuration. Those public features map directly to the engineering challenge: the desktop UI, native USB layer, firmware parser, input engine, lighting state, and flash persistence all had to agree on one device behavior model.
Product architecture
Unity / C# configuration UI
|
v
Native C++ device bridge
|
v
USB HID plus vendor control protocol
|
v
STM32L4 / FreeRTOS firmware
|
+-- input scanning, sensor, buttons, Hall sensors
+-- profile interpreter, mappings, macros
+-- LED and mode behavior
+-- QSPI flash profile persistenceThe project was structured around explicit contracts: requirements and data models defined what the UI could express; the C++ bridge translated host operations into device commands; the firmware stored and executed compact profile data in real time.
RTOS and edge-case challenge
The difficult RTOS problem was allowing configuration, flash writes, USB transfers, LED behavior, and live input handling to coexist without unpredictable latency or corrupted device state. A gaming peripheral is unforgiving: missed input, a stuck mode, or a partially written profile is immediately visible to the user.
Important edge cases included malformed profile data, interrupted USB transfers, reset during profile save, switching between joystick and WASD-style behavior, active input while configuration is changing, flash timing, queue pressure, and making sure stored profiles remain valid when the desktop application is removed or the mouse is moved to another computer.
Implementation approach
Make behavior device-resident
Store profiles on the mouse so configuration survives power cycles and does not depend on a background desktop service during gameplay.
Keep real-time paths deterministic
Use FreeRTOS tasks, queues, notifications, timers, static allocation, and clear priority separation so configuration work cannot destabilize input handling.
Define the host-device contract
Align Unity UI objects, C++ structures, USB command frames, firmware parsing, and flash layout around a consistent data model.
Validate at product boundaries
Debug issues across UI state, native transport, USB pacing, firmware state, and nonvolatile storage instead of treating each layer as a separate project.
Outcome
The engagement delivered a configurable connected peripheral where the public user-facing promise is backed by a complete embedded architecture. A customer can configure the mouse, disconnect the software, and continue using stored profiles because the product behavior lives on the device.