Portions of the advice are so good, they bear restatement in the context of our ongoing discussion about reliable firmware architecture:
1. Verbosity The API for your logger module should allow for the selection of a verbosity level, within a range from debug-only to critical. That way, application code that desires to have log something need not be changed even as you shift to a production release environment in which you wish to minimize log memory size.
2. Timestamps All logged events should be timestamped. Furthermore, these timestamps should be added as close as possible to the time of the actual event’s occurrence. Note that timer ticks since reset may be an acceptable form of a timestamp in systems not otherwise requiring date/time knowledge.
3. Readability The underlying log format should favor readability by humans. Event logs will ideally be parse-able by automated testing tools as well as by humans who must occasionally develop new automated tests. If the underlying log format cannot itself be human readable, then an offline tool should be provided to translate the raw log data to a human readable format.
If your logger module does only these three things, it will provide a powerful foundation on which much additional functionality can be built.