Blog 001 | ATtiny85 USB HID

This project explores how a highly constrained microcontroller behaves when interacting with a host system over USB HID. The focus was not on payload delivery, but on understanding how memory limits, USB behavior, and system defenses influence what is realistically possible on minimal hardware.

Rather than aiming for reliability or completeness, the experiment was designed to observe failure modes, unexpected behavior, and trade-offs that emerge when theoretical examples are applied to real, resource-limited devices.

Why I Built This

I built this experiment to move beyond simplified examples commonly found online and test what actually breaks when constraints are real. Many demonstrations assume ideal conditions, abundant memory, or abstract away system defenses entirely.

I wanted to understand where those assumptions fail — specifically, how far a small microcontroller like the ATtiny85 can go before limitations in memory, USB handling, or system behavior force design compromises or complete rethinking.

Constraints & Assumptions

1. Extremely limited flash and RAM availability

2. No external storage or secondary controller.

3. USB interaction limited to basic HID behavior.

4. Host system protections left enabled during testing.

5. Focus on behavior observation, not persistence or automation.

High-Level Approach

The experiment centered around observing how the device interacts with the host system through basic USB HID communication. Instead of treating the microcontroller as a delivery mechanism, I treated it as a probe — a way to understand how constrained devices are interpreted and handled by the host.

The design was iterated multiple times to reduce memory usage and simplify logic, allowing the core interaction to function without overwhelming the device’s limits.

What Broke / Didn’t Work

Memory constraints were the primary limiting factor. Common approaches that work in theory failed in practice due to RAM exhaustion, incomplete execution, or unstable behavior. Even minor increases in logic complexity led to crashes or inconsistent results.

This exposed a gap between examples that appear simple on paper and what constrained hardware can reliably support.

Adjustments & Decisions

After repeated failures, I shifted focus away from standard patterns and explored more memory-aware alternatives. This required deeper understanding of how the device handles data internally, rather than relying on familiar abstractions.

Simplifying interactions and reducing assumptions about available resources proved more effective than adding features or complexity.

Key Takeaways

This project reinforced a pattern I keep encountering: partial understanding doesn’t hold up under real constraints. Either the system is deeply understood, or every available resource must be used intentionally to compensate.

Working in the middle — with surface-level knowledge and limited resources — almost always fails.

// Personal Note
                 →  Either have complete knowledge or complete resources — 
                staying in between leads to failure.