The part that says "Always set CONFIG_BOARD here" is outdated. In HWMv2,
CONFIG_BOARD is set by the build system, and we don't want to encourage
users to set it manually.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
The introductory paragraph had a broken link and was arbitrarily
referencing a couple of files that will be described extensively later.
Instead, just present the content generically.
Fixes#69990.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
These files have been moved/renamed as the project grew but this part of
the documentation has gotten out of sync.
This fixes the most obvious discrepancies.
Signed-off-by: Wilfried Chauveau <wilfried.chauveau@arm.com>
Looking to expand the sensor docs and break out significant sections.
First though to move this to a directory to allow for multiple sensor
related rst docs.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Deprecate the CAN controller bus-speed/bus-speed-data properties and rename
them to bitrate/bitrate-data to match the terminology used in other CAN
devicetree properties and the CAN subsystem API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adds some introductory context to the charger documentation. This
is being aided to help developers understand what a charger device
is and how the charger_driver_api is relevant to system operation.
Signed-off-by: Ricardo Rivera-Matos <ricardo.rivera-matos@cirrus.com>
Include the device name when printing received CAN frames. This improves
the user experience when working with multiple CAN controllers via the CAN
shell.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fixes: #27439
This commit introduces an initial SoC porting guide with a general
description of the minimal set of files needed to support a new SoC in
Zephyr, along with some examples of the content.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Remove all CAN controller "bus-speed" and "bus-speed-data"
properties. These all use the default bitrates set via Kconfig.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This enhances the description of i.MX8MPlus SoC with the Cadence HIFI4
core and thus will make this example more relevant to the benefits of
HWMv2.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Adds some documentation about the Xtensa HiFi AudioEngine DSP and
how to enable its use with Zephyr.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
Added a newline to display the list correctly
The list is displayed like:
MIPI DBI defines 3 interface types: * Type A: Motorola 6800 parallel bus
* Type B: Intel 8080 parallel bus
But it should be like:
MIPI DBI defines 3 interface types:
* Type A: Motorola 6800 parallel bus
* Type B: Intel 8080 parallel bus
This was fixed by an example from another doc:
doc/hardware/peripherals/i3c.rst
Signed-off-by: Dmytro Yaskov <dmytro.v.yaskov@gmail.com>
The current diagram uses a custom font that does not render correctly on
some browsers. Replace it with a common font (Courier New) instead so
that there are no rendering issues.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Update the presentation of the hardware hierarchy description so that it
does not appear to have missing words at the end of the bullet points,
by using a paragraph instead. And tweak the wording slightly.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Followup: #69905
Adopting new board terminology for CMake, python, and Kconfig code to
use qualifiers instead of identifiers.
Also adjusted to board target where applicable.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add a terminology section to the board porting guide.
This provides a single location where terminologies used for boards can
be found and linked to.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The current board porting guide explains the new hardware model without
making any references to the previous one. Add a new section that
explains the rationale behind the transition as well as adding important
bits of information for users that need to convert their boards.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Since all CAN controllers drivers seem to support automatic recovery (for
any future drivers for hardware without this hardware capability this can
easily be implemented in the driver), change the Zephyr CAN controller API
policy to:
- Always enable automatic bus recovery upon driver initialization,
regardless of Kconfig options. Since CAN controllers are initialized in
"stopped" state, no unwanted bus-off recovery will be started at this
point.
- Invert and rename the Kconfig CONFIG_CAN_AUTO_BUS_OFF_RECOVERY, which is
enabled by default, to CONFIG_CAN_MANUAL_RECOVERY_MODE, which is disabled
by default. Enabling CONFIG_CAN_MANUAL_RECOVERY_MODE=y enables support
for the can_recover() API function and a new manual recovery mode (see
next bullet). Keeping this guarded by Kconfig allows keeping the flash
footprint down for applications not using manual bus-off recovery.
- Introduce a new CAN controller operational mode
CAN_MODE_MANUAL_RECOVERY. Support for this is only enabled if
CONFIG_CAN_MANUAL_RECOVERY_MODE=y. Having this as a mode allows
applications to inquire whether the CAN controller supports manual
recovery mode via the can_get_capabilities() API function and either fail
or rely on automatic recovery - and it allows CAN controller drivers not
supporting manual recovery mode to fail early in can_set_mode() during
application startup instead of failing when can_recover() is called at a
later point in time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Asynchronous and interrupt driven APIs can be used at the same time for
different hardware peripherals.
Signed-off-by: Johan Stridkvist <johan.stridkvist@nordicsemi.no>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within the doc/build, hardware, kernel, project directory.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
A growing number of CAN controllers do not have support for individual RX
hardware filters based on the Remote Transmission Request (RTR) bit. This
leads to various work-arounds on the driver level mixing hardware and
software filtering.
As the use of RTR frames is discouraged by CAN in Automation (CiA) - and
not even supported by newer standards, e.g. CAN FD - this often leads to
unnecessary overhead, added complexity, and worst-case to non-portable
behavior between various CAN controller drivers.
Instead, move to a simpler approach where the ability to accept/reject RTR
frames is globally configured via Kconfig. By default, all incoming RTR
frames are rejected at the driver level, a setting which can be supported
in hardware by most in-tree CAN controllers drivers.
Legacy applications or protocol implementations, where RTR reception is
required, can now select CONFIG_CAN_ACCEPT_RTR to accept incoming RTR
frames matching added CAN filters. These applications or protocols will
need to distinguish between RTR and data frames in their respective CAN RX
frame handling routines.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In some cases, PINCTRL_STATE_SLEEP may be required even when
CONFIG_PM_DEVICE is not defined.
One example is the possibility/need to put JTAG pins to analog when
CONIG_PM=y and CONFIG_DEBUG=n.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
Add a small paragraph about the EEPROM simulator,
and improve slightly the flash simulator section
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Add reference to section in RTC peripheral documentation which
covers the emulated RTC.
Signed-off-by: Bjarki Arge Andreasen <bjarki@arge-andreasen.me>
* Convert png figures to svg
* Remove app.png and the paragraph which elaborated on it.
(It was very specific to some particular
user case, and having it did not improve understanding)
* Correct all references to "native_posix drivers" to
the be just "emulated drivers"
(they are not native_sim specific)
* Correct path for a file which was moved
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Limit the content of this page to only cover the bus
emulators and their peripherals.
Until now, there was some out of place references to
emulators of a completely different type which did
not match the descriptions in this page.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Created new emulators page, and moved the
current page to be a page dedicated to bus emulators.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Adds a charge_enable handler to facilitate enabling and disabling
a charge cycle. This deprecates enabling and disable the charge
cycle via the CHARGER_PROP_STATUS property.
Signed-off-by: Ricardo Rivera-Matos <ricardo.rivera-matos@cirrus.com>
The section overview list at the beginning of the document
is missing a few sections which were added after the list
was first created. So add them.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The function _Cstart has already been renamed to z_cstart,
so change the remaining references of it in various docs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The stack object memory map was missing from the doc due to
incorrect indentation. Fix it so that it shows up in the doc.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Another round of repeated words cleanup. This commit tries to keep the
diff minimal and line wrapping was mostly left intact in the touched
files, as having them consistent across the documentation is probably
the topic of a future tree-wide cleanup (or not)
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
* Fix app path in documentation
* Move the at24 emulator overlays to be general instead of
native_posix specific
* Switch default test platform from native_posix to native_sim
* From build only test, exclude platforms which are used
in the build and run test.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Replace the references to native_posix with native_sim.
Background: during this release native_sim is replacing
native_posix as the main host test/development platform.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The DMA API has several expectations for drivers and callers that were
underdocumented or undocumented. Better clarify the driver expectations
and caller expectations.
The DMA API from the caller side is not a portable API and really cannot
be as each DMA has unique properties and expectations of memory,
peripheral interaction, and features. The API in effect provides a union
of all useful DMA functionality drivers have needed in the tree. It can
still be a good abstraction, with care, for peripheral devices for
vendors where the DMA IP might be very similar but have slight
variances.
From the driver implementation side expectations around synchronization,
state transitions, and memory management for transfer descriptors is now
described in documentation rather than solely from me in github review
comments.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Correct Properties subsection of the document to be accurate
to the latest implementation of the charger API.
Signed-off-by: Ricardo Rivera-Matos <ricardo.rivera-matos@cirrus.com>
Removes a statement at the introduction claiming only getting
properties is supported by the API. The charger API can get/set
properties.
Signed-off-by: Ricardo Rivera-Matos <ricardo.rivera-matos@cirrus.com>
Unify spelling of CAN Flexible Data-rate abbreviation to "CAN FD" instead
of "CAN-FD". The former aligns with the CAN in Automation (CiA)
recommendation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Split out the CAN transceiver API documentation from the CAN controller API
documentation. The CAN transceiver API was introduced in Zephyr v3.1.0.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
- Added GNSS documentation entry to peripherals
- Added GNSS API entry to the API overview as 3.6 experimental
Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
Move the documentation for high-level CAN protocols (for now only covering
ISO-TP) from the peripherals section to the connectivity section.
This matches the layout in code, where the CAN controllers are under the
drivers/can directory and the protocols are under the subsys/canbus/
directory.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adds a note on how to configure and what to beware of when
disabling mutex support in a multithreading application
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Tweak a few sentences and add a basic example, to fit in with the
overall document a little better. Also, fix an invalid cross-reference.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
It was awkwardly placed in the middle of the "Write your devicetree"
section, breaking up the flow of the guide. A more natural placement
would be underneath "Contributing your board", considering that this
feature deals with boards already submitted to Zephyr.
Let's relocate this part and swap two of its paragraphs in the process,
to motivate the feature before describing it.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Based on review of the similar charger driver API, it's been demonstrated
from the community that embedding a per value property type when fetching
properties. Separating off the property types from the property values
themselves also allow an array of property types to declared as static
const.
Break up fuel_gauge_property struct into a fuel_gauge_prop_val union and a
fuel_gauge_prop_t property type as inputs into fuel gauge API functions.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
The fuel_gauge_get_prop() function prototype declares a function that
retrieves multiple fuel gauge properties at once. The naming suggests it
ought to fetch a singular property at a time. Moreso, some clients may just
want to fetch properties one at a time and may feel uncomfortable using a
prototype for fetching multiple properties when wanting to fetch them one
at a time.
Modify fuel_gauge_get_prop() to fetch a single property and add
fuel_gauge_get_props() to support fetching multiple properties. Modify
existing tests/drivers/samples.
This is part of #61818 work.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
Use the new code-sample directive and roles to document the networking
samples so that they show up as "Related samples" when browsing the
various relevant networking APIs.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The fuel gauge API uses separate get/set property structs to indicate what
properties are readable or writable. This lead to duplication in property
names and potential confusion for new users of the API. See issue #61818.
In addition to above, drivers already determine at runtime if a property is
supported for read or write actions.
Join the get/set fuel gauge property structs as a single struct.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This commit follows the parent commit work.
This commit introduces the following major changes.
1. Move all directories and files in 'include/zephyr/arch/arm/aarch32'
to the 'include/zephyr/arch/arm' directory.
2. Change the path string which is influenced by the changement 1.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
It doesn't make sense to keep the aarch32 directory in the
'arch/arm/core' directory as the aarch64 has been moved out.
This commit introduces the following major changes.
1. Move all directories and files in 'arch/arm/core/aarch32' to
'arch/arm/core' and remove the 'arch/arm/core/aarch32' directory.
2. Move all directories and files in 'arch/include/aarch32' to
'arch/include' and remove the 'arch/include/aarch32' directory.
3. Remove the nested including in the 'arch/include/kernel_arch_func.h'
and 'arch/include/offsets_short_arch.h' header files.
4. Change the path string which is influenced by the changement 1
and 2.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
Adds a short stub doc as a placeholder for future documentation in the
charger API.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Many fuel gauge ICs offer a battery cutoff/shipping mode functionality that
cutoff charge from the battery. This is often useful for preserving battery
charge on devices while in storage.
Add battery cutoff support to the fuel gauge API with a generic default SBS
driver showing an example of support in tests.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
Board extensions are board fragments that may be present in any board
root folder, under `${BOARD_ROOT}/extensions/${BOARD}`. The board
extension directory may contain Kconfig fragments and/or devicetree
overlays. Board extensions are automatically loaded and applied on top
of board files, before anything else. There is no guarantee on which
order extensions are applied, in case multiple exist.
Board extensions may be useful in the context of Zephyr modules, such as
`example-application`. In some situations, certain hardware description
or choices can not be added in the upstream Zephyr context, but they do
in a downstream project, where custom bindings or driver classes can
also be created. This feature may also be useful in development phases,
when the board skeleton lives upstream, but other board features are not
yet present.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Update ARC support status page as now we have scalar ARC VPX
port upstreamed.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Add a new option to `board_check_revision` that can make specifying a
board revision optional. This makes it easier to work with boards that
can come in a base variant with extensions. For example Fanstel BLE
modules that come with/without power amplifiers.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This PR introduces a backend API to be implemented by sensor emulators
that creates a standardized mechanism for setting expected sensor
readings in tests. This unlocks the ability to create a generic sensor
test that can automatically set expected values in supported sensor
emulators and verify them through the existing sensor API. An
implementation of this API is provided for the AKM09918C magnetometer.
A generic sensor test is also created to exercise this implementation.
Observe that this test knows nothing about the AKM09918C; info about
supported channels and sample ranges is discovered through the backend
API. The test iterates over all devices attached to the virtual I2C and
SPI buses in the test binary's device tree, which (theoretically) covers
all sensors. Sensors whose emulator does not exist yet or does not
support the backend API are skipped.
Signed-off-by: Tristan Honscheid <honscheid@google.com>
Both the IRQ API and Asynchronous API support callback.
However, since they are both interrupt driven, having
callbacks on both API would interfere with each other
in almost all cases. So this adds a kconfig to signal
that the callbacks should be exclusive to each other.
In other words, if one is set, the other should not
be active. Drivers implementing both APIs have been
updated to remove the callbacks from the other API.
Though, this still leaves the option to disable
the kconfig and allows both APIs to have callbacks
if one desires.
Fixes#48606
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In order to support easier setup of test scenarios with fuel gauge
emulators, we should expose an API that can change internal emulator state.
Add a minimal fuel gauge emulator backend API for setting the charging
current and voltage with a sample implementation in the emul_sbs_gauge with
an associated driver test.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
DSP AGU/XY extensions ARC EM processors are supported now in
Zephyr.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Usage of numfig=True option in conf.py significantly increases doc build
time. While it is a nice feature, it's not extensively used in Zephyr
documentation, so let's remove its usage in favor of faster doc builds.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Add doxygen group and improve documentation for bbram.h
- Add a bbram section under peripherals in the main doc/ directory
Fixes#55257
Signed-off-by: Yuval Peress <peress@google.com>
Fixed spelling mistakes, added links in place of
highlighted text where appropriate and switched
unformatted blocks with bash commands to bash
code blocks.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
Improve and update driver class introduction. Removed some outdated
information about on/off, mention PMICs, generalize *-supply properties,
etc.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The emulated RTC device driver is used to emulate a real
RTC device. Note that it is not a replacement for the
native_rtc module, which is used to control simulated time,
get time from the host system, etc.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
This test suite adds tests for the following:
- Setting and getting time
- Validating time is incrementing correctly
- Validating behavior of alarms with callback disabled
- Validating behavior of alarms with callback enabled
- Validating update callback
The test suite uses the devicetree alias rtc to find
the device to test.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
This commit adds the rtc.h header file which contains
API functions for real-time-clocks, which are low power
devices which track and represent broken-down time.
It also changes one line of doxygen documentation in the
maxim_ds3132.h file to place it in its own group.
The handlers for use of the API from userspace is also
added with this commit.
The API is split into one mandatory section, setting and
getting time, and three optional sections, alarms, update
event callback, and clock calibration.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
