Commit Graph

9 Commits

Author SHA1 Message Date
Tom Burdick f9d16072e8 rtio: Add macro to define iodev submission queue
The iodev submission queue existed but wasn't easily constructed as
there was no macro to define it.

Adds a simple macro wrapper around RTIO_SPSC_DEFINE for creating
the RTIO IO Device Submission Queue enabling each IO device to
have its own pending queue of requests.

The sample has been updated to use the iodev submission queue rather
than a k_msgq.

Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
2022-10-05 12:42:16 +02:00
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
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>
2022-09-05 16:31:47 +02:00
Gerard Marull-Paretas a202341958 devices: constify device pointers initialized at compile time
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).

Automated using:

```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-08-22 17:08:26 +02:00
Manuel Arguelles 7f26c1c25c tests: samples: revert timeout change for FVP BaseR
Partially revert commit 0028e97332.
Timeout for tests/posix/common must be still increased for slow
platforms (previously was 120 sec).

Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
2022-08-16 15:51:38 +02:00
Benjamin Björnsson c8ba22f561 samples: sensor_batch_processing: Update sample to remove DT_INST
Update sample to use DT_COMPAT_GET_ANY_STATUS_OKAY in order to remove
DT_INST.

Signed-off-by: Benjamin Björnsson <benjamin.bjornsson@gmail.com>
2022-07-21 14:01:55 +00:00
Kumar Gala 28143b1cdc samples: subsys: Remove label property from devicetree overlays
"label" properties are not required.  Remove them from samples.

Signed-off-by: Kumar Gala <galak@kernel.org>
2022-07-19 10:30:20 +02:00
Tomislav Milkovic 0fe2c1fe90 everywhere: Fix legacy include paths
Any project with Kconfig option CONFIG_LEGACY_INCLUDE_PATH set to n
couldn't be built because some files were missing zephyr/ prefix in
includes
Re-run the migrate_includes.py script to fix all legacy include paths

Signed-off-by: Tomislav Milkovic <milkovic@byte-lab.com>
2022-07-18 16:16:47 +00:00
Manuel Arguelles f2ae4b67b2 tests: samples: bump timeout for FVP BaseR board
Timeout must be increased for fvp_baser_aemv8r_aarch32 board. Enabling
MPU on this board makes simulation slower.

Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
2022-07-11 11:17:02 +02:00
Maureen Helm fd204f31d4 samples: rtio: Add sensor batch processing sample application
Adds a new sample application that demonstrates using the RTIO subsystem
to read periodic sensor data directly into buffers allocated by the
application, asynchronously process batches of data with an algorithm,
and recycle buffers back for reading additional sensor data.

The sensor iodev in this application is an timer-driven device that
executes one read request per timer period. It doesn't actually send any
transactions to a real I2C/SPI bus or read any real data into the
application-provided buffers. This timer-driven behavior mimics how a
real sensor periodically triggers a GPIO interrupt when new data is
ready.

The sensor iodev currently uses an internal message queue to store
pending requests from the time they are submitted until the next timer
expiration. At least one pending request needs to be stored by the iodev
to ensure that it has a buffer available to read data into. However,
any more than that should probably be handled by the application, since
it's the application that determines how often it can submit new
requests and therefore how deep the queue needs to be.

The sensor iodev is implemented to support multiple instances with
devicetree, but additional work remains to enable and use more than one
in the application.

Tested on native_posix and frdm_k64f.

Signed-off-by: Maureen Helm <maureen.helm@intel.com>
2022-06-28 13:53:13 -04:00