UART and logging in automated BabbleSim tests, suggestions?

[Tom Weber]

Hello!

I am trying to set up automated tests for an application on the nRF54L15 BabbleSim target. The application needs two-way communication with a test script; this would be UART with another chip on real hardware. At the same time, logs from the application must be collected for debugging failed tests. What are my options here?

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.

Using stdin/stdout for UART is also problematic, because the logs are also printed to stdout and I haven't found a way to log to a file instead.

Using TCP in place of UART doesn't work either:  Offloaded sockets driver on Babblesim nRF54L15 

TCP over zeth is not an option because it requires root privileges to set up.

Are there any other ways of communicating with a script on the host OS?

[Alberto Escolar]

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.

[Tom Weber]

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. 

[Alberto Escolar]

> 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 

[Tom Weber]

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.