Lines Matching +full:off +full:- +full:on +full:- +full:delay +full:- +full:us
17 - Deferred logging reduces the time needed to log a message by shifting time
20 - Multiple backends supported (up to 9 backends).
21 - Custom frontend support. It can work together with backends.
22 - Compile time filtering on module level.
23 - Run time filtering independent for each backend.
24 - Additional run time filtering on module instance level.
25 - Timestamping with user provided function. Timestamp can have 32 or 64 bits.
26 - Dedicated API for dumping data.
27 - Dedicated API for handling transient strings.
28 - Panic support - in panic mode logging switches to blocking, synchronous
30 - Printk support - printk message can be redirected to the logging.
31 - Design ready for multi-domain/multi-processor system.
32 - Support for logging floating point variables and long long arguments.
33 - Built-in copying of transient strings used as arguments.
34 - Support for multi-domain logging.
39 During compilation logs can be filtered out on module basis and severity level.
41 Logs can also be compiled in but filtered on run time using dedicate API. Run
51 - ``LOG_X`` for standard printf-like messages, e.g. :c:macro:`LOG_ERR`.
52 - ``LOG_HEXDUMP_X`` for dumping data, e.g. :c:macro:`LOG_HEXDUMP_WRN`.
53 - ``LOG_INST_X`` for standard printf-like message associated with the
55 - ``LOG_INST_HEXDUMP_X`` for dumping data associated with the particular
60 - :c:macro:`LOG_WRN_ONCE` for warnings where only the first occurrence is of interest.
95 :kconfig:option:`CONFIG_LOG`: Global switch, turns on/off the logging.
139 :kconfig:option:`CONFIG_LOG_PROCESS_THREAD_STARTUP_DELAY_MS`: Delay in milliseconds
181 :kconfig:option:`CONFIG_LOG_BACKEND_UART`: Enabled built-in UART backend.
197 .. code-block:: c
209 .. code-block:: c
222 .. code-block:: c
239 .. code-block:: none
242 module-str = foo
248 In case of modules which are multi-instance and instances are widely used
250 which can be used to provide filtering on instance level rather than module
255 - a pointer to specific logging structure is declared in instance structure.
258 .. code-block:: c
267 - module must provide macro for instantiation. In that macro, logging instance
270 .. code-block:: c
281 In order to use the instance logging API in a source file, a compile-time log
284 .. code-block:: c
290 LOG_INST_INF(f->log, "Initialized.");
293 In order to use the instance logging API in a header file, a compile-time log
296 .. code-block:: c
302 LOG_INST_INF(f->log, "Initialized.");
323 .. code-block:: c
349 In case of error condition system usually can no longer rely on scheduler or
382 - Frontend
383 - Core
384 - Backends
399 -----------
407 * Each message is a self-contained, continuous block of memory thus it is suited
414 +------------------+----------------------------------------------------+
416 | +----------------------------------------------------+
418 | +----------------------------------------------------+
420 | +----------------------------------------------------+
422 | +----------------------------------------------------+
424 | +----------------------------------------------------+
426 | +----------------------------------------------------+
428 | +----------------------------------------------------+
430 | +----------------------------------------------------+
432 | +----------------------------------------------------+
434 +------------------+----------------------------------------------------+
436 | +----------------------------------------------------+
438 | | (optional) +----------------------------------------------------+
440 +------------------+----------------------------------------------------+
442 +------------------+----------------------------------------------------+
444 +------------------+----------------------------------------------------+
448 .. [#l0] Depending on the platform and the timestamp size fields may be swapped.
452 ----------------------
458 - No overflow - the new log is dropped if space for a message cannot be allocated.
459 - Overflow - the oldest pending messages are freed, until the new message can be
466 Run-time filtering
467 ------------------
469 If run-time filtering is enabled, then for each source of logging a filter
472 the system. *Slot 0* (bits 0-2) is used to aggregate maximal filter setting for
480 2 up to info level (*slot 2*). Slots 3-9 are not used. Aggregated filter
484 +------+------+------+------+-----+------+
486 +------+------+------+------+-----+------+
487 | INF | ERR | INF | OFF | ... | OFF |
488 +------+------+------+------+-----+------+
506 ---------------------------------------------------------
518 Multi-domain support
523 of the binaries (Secure or Nonsecure) on an ARM TrustZone core.
525 Tracing and debugging on a multi-domain system is more complex and requires an efficient logging
531 as logs are presented on independent outputs.
532 * Use a multi-domain logging system where log messages from each domain end up in one root domain,
535 created from the backend on one side and linked to the other.
537 The Log link is an interface introduced in this multi-domain approach. The Log link is
542 source names, and so on.
544 There are three types of domains in a multi-domain system:
546 * The *end domain* has the logging core implementation and a cross-domain
549 have backends that output logs to the user. It has a cross-domain backend either to
554 See the following image for an example of a multi-domain setup:
558 Multi-domain example
561 For example, let's consider an SoC with two ARM Cortex-M33 cores with TrustZone: cores A and B (see
564 root domain, it has two links: one to *core A secure* (A_NS-A_S) and one to
565 *core B nonsecure* (A_NS-B_NS). *B_NS* domain has one link, to *core B secure*
566 *B_NS-B_S*), and a backend to *A_NS*.
570 in the illustration above as a dotted UART backend on the *B_NS* domain.
573 ---------
595 Let's consider a log message created on the *B_S* domain:
598 #. When the *B_NS-B_S* link receives the message, it increases the ``domain_id``
599 to ``1`` by adding the *B_NS-B_S* offset.
601 #. When the *A_NS-B_NS* link receives the message, it adds the offset (``2``) to the ``domain_id``.
605 Cross-domain log message
606 ------------------------
611 processing can include converting a string package to a *fully self-contained*
612 version (copying read-only strings to the package body).
618 -----------------
620 In the single-domain case, each log source has a dedicated variable with runtime
621 filtering for each backend in the system. In the multi-domain case, the originator of
625 filtering setting in each domain on the way to the root domain. As the number of
632 in both multi-domain and single-domain scenarios.
635 ----------------
642 * If domains have the same timestamp source or if there is an out-of-bound mechanism that
668 enter panic mode with :c:func:`log_backend_panic`. On that call backend should
669 switch to synchronous, interrupt-less operation or shut down itself if that is
681 ------------------
688 .. code-block:: console
695 Dictionary-based Logging
698 Dictionary-based logging, instead of human readable texts, outputs the log
708 an offline parser and is not as intuitive to use as text-based log messages.
716 -------------
718 Here are kconfig options related to dictionary-based logging:
720 - :kconfig:option:`CONFIG_LOG_DICTIONARY_SUPPORT` enables dictionary-based logging
723 - The UART backend can be used for dictionary-based logging. These are
726 - :kconfig:option:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_HEX` tells
731 - :kconfig:option:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_BIN` tells
736 -----
738 When dictionary-based logging is enabled via enabling related logging backends,
746 .. code-block:: console
752 Add an optional argument ``--hex`` to the end if the log data file contains
757 Please refer to the :zephyr:code-sample:`logging-dictionary` sample to learn more on how to use
777 .. code-block:: c
786 on ``qemu_x86``. It is a rough comparison to give a general overview.
788 +--------------------------------------------+------------------+
791 | Kernel logging | 7us [#f0]_/11us |
793 +--------------------------------------------+------------------+
794 | User logging | 13us |
796 +--------------------------------------------+------------------+
797 | kernel logging with overwrite | 10us [#f0]_/15us |
798 +--------------------------------------------+------------------+
799 | Logging transient string | 42us |
800 +--------------------------------------------+------------------+
801 | Logging transient string from user | 50us |
802 +--------------------------------------------+------------------+
805 +--------------------------------------------+------------------+
807 +--------------------------------------------+------------------+
809 +--------------------------------------------+------------------+
812 +--------------------------------------------+------------------+
826 .. [#f4] Average size of a log message (excluding string) with 2 arguments on ``Cortex M3``
832 is optimized it may lead to stack overflow. Stack usage depends on mode and optimization. It
836 which includes string formatting. In case of that mode, stack usage will depend on which backends
840 on mode, optimization and platform used. Test is using only the default backend.
844 +---------------+----------+----------------------------+-----------+-----------------------------+
847 | ARM Cortex-M3 | 40 | 152 | 412 | 783 |
848 +---------------+----------+----------------------------+-----------+-----------------------------+
850 +---------------+----------+----------------------------+-----------+-----------------------------+
852 +---------------+----------+----------------------------+-----------+-----------------------------+
854 +---------------+----------+----------------------------+-----------+-----------------------------+
856 +---------------+----------+----------------------------+-----------+-----------------------------+
861 For logging on NRF54H20 using ARM Coresight STM see :ref:`logging_cs_stm`.