This tests makes little sense to have for a number of reasons:
1. One should not use `iprintf()` for a number of reasons:
1. It is non-standard and using it over `printf()` makes the code
less portable (e.g. it cannot be used on AVR)
2. The idea of adding a leaner variant of `printf()` in addition to
the larger one is bogus, as apps will end up using both resulting
in a *larger* firmware instead of a smaller
3. RIOT's build system already has the `printf_float` module to
control whether formatting of floating point numbers should be
suppered. This mechanism will actually result in smaller builds,
if floating point support is not needed, as it prevents two
variants of printf to be linked in.
2. The test checks some implementation details (e.g. whether the
address of two functions is identical), rather than correct behavior
of the implementation. This is completely bogus.
This adds a simple test applications that runs snprintf on standard
format specifiers and compares the output with the expected output.
The assumption is that internally every stdio implementation uses the
same formatting code for each member of the printf functions family,
so testing snprintf only is sufficient.
examples: Fix incorrect category heading
examples: shorten coap folder name
static-tests/examples: check subfolders for entries
ci/test_native: Adjust to new examples structure
examples: adjust makefiles to new structure
ci/tests: Fix symlinks to point towards proper examples
Several boards have been removed from the exclusion list to reassess
their compatibility. This updates test coverage while keeping only truly
incompatible boards excluded.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Increase Shell buffer size for 64 bytes payload length of CAN FD frame.
This also implies to increase main thread stack size and especially for
native architectures.
Add two new sub-commands to test_can command:
* fdsend: to send a CAN FD frame
* fdsendrtr: to send a CAN FD RTR frame (payload length = 0).
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Whole CAN code in RIOT is using 'struct can_frame' to represent a CAN
frame.
However incoming CAN FD support will bring 'struct canfd_frame' to
represent CAN FD frames.
Even if the 'struct canfd_frame' has additional flags and a bigger
payload, it is aligned on 'struct can_frame' and thus they can be
referenced by the same pointers in the code.
As it is impossible to predict which one will be used in RIOT, just
define a new type 'can_frame_t' which will map to the right struct
according to the MCU CAN supported format.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
RIOT implementation of CAN bus relies on SocketCAN model.
Since commit c398e56 (can: add optional DLC element to Classical CAN
frame structure), '__u8 can_dlc' attribute of struct can_frame is
considered as deprecated in SocketCAN and kept for legacy support.
Attribute '__u8 len' should be used instead.
union {
/* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
* was previously named can_dlc so we need to carry that
* name for legacy support
*/
__u8 len;
__u8 can_dlc; /* deprecated */
};
Moreover, CAN FD frame structure does not support legacy attribute
'can_dlc', making 'len' mandatory for incoming CAN FD support in RIOT.
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[CANFD_MAX_DLEN]
__attribute__((aligned(8)));
};
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
On `native` when build with LLVM, time seems to not monotonically
increase, causing a test to be flaky.
This disables the part that is flaky on native on native.
