Currently, zbus uses a single global `net_buf`pool to publish messages to
msg_subscribers. It would be good to have a way to separate the pools for
channels related to critical parts of the systems to avoid publication
failure on these particular channels. These channels will not use the
global pool. They can set an isolated pool by calling the
`zbus_chan_set_msg_sub_pool.`
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Replace mutexes with semaphores to protect the channels in conjunction with
a priority boost algorithm based on the observers' priority.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
After some further investigation, I could find the current solution to
enable zbus channels (by using ZBUS_CHAN_DECLARE) to be used in C++
files, which generates a warning when we mix C and C++ code. This fixes
the issue by using an approach to add the extern keyword only when the
file is being compiled with a C++ compiler.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
The current implementation of ZBUS_CHAN_DECLARE is not compatible with
C++. It fixes the bug by adding the extern keyword at the channel
definition which will work for both C and C++.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
_zbus_timeout_remainder was removed in a7b3584 however 7e44469
re-introduced it in the header.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Besides the changed channel reference, the message subscribers receive a
copy of the message during the VDED execution. ZBus guarantees message
delivery for `MSG_SUBSCRIBERS`.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
The macro is clearly creating the listener in the enabled
state since it is calling the ZBUS_LISTENER_DEFINE_WITH_ENABLE
with 2nd argument being true. Fix the documentation, and add
the same remark to ZBUS_SUBSCRIBER_DEFINE documentation as
well.
Signed-off-by: Miika Karanki <miika.karanki@vaisala.com>
ZBus stores observers in two ways: statically using a list and dynamically
using a memory slab. Both present limitations. Static observers work only
for channel definition. The dynamic observers rely on a memory slab that
forces the user to manage its size to avoid issues with adding
observers. This commit fixes the static allocation problem by using the
iterable sections for allocating observation data and replacing the VDED
execution sequence since now it is possible to prioritize static observer
execution. All the runtime observers are dynamically allocated on the heap
instead of a specific memory pool.
BREAK changes (only internal, not APIs):
* ZBus channel metadata changed. Remove the observers' static array
pointer. Rename the `runtime_observers` pointer to `observers`. Add
`observer_start_idx` and `observer_end_idx`;
* Change the VDED execution sequence. The position (on definition time),
the priority in conjunction with the lexical order, is considered for
static post-definition time observers. At last, the runtime observer
follows the adding sequence;
* Replace the `CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE` with
`CONFIG_ZBUS_RUNTIME_OBSERVERS`.
New APIs:
* New iterable section iterators (for channels and observers) can now
receive a user_data pointer to keep context between the function calls;
* New `ZBUS_LISTENER_DEFINE_WITH_ENABLE(_name, _cb, _enable)` and
`ZBUS_SUBSCRIBER_DEFINE_WITH_ENABLE(_name, _queue_size, enable)` that
enable developers define disabled observers. They need to be enabled
during runtime to receive notifications from the bus;
* `ZBUS_CHAN_ADD_OBS` macro for adding post-definition static observers of
a channel.
Important changes:
* Move the ZBus LD file content to the `common-ram.ld` LD file. That was
necessary to make ZBus compatible with some Xtensa and RISCV boards.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add zbus message bus as a Zephyr subsystem. No message bus
or communication abstraction other than the usual (message queues,
mailboxes, etc.) enabled developers to implement event-driven systems in
Zephyr quickly. Zbus would fill that gap by providing the community with
a lightweight and flexible message bus. The implementation tries to be
closest as possible to the existing ones. We use the claim/finish
approach, and the API for publishing and reading channels are similar
in message queues. Zbus is about channels, messages, and observers.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
