79e6b0e0f6
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> |
||
|---|---|---|
| .. | ||
| boards | ||
| dts | ||
| src | ||
| CMakeLists.txt | ||
| prj.conf | ||
| README.txt | ||
| testcase.yaml | ||
Fixed Regulator
###############
This application tests the fixed regulator driver in multiple
configurations. Like the GPIO driver test it requires that two GPIO
pins be shorted so that changes made to the state of one can be verified
by inspecting the other.
Unlike the GPIO driver test the behavior of a fixed regulator depends
heavily on the properties specified in its devicetree node. The
``compatible`` property causes the underlying driver implementation to
select between one that supports asynchronous transitions and an
optimized one synchronous transitions. The initial state of the
regulator, whether it can be changed, and enforced transition delays are
all controlled by devicetree properties.
Because the regulator can only be configured at system startup it is
necessary to test varying configurations in separate test sessions. The
``testcase.yaml`` file provides a variety of flags intended to cover the
various behaviors.
Only boards for which an overlay is present can pass this test. Boards
without an overlay, or for which the required wiring is not provided,
will fail with an error like this:
Assertion failed at ../src/main.c:182: test_preconditions: (precheck not equal to PC_OK)
precheck failed: active check failed
No special build options are required to make use of the overlay.