Exercise 3
Exploring the logger module features
In this exercise, we will practice configuring a software module using Kconfig configuration options. We will use the logger module as a case study and experiment with some of its features.
When the logger module is enabled by setting the global configuration symbol CONFIG_LOG=y, the following logger configurations are enabled by default.
| Option | Description |
|---|---|
LOG_MODE_DEFERRED | Deferred mode is used by default. Log messages are buffered and processed later. This mode has the least impact on the application. Time-consuming processing is deferred to the known context. |
LOG_PROCESS_THREAD | A thread is created by the logger subsystem (deferred mode). This thread is woken up periodically (LOG_PROCESS_THREAD_SLEEP_MS) or whenever the number of buffered messages exceeds the threshold (LOG_PROCESS_TRIGGER_THR). |
LOG_BACKEND_UART | Send logs to the UART console. |
LOG_BACKEND_SHOW_COLOR | Prints errors in red and warnings in yellow. Not all terminal emulators support this feature. |
LOG_BACKEND_FORMAT_TIMESTAMP | Timestamp is formatted to hh:mm:ss.ms,us. |
LOG_MODE_OVERFLOW | If there is no space to log a new message, the oldest one is dropped. |
Let’s verify this by invoking nRF Kconfig GUI.
This is accessible from the ACTIONS menu:
The logger module is found under the menu Sub Systems and OS Services as shown in the figure below:
CONFIG_LOGThese default settings are set by the nRF Connect SDK through Kconfig definition files (covered in Lesson 3). We can overwrite the default settings using the application configuration file prj.conf as we will see in this exercise.
Exercise steps
1. In the GitHub repository for this course, open the base code for this exercise, found in l4/l4_e3 of the version directory v2.8.x-v2.7.0
This code is identical to the one in the previous exercise.
2. For the sake of demonstration, let’s disable CONFIG_LOG_BACKEND_SHOW_COLOR.
This is done by adding the following configuration line into the application configuration file prj.conf.
CONFIG_LOG_BACKEND_SHOW_COLOR=nSince the application configuration file has the highest precedence, it will override the default settings and disable this feature.
3. Build the exercise
You can confirm that this feature has been disabled by opening Kconfig and typing LOG_BACKEND_SHOW_COLOR in the search bar. You can see that the “Colors in the backend” box is unchecked and this feature has been disabled.
LOG_BACKEND_SHOW_COLOR has been disabled4. Flash the application to the board as we have done in previous exercises. You should notice that the error and warning messages are no longer colored.
LOG_BACKEND_SHOW_COLOR disabled5. Let’s try another feature of the logger module.
CONFIG_LOG_MODE_MINIMAL enables a minimal logging implementation.
This is very useful when you have limited memory, and are not in need of the deferred feature of the logger. It has very little memory footprint overhead on top of the printk() implementation for standard logging macros. There are no timestamps, prefixes, colors, or asynchronous logging, and all messages are processed in-place which simply means it is sent to the console just like we did with printk().
Once CONFIG_LOG_MODE_MINIMAL is enabled, most other logger configurations will be unavailable, i.e they will have no effect.
Add the following configuration line into prj.conf
CONFIG_LOG_MODE_MINIMAL=y6. Build the exercise and flash it to the board.
Notice that the output of the logger module is significantly different when the minimal mode is activated.
Log levels are now indicated by letters (D=Debug, I=Info, W=Warning, E=Error) and timestamps and prefixed module names are not displayed.
The solution for this exercise can be found in the GitHub repository, in l4/l4_e3_sol of the version directory v2.8.x-v2.7.0.
Exploring the logger module features
In this exercise, we will practice configuring a software module using Kconfig configuration options. We will use the logger module as a case study and experiment with some of its features.
When the logger module is enabled by setting the global configuration symbol CONFIG_LOG=y, the following logger configurations are enabled by default.
| Option | Description |
|---|---|
LOG_MODE_DEFERRED | Deferred mode is used by default. Log messages are buffered and processed later. This mode has the least impact on the application. Time-consuming processing is deferred to the known context. |
LOG_PROCESS_THREAD | A thread is created by the logger subsystem (deferred mode). This thread is woken up periodically (LOG_PROCESS_THREAD_SLEEP_MS) or whenever the number of buffered messages exceeds the threshold (LOG_PROCESS_TRIGGER_THR). |
LOG_BACKEND_UART | Send logs to the UART console. |
LOG_BACKEND_SHOW_COLOR | Prints errors in red and warnings in yellow. Not all terminal emulators support this feature. |
LOG_BACKEND_FORMAT_TIMESTAMP | Timestamp is formatted to hh:mm:ss.ms,us. |
LOG_MODE_OVERFLOW | If there is no space to log a new message, the oldest one is dropped. |
Let’s verify this by invoking nRF Kconfig GUI.
This is accessible from the ACTIONS menu:
The logger module is found under the menu Sub Systems and OS Services as shown in the figure below:
CONFIG_LOGThese default settings are set by the nRF Connect SDK through Kconfig definition files (covered in Lesson 3). We can overwrite the default settings using the application configuration file prj.conf as we will see in this exercise.
Exercise steps
1. In the GitHub repository for this course, open the base code for this exercise, found in l4/l4_e3 of whichever version directory you are using .
This code is identical to the one in the previous exercise.
2. For the sake of demonstration, let’s disable CONFIG_LOG_BACKEND_SHOW_COLOR.
This is done by adding the following configuration line into the application configuration file prj.conf.
CONFIG_LOG_BACKEND_SHOW_COLOR=nSince the application configuration file has the highest precedence, it will override the default settings and disable this feature.
3. Build the exercise
You can confirm that this feature has been disabled by opening Kconfig and typing LOG_BACKEND_SHOW_COLOR in the search bar. You can see that the “Colors in the backend” box is unchecked and this feature has been disabled.
LOG_BACKEND_SHOW_COLOR has been disabled4. Flash the application to the board as we have done in previous exercises. You should notice that the error and warning messages are no longer colored.
LOG_BACKEND_SHOW_COLOR disabled5. Let’s try another feature of the logger module.
CONFIG_LOG_MODE_MINIMAL enables a minimal logging implementation.
This is very useful when you have limited memory, and are not in need of the deferred feature of the logger. It has very little memory footprint overhead on top of the printk() implementation for standard logging macros. There are no timestamps, prefixes, colors, or asynchronous logging, and all messages are processed in-place which simply means it is sent to the console just like we did with printk().
Once CONFIG_LOG_MODE_MINIMAL is enabled, most other logger configurations will be unavailable, i.e they will have no effect.
Add the following configuration line into prj.conf
CONFIG_LOG_MODE_MINIMAL=y6. Build the exercise and flash it to the board.
Notice that the output of the logger module is significantly different when the minimal mode is activated.
Log levels are now indicated by letters (D=Debug, I=Info, W=Warning, E=Error) and timestamps and prefixed module names are not displayed.
The solution for this exercise can be found in the GitHub repository, l4/l4_e3_sol of whichever version directory you are using.
Exploring the logger module features
In this exercise, we will practice configuring a software module using Kconfig configuration options. We will use the logger module as a case study and experiment with some of its features.
When the logger module is enabled by setting the global configuration symbol CONFIG_LOG=y, the following logger configurations are enabled by default.
| Option | Description |
|---|---|
LOG_MODE_DEFERRED | Deferred mode is used by default. Log messages are buffered and processed later. This mode has the least impact on the application. Time-consuming processing is deferred to the known context. |
LOG_PROCESS_THREAD | A thread is created by the logger subsystem (deferred mode). This thread is woken up periodically (LOG_PROCESS_THREAD_SLEEP_MS) or whenever the number of buffered messages exceeds the threshold (LOG_PROCESS_TRIGGER_THR). |
LOG_DETECT_MISSED_STRDUP | Assert and log error messages when the logger detects a local string format specifier (%s) and string address that is not from the read-only memory section and not from the pool used for string duplicates. |
LOG_BACKEND_UART | Send logs to the UART console. |
LOG_BACKEND_RTT | Send logs to the RTT console. Note that by default the logger sends output to two consoles. |
LOG_BACKEND_SHOW_COLOR | Prints errors in red and warnings in yellow. Not all terminal emulators support this feature. |
LOG_BACKEND_FORMAT_TIMESTAMP | Timestamp is formatted to hh:mm:ss.ms,us. |
LOG_MODE_OVERFLOW | If there is no space to log a new message, the oldest one is dropped. |
Let’s verify this by invoking guiconfig. The logger module is found under the menu Sub Systems and OS Services as shown in the figure below:
These default settings are set by the nRF Connect SDK through Kconfig definition files (covered in Lesson 3). We can overwrite the default settings using the application configuration file prj.conf as we will see in this exercise.
Exercise steps
1. In the GitHub repository for this course, open the base code for this exercise, found in l4/l4_e3 of whichever version directory you are using.
This download is identical to the one in the previous exercise.
2. For the sake of demonstration, let’s disable CONFIG_LOG_BACKEND_SHOW_COLOR.
This is done by adding the following configuration line into the application configuration file prj.conf.
CONFIG_LOG_BACKEND_SHOW_COLOR=nSince the application configuration file has the highest precedence, it will override the default settings and disable this feature.
3. Build the exercise
You can confirm that this feature has been disabled by opening guiconfig and examining the Output Formatting submenu in the Logging menu. You should see that the Enable colors in the backend is unchecked now.
4. Flash the application to the board as we have done in previous exercises. You should notice that the error and warning messages are no longer colored.
5. Let’s try another feature of the logger module.
CONFIG_LOG_MODE_MINIMAL enables a minimal logging implementation.
This is very useful when you have limited memory, and are not in need of the deferred feature of the logger. It has very little memory footprint overhead on top of the printk() implementation for standard logging macros. There are no timestamps, prefixes, colors, or asynchronous logging, and all messages are processed in-place which simply means it is sent to the console just like we did with printk().
Once CONFIG_LOG_MODE_MINIMAL is enabled, most other logger configurations will be unavailable, i.e they will have no effect.
Add the following configuration line into prj.conf
CONFIG_LOG_MODE_MINIMAL=y6. Build the exercise and flash it to the board.
Notice that the output of the logger module is significantly different when the minimal mode is activated.
Log levels are now indicated by letters (D=Debug, I=Info, W=Warning, E=Error) and timestamps and prefixed module names are not displayed.
The solution for this exercise can be found in the GitHub repository, l4/l4_e3_sol of whichever version directory you are using.
