Add a new set of helpers for expanding property entries with a
separator. These macros complement DT(_INST)FOREACH_PROP_ELEM(_VARGS) by
adding the capability to expand with a custom separator between property
entries. This allows, in some cases, to re-use existing macros (e.g.
DT_PROP_BY_IDX) without creating an auxiliary macro that just appends a
separator. Example:
```dts
n: node {
...
my-gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>,
<&gpiob 1 GPIO_ACTIVE_HIGH>;
};
```
Before:
```c
#define GPIO_DT_SPEC_BY_IDX_AND_COMMA(node_id, prop, idx) \
GPIO_DT_SPEC_BY_IDX(node_id, prop, idx),
struct gpio_dt_spec specs[] = {
DT_FOREACH_PROP_ELEM(DT_NODELABEL(n), my_gpios,
GPIO_DT_SPEC_BY_IDX_AND_COMMA)
};
```
After:
```c
struct gpio_dt_spec specs[] = {
DT_FOREACH_PROP_ELEM_SEP(DT_NODELABEL(n), my_gpios,
GPIO_DT_SPEC_BY_IDX, (,))
};
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This was copied from the ARM version of the test's linker script, which
in turn seems to have been copied from another linker script at some
point. Remove the incorrect comment.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
It's useful for the default RAM region to have a uniform name across
architectures so higher-level build processes do not need to have their
own awareness of the names. Since NIOS2 uniformly uses 'SRAM', change it
to 'RAM' to match most other architectures.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
As with 32-bit ARM, it is useful to make the RAMABLE_REGION name uniform
across architectures so the build system does not need to be aware of
the differences when CODE_DATA_RELOCATION is supported. Generalize the
name to just 'RAM' for uniformity.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
It's useful for RAMABLE_REGION to have a uniform name when
CODE_DATA_RELOCATION is supported, because otherwise the build system
needs to be aware of how the region name differs between architectures.
Since architectures tend to prefer one of 'SRAM' or 'RAM' for that
region, prefer to use 'RAM' as the more general term.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
This can be used in DTOs
The boosterpack_connector.dtsi is an attempt to add something similar
to the arduino_r3_connectors that make using DT overlays with these
boards far easier and cleaner.
This can probably also be expanded to other CC32x TI launchpads
having similar layouts.
Referred swru465, ie. cc3220 TRM Table 5-14 and compared with launchpad
pinout. The numbering is done from 0...40 as per in the boosterpack pinout.
The pins like VCC/ GND have been skipped from the numbering. Also
the non-default pins are skipped.
Also add gpio status ok: This ensures that all the gpios are
enabled by default
Signed-off-by: Dhruva Gole <goledhruva@gmail.com>
This function allows the application to close an ipc_service instance.
It is intended for use when the remote agent it is communicating with
has gone down and allows for cleanup.
It first checks that the endpoints have been separately deregistered
with the instance using the deregister_endpoint function before
calling into previously added functions in ipc_static_vrings.c
and ipc_rpmsg.c to close those instances.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
This function deinitialises the static vrings used by the ipc_service
instance. It acheieves this by tearing down the initialised
virtqueues before closing the various aspects of libmetal which
are in use.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
This function does the opposite of the ipc_rpmsg_init function and
allows the rpmsg instance to be torndown in the case that the application
wishes to do so. It is intended to be used by the ipc_service subsystem.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
Some tests assume that if IUT accepted HCI_LE_Set_Data_Length command
than HCI_LE_Data_Length_Change event will always be sent. This is not
the case anymore as HCI_LE_Data_Length_Change is sent only if effective
parameters changed.
Those tests should be re-enabled when EDDT implementation is updated.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
LE Write Suggested Default Data Length and LE Set Data Length commands
are suggestions from host and should be validated only as per HCI
specification regarding internal setting of LLCP.
LLCP is allowed to use other values if needed.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
to the ESP32 S2 Franzininho educational development
board.
Signed-off-by: Felipe Neves <felipe.neves@linaro.org>
boards: xtensa: esp32s2_franzininho: remove docs
section for debugging since this board does not have
any on board debug or connection for that.
Signed-off-by: Felipe Neves <felipe.neves@linaro.org>
I am not using Silicon Labs platform for a while now and will not be for
the foreseeable future.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
I am not using Silicon Labs platform for a while now and will not be for
the foreseeable future.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
Some systems may need to query the available memory regions in runtime.
For those, this patch adds a simple API that memory management drivers
can implement to provide such discovery.
A small test also added to exercise the default, empty implementation.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
ESP32 Ethernet support required hal_espressif modifications:
Espressif Ethernet MAC HAL and pinctrl definitions
Signed-off-by: Grant Ramsay <grant.ramsay@hotmail.com>
A sample project for ESP32 Ethernet testing.
Possibly this should be consolidated into existing networking samples
Signed-off-by: Grant Ramsay <grant.ramsay@hotmail.com>
Adds support for the esp32_ethernet_kit board.
esp32_ethernet_kit board is useful for testing ESP32 Ethernet
Signed-off-by: Grant Ramsay <grant.ramsay@hotmail.com>
Due to the diverse coding styles and lack of preprocessing when
scanning for test cases, there were many unintended combinations
of yaml test scenarios and C test functions with the regex-based
test case discovery, which caused an inaccurate test plan and test
result stats.
As the new ztest fx is used, the test cases of a test instance can
be accurately determined via zephyr.symbols file.
Because the zephyr.symbols file is not available until after build,
test cases determination is placed right after the build stage of
the pipeline and before the runtime test collection.
For those test instances that don't go through the build stage,
such as those with "Skip filtered" (statically filtered) reason
before entering the pipeline, they are not affected.
This patch also adjust the stats logic because the zephyr.symbols
file is generated after build. So ExecutionCounter update is split
and some must be postponed until test execution pipeline is completed.
Some concepts:
A test instance = a yaml scenario + a platform
"Test instance" and "test config" are synonyms in twister, unfortunately
excessive IMHO...
A test instance can be filtered or skipped in 3 ways.
Let's define "runtime" as "after entering the execution pipeline".
1) statically filtered (before runtime)
Such test instance is filtered by analyzing the yaml and never
enters the execution pipeline.
2) cmake filtered (runtime)
Such test instance enters pipeline and is filtered at cmake stage.
3) build skipped (also runtime)
Such test instance enters pipeline and is skipped at build stage.
All the test instances that enter the execution pipeline will go
through the report stage, where ExecutionCounter is further updated.
The meaning of the fields of ExecutionCounter are:
.skipped_configs = static filtered + cmake filtered + build skipped
.skipped_runtime = cmake filtered + build skipped
.skipped_filter = static filtered
.done = instances that enter the execution pipeline
.passed = instances that actually executed and passed
Definition of the overall stats:
total_complete = .done + .skipped_filter
total = yaml test scenario * applicable platforms
complete percentage = total_complete / total
pass rate = passed / (total - skipped_configs)
Signed-off-by: Ming Shao <ming.shao@intel.com>