kernel-basics
Scannednpx machina-cli add skill beriberikix/zephyr-agent-skills/kernel-basics --openclawZephyr Kernel Basics
Master the essential services that bring your Zephyr application to life.
Core Workflows
1. Threads & Scheduling
Create and manage multi-threaded application flows.
- Reference: threads.md
- Key Tools:
K_THREAD_DEFINE,k_sleep,k_yield, Priorities.
2. Logging & Diagnostics
Implement layered logging for better observability and troubleshooting.
- Reference: logging.md
- Key Tools:
LOG_MODULE_REGISTER,LOG_INF,LOG_ERR, Dynamic Filtering.
3. Interactive Shell (CLI)
Build powerful command-line interfaces for hardware and software inspection.
- Reference: shell.md
- Key Tools:
SHELL_CMD_REGISTER,SHELL_STATIC_SUBCMD_SET_CREATE.
Quick Start (Logging)
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(my_app, CONFIG_APP_LOG_LEVEL);
void my_fn(void) {
LOG_INF("Hello from Zephyr!");
}
Quick Start (Threads)
K_THREAD_DEFINE(worker_tid, 1024, worker_fn, NULL, NULL, NULL, 5, 0, 0);
Resources
- References:
threads.md: Configuration and creation of kernel threads.logging.md: Log levels, modules, and backends.shell.md: Interactive command registration and subcommands.
Source
git clone https://github.com/beriberikix/zephyr-agent-skills/blob/main/skills/kernel-basics/SKILL.mdView on GitHub Overview
Kernel Basics covers Zephyr's essential kernel services including thread lifecycle and scheduling, the logging subsystem for diagnostics, and the interactive shell for real-time hardware inspection. This skill helps you design multi-threaded flows, observe system behavior with configurable logs, and interactively inspect devices during debugging.
How This Skill Works
Threads are created and scheduled using K_THREAD_DEFINE, k_sleep, and k_yield with explicit priorities. The logging subsystem uses LOG_MODULE_REGISTER along with LOG_INF and LOG_ERR to emit structured messages, often with dynamic filtering for visibility. The interactive shell is built with SHELL_CMD_REGISTER and supports subcommands via SHELL_STATIC_SUBCMD_SET_CREATE to expose runtime diagnostics and control.
When to Use It
- Designing and orchestrating multi-threaded application flows with clear thread lifecycles
- Adding, configuring, or tuning logging for observability and troubleshooting
- Building an interactive CLI to inspect hardware and software state in real time
- Diagnosing scheduling issues or adjusting thread priorities for real-time tasks
- Creating modular shell commands to diagnose, trigger, and validate runtime behavior
Quick Start
- Step 1: Register a logging module with LOG_MODULE_REGISTER(my_app, CONFIG_APP_LOG_LEVEL);
- Step 2: Log an event using LOG_INF("Hello from Zephyr!");
- Step 3: Define a worker thread with K_THREAD_DEFINE(worker_tid, 1024, worker_fn, NULL, NULL, NULL, 5, 0, 0);
Best Practices
- Register a dedicated log module with LOG_MODULE_REGISTER and pick an appropriate CONFIG_APP_LOG_LEVEL
- Use relevant log levels (LOG_INF, LOG_ERR) and avoid verbose logging in time-critical paths
- Leverage dynamic filtering to reduce log noise in production while keeping essentials visible
- Keep shell commands lightweight and thread-safe; document usage with clear help text
- Validate thread definitions (K_THREAD_DEFINE) and ensure proper synchronization when sharing data
Example Use Cases
- A sensor node runs a worker thread via K_THREAD_DEFINE to collect data and logs readings with LOG_INF
- A module uses LOG_MODULE_REGISTER and logs errors when a peripheral initialization fails (LOG_ERR)
- A CLI command registered with SHELL_CMD_REGISTER allows inspecting peripheral status at runtime
- Thread priorities are tuned (e.g., high-priority sensor task) to meet real-time deadlines
- Developer uses the shell to verify hardware presence and inspect registers during boot
