Lines Matching +full:count +full:- +full:width
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
38 :width: 75%
54 :width: 70%
66 :width: 70%
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
87 :width: 75%
100 Suppose a usual sensor-based solution is in the figure below for illustration purposes. When
114 :alt: ZBus sensor-based application
115 :width: 85%
117 ZBus sensor-based application.
128 well-defined behaviors (we call that module) only uses zbus channels and not hardware interfaces, it
132 The last important note is the zbus solution reach. We can count on many ways of using zbus to
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
168 :width: 45%
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,
195 :width: 85%
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.
258 :width: 85%
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 ------------------
323 :width: 85%
329 consider the observer's priority. The following code illustrates the thread-attaching function.
332 .. code-block:: c
333 :emphasize-lines: 10
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;
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
655 int *count = user_data;
657 LOG_INF("%d - Channel %s:", *count, zbus_chan_name(chan));
661 ++(*count);
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);
683 int *count = user_data;
685 LOG_INF("%d - %s %s", *count, obs->queue ? "Subscriber" : "Listener", zbus_obs_name(obs));
687 ++(*count);
694 int count = 0;
698 zbus_iterate_over_channels_with_user_data(print_channel_data_iterator, &count);
700 count = 0;
704 zbus_iterate_over_observers_with_user_data(print_observer_data_iterator, &count);
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 --------------------------
784 to the channel. Suppose we would like to count how many times the channels exchange messages. We
788 .. code-block:: c
798 .. code-block:: c
811 .. code-block:: c
821 -----------------------------
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