Embedded telemetry
ChipWatch
Structured telemetry for firmware where conventional logging frameworks are too expensive or simply unavailable.
Discuss your target// generated at compile time
CW_EVENT(temperature_sample,
uint16_t sensor_id,
int16_t millidegrees);
void sample_sensor() {
const auto value = read_temp();
chipwatch::emit(
temperature_sample,
SENSOR_04,
value
);
}heap allocations: 0buffer: 31%
THE RULE
A device is allowed to lose telemetry.
It is not allowed to crash because it could not record telemetry.
That distinction is fundamental to the design.
01 / CORE PROPERTIES
Everything has a boundary.
ChipWatch writes binary structured events into a bounded memory buffer. Host-side tools decode them later.
01Bounded memory consumptionKnown before deployment
02No mandatory heap allocationStatic storage is sufficient
03Compile-time event definitionsSchema mistakes fail early
04Binary event encodingCompact on constrained links
05Configurable overflow behaviorThe application remains in control
06C ABI availableFor mixed-language firmware
02 / TRANSPORT
Generate here. Move it however you can.
Transport is supplied separately from event generation. ChipWatch does not require threads, filesystem access, or an IP network.
ChipWatch bufferstructured binary events
03 / LONG-LIVED FIRMWARE
Compatibility is part of the product.
Compile-time schema generation and version-aware host decoding allow tools and firmware to evolve on different schedules, because embedded deployments usually do.
DEVICEChipWatch 2.xstill producing events
→SCHEMAversion-awareadditive definitions
→HOST TOOLChipWatch 3.xdecodes both versions
CHIPWATCH
Tell us what the target permits.
Memory, compiler, transport, timing constraints, and the age of the toolchain are all useful information.
sales@insight-technology.org