Upgrade to accel_polling sample application to support
RTIO streaming functionality. This mode is enabled when
CONFIG_SENSOR_ASYNC_API is defined. NUM_SENSORS must be
set to the correct number of sensors used.
Signed-off-by: Vladislav Pejic <vladislav.pejic@orioninc.com>
The accel_polling sample uses various sensor, but doesn't set a sampling
rate. But some sensors (like st,lsm6dso) have a default sampling
frequency of 0. So, depending on the sensor, the sample may not always
work.
There are two ways to fix this: either all drivers must set a valid
sampling rate, or the sample shall at least try to set a value if there
is none.
We propose here the second approach, wich should allow the sample to
work on more sensors out of the box.
Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.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>
It is frequent to find variable definitions like this:
```c
static const struct device *dev = DEVICE_DT_GET(...)
```
That is, module level variables that are statically initialized with a
device reference. Such value is, in most cases, never changed meaning
the variable can also be declared as const (immutable). This patch
constifies all such cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a polling sample for 3-Axis accelerometers.
This sample demonstrates how to data fetch and print to the console.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
