See Discussion https://github.com/zephyrproject-rtos/zephyr/discussions/83659
for information about the purpose of this change.
Modifies run actions of hierarchical state machines
to return a value indicating if the event was handled
by the run action or should be propagated up to the
parent run action. Flat state machines are not affected,
and their run action returns void.
smf_set_handled() has been removed and replaced by
this return value. smf_set_state() will not propagate
events regardless of the return value as the transition
is considered to have occurred.
Documentation, tests, samples, has been updated.
USB-C and hawkBit use SMF and have been updated to use
the new return codes.
Signed-off-by: Glenn Andrews <glenn.andrews.42@gmail.com>
Modify the SMF such that state transitions from parent states choose the
correct Least Common Ancestor based on the transition source rather than
the current state.
SMF set as experimental.
Signed-off-by: Glenn Andrews <glenn.andrews.42@gmail.com>
This sets the number of arguments for SMF_CREATE_STATE() to always
be the same, independent of the selected Kconfig options.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Brings SMF framework closer into alignment with accepted Hierarchical State
Machine operation by:
1. Allowing 'programming by difference' by having some child states handle
events and prevent propagation up to the parent run actions while others
propagate events up to a common handler in a parent state.
2. Optionally allow initial transitions within a parent state to determine
the most nested child state to transition to.
3. Adding a test case for `CONFIG_SMF_INITIAL_TRANSITION` and
`smf_set_handled()`
4. Updating documentation for the new API (and fixing some references)
There was discussion in https://github.com/zephyrproject-rtos/zephyr/issues/55344
about not making the initial transition a Kconfig option, but I'm not sure
of any way else of doing it without permanently adding a pointer to each
`smf_state` entry, which is a problem for resource-constrained devices.
This does not fix https://github.com/zephyrproject-rtos/zephyr/issues/66341
but documentation has been updated to warn users of the issue.
Signed-off-by: Glenn Andrews <glenn.andrews.42@gmail.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
