This fixes the documentation instructions for building the SMP Pi
sample program, which incorrectly listed an underscore instead of
a path separator slash.
Signed-off-by: Steve Winslow <steve@swinslow.net>
This provides a better error message when building with CMake and
forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package
registry. See parent commit for more details (split from parent for
better readability).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This was silently corrupting memory on x86-64.
Enable CONFIG_TEST so that this is detected properly,
and increase the stack size appropriately.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The seasonal overhaul of test identifiers aligning the terms being used
and creating a structure. This is hopefully the last time we do this,
plan is to document the identifiers and enforce syntax.
The end-goal is to be able to generate a testsuite description from the
existing tests and sync it frequently with the testsuite in Testrail.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Mark the old time conversion APIs deprecated, leave compatibility
macros in place, and replace all usage with the new API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This sample showcases efficient utilization of SMP system
with processing of independent resource-hungry workloads.
With no cross-dependencies between workers and no usage of shared
resources (during heavy-lifting itself) we may demonstrate almost
linear scaling of efficiency. I.e. 2 cores do the same amount of
calculations twice faster than only 1 core. 4 cores complete
the same calculations 2 times faster than 2 cores.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Steve Winslow