Fixes: #73831
find_package(Zephyr) should be called before first project() call.
Zephyr package will test and force-set the correct toolchain, especially
the C compiler.
The project() will also set the C compiler, if not set already.
If project() is called first, then conflict arises on the C compiler
selection and thus the following message is seen:
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_C_COMPILER= /usr/bin/gcc
This cache deletion results in other errors, such as a missing BOARD
setting.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fix the deprecated calls to loading ZephyrUnittest by replacing them
with `Zephyr COMPONENTS unittest`.
Signed-off-by: Yuval Peress <peress@google.com>
It's not uncommon to have Zephyr running in environments where it
shares a memory bus with a foreign/non-Zephyr system (both the older
Intel Quark and cAVS audio DSP systems share this property). In those
circumstances, it would be nice to have a utility that allows an
arbitrary-sized chunk of that memory to be used as a unidirectional
buffered byte stream without requiring complicated driver support.
sys_winstream is one such abstraction.
This code is lockless, it makes no synchronization demands of the OS
or hardware beyond memory ordering[1]. It implements a simple
file/socket-style read/write API. It produces small code and is high
performance (e.g. a read or write on Xtensa is about 60 cycles plus
one per byte copied). It's bidirectional, with no internal Zephyr
dependencies (allowing it to be easily ported to the foreign system).
And it's quite a bit simpler (especially for the reader) than the
older cAVS trace protocol it's designed to replace.
[1] Which means that right now it won't work reliably on arm64 until
we add a memory barrier framework to Zephyr! See notes in the code;
the locations for the barriers are present, but there's no utility to
call.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
