agentleFS
wedsamuel1230wedsamuel1230/embedded-engineering-skills/skills/non-blocking-patterns/SKILL.md

non-blocking-patterns

Skill28 starsChanged 28 days agoMITView on GitHub

Use when Arduino or embedded C++ code uses delay(), needs button debouncing, periodic work, cooperative scheduling, watchdog-safe timing, state machines, or latency/jitter control under sensor, network, or motor load.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep the main loop responsive and make timing behavior testable.

    line 11
  2. Distinctive:

    No unbounded blocking call remains in the time-critical path without a documented reason and timeout.

    line 48
  3. Distinctive:

    Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, …

    line 57

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Non-Blocking Patterns

Keep the main loop responsive and make timing behavior testable. Prefer C/C++ patterns that can be compiled for the exact board; use Python only for relevant test or log analysis tooling.

Intake

Record board/core version, task periods, deadlines, maximum work duration, input bounce, serial/network behavior, watchdog policy, interrupt constraints, and the safety response for missed deadlines.

Process

  1. List each periodic or event-driven task with period, deadline, and worst-case work. Identify any blocking library call.
  2. Replace long delay() calls with unsigned wrap-safe elapsed checks such as if (static_cast<unsigned long>(now - last) >= period). Use hardware timers or RTOS tasks only when board and framework support is confirmed.
  3. Model multi-step work as an explicit state machine with bounded transitions; do not hide waits inside a helper.
  4. Debounce inputs using a stable-state timer or event filter, not a blocking pause. Bound serial parsing, network retries, and sensor conversion waits.
  5. Define watchdog feeding, output inhibit, timeout, and recovery behavior.
  6. Measure loop latency and task jitter under representative logging, radio, storage, and actuator load.

Anti-rationalization

ShortcutResponse
"A shorter delay is fine."It is still blocking; show the deadline and replace it.
"The loop is fast on USB."Measure with the actual radio, storage, and actuator load.
"The enum makes it a state machine."Require timed transitions, explicit entry/exit, and timeout behavior.
"The watchdog can be fed everywhere."Define ownership and fail-safe behavior; do not mask a stuck task.
"millis() never wraps."Use unsigned subtraction and test the wrap boundary.

Verification

  • No unbounded blocking call remains in the time-critical path without a documented reason and timeout.
  • Debounce, wraparound, timeout, and missed-deadline cases have tests.
  • Exact-target compile proof and timing/serial evidence are separate.
  • Outputs enter a safe state when a task, sensor, or communication path times out.

Shared output contract

Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, known limitations, and recovery/security notes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.