DEV Community: kamin deng

One C++ Interface Across Linux and Multiple RTOSes: The Design Value of dp_sdk_core

kamin deng — Sun, 19 Apr 2026 08:55:17 +0000

One C++ Interface Across Linux and Multiple RTOSes: The Design Value of `dp_sdk_core`

GitHub: https://github.com/KaminDeng/dp_sdk_core

Many embedded projects move quickly in the beginning.

A workflow is validated on Linux first, then moved to an MCU. One board is supported first, then more hardware variants follow. One RTOS is adopted first, and portability is considered later.

The real difficulty is usually not whether the first version can run, but whether the codebase remains stable when platforms start changing:

can business logic remain stable when the OS changes?
can Linux and multiple RTOSes share a reasonably aligned programming model?
can board, chip, or system changes stay confined to a small number of boundaries?
can C++ abstractions preserve expressiveness on MCUs without letting resource cost get out of control?

dp_sdk_core is aimed at exactly those problems.

It is not “one more wrapper layer.” It is an attempt to provide a core layer better suited for long-term embedded evolution.

1. Its real value is not just “cross-platform support”

dp_sdk_core consists of three core modules:

Module	Focus	Role
`dp_osal`	OS abstraction	Unifies threads, mutexes, queues, timers, semaphores, and related primitives
`dp_hal`	Hardware abstraction	Unifies UART, GPIO, SPI, I2C, ADC, PWM, and related peripheral interfaces
`dp_device`	Device management	Unifies registration, lookup, open/close control, and lifecycle handling

The dependency structure is intentionally restrained:

device  ->  hal   (public)
device  ->  osal  (private)
hal     ->  independent
osal    ->  POSIX / CMSIS-OS backend

What matters is not only that the project is split into three modules.

What matters is that this split gives change a clear home:

OS differences are contained in dp_osal
hardware differences are contained in dp_hal
device lifecycle concerns are contained in dp_device

For embedded systems that must evolve over time, those boundaries matter more than how fast a single driver can be wrapped.

2. CMSIS-OS is used to adapt multiple RTOSes and align Linux / RTOS programming interfaces

This is one of the most important characteristics of dp_sdk_core.

Many embedded projects do not fail because they support only one system. They fail because, even when multiple systems are supported, the programming model becomes fragmented:

Linux uses one threading and synchronization style
FreeRTOS uses another
RT-Thread or Zephyr requires another adaptation layer
the business logic stays conceptually similar, but the upper-layer programming style does not

dp_sdk_core does not expose each RTOS’s native API directly to the application layer.

Instead, it stabilizes the upper-layer system programming model through dp_osal, and converges different RTOSes through the CMSIS-OS interface.

That means:

upper-layer code is primarily written against one OSAL interface,
RTOS-specific variation is concentrated in the adaptation layer,
any RTOS that can be adapted to CMSIS-OS can, in principle, fit into this framework.

The project has already been adapted and validated on FreeRTOS, RT-Thread, and Zephyr.

This is why its value is not merely “multi-RTOS support,” but a unified interface model across Linux and multiple RTOS environments.

3. Structurally, it solves the problem of where change should live

The main value of this diagram is not just its layered layout.

It shows several engineering realities:

Application logic should remain as stable as possible

Upper-layer business code depends on core abstractions rather than direct platform APIs.
OS differences are concentrated in dp_osal

Linux / POSIX and RTOS environments both expose capabilities upward through one OSAL model.
Hardware differences are concentrated in dp_hal

UART, GPIO, SPI, I2C, and similar peripheral implementations do not directly leak into business code.
Device lifecycle is concentrated in dp_device

Registration, lookup, open/close behavior, and centralized management are not scattered across modules.

Cross-platform projects rarely fail because differences exist.

They fail because those differences have no disciplined boundary.

That is one of the clearest strengths of dp_sdk_core.

4. From an evolution perspective, it makes migration and product expansion more controllable

Compared with the architecture diagram, this migration view is closer to the project’s practical engineering value.

The left side reflects a common embedded state:

business logic, RTOS APIs, vendor HAL calls, and device initialization order are all mixed together
the firmware runs, but any system, hardware, or product-profile change quickly expands the modification surface

