logging: log_backend_ble: add level prefix and improve flag settings

[dathpo]

Two changes:

1. Enable the logging level prefix as default. I think this adds a lot of value and allows for easy filtering of messages on the receiving device
2. For those flags that have an equivalent Kconfig option, match its value

@vChavezB I am tagging you because you worked on this module.

[github-actions]

Hello @dathpo, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[ubieda]

Two cents on this:
Could we instead use the BLE UART emulator? This emulator acts as an UART driver and enables BLE Logging through the UART backend.

BLE Logging backend was initially going to be deprecated when the emulator was introduced but there were some comments on the BT UART emulator being experimental and 'less simple' (see: #68076 (comment) and #69881 (comment)).

Given the emulator has been released for the LTS and I'm planning to keep maintaining it, perhaps we sould start the deprecation process for the Logging Backend?

CC: @bjarki-andreasen @jori-nordic @vChavezB

[bjarki-andreasen]

@ubieda just to validate, the uart emulator is NUS right?

[ubieda]

just to validate, the uart emulator is NUS right?

Correct

[dathpo]

Two cents on this:
Could we instead use the BLE UART emulator? This emulator acts as an UART driver and enables BLE Logging through the UART backend.

BLE Logging backend was initially going to be deprecated when the emulator was introduced but there were some comments on the BT UART emulator being experimental and 'less simple' (see: #68076 (comment) and #69881 (comment)).

Given the emulator has been released for the LTS and I'm planning to keep maintaining it, perhaps we sould start the deprecation process for the Logging Backend?

CC: @bjarki-andreasen @jori-nordic @vChavezB

I am not familiar with the BT UART emulator so I won't comment directly on it but what I like about the BLE logging backend is:

• It's simple and straightforward, doesn't require many more Kconfig options
• It inherits the logging configuration
• I can still keep my wired RTT console connection and see logs there as well if I want to. Would the UART emulator allow that or would it clash with the RTT console?
• Small flash memory footprint. How does that compare to the UART emulator?

[bjarki-andreasen]

Well, at the time, I also argued that the emulator was more complex, but, it is more flexible. The emulator does provide a more scalable solution compared to the dedicated ble logging backend. I think it makes most sense to make the shell/logging uart backends multi instance (if they arent already) and deprecate the ble log backend in favor of using ble uart emulator + uart backend

[dathpo]

Understood. I was looking for the BT UART emulator (through the UART_BT option) to try it out but it seems that it does not exist in the nRF Connect SDK v2.7.0, which is what I use.
I know that this conversation is now shifting to a Nordic Semiconductor domain but I would appreciate if anyone could explain how to achieve what I am looking for.

For now I am thinking of keeping the BLE logging backend enabled and apply local patches to it like this diff.

Otherwise, I think the PR can be closed.

[ubieda]

@dathpo Good news: UART_BT is on NCS 2.7.0 :)

Here's how you try it on Logging. Check out:

west build -b nrf52840dk/nrf52840 -S nus-console samples/subsys/logging/logger

[dathpo]

@dathpo Good news: UART_BT is on NCS 2.7.0 :)

Here's how you try it on Logging. Check out:

west build -b nrf52840dk/nrf52840 -S nus-console samples/subsys/logging/logger

Thanks @ubieda, I can see the sample. It turns out I was running the UART_BT search on an NCS clone that didn't have the modules setup, including the zephyr repository.

I will close the PR once I run the example if I don't have any related questions, if everyone is ok with that.

[dathpo]

@ubieda I tested the logging functionality with UART_BT on my device and it works well after applying a few tweaks. The points I had to tweak:

1. If I keep the MTU as with its current default value of 20, I enter an infinite loop of connecting and logs being streamed, but the conn.c:1528 warning Unable to allocate buffer within timeout is thrown before pairing and subscription, which triggers a disconnection. The same error occurs on the following attempts. I have tried increasing the TX buffers but it doesn't make a difference. I see that you are working on serial: bluetooth: Maximize notification payload size based on ATT MTU #77178 but I was wondering if there is anyway I can avoid this issue without increasing the default MTU value in uart_bt.c?
2. When compiling with the default CONFIG_UART_LOG_LEVEL, which seems to be INF, I get endless Ring buffer full, discard prints on the console, and which seem to also jam any BLE connection with my target due to the repeated sends. Setting the log level to WRN or setting that print to DBG allows me to continue smoothly. Perhaps the message should be at the DBG level? Unless I've misunderstood and there is a problem with my setup.
   

[ubieda]

1. If I keep the MTU as with its current default value of 20, I enter an infinite loop of connecting and logs being streamed, but the conn.c:1528 warning Unable to allocate buffer within timeout is thrown before pairing and subscription, which triggers a disconnection. The same error occurs on the following attempts. I have tried increasing the TX buffers but it doesn't make a difference. I see that you are working on serial: bluetooth: Maximize notification payload size based on ATT MTU #77178 but I was wondering if there is anyway I can avoid this issue without increasing the default MTU value in uart_bt.c?

Not sure about this one: can you capture an issue with repro steps? I'll take a look.

2. When compiling with the default CONFIG_UART_LOG_LEVEL, which seems to be INF, I get endless Ring buffer full, discard prints on the console, and which seem to also jam any BLE connection with my target due to the repeated sends. Setting the log level to WRN or setting that print to DBG allows me to continue. Perhaps the message should be at the DBG level? Unless I've misunderstood and there is a problem with my setup.

This seems like an oversight on my part: We can change this to be LOG_WRN_ONCE so it doesn't clutter the logs (see: #70282). Would you like to file a PR for this?

[dathpo]

1. Issue captured: Serial: Bluetooth: Unable to allocate buffer when sending over other Characteristic  #77435
2. PR opened: serial: bluetooth: Print warning once when ring buffer is full #77430

Thanks @ubieda, I will close this PR now.