debade9121
... because it is (required).
This makes a difference when building with CMake and forgetting
ZEPHYR_BASE or not registering Zephyr in the CMake package registry.
In this particular case, REQUIRED turns this harmless looking log
statement:
-- Could NOT find Zephyr (missing: Zephyr_DIR)
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- ...
-- ...
-- ...
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:8 (target_sources):
Cannot specify sources for target "app" which is not built by
this project.
... into this louder, clearer, faster and (last but not least) final
error:
CMake Error at CMakeLists.txt:5 (find_package):
Could not find a package configuration file provided by "Zephyr" with
any of the following names:
ZephyrConfig.cmake
zephyr-config.cmake
Add the installation prefix of "Zephyr" to CMAKE_PREFIX_PATH or set
"Zephyr_DIR" to a directory containing one of the above files. If
"Zephyr" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| README.rst | ||
| prj.conf | ||
| testcase.yaml | ||
README.rst
Scheduler Microbenchmark
########################
This is a scheduler microbenchmark, designed to measure minimum
latencies (not scaling performance) of specific low level scheduling
primitives independent of overhead from application or API
abstractions. It works very simply: a main thread creates a "partner"
thread at a higher priority, the partner then sleeps using
_pend_curr_irqlock(). From this initial state:
1. The main thread calls _unpend_first_thread()
2. The main thread calls _ready_thread()
3. The main thread calls k_yield()
(the kernel switches to the partner thread)
4. The partner thread then runs and calls _pend_curr_irqlock() again
(the kernel switches to the main thread)
5. The main thread returns from k_yield()
It then iterates this many times, reporting timestamp latencies
between each numbered step and for the whole cycle, and a running
average for all cycles run.
Note that because this involves no timer interaction (except, on some
architectures, k_cycle_get_32()), it works correctly when run in QEMU
using the -icount argument, which can produce 100% deterministic
behavior (not cycle-exact hardware simulation, but exactly N
instructions per simulated nanosecond). You can enable this using an
environment variable (set at cmake time -- it's not enough to do this
for the subsequent make/ninja invocation, cmake needs to see the
variable itself):
export QEMU_EXTRA_FLAGS="-icount shift=0,align=off,sleep=off"