Embedded C++ library / Prototype 2.0

CASTLE

C++ built for bounded systems.

A C++17 header-only library for embedded software, where memory, timing, and failure behavior matter a great deal.

CORE IDEA: MAKE THE COST VISIBLE BEFORE THE CODE RUNS.

Automotive applications Automotive services / applications ADAS · Infotainment · Diagnostics

CASTLE contributes to middleware + application development Middleware serves applications

Cross-cutting C++ template library CASTLE library Replaces STL & common-purpose libraries

Hardware adapter Middleware Interfaces with Platform Hardware abstraction

Platform foundation for middleware

Execution environment Platform Bare metal · Embedded Linux · Zephyr · QNX · VxWorks · AUTOSAR Classic

BSP provides boot management + drivers

Hardware foundation Board Support Package (BSP) Bootloader · MCU / SoC device drivers · Hardware interfaces (CAN · Ethernet · SPI)

01 / The problem space

Embedded systems pay for hidden decisions.

Many C++ features are useful on a desktop, but an embedded product has a much smaller budget and stricter timing.

01 / Memory

HEAP

The memory left depends on what ran earlier. Allocation can fail, and fragmentation makes memory hard to use.

02 / Control

EXCEPTIONS

Control can jump across several stack frames, which is hard to see at the call site.

03 / Dispatch

VIRTUAL

Virtual interfaces add runtime indirection and make the call target less visible.

04 / Dependencies

STL

Library facilities may rely on assumptions, headers, or runtime support that a target does not fit.

05 / Timing

UNKNOWN

Any operation with unclear worst-case work makes timing analysis harder.

These tools are not "bad practices", but unsuitable for embedded work.
Before we adopt a feature, we ask: how much memory, how can it fail, and how much work can it do?

02 / Storage by design

Make the memory budget visible.

The capacity is part of the type. The container owns its storage inside the object and does not silently grow.

quick-start.cppFIXED CAPACITY
#include "castle/container/vector.hpp"
#include "castle/error/status.hpp"

castle::container::vector<uint16_t, 16U> samples;

if (samples.push_back(42U) == castle::status::ok)
{
    // Use the stored sample.
}
CAPACITY IS EXPLICITNO REALLOCATION

Compile-time bound16 elements

Storage modelInside the object

Conceptual slots / 16 totalThe illustration shows capacity, not the current size.

03 / Failure as data

Make failure an ordinary result.

A full buffer or an empty queue is a normal condition that the system must handle every day. CASTLE returns a status for the caller to check.

Typical container operationRead / write

status::ok

Continue with the accepted data.

status::full

Reject the item, apply backpressure, or record a diagnostic.

status::empty

Handle “nothing to read” as an expected state.

Expected runtime outcomes use status or bool. Programmer-contract violations use the configured assertion policy.

04 / Abstraction with a budget

Pay for abstraction deliberately.

The goal is not to remove abstraction. It is to choose where work happens and make storage and dispatch costs inspectable.

01 / DEFAULT PATH

Templates and static dispatch

Types and behavior are selected at compile time. The compiler can specialize the code without a runtime base-class lookup.

02 / OWNED CALLABLES

In-place storage

The function wrapper keeps a callable in a bounded local buffer. A callable that does not fit is rejected at compile time.

03 / EXPLICIT SEAMS

Limited virtual interfaces

Core data structures avoid virtual dispatch. Observer, visitor, and delegate interfaces use it, so explain its cost and why it helps.

The same discipline applies to language and library features: no exceptions or RTTI, and no required STL containers or algorithms.

05 / The library shape

One library. Two layers.

The core gives reusable building blocks. The extensions apply them to more specific jobs.

CASTLE CORE

Containers and memorystorage and lifetime helpers

Utility, algorithms, bitlanguage building blocks

Chrono and mathtime and computation

Callbacks and eventscontrolled behavior

Sync, iterators, traitssynchronization and errors

HEADER-ONLY / C++17 / NO REQUIRED STL

CASTLE EXTENSIONS

Protocols and parsersCAN · LIN · NMEA · UBX · PTP

Input / outputGPIO · UART · SPI · I²C

Data formatsCSV · INI · JSON · XML

Checksums and codecsCRC · Base64 · hex

Domain servicescrypto · geodetic · diagnostics · filtering

INCLUDE ONLY WHAT YOUR PLATFORM SUPPORTS

Some facilities use POSIX or Linux APIs, some use pthreads, and there is also a Zephyr GPIO backend.

06 / The daily coding shift

A different everyday coding habit.

The code has a few more explicit lines. Those lines are not noise. They record decisions the system already had to make.

event dispatchCASTLE STYLE
struct TickEvent {};

using dispatcher_type = castle::events::event_dispatcher<
  castle::events::event_tag_config<TickEvent, 4U, void(uint32_t)>>;

dispatcher_type dispatcher;
auto sub = dispatcher.register_callback<TickEvent>([](uint32_t){});
dispatcher.dispatch_event<TickEvent>(1U);
sub.unsubscribe();
FIXED TAG CAPACITYVISIBLE

In the typeHow much can exist?

At the call siteWhat can go wrong?

In the ownerWho decides how long it lives?

Before you add a buffer, decide its size. Before you add a callback, decide who owns it.

07 / Review mindset

A code review asks different questions.

We still check correctness and tests, but we also ask four resource questions.

01

Memory

Where does the storage live, and who owns it? Is it borrowed or owned by the object? What is the maximum size?

02

Capacity and failure

What happens when the queue is full, the buffer is empty, or a lookup fails? Is it handled or ignored?

03

Timing and work

What work happens in the worst case? Is that cost right for the task period?

04

Concurrency and lifetime

Can this run from more than one task or an interrupt? Who protects shared state? Can a callback outlive its object?

A strong review explains these answers from the design and code, not only from a passing test.

08 / Impact and limits

Predictability improves. It still must be proven.

CASTLE makes component behavior easier to reason about. It does not replace evidence at the system level.

What becomes easier

Clearer engineering budgets

Known storage bounds help with RAM budgeting.
Explicit statuses help define recovery behavior.
No heap, exceptions, RTTI, or STL means less runtime machinery to account for.
Consistent patterns make code easier to maintain across teams.

What still needs evidence

System-level validation

Measure worst-case timing on the actual microcontroller.
Size buffers using real traffic and fault scenarios.
Understand the OS backend, scheduler, and interrupt constraints.
Check synchronization, compiler, and processor behavior.

BOUNDED COMPONENTS + EXPLICIT POLICY + TARGET VALIDATION = MORE PREDICTABLE SYSTEMS

09 / Take it into the next change

Design the bounds.
Then write the code.

When we review a component, we should explain how much memory it can own, what happens at its limit, and what work it can do.

01 Choose storage and capacity up front.

02 Make expected outcomes explicit.

03 Keep lifetimes and dispatch visible.

04 Measure timing and concurrency on the real target.

Fewer hidden decisions. More deliberate systems.

THANK YOU / CASTLE 2.0 / C++17 EMBEDDED TEMPLATE LIBRARY

APPENDIX / A · Method

Benchmark setup.

Each CASTLE operation has an STL counterpart run under the same harness. The figures come from one captured run, so read them as a guide, not a statistical result.

Host CPU16 CPUs · ~2.0 GHz

HarnessGoogle Benchmark

MetricCPU ns per op

Captured2026-09-17

How to read

Lower is faster

Each pair runs the same operation: CASTLE and STL.
Ratio = STL time ÷ CASTLE time. Above 1.00x favors CASTLE.

Excluded from charts

Unreliable rows

One-iteration rows report about 1.4e+11 ns (algorithm, iterator, most lookups).
Rows near 0.2 ns sit at the loop floor; the work was likely optimized away.
Build flags and compiler version are not recorded in this capture.

APPENDIX / B · Overview

Speed ratio overview.

Most common operations sit at parity. The clearest CASTLE gains are string search, array access, and associative containers.

CASTLE faster Parity (±3%) STL faster

string_find

2.11x

hash_set_insert

1.32x

array_access

1.31x

tree_map_erase

1.28x

hash_map_insert

1.26x

bitset_to_string

1.26x

hash_set_erase

1.25x

tree_set_insert

1.17x

steady_clock_now

1.05x

inplace_function_call

1.03x

vector_push_back

1.00x

stack_push_pop

1.00x

string_view_find_substring

0.97x

queue_push_pop

0.95x

string_construct

0.94x

Ratio = STL ÷ CASTLE, CPU ns per op. Vertical line marks 1.00x (parity). Bar scale 0–2.2x.

Results within ±3% are treated as parity, so single-run noise is not read as a win.

APPENDIX / C · Containers

Associative containers.

All eight associative operations are faster on CASTLE in this run, between about 1.17x and 1.32x.

CASTLE STL

hash_map insert

864 ns

1085 ns

hash_map erase

857 ns

1080 ns

hash_set insert

865 ns

1141 ns

hash_set erase

855 ns

1072 ns

tree_map insert

1306 ns

1546 ns

tree_map erase

1110 ns

1425 ns

tree_set insert

1283 ns

1505 ns

tree_set erase

1114 ns

1427 ns

CPU ns per op. Scale 0–1600 ns. Shorter bar is faster.

The source of each gap is not shown in this capture; check the implementation before naming a cause.

APPENDIX / D · Sequences and strings

Sequences, strings, bits.

Most rows are at parity. The notable gaps are string_find (2.1x faster on CASTLE) and small CASTLE deficits in queue push/pop and string construct.

CASTLE STL

Containers and stacks · 0–1000 ns

vector push_back

794 ns

vector emplace_back

795 ns

815 ns

stack push+pop

931 ns

935 ns

queue push+pop

926 ns

879 ns

string append

723 ns

732 ns

Small operations · 0–70 ns

array access

19.1 ns

25.1 ns

string find

4.00 ns

8.43 ns

string construct

14.7 ns

13.8 ns

bitset to_string

50.2 ns

63.1 ns

Outside the highlighted rows the gaps are small, so speed alone should not drive the design choice.