The right side reflects the state dp_sdk_core is designed to establish:

upper-layer business code depends on stable contracts
OS differences are absorbed through POSIX / CMSIS-OS paths
hardware differences are absorbed through HAL ports
device lifecycle is gathered into the Device layer

That is also why this design is especially suitable when a team moves from a demo mindset to a product-line mindset.

A demo optimizes for “getting it running.”

A product line optimizes for “keeping change under control.”

5. It is not only about abstraction, but also about the engineering value of C++ interfaces

Many embedded abstraction layers eventually become little more than renamed C APIs. They may use C++ syntax, but they do not significantly improve expressiveness or cost control.

dp_sdk_core is more interesting because it does not give up the engineering strengths of C++.

5.1 Production paths prefer CRTP instead of default all-virtual interfaces

In dp_osal and dp_hal, many core interfaces are built around CRTP.

The point is not to appear “more template-oriented.”

The point is compile-time binding of implementation types:

hot paths are easier to inline
a vtable is not introduced by default
abstraction remains available without automatically becoming a runtime burden

That matters on MCUs because abstraction becomes risky when runtime cost is spread across every path by default.

5.2 Virtual wrappers are used only when test injection is needed

The project also provides dp_osal_virtual.h and dp_hal_virtual.h for host-side dependency injection and GMock scenarios.

That reflects a clear design strategy:

shipping / production paths prefer CRTP
host-test paths can switch to virtual wrappers only when mocking is required

So testability is preserved, but test-related runtime cost is not forced onto all firmware paths.

5.3 This is disciplined use of modern C++

From an engineering perspective, the project uses several C++ features that are genuinely valuable for long-term maintenance:

typed interfaces instead of raw pointer-heavy plumbing
RAII-style helpers such as lock guards
templates combined with compile-time switches for trimming and portability
clearer separation of interfaces and implementations for collaborative development

So the notable characteristic is not merely that dp_sdk_core uses C++17.

It is that it uses C++ interface design to improve engineering structure while keeping the added cost under control.

6. `dp_device` addresses one of the most failure-prone late-stage problems: device lifecycle

Early in an embedded project, teams tend to focus on whether drivers work. Very few teams treat device lifecycle management as a first-class design concern from the beginning.

Once the system grows, the following problems usually appear:

device initialization order becomes unclear
some modules reopen devices while others close them too early
naming and type expectations remain informal conventions
lookup, registration, and cleanup logic spreads across modules

dp_sdk_core turns that into a dedicated layer through dp_device:

Device provides a unified base for naming, typing, and open/close reference counting
DeviceManager centralizes registration, lookup, iteration, and removal
the registry uses a fixed-size array with an explicit upper bound
type handling relies on DeviceType instead of RTTI
synchronization can be protected by OSAL primitives

This may be less visually obvious than a driver optimization, but it is critical for long-term maintainability.

It turns device usage rules from “things the team is expected to remember” into “things the framework enforces.”

7. Its treatment of resource cost is “controlled,” not “pretending there is no cost”

This is a very important point.

Many embedded abstraction layers talk about elegance, consistency, and modernization, but avoid the harder question: what exactly does the abstraction cost, and where is it appropriate?

dp_sdk_core takes a more grounded approach. It does not market all paths as “zero cost.” Instead, it tries to keep costs analyzable, trimmable, and verifiable.

7.1 What cost is intentionally reduced

dp_hal is primarily header-only + CRTP, with the goal of eliminating most abstraction overhead at compile time
dp_osal core interfaces are not all-virtual by default
dp_device uses fixed-size arrays instead of default heap allocation
type handling avoids RTTI where practical

7.2 What cost is explicitly acknowledged

threads, thread pools, and timers are not cost-free primitives
once std::function, synchronization objects, and extra state are introduced, RAM / Flash impact must be evaluated
switching to virtual wrappers for host-side testing naturally adds runtime dispatch cost

That is much more credible than pretending abstraction is free.

7.3 The MCU feasibility table is already a good way to explain this

Target MCU	Feasibility	Notes
Cortex-M4 / M7, RAM ≥ 192 KB (CCM recommended)	✅ current full-test profile is feasible	already has a practical build-and-validate basis
Cortex-M3 / small-memory M4, RAM 64–128 KB	⚠️ feasible only with aggressive trimming	`test_all` must be disabled, features reduced, and the result re-measured
Cortex-M0 / M0+, RAM ≤ 64 KB	❌ not something the current profile should claim directly	requires a dedicated tiny profile and measured proof

The importance of this table is not only the conclusion itself.

More importantly, it shows an engineering attitude:

not every MCU should be treated as equally suitable for the same profile
architectural value does not remove the need to respect hardware limits
whether the abstraction is viable depends on target profile, trimming strategy, and measurement

So the project’s stance on cost is not “there is no cost.”

It is that cost can be controlled and reasoned about through CRTP, fixed limits, feature trimming, and platform validation.

8. The best-fit workflow is to validate on Linux first, then move smoothly to RTOS and hardware targets

Looking at its structure and interface model, dp_sdk_core fits a workflow like this:

validate core business logic in Linux / POSIX first
keep upper-layer programming stable through unified OSAL / HAL interfaces
bring different RTOSes into the same model through CMSIS-OS adaptation
finally switch to target-specific hardware implementations and complete MCU integration and measurement

The benefits are direct:

business logic can be verified earlier on the host
Linux and RTOS-side programming styles stay closer
board and system changes stay more localized
teams can treat business validation, RTOS adaptation, and hardware porting as one coherent engineering path

9. What kind of teams benefit most from this kind of core layer

This type of architecture tends to pay off most when:

business logic must run in both Linux simulation and MCU firmware
the product must span multiple RTOSes or multiple hardware platforms
the team is already paying visible maintenance cost for platform glue code
a reusable C++17 foundation layer is desired
a more consistent Linux / multi-RTOS interface experience matters

By contrast, if the firmware is short-lived, one-off, and tied to a single fixed platform, a custom lightweight platform layer may still be enough.

The value of dp_sdk_core appears most clearly in long-term evolution, not in one-time bring-up.

10. Conclusion

What makes dp_sdk_core worth attention is not merely that it wraps threads, UART, or GPIO.

Its real value is that it places several of the most failure-prone parts of embedded development into one coherent structure:

how to keep Linux and multiple RTOSes closer to one programming model
how to converge different RTOSes through CMSIS-OS
how to isolate hardware differences through HAL ports
how to centralize device lifecycle handling
how to retain C++ expressiveness while controlling resource cost

From that perspective, it is not just “another abstraction layer.”

It is a more stable, more unified, and more evolvable foundation for embedded development across Linux, RTOS, and hardware platforms.

Open Source: Control Claude Code / Codex CLI Entirely from Your Phone with Feishu (Lark) — Approve, Choose, and Send Commands on the Go

kamin deng — Thu, 09 Apr 2026 04:10:40 +0000

Ever had this happen? Claude Code has been running for a while and finally pops up a permission prompt — but you've already walked away to grab coffee.

Or Codex finishes an entire task, and you only realize it when you come back — ten minutes too late.

Today I'm open-sourcing a little tool I use daily — Agent Notifier. It routes all interactions from Claude Code and Codex CLI to Feishu, so you can handle everything from your phone without being chained to the terminal.

GitHub: https://github.com/KaminDeng/agent_notifier

1. The Problem It Solves

When you use Claude Code or Codex CLI for coding, the biggest pain point isn't that the AI isn't smart enough — it's the interaction gap:

The AI needs your approval to run a command → you're away from your desk → task stalls
The AI offers three approaches and asks you to pick one → you don't see it → task stalls
The task finishes → you have no idea → you've been waiting for nothing for 30 minutes

At its core, these CLI tools have no mobile interaction layer. You have to sit in front of the terminal, watching the output in real time.

Agent Notifier's approach is simple: turn Feishu into your remote terminal controller.

Pain Point	Solution
Stuck waiting for permission prompts at the terminal	Feishu pushes interactive cards in real time — one tap on your phone
Want mobile access, but there's no official app	Feishu is a full multi-platform app — iOS / Android / Mac / Windows / Web
Self-hosted push notifications need a server, domain, and SSL	Feishu's long-connection (WebSocket) mode requires no public IP — direct local connection
Enterprise app approval is a bureaucratic nightmare	Feishu's custom enterprise apps get instant approval; personal accounts work too — completely free
Running tasks across multiple terminals, notifications get tangled	Multi-terminal parallel routing — each terminal gets its own delivery channel, no cross-talk

2. What It Looks Like

Here are actual screenshots from the Feishu mobile app:

Permission Confirmation & Option Selection

When Claude Code needs you to approve a command, or an AskUserQuestion prompt pops up with choices, Feishu sends you an interactive card:

Left: Permission confirmation — Allow / Deny / Allow for Session / Allow Always + text input
Center: Permission options — Tool option buttons (e.g. ExitPlanMode) + text input
Right: Option selection — AskUserQuestion with dynamic choices + Other + free-form input
Footer: project name · terminal ID (fifo:/tmp/claude-inject-ptsN) · session duration · timestamp

Tap a button or type a response, and the action flows directly back to your local terminal — as if you were typing on your keyboard.

Live Execution Summary

Every time Claude invokes a tool, Feishu pushes a real-time execution summary card. Cards for the same task update in-place instead of flooding your chat:

Live execution summary — tool call table · in-place patch updates for the same task
Footer: project name · timestamp

Task Completion Notification

When a task finishes, you get a completion card with a change summary, token usage, and duration stats. There's a text input at the bottom so you can continue the conversation right away:

Left: Change summary + text input to continue chatting
Right: Test results table + text input to continue chatting
Footer: project name · session duration · timestamp · token usage breakdown (input / output / cache read / cache write)

3. Supported Card Types

Scenario	Card Color	Description
Permission confirmation	Orange	Allow / Allow for Session / Deny + text input
AskUserQuestion (single choice)	Orange	Dynamic option buttons + Other + text input
AskUserQuestion (multi-part)	Orange	Q1 → Q2 → Q3 sent sequentially
Task complete	Green	Summary, duration, tokens + text input
Abnormal exit	Red	Error details + text input
Live execution summary	Blue	In-place patch updates for the same task

4. Why Feishu Instead of WeChat / Telegram / Slack?

This is the question I get asked the most, so let me address it:

Feishu custom apps are free — you can create one with a personal account, and enterprise approval is instant
Feishu supports long connections (WebSocket) — no public IP or domain required. Whether you're at home, at the office, or on a VPN, it just works
Feishu's interactive card system is incredibly powerful — buttons, text inputs, tables, multi-column layouts — far beyond what a basic message notification can do
Feishu syncs natively across all devices — phone, desktop, tablet, and web all receive and can interact with the same card
No need to build a separate app — the Feishu client itself becomes your remote control

That said, the architecture uses a channel abstraction layer (src/channels/), so adding support for other platforms is straightforward.

5. Get Started in 5 Minutes

Prerequisites

Node.js >= 18
Python 3 (for the PTY terminal relay)
A Feishu account

Installation

# 1. Clone the repo
git clone https://github.com/KaminDeng/agent_notifier.git
cd agent_notifier

# 2. Edit .env with your Feishu app credentials (auto-created on first run)
#    FEISHU_APP_ID=your_app_id
#    FEISHU_APP_SECRET=your_app_secret

# 3. One-command install (handles all configuration automatically)
bash install.sh

# 4. Reload your shell
source ~/.zshrc  # or source ~/.bashrc

# 5. Use Claude Code as usual
claude

install.sh automatically takes care of:

Installing npm dependencies
Writing Claude Code hooks to ~/.claude/settings.json
Injecting claude / codex shell wrapper functions
Starting the Feishu listener and registering it for auto-start (launchd on macOS, systemd on Linux)

Running install.sh again is safe — it always cleans up before reinstalling.

Feishu App Setup (3 Minutes)

Log in to the Feishu Open Platform and create a custom enterprise app
Copy the App ID / App Secret into your .env file
Enable bot capabilities
Set the event subscription to Long Connection (no public IP needed)
Add the event: card.action.trigger
Request permissions: im:message, im:message:send_as_bot, im:chat:readonly
Publish the app and add the bot to your target group

That's it. No domain, no SSL certificates, no dedicated server.

6. Cross-Platform Support

Platform	Service Management	Auto-Start
macOS	launchd	RunAtLoad + KeepAlive
Linux (systemd)	systemd user service	systemctl --user enable
Linux (SSH / no systemd)	nohup + crontab @reboot	crontab fallback

Uninstalling is a single command:

bash uninstall.sh

This cleans up all configuration, stops services, and removes hooks and shell injections.

7. How It Works (Brief Overview)

There are two main pipelines:

Claude Code Pipeline:

Claude Hooks fire an event → hook-handler.js parses it → generates Feishu interactive card
                                                              ↓
User taps/types in Feishu → feishu-listener.js receives callback → injects input into local terminal

Codex CLI Pipeline:

pty-relay.py creates a PTY terminal proxy → captures Codex output → generates Feishu card
                                                              ↓
User taps/types in Feishu → feishu-listener.js receives callback → injects input via FIFO into terminal

Terminal injection supports multiple methods: tmux, PTY FIFO, pty master direct write, and TIOCSTI — the best method is auto-detected.

8. Project Structure

agent_notifier/
├── install.sh / uninstall.sh          # Install / uninstall
├── hook-handler.js / live-handler.js  # Claude Hooks entry points (thin shims)
├── bin/
│   └── pty-relay.py                   # PTY terminal relay
├── src/
│   ├── apps/                          # App entry points (claude-hook, claude-live, feishu-listener, etc.)
│   ├── adapters/                      # Claude / Codex adapters
│   ├── channels/                      # Feishu channel (card rendering, client, interaction handling)
│   ├── core/                          # Low-level primitives (session store, terminal injector)
│   └── lib/                           # App-level services (env config, session state, terminal inject)
├── tests/                             # 81 test cases
└── scripts/                           # Debug / test scripts

9. Who Is This For?

If any of the following apply to you:

You use Claude Code or Codex CLI for daily coding
You frequently step away from your desk and don't want tasks stalling on permission prompts
You want to interact with your AI coding assistant from your phone
You run multiple terminals simultaneously and need a unified notification hub

Then this tool was built for you.

10. Wrapping Up

The project is fully open source under the MIT license. Stars, forks, and issues are all welcome.

GitHub: https://github.com/KaminDeng/agent_notifier

If you find this tool useful, a star on the repo is the best way to show your support. Feel free to open an issue if you have questions or feedback.

DEV Community: kamin deng

One C++ Interface Across Linux and Multiple RTOSes: The Design Value of dp_sdk_core

One C++ Interface Across Linux and Multiple RTOSes: The Design Value of dp_sdk_core

1. Its real value is not just “cross-platform support”

2. CMSIS-OS is used to adapt multiple RTOSes and align Linux / RTOS programming interfaces

3. Structurally, it solves the problem of where change should live

4. From an evolution perspective, it makes migration and product expansion more controllable

5. It is not only about abstraction, but also about the engineering value of C++ interfaces

5.1 Production paths prefer CRTP instead of default all-virtual interfaces

5.2 Virtual wrappers are used only when test injection is needed

5.3 This is disciplined use of modern C++

6. dp_device addresses one of the most failure-prone late-stage problems: device lifecycle

7. Its treatment of resource cost is “controlled,” not “pretending there is no cost”

7.1 What cost is intentionally reduced

7.2 What cost is explicitly acknowledged

7.3 The MCU feasibility table is already a good way to explain this

8. The best-fit workflow is to validate on Linux first, then move smoothly to RTOS and hardware targets

9. What kind of teams benefit most from this kind of core layer

10. Conclusion

Open Source: Control Claude Code / Codex CLI Entirely from Your Phone with Feishu (Lark) — Approve, Choose, and Send Commands on the Go

1. The Problem It Solves

2. What It Looks Like

Permission Confirmation & Option Selection

Live Execution Summary

Task Completion Notification

3. Supported Card Types

4. Why Feishu Instead of WeChat / Telegram / Slack?

5. Get Started in 5 Minutes

Prerequisites

Installation

Feishu App Setup (3 Minutes)

6. Cross-Platform Support

7. How It Works (Brief Overview)

8. Project Structure

9. Who Is This For?

10. Wrapping Up

One C++ Interface Across Linux and Multiple RTOSes: The Design Value of `dp_sdk_core`

6. `dp_device` addresses one of the most failure-prone late-stage problems: device lifecycle