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>
Daniel DeGrasse
Johan Stridkvist
Henrik Brix Andersen
Pisit Sawangvonganan
Erwan Gouriou
Alberto Escolar Piedras
Bjarki Arge Andreasen
Ricardo Rivera-Matos
Anas Nashif
Daniel Leung
Benjamin Cabé
Tom Burdick
Bjarki Arge Andreasen
Yanfeng Liu
Jamie McCrae
Grzegorz Swiderski
Anisetti Avinash Krishna
Aaron Massey
Carlo Caione
Huifeng Zhang
Ricardo Rivera-Matos
Gerard Marull-Paretas
Declan Snyder