Three Open Source Libraries Commonly Used by MCU Experts

Since we cannot always step through the program using a debugger, the device’s operational logs become particularly important.

Typically, we have the following requirements for logs:

• Different log levels (Debug, Warning, Info, Error, Fatal);
• Log printing should be as simple and easy to use as printf;
• Ability to set log levels;
• Small footprint;
• Configurable, and even able to disable logs;
• Support color highlighting based on different log levels;
• Customizable configurations, including timestamps;
• Support for RTOS;

The above are basic functionalities, but in embedded devices, sometimes we want to save the device’s operational logs, and we need the following functionalities;

• Support multiple access methods, such as serial terminal or saving to embedded file systems;
• Support shell commands accessed through a serial terminal;

Not all of these requirements may be fully implemented.

Apart from the commonly used log4c and log4cpp, here are three excellent open-source logging libraries that are particularly suitable for microcontroller projects. Starting from lightweight to feature-rich, the last one is very powerful, so please be patient and read to the end.

rxi_log

Project address: https://github.com/rxi/log.c

A simple logging library implemented in C99, with output as shown below;

Specific usage

Integrate log.c and log.h from the source code into your project. To print logs, simply call the following APIs;

log_trace(const char *fmt, ...);log_debug(const char *fmt, ...);log_info(const char *fmt, ...);log_warn(const char *fmt, ...);log_error(const char *fmt, ...);log_fatal(const char *fmt, ...);

In addition to these APIs, there are log_set_quiet, log_set_lock, LOG_USE_COLOR, etc. For details, please refer to the original project.

ulog

Project address: https://github.com/rdpoor/ulog

uLog provides a structured logging mechanism for embedded microcontrollers or any resource-constrained systems. It inherits some concepts from popular Log4c and Log4j platforms but with lower overhead.

Some features of uLog include:

• uLog is easy to integrate into almost any environment, consisting of one header file and one source file, and is written in pure C.
• uLog provides familiar severity levels (CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE).
• uLog supports multiple user-defined outputs (console, log files, memory buffers, etc.), each with its own reporting threshold level.
• uLog is “actively independent” with minimal dependencies, requiring only stdio.h, string.h, and stdarg.h.
• When you are not using uLog, it does not interfere: if ULOG_ENABLED is not defined at compile time, no logging code will be generated.
• uLog has been well tested. For details, see the accompanying ulog_test.c file.

EasyLogger

Project address: https://github.com/armink/EasyLogger

I have used this project for a long time and highly recommend it. It is the work of RT-Thread experts and has been integrated into the RTOS. It supports a wide range of features that basically meet various development needs.

Features include:

• Lightweight, ROM<1.6K, RAM<0.3K;
• Supports various access modes (e.g.: terminal, file, database, serial, 485, Flash…);
• Log content can include level, timestamp, thread information, process information, etc.;
• Thread-safe, and supports asynchronous output and buffered output modes;
• Supports multiple operating systems (RT-Thread, UCOS, Linux, Windows…), and also supports bare-metal platforms;
• Logs support RAW format and hexdump;
• Supports dynamic filtering by tag, level, and keyword;
• Logs of different levels support different color displays;
• Highly extensible, supports extending new features in plugin form.

The above is just a part of this project; for specifics, please refer to the project address.

summary

I hope everyone pays attention to the use of logs in their daily development. Set different levels of logs for each development stage, and set module logs for different modules. This helps quickly locate issues and resolve them efficiently.