Older versions of newlib already provide the magic endian numbers
via `machine/endian.h`, which may be indirectly included. This changes
the header to only provide the macros if the are not provided otherwise.
For sanity, it checks if the values are indeed the expected magic
numbers, even if provided from other sources.
The constants BIG_ENDIAN etc. were not consistently defined. This
bug was not caught by the unit tests, as the preprocessor would
treat undefined macros as being `0` in numeric comparisons, hence
the following test did select the correct implementation:
```C
#if BYTE_ORDER == LITTLE_ENDIAN
/* correct implementation for all currently supported boards */
#endif
```
This adds now an explicit test to the unit tests to ensure that the
magic numbers are consistently the correct values. Hence, this bug
should no longer be able to sneak in.
Co-authored-by: Teufelchen <9516484+Teufelchen1@users.noreply.github.com>
The script to fix the vendor header files has been renamed to
`fix_headers.sh` and now does two things:
1. Strip bogus type qualifiers in front of padding (as before)
2. Strip bogus `LITTLE_ENDIAN` defines.
This provides glibc, NetBSD, FreeBSD compatible endian.h header with a
lean and simple API to convert between host byte order to little endian
and big endian and the other way around.
Add support for querying the frequency supported by
`periph_timer`. This allows applications which require
this feature to run on the `native` board.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
The tramp assembly was missing a `.note.GNU-stack` section,
meaning the compiler was forced to assume that we require
an executable stack.
Fix this by adding the necessary section.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Note that for the very CPU this driver is used with (nRF52 on the
microbit-v2 board), this currently needs extra workarounds to copy
written data from flash to RAM so that the driver can see it. (Otherwise
it silently writes 00, and then correctly reads 00 from the bus all the
time).
The underlying peripheral can only read from RAM. This uses the
existing infrastructure (already needed to work around the lack of a
hardware support for I2C_NOSTART) to unconditionally copy any to-be-sent
data into RAM.