Lines Matching +full:high +full:- +full:dynamic +full:- +full:output

9    https://www.figma.com/community/file/1292866458780627559/zbus-diagram-assets
12 The :dfn:`Zephyr bus - zbus` is a lightweight and flexible software bus enabling a simple way for
13 threads to talk to one another in a many-to-many way.
21 Threads can send messages to one or more observers using zbus. It makes the many-to-many
22 communication possible. The bus implements message-passing and publish/subscribe communication
25 The communication through zbus is channel-based. Threads (or callbacks) use channels to exchange
72 * Subscriber, a thread-based observer that relies internally on a message queue where the event
76 * Message subscribers, a thread-based observer that relies internally on a FIFO where the event
100 Suppose a usual sensor-based solution is in the figure below for illustration purposes. When
114 :alt: ZBus sensor-based application
117 ZBus sensor-based application.
128 well-defined behaviors (we call that module) only uses zbus channels and not hardware interfaces, it
134 be dynamic or static allocated; notifications can be synchronous or asynchronous; the developer can
136 metadata information to a channel by using the user-data field, the discretionary use of a validator
138 the solutions that can be done with zbus and make it a good fit as an open-source community tool.
155 the same sequence they appear on the channel observers' list. The listeners can perform non-copy
175 .. code-block:: c
187 In the figure below, the letters indicate some action related to the VDED execution. The X-axis
188 represents the time, and the Y-axis represents the priority of threads. Channel A's message,
207 .. list-table:: VDED execution steps in detail for priority T1 > MS1 > MS2 > S1.
209 :header-rows: 1
211 * - Actions
212 - Description
213 * - a
214 - T1 starts and, at some point, publishes to channel A.
215 * - b
216 - The publishing (VDED) process starts. The VDED locks the channel A.
217 * - c
218 - The VDED copies the T1 message to the channel A message.
220 * - d, e
221 - The VDED executes L1 and L2 in the respective sequence. Inside the listeners, usually, there
225 * - f, g
226 - The VDED copies the message and sends that to MS1 and MS2 sequentially. Notice the threads
229 * - h
230 - The VDED pushes the notification message to the queue of S1. Notice the thread gets ready to
234 * - i
235 - VDED finishes the publishing by unlocking channel A. The MS1 leaves the pending state and
238 * - j
239 - MS1 finishes execution. The MS2 leaves the pending state and starts executing.
241 * - k
242 - MS2 finishes execution. The S1 leaves the pending state and starts executing.
244 * - l, m, n
245 - The S1 leaves the pending state since channel A is not locked. It gets in the CPU again and
249 * - o
250 - S1 finishes its workload.
264 .. list-table:: VDED execution steps in detail for priority T1 < MS1 < MS2 < S1.
266 :header-rows: 1
268 * - Actions
269 - Description
270 * - a
271 - T1 starts and, at some point, publishes to channel A.
272 * - b
273 - The publishing (VDED) process starts. The VDED locks the channel A.
274 * - c
275 - The VDED copies the T1 message to the channel A message.
277 * - d, e
278 - The VDED executes L1 and L2 in the respective sequence. Inside the listeners, usually, there
282 * - f
283 - The VDED copies the message and sends that to MS1. MS1 preempts T1 and starts working.
286 * - g
287 - The VDED copies the message and sends that to MS2. MS2 preempts T1 and starts working.
290 * - h
291 - The VDED pushes the notification message to the queue of S1.
293 * - i
294 - VDED finishes the publishing by unlocking channel A.
296 * - j, k, l
297 - The S1 leaves the pending state since channel A is not locked. It gets in the CPU again and
303 ------------------
329 consider the observer's priority. The following code illustrates the thread-attaching function.
332 .. code-block:: c
333 :emphasize-lines: 10
369 * The HLP priority is dynamic and can change in execution;
373 * The Highest Locker Protocol's major disadvantage, the Inheritance-related Priority Inversion, is
383 high-speed stream of bytes between threads. The :ref:`Pipe <pipes_v2>` kernel object solves this
387 -------------------
394 * Keep the listeners quick-as-possible (deal with them as ISRs). If some processing is needed,
395 consider submitting a work item to a work-queue;
396 * Try to give producers a high priority to avoid losses;
408 at the :zephyr:code-sample:`zbus-msg-subscriber` to see the isolation in action.
420 -------------------------
445 .. code-block:: c
468 LOG_DBG("From listener -> Acc x=%d, y=%d, z=%d", acc->x, acc->y, acc->z);
489 LOG_DBG("From subscriber -> Acc x=%d, y=%d, z=%d", acc.x, acc.y, acc.z);
507 … LOG_INF("From msg subscriber -> Acc x=%d, y=%d, z=%d", acc.x, acc.y, acc.z);
516 that a post-definition static observer. The command enables us to indicate an initialization
518 the post-definition static observers. There is no possibility to overwrite the message delivery
531 may want to piggy-back on their channels. The following code defines and initializes a :dfn:`hard
534 only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other
537 .. code-block:: c
545 bool is_valid = (cm->move == -1) || (cm->move == 0) || (cm->move == 1);
574 .. code-block:: c
591 .. code-block:: c
615 .. code-block:: c
633 .. code-block:: c
651 .. code-block:: c
657 LOG_INF("%d - Channel %s:", *count, zbus_chan_name(chan));
665 for (int16_t i = *chan->observers_start_idx, limit = *chan->observers_end_idx; i < limit;
669 LOG_INF(" - %s", observation->obs->name);
674 SYS_SLIST_FOR_EACH_CONTAINER_SAFE(chan->observers, obs_nd, tmp, node) {
675 LOG_INF(" - %s", obs_nd->obs->name);
685 LOG_INF("%d - %s %s", *count, obs->queue ? "Subscriber" : "Listener", zbus_obs_name(obs));
710 The code will log the following output:
712 .. code-block:: console
715 D: 0 - Channel acc_chan:
718 D: - my_listener
719 D: - my_subscriber
720 D: 1 - Channel version_chan:
724 D: 0 - Listener my_listener
725 D: 1 - Subscriber my_subscriber
737 ------------------------
745 .. code-block:: c
755 LOG_DBG("From listener -> Acc x=%d, y=%d, z=%d", acc->x, acc->y, acc->z);
760 ---------
764 individual for each channel. Also, note that ``user_data`` access is not thread-safe. For
765 thread-safe access to ``user_data``, see the next section.
769 --------------------------
788 .. code-block:: c
798 .. code-block:: c
811 .. code-block:: c
821 -----------------------------
824 nodes dynamically. The heap size limits the number of dynamic observers zbus can create. Therefore,
831 .. code-block:: c
849 * :zephyr:code-sample:`zbus-hello-world` illustrates the code used above in action;
850 * :zephyr:code-sample:`zbus-work-queue` shows how to define and use different kinds of observers.
853 * :zephyr:code-sample:`zbus-msg-subscriber` illustrates how to use message subscribers;
854 * :zephyr:code-sample:`zbus-dyn-channel` demonstrates how to use dynamically allocated exchanging
856 * :zephyr:code-sample:`zbus-uart-bridge` shows an example of sending the operation of the channel to
858 * :zephyr:code-sample:`zbus-remote-mock` illustrates how to implement an external mock (on the host)
860 * :zephyr:code-sample:`zbus-priority-boost` illustrates zbus priority boost feature with a priority
862 * :zephyr:code-sample:`zbus-runtime-obs-registration` illustrates a way of using the runtime
864 * :zephyr:code-sample:`zbus-confirmed-channel` implements a way of implement confirmed channel only
866 * :zephyr:code-sample:`zbus-benchmark` implements a benchmark with different combinations of inputs.
871 Use zbus to transfer data (messages) between threads in one-to-one, one-to-many, and many-to-many