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>
Schedules I/O chains in the same order as they arrive providing a fixed
amount of concurrency. The low memory cost comes at the cost of some
computational cost that is likely to be acceptable with small amounts
of concurrency.
The code cost is about 4x higher than the simple linear executor
which isn't entirely unexpected as the logic requirements are quite a bit
more than doing the next thing in the queue.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
A DMA friendly Stream API for zephyr. Based on ideas from io_uring
and iio, a queue based API for I/O operations.
Provides a pair of fixed length ringbuffer backed queues for submitting
I/O requests and recieving I/O completions. The requests may be chained
together to ensure the next operation does not start until the current
one is complete.
Requests target an abstract rtio_iodev which is expected to wrap all
the hardware particulars of how to perform the operation. For example
with a SPI bus device, a description of what a read, and write mean
can be decided by the iodev wrapping a particular device
hanging off of a SPI controller.
The queue pair are submitted to an executor which may be a simple
inplace looping executor done in the callers execution context
(thread/stack) but other executors are expected. A threadpool executor
might for example allow for concurrent request chains to execute in
parallel. A DMA executor, in conjunction with DMA aware iodevs
would allow for hardware offloading of operations going so far as to
schedule with priority using hardware arbitration.
Both the iodev and executor are definable by a particular
SoC, meaning they can work in conjuction to perform IO operations
using a particular DMA controller or methodology if desired.
The application decides entirely how large the queues are, where
the buffers to read/write come from (some executors
may have particular demands!), and which executor to submit
requests to.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Add additional user tracing calls for thread states, names
and priorities.
add the following user tracing calls:
sys_trace_thread_create_user
sys_trace_thread_abort_user
sys_trace_thread_suspend_user
sys_trace_thread_resume_user
sys_trace_thread_name_set_user
sys_trace_thread_info_user
sys_trace_thread_priority_set_user
sys_trace_thread_sched_ready_user
sys_trace_thread_pend_user
Signed-off-by: Eugene Cohen <quic_egmc@quicinc.com>
Starting with Zephyr 2.1, the back-end must filter out all old entities
and call the callback with only the newest entity.
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
This commit rewrite renesas R-Car clock driver in order
to be able to support any new SoC easier.
This work is so creating a clock driver per soc alongside a
common driver for all reneasas r-car boars.
- drivers: create a driver per soc
- create a common driver
- create a common header used by soc & common driver
- create a soc specific driver calling for common driver
- dts: use new compatible
- use old yaml as common yaml
- create a new "child" yaml to define the new compatible field
- change compatible in device tree
As in Linux, the driver can support both r8a77951 and r8a77950
SoC's so we decided to name the new driver as in Linux with Zephyr
prefix : "clock_control_r8a7795_cpg_mssr.c".
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
This commit is reworking clock definition in
order to match linux filetree and definition
as much as possible.
- dt-bindings: rework renesas clocks dt-bindings
- regroup renesas related dt-bindings in a folder
- rename renesas rcar common dt-binding to match linux name
- add soc specific dt-binding matching linux name
- soc dt-bindings are defining clocks matching linux names
- dts: use new clocks names
- move clocks definitions in SoC layer for each core clock entry
- driver: use new clocks names
As seen in this commit, we are declaring clocks for "R8A7795" SoC
to match linux names.
Linux is not declaring "R8A77951" SoC specific files because
its also supporting the first H3 SoC version numbered "R8A77950".
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
In the function tx_work_handler, a pointer to ring buffer data is given
to usb_transfer then the ring_buf_get_finish is called. So, the data is
mark as read (by ring_buf_get_finish) while the data are not yet
transferred to usb. If later a user send data, the pointer hold by usb
stack could be rewrite.
Signed-off-by: Julien D'Ascenzio <julien.dascenzio@paratronic.fr>
Replace 'platform_allow' with 'filter' based on ws2812 compatible
being enabled. This will allow, for example, to run the sample on
mimxrt1050_evk and mimxrt1050_evk_qspi boards.
Signed-off-by: Jeppe Odgaard <jeppe.odgaard@prevas.dk>
Driver was in a weird state: it made use of
DT_INST_FOREACH_STATUS_OKAY, however, it had an assertion to support a
single instance and used instance 0 properties.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move the sentence to the end of the section on labels applicable to
PRs only, reword it and convert to a note, indicating that the note
is for all labels in this section.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Use full label names for examples in the description, and other minor
enhancements.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Split the explanation on dev-review and TSC labels into two separate ones,
and slightly reword both. For both, amend corresponding link to point to
the more relevant place in the online page on Zephyr meetings. Add
explanation for acronym "TSC".
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Directory <Zephyr-root>/ext does not exist anymore. Remove the
reference to it from the documentation.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Label "Stale" is used for both issues and pull requests. It is currenly
listed as applicaple to pull requests only, however. Move it to the
right place.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Some label names in the documentation do not match with what is
seen in Github interface. Fix it by syncing with Github.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Mostly due to limited support for tables in rst format, information on
labels used for Zephyr issues and pull requests in Github is hard to
navigate and is visually not pleasing. Rearange the content of the
section so that bullets are mainly utilized rather than tables. Format
label names as 'emphasis', rather that 'monospace' (which should be
used primarily for code snippets, and Github labels are not code).
Also, group the information according to applicability (taking into
account if a label is applicable to:
* issues only;
* pull requests only;
* both issues and pull requests.
Label names and decriptions are otherwise left 'as is' in this commit.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
There is a compiler bug in the current Zephyr SDK (GCC 10.3.0) that
prevents using LVGL on ARM Cortex M0/M0+. Disable LVGL on such CPU until
the next SDK is deployed (GCC 12.1), as the issues does not appear
anymore.
Ref. https://github.com/lvgl/lvgl/issues/3425
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
If we enable DISPLAY=y, ILI9341 will be selected automatically if all of
its dependencies are met as well (SPI), let's add this to the board
defconfig.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
LVGL eats a considerable amount of flash, so tests may fail on platforms
that meet all requirements but that have a low amount of flash, e.g.
nucleo_g071rb. Set min_flash for all cases to 250K (result of some quick
experimentation). Also update minimum ram to exclude platforms that
cannot run Zephyr + LVGL (e.g. those with just 16K).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
'display' harness doesn't exist, so replace it with 'none' to make
things more clear. It is required so that test is not run e.g. on CI,
test would timeout because the GUI is left ON forever.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify sample.yaml by just adding a single test case. In future
commits, test case will be refined to be based on DT filters so that it
is made more generic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The PAN1780 evaluation board is a development tool for the nRF52840
from Nordic Semiconductor.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
The PAN1781 evaluation board is a development tool for the nRF52820
from Nordic Semiconductor.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
The PAN1782 evaluation board is a development tool for the nRF52833
from Nordic Semiconductor.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
The PAN1770 evaluation board is a development tool for the nRF52840
from Nordic Semiconductor.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
The test_adc.c still have hardcoded information on a board basis,
that need to be added manually.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
Some of the Panasonic's evaluation boards have limited amount of pins.
So not all arduino pins can be occupied and not all shields are
compatible.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
Panasonic's reduced Arduino header is based on the Arduino UNO layout.
The main difference is that some pins are not available due to the
lack of pins on the Panasonic module.
Signed-off-by: Steffen Jahnke <steffen.jahnke@eu.panasonic.com>
Move driver to use gpio_dt_spec for GPIO interrupt handling.
Added check to vcnl4040_trigger_set to handle case of trigger
mode enabled but the devicetree doesn't have an int_gpios property.
Also, moved up the checking/handling of gpio port device in
vcnl4040_trigger_init so that if we error out its before we
setup any threads and such.
Signed-off-by: Kumar Gala <galak@kernel.org>
Move to use DEVICE_DT_GET_ONE instead of device_get_binding as we
work on phasing out use of DTS 'label' property.
Signed-off-by: Kumar Gala <galak@kernel.org>
Fix duplicate ID for systemview. Remove k_timer_user_data_set as it is
not being tracing and uses a duplicate ID like k_sem_reset.
Fixes#46541
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix wrong control register address used in uart_altera_jtag_init
function which caused memory corruption.
Signed-off-by: Khor Swee Aun <swee.aun.khor@intel.com>
By default ARCH_IRQ_VECTOR_TABLE_ALIGN and ARCH_SW_ISR_TABLE_ALIGN are
set to 0. Use a more proper value.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This test is based on the wrong assumption that the IRQ vector table
symbols are always placed by the linker script also when
CONFIG_GEN_IRQ_VECTOR_TABLE is not actually set.
This is of course broken with the reworked mechanism of the IRQ vector
table placement.
Fix the test by reintroducing the old behaviour by forcefully
reinstating the symbols in the linker script.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
