UART and logging in automated BabbleSim tests, suggestions?

RE: UART and logging in automated BabbleSim tests, suggestions?

Tom Weber — Fri, 08 Aug 2025 10:18:44 GMT

Thank you. I have verified that Unix domain sockets work, with no changes to configuration or build files. This will be good enough for my use case.

RE: UART and logging in automated BabbleSim tests, suggestions?

Alberto Escolar — Wed, 06 Aug 2025 16:52:03 GMT

> I thought the application is linked with a minimal standard C library and not the host one.

In general there is a choice of libC
https://docs.zephyrproject.org/latest/boards/native/native_sim/doc/index.html#c-library-choice
If you build with CONFIG_EXTERNAL_LIBC you are building directly with the host libC
If you build with an embedded libC, you need to be a bit more careful to be able to call out into the Linux side. That is why most native_sim drivers are split in 2 parts, one built with the embedded side and another one build in the host side:
https://docs.zephyrproject.org/latest/boards/native/doc/arch_soc.html#native-simulator-runner-context-and-the-embedded-context

RE: UART and logging in automated BabbleSim tests, suggestions?

Tom Weber — Wed, 06 Aug 2025 15:12:32 GMT

Hello Alberto, thank you for your answer!

> In the meanwhile, if you want to connect to a python(?) script, maybe you want to avoid using intermediary components, and directly open a Linux pipe for which you open the other side in your python script?

I did not know that this is possible, I thought the application is linked with a minimal standard C library and not the host one. Will try to open a Unix socket and get back to you.

RE: UART and logging in automated BabbleSim tests, suggestions?

Alberto Escolar — Mon, 04 Aug 2025 10:03:54 GMT

Hi Tom, as this is a plain Zephyr question, it may be easier to discuss it in Zephyr's discord (https://chat.zephyrproject.org/ #babblesim channel), or as a GH discussion (https://github.com/zephyrproject-rtos/zephyr/discussions/new/choose).
You are welcome to ping me (aescolar) there.
In the meanwhile, if you want to connect to a python(?) script, maybe you want to avoid using intermediary components, and directly open a Linux pipe for which you open the other side in your python script?
(see for ex. how the EDTT driver works https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bsim/bluetooth/ll/edtt/common/edtt_driver_bsim.c , where the EDTT is a python tool https://github.com/EDTTool/EDTT . Note, I'm not telling you to use EDTT for this, this is just an example of a "funny driver" that connects to a python script).

> Using a PTY for UART is problematic because the PTY number gets assigned by the host OS and can not be explicitly specified, so it is unpredictable from an automation perspective.

Note you can ask the PTY driver to run any arbitrary command you want when the pty is created.

> because the logs are also printed to stdout and I haven't found a way to log to a file instead.

Correct. The Logger defaults to either use a backend that prints to stdout, or to one of the UARTs.