For all remaining samples which now set their integration platform
as native_posix(_64) switch them to native_sim(_64)
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
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>
- Add integration_platforms to avoid excessive filtering
- Make sure integration platforms are actually part of the filter
- Fix some tags and test meta data
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Remove the CAN_HAS_CANFD Kconfig helper symbol in order to allow enabling
CAN-FD support in the API regardless of driver support.
Change default to CAN-FD support being disabled and have samples and tests
that require CAN-FD support turn it on. This aligns the default
configuration across CAN controller drivers regardless of their
capabilities.
The rationale behind this is that we are starting to see MCUs with multiple
CAN controllers, some CAN-FD compatible, some not (e.g. NXP i.MX RT1060 and
FPGAs). Automatically enabling CAN-FD support based on the presence of a
CAN-FD capable CAN controller leads to different application default
settings based on the CAN controller(s) in use.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The can_frame and can_filter structs support a number of different flags
(standard/extended CAN ID type, Remote Transmission Request, CAN-FD format,
Bit Rate Switch, ...). Each of these flags is represented as a discrete bit
in the given structure.
This design pattern requires every user of these structs to initialize all
of these flags to either 0 or 1, which does not scale well for future flag
additions.
Some of these flags have associated enumerations to be used for assignment,
some do not. CAN drivers and protocols tend to rely on the logical value of
the flag instead of using the enumeration, leading to a very fragile
API. The enumerations are used inconsistently between the can_frame and
can_filter structures, which further complicates the API.
Instead, convert these flags to bitfields with separate flag definitions
for the can_frame and can_filter structures. This API allows for future
extensions without having to revisit existing users of the two
structures. Furthermore, this allows driver to easily check for unsupported
flags in the respective API calls.
As this change leads to the "id_mask" field of the can_filter to be the
only mask present in that structure, rename it to "mask" for simplicity.
Fixes: #50776
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In a Controller Area Network a babbling node is a node continuously (and
usually erroneously) transmitting CAN frames with identical - often high -
priority. This constant babbling blocks CAN bus access for any CAN frame
with lower priority as these frames will loose the bus arbitration.
Being able to simulate a babbling CAN node is useful when examining the
behavior of other nodes on the same CAN bus when they constantly loose bus
arbitration.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
