Open-Source Observability · rokath

trice

Trice is a compact, ID-based logging framework for embedded C/C++ that replaces printf-style logging with binary trace records to reduce FLASH usage, bandwidth, and CPU overhead. The PC-side tool decodes these records using a cumulative format map (til.json), enabling field diagnostics even on older firmware versions.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/rokath/trice

964

GitHub stars

103

Forks

Primary language

MIT

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	rokath/trice
Owner	rokath
Primary language	C
License	MIT — OSI-approved
Stars	964
Forks	103
Open issues	0
Latest release	v1.3.0 (2026-07-07)
Last updated	2026-07-07
Source	https://github.com/rokath/trice

What trice is

Trice uses source-level macro instrumentation to emit only trace IDs and runtime values instead of full format strings, with optional SEGGER RTT, UART, USB, or custom transport backends. A Go-based host tool reconstructs logs by mapping IDs to format strings in til.json, supporting encryption, timestamps, and flexible buffering modes (direct, ring buffer, double buffer).

Quickstart

Get the trice source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/rokath/trice.git2cd trice3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Bare-metal and RTOS embedded logging

MCU firmware requiring non-intrusive logging in interrupt handlers and time-critical sections, where traditional printf is too slow or too large (ARM Cortex-M, STM32, etc.).

Field diagnostics and long-term support

Deployed products needing offline log decoding and backward compatibility; the accumulated til.json allows decoding logs from years-old firmware releases.

Resource-constrained devices

Systems with limited FLASH, RAM, or bandwidth where reducing format-string storage and log transfer size is critical (e.g., IoT sensors, wearables, battery-powered devices).

Implementation considerations

Source code instrumentation: Embed `trice insert` and `trice clean` into the build pipeline before/after compilation; choose ID workflow (keep in source, clean after build, or use cache) early and document.
Transport integration: Select a backend (SEGGER RTT for lab, UART/USB for serial, custom non-blocking byte writer); ensure the target provides a write function with low latency and minimal stack impact.
Artifact management: The cumulative til.json must be version-controlled and retained for field diagnostics; treat it as a build dependency alongside the firmware binary.
Configuration tuning: Select appropriate buffering mode (deferred ring/double buffer vs. direct) based on RAM budget, CPU overhead tolerance, and log volume; optimize compiler flags for minimal insertion.
Testing and validation: Verify that log IDs are stable across builds, test decoding of logs from multiple firmware versions, and validate encrypted/timestamped output if using advanced features.

When to avoid it — and what to weigh

High-level application logging — Desktop or server-side applications where printf or structured logging libraries (spdlog, zap) are simpler and more standard; Trice adds source-code rewriting overhead.
Dynamic or ad-hoc format strings — Systems generating log messages at runtime with user-supplied format strings; Trice requires pre-defined format strings at build time.
Team unfamiliar with embedded build workflows — Projects where developers are not comfortable with pre-build instrumentation steps (trice insert/clean) or managing cumulative ID mapping files.
No access to PC-side tooling infrastructure — Environments where running a Go-based host tool or managing til.json artifacts is infeasible, or where log decoding must happen entirely on-device.

License & commercial use

MIT License (permissive, OSI-approved). Allows commercial use, modification, and redistribution with attribution and no warranty.

MIT is a permissive open-source license suitable for commercial products. No license restrictions on embedding Trice in proprietary firmware or commercial tools. However, ensure your organization's legal review confirms compatibility with any proprietary dependencies or export controls.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Trice supports optional encryption (mentioned in topics and features overview), but specific cryptographic details, key management, or vulnerability disclosures are not detailed in provided data. Requires review of full documentation and source code for cryptographic implementation quality and no-replay protections. Binary log files and til.json artifacts should be treated as sensitive in field diagnostics workflows.

Alternatives to consider

SEGGER SystemView

Proprietary real-time tracing with RTT backend and GUI analysis; simpler plug-and-play integration but requires SEGGER license and does not offer legacy field decoding via text artifacts.

Traditional printf with log ringbuffer

Simpler, no build-time instrumentation; suitable for less resource-constrained systems but incurs higher FLASH/bandwidth costs and limited ability to decode offline without source access.

OpenOCD/GDB logging

Integrated with standard debugging toolchain; interactive but slower and intrusive; does not address production field logging or offline decoding scenarios.

Software development agency

Build on trice with DEV.co software developers

Explore Trice integration for your firmware project. Review the quickstart guides and example projects on GitHub, then contact our experts for architectural guidance on build-system integration and field-support workflows.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

trivy mtail tfsec

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability Embedded & IoT Development DevOps & Build Integration Talk to DEV.co

trice FAQ

Do I need to rewrite all my printf calls to use Trice?

No. Trice provides a `-alias` option to reuse existing printf-style code with minimal changes. You can also keep printf for high-level logging and use Trice selectively for performance-critical or interrupt paths.

What happens if I lose the til.json file?

Without til.json, binary log records cannot be decoded to readable text. This is why til.json must be version-controlled and retained as a build artifact. The cumulative design means one til.json can decode logs from any released firmware version.

Can I decode logs without the PC tool?

Yes, if you implement your own receiver. Binary Trice records contain an ID and optional values; you can read til.json, parse the records, and reconstruct text. The Go source code and format specification can guide custom implementations.

What is the overhead in a typical use case?

A few CPU cycles per trice() call in optimized configurations; FLASH savings are substantial (format strings removed from target image). Exact overhead depends on transport, buffering mode, and compiler optimization.

Software developers & web developers for hire

DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If trice is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.

Ready to streamline embedded logging?

Talk to DEV.co Schedule a Consultation