Lines Matching +full:time +full:- +full:slot
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.
36 Logging API is highly configurable at compile time as well as at run time. Using
38 compilation to reduce image size and execution time when logs are not needed.
41 Logs can also be compiled in but filtered on run time using dedicate API. Run
42 time filtering is independent for each backend and each source of log messages.
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.
78 Logger's default frontend is designed to be thread safe and minimizes time needed
79 to log the message. Time consuming operations like string formatting or access to the
181 :kconfig:option:`CONFIG_LOG_BACKEND_UART`: Enabled built-in UART backend.
193 Optionally, a compile time log level for the module can be specified as the
197 .. code-block:: c
205 Optionally, a compile time log level for the module can be specified as
209 .. code-block:: c
217 before logging API is called. Optionally, a compile time log level for the module
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
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
382 - Frontend
383 - Core
384 - Backends
394 time), allocating a buffer for the message, creating the message and committing that
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 +------------------+----------------------------------------------------+
452 ----------------------
455 system is generating more log messages than it can process in certain time
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
471 bit slots. Except *slot 0*, each slot stores current filter for one backend in
472 the system. *Slot 0* (bits 0-2) is used to aggregate maximal filter setting for
473 given source of logging. Aggregate slot determines if log message is created
477 time filtering, binary footprint is increased because logs are compiled in.
479 In the example below backend 1 is set to receive errors (*slot 1*) and backend
480 2 up to info level (*slot 2*). Slots 3-9 are not used. Aggregated filter
481 (*slot 0*) is set to info level and up to this level message from that
484 +------+------+------+------+-----+------+
485 |slot 0|slot 1|slot 2|slot 3| ... |slot 9|
486 +------+------+------+------+-----+------+
488 +------+------+------+------+-----+------+
506 ---------------------------------------------------------
518 Multi-domain support
525 Tracing and debugging on a multi-domain system is more complex and requires an efficient logging
532 * Use a multi-domain logging system where log messages from each domain end up in one root domain,
537 The Log link is an interface introduced in this multi-domain approach. The Log link is
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*.
573 ---------
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
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
647 indicates the time of the message generation.
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
703 instead of the whole strings. A dictionary created at build time contains
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
788 +--------------------------------------------+------------------+
793 +--------------------------------------------+------------------+
796 +--------------------------------------------+------------------+
798 +--------------------------------------------+------------------+
800 +--------------------------------------------+------------------+
802 +--------------------------------------------+------------------+
805 +--------------------------------------------+------------------+
807 +--------------------------------------------+------------------+
809 +--------------------------------------------+------------------+
812 +--------------------------------------------+------------------+
844 +---------------+----------+----------------------------+-----------+-----------------------------+
847 | ARM Cortex-M3 | 40 | 152 | 412 | 783 |
848 +---------------+----------+----------------------------+-----------+-----------------------------+
850 +---------------+----------+----------------------------+-----------+-----------------------------+
852 +---------------+----------+----------------------------+-----------+-----------------------------+
854 +---------------+----------+----------------------------+-----------+-----------------------------+
856 +---------------+----------+----------------------------+-----------+-----------------------------+