When working with microcontrollers, debugging can feel like peering through a keyhole. Unlike desktop development, there\u2019s no rich OS to lean on, no debugger always attached, and no full-featured console to tell you what went wrong. If your system crashes, often the only trace left is whatever text you managed to push out before everything froze.<\/p>\n\n\n\n
That\u2019s why a good logging framework<\/strong> is one of the first things I wanted in MicrOS \u2014 my small embedded operating system. In this series, I\u2019ll walk you through how I built a lightweight but flexible logging API for MicrOS, starting from the simplest ideas and growing it into a colorful, structured system with per-module filtering and runtime flexibility.<\/p>\n\n\n\n The simplest way to log on a microcontroller is to sprinkle In an RTOS like MicrOS, I wanted something closer to what you\u2019d expect in a professional system:<\/p>\n\n\n\n I set out a few rules for the system:<\/p>\n\n\n\n At the heart of the API is a simple enum:<\/p>\n\n\n\n This gives us a spectrum from completely silent ( A global ceiling is set at build time:<\/p>\n\n\n\n So if you compile with Before adding colors or fancy formatting, we just need a function to send messages out:<\/p>\n\n\n\n This function will later handle formatting and writing to Each C file that wants to log needs to \u201cintroduce itself\u201d:<\/p>\n\n\n\n This macro stores the module\u2019s name ( Once a module is registered, logging is as easy as:<\/p>\n\n\n\n The API will decide (based on global and module levels) whether to actually print the message.<\/p>\n\n\n\n So far we\u2019ve defined:<\/p>\n\n\n\n That\u2019s enough to sketch out the framework, but it doesn\u2019t yet make logs easy to read. Everything is still monochrome, and debug logs don\u2019t tell you where they came from.<\/p>\n\n\n\n In Part 2<\/strong>, we\u2019ll fix that: we\u2019ll add structured formatting and VT100 colors<\/strong>, so logs pop off the screen and errors can\u2019t be missed.<\/p>\n\n\n\n \ud83d\udc49 Stay tuned for Part 2: Coloring and Structuring Logs<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":" When working with microcontrollers, debugging can feel like peering through a keyhole. Unlike desktop development, there\u2019s no rich OS to lean on, no debugger always attached, and no full-featured console to tell you what went wrong. If your system crashes, often the only trace left is whatever text you managed to push out before everything […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7],"tags":[],"class_list":["post-151","post","type-post","status-publish","format-standard","hentry","category-development","category-logging"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/151","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/comments?post=151"}],"version-history":[{"count":1,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/151\/revisions"}],"predecessor-version":[{"id":152,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/151\/revisions\/152"}],"wp:attachment":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/media?parent=151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/categories?post=151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/tags?post=151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nWhy Not Just
printf<\/code>?<\/h2>\n\n\n\nprintf()<\/code> calls wherever you need to see something. And in very small projects, that works fine. But once you scale up, it quickly becomes a problem:<\/p>\n\n\n\n\n
printf<\/code>s eat cycles and code space.<\/li>\n\n\n\n\n
\n\n\n\nDesign Goals for MicrOS Logging<\/h2>\n\n\n\n
\n
CONFIG_MICROS_LOG_LEVEL<\/code>).<\/li>\n\n\n\nMICROS_LOG_REGISTER(main, MICROS_LOG_LEVEL_INFO)<\/code>).<\/li>\n\n\n\nE(\"...\")<\/code>, W(\"...\")<\/code>, I(\"...\")<\/code>, D(\"...\")<\/code>.<\/li>\n\n\n\n
\n\n\n\nThe First Building Block: Log Levels<\/h2>\n\n\n\n
typedef enum {\n MICROS_LOG_LEVEL_NONE = 0,\n MICROS_LOG_LEVEL_ERROR = 1,\n MICROS_LOG_LEVEL_WARN = 2,\n MICROS_LOG_LEVEL_INFO = 3,\n MICROS_LOG_LEVEL_DEBUG = 4\n} micros_log_level_t;\n<\/code><\/pre>\n\n\n\nNONE<\/code>) to full verbosity (DEBUG<\/code>).<\/p>\n\n\n\n#define CONFIG_MICROS_LOG_LEVEL MICROS_LOG_LEVEL_DEBUG\n<\/code><\/pre>\n\n\n\nINFO<\/code>, you\u2019ll never even build debug messages into your binary.<\/p>\n\n\n\n
\n\n\n\nA Simple Logging Function<\/h2>\n\n\n\n
void _log(micros_log_level_t level,\n const char* module_name,\n const char* file,\n int line,\n const char* fmt,\n ...);\n<\/code><\/pre>\n\n\n\nstdout<\/code>\/stderr<\/code>. For now, it\u2019s just a placeholder we can build around.<\/p>\n\n\n\n
\n\n\n\nRegistering a Module<\/h2>\n\n\n\n
MICROS_LOG_REGISTER(main, MICROS_LOG_LEVEL_INFO);\n<\/code><\/pre>\n\n\n\n\"main\"<\/code>) and its default verbosity. It means we can later filter logs differently per module.<\/p>\n\n\n\n
\n\n\n\nUsing the API<\/h2>\n\n\n\n
I(\"System is starting up...\");\nE(\"Fatal error: %d\", code);\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat\u2019s Next<\/h2>\n\n\n\n
\n
\n\n\n\n