This migrates the subsys code samples to the new Sphinx code-sample
extension, making it easier to find relevant samples when browsing
API reference.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
- Add integration_platforms to avoid excessive filtering
- Make sure integration platforms are actually part of the filter
- Fix some tags and test meta data
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.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>
integration platforms should not be in common section if we have
scenarios with different set of integration platforms.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In order to bring consistency in-tree, migrate all samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Compilers often combine strings to conserve space, if one string is
a perfect substring of another one towards the end. So add another
string in the test to make sure dictionary logging is still working
correctly under this scenario.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This enables CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY so that
the UART backend is in dictionary logging mode.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Reduced logging mode selection to deferred, immediate, minimal and
frontend. Decoupled logging version from mode and created CONFIG_LOG1
which can be used to explicitly select deprecated version.
From now on, chosing CONFIG_LOG_MODE_{IMMEDIATE,DEFERRED} will result
in version2.
Deprecated CONFIG_LOG2_MODE_{IMMEDIATE,DEFERRED} with cmake warning.
Codebase adapted to those changes.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The cbprintf packaging needs CONFIG_CBPRINTF_PACKAGE_LONGDOUBLE
to be enabled to work with long double. So #ifdef that inside
CONFIG_FPU.
Also add to the sample.yaml to enable testing with FPU and
long doubles.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a sample application on dictionary-based logging.
The README file includes instruction on how to run the log parser
to generate human readable log messages.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
