zephyr/samples/subsys/zbus/remote_mock
Alberto Escolar Piedras cb53e40ff9 drivers uart_native_posix: rename to native_pty and support N instances
Rename the driver from uart_native_posix to uart_native_pty.
Including renaming the DTS compatible, and kconfig options, deprecating
the old ones.

And refactor the driver, generalizing it, so we can have any number of
instances.
Note that, unfortunately generalizing to N instances cannot be done
without a degree of backwards compatibility breakage: This driver was
born with all its configuration and selection of the instances based on
kconfig.
When the driver was made to use DT, it was done in a way that required
both DT and kconfig needing to manually coherently enable the 2nd UART.
This has now been fixed, which it means only DT is used to decide how
many instances are avaliable, and UART_NATIVE_POSIX_PORT_1_ENABLE is
just ignored.

Including:
* Deprecate UART_NATIVE_WAIT_PTS_READY_ENABLE: the options is always on
  now as it has no practical drawbacks.
* Deprecate UART_NATIVE_POSIX_PORT_1_ENABLE: DTS intanciation defines it
  being available now.
* Rename a few functions and in general shorten pseudo-tty/pseudo-
  terminal to PTY instead of PTTY.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
2025-03-11 18:54:02 +01:00
..
boards drivers uart_native_posix: rename to native_pty and support N instances 2025-03-11 18:54:02 +01:00
src
CMakeLists.txt
prj.conf
README.rst
remote_mock.py python: Format and sort imports 2024-11-25 10:07:13 +01:00
sample.yaml

.. zephyr:code-sample:: zbus-remote-mock
   :name: Remote mock sample
   :relevant-api: zbus_apis

   Publish to a zbus instance using UART as a bridge.

Overview
********

This application demonstrates how a host script can publish to the zbus in an embedded device using the UART as a bridge.
The device sends information to the script running on a computer host. Then, the script sends back information when it would simulate a publish to some channel. Finally, the script decodes the data exchanged and prints it to the stdout.

With this approach, developers can implement tests using any language on a computer to talk directly via channels with threads running on a device. Furthermore, it gives the tests more controllability and observability since we can control and access what is sent and received by the script.

Building and Running
********************

This project outputs to the console. It can be built and executed
on :ref:`native_sim <native_sim>` as follows:

.. zephyr-app-commands::
   :zephyr-app: samples/subsys/zbus/remote_mock
   :host-os: unix
   :board: native_sim
   :goals: run

Sample Output
=============

.. code-block:: console

    -- west build: running target run
    [0/1] cd /.../zephyr/build/zephyr/zephyr.exe
    uart_1 connected to pseudotty: /dev/pts/2
    uart connected to pseudotty: /dev/pts/3
    *** Booting Zephyr OS build zephyr-v3.1.0 ***
    D: [Mock Proxy] Started.
    D: [Mock Proxy RX] Started.
    D: [Mock Proxy RX] Found sentence
    D: Channel start_measurement claimed
    D: Channel start_measurement finished
    D: Publishing channel start_measurement
    D: START processing channel start_measurement change
    D: Channel start_measurement claimed
    D: discard loopback event (channel start_measurement)
    D: Channel start_measurement finished
    D: FINISH processing channel start_measurement change
    D: START processing channel sensor_data change
    D: Channel sensor_data claimed
    D: sending message to host (channel sensor_data)
    D: Channel sensor_data finished
    D: FINISH processing channel sensor_data change
    D: sending sensor data err = 0

    <repeats endlessly>

Exit execution by pressing :kbd:`CTRL+C`.

The :file:`remote_mock.py` script can be executed using the following command:

.. code-block:: bash

    python3.8 samples/subsys/zbus/remote_mock/remote_mock.py /dev/pts/2


Note the run command above prints the value of pts port because it is running in
:ref:`native_sim <native_sim>`.
Look at the line indicating ``uart_1 connected to pseudotty: /dev/pts/2``.
It can be different in your case. If you are using a board, read the documentation to get the
correct port destination (in Linux is something like ``/dev/tty...`` or in Windows ``COM...``).

From the remote mock (Python script), you would see something like this:

.. code-block:: shell

    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 1
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 2
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 3
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 4
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 5
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 6
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 7
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 8
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 9
    Proxy PUB [start_measurement] -> start measurement
    Proxy NOTIFY: [sensor_data] -> sensor value 10

    <continues>

Exit the remote mock script by pressing :kbd:`CTRL+C`.