The spi scalar calculation tool for the kinetis family is stand-alone
and doesn't use the RIOT headers. It doesn't include the ARRAY_SIZE
macro from the RIOT headers. This commit adds a local definition of the
ARRAY_SIZE macro
Rename the variable to make it clearer that it refers to the last Makefile
included.
Usually this is the current file, but when another Makefile is included this
changes.
This moves the following modules to a architecture-specific Makefile.dep
file:
- cortexm_common
- cortexm_common_periph
- newlib
- newlib_nano
- periph
Now that CPU and CPU_MODEL are defined in the board's Makefile.features
it can be used to determine the available features provided by the
specific model.
- Removed stdio_init() from newlib's _init(), as this is too late in the boot
process to allow DEBUG()ing during periph_init()
- Added stdio_init() to the various cpu_init() routines of the ARM CPUs just
before periph_init()
On cppcheck 1.82 it throws a warning.
Since it costs cycles and does nothing the ++dummy is (void)dummy.
A warning suppression is added so the CI is happy.
This fixes the positive result when master write data is NACKed.
This false positive occurs when the write frame is finished but a data nack occurred.
The AF check should occur first.
- _rom_start_addr, _ram_start_addr, _rom_length and _ran_length are
already defined in cortexm_common/Makefile.included and can therefore
be removed from kinetis/Makefile.include
- _ram_base_addr is never used and was not in commit history so
is also removed
- To be able to flash at an offset the vector table must be
relocated accordingly to the IMAGE_OFFSET, therefore linkage
needs to take the offset into account.
Rational: the periph_common module is required by (most) other periph drivers
and also during startup of the CPU/MCU to run periph_init. The latter is only
required if other periph drivers are used, hence periph_common should be a
depency of periph_* modules and *not* of the CPU/MCU. This PR fixes that
by making periph_common a depency of periph_* and removing the explicit
include in the CPU/MCU implementation.
Keep the compiled '.bin' file to remove the need to compile it when
flashing. This remove the need to have the toolchain when flashing so
allow compiling and flashing with `BUILD_IN_DOCKER=1` without a local
toolchain.
Even if it ends up storing a binary, the file is only 34 bytes.
Get OBJDUMP from the environment instead of hardwriting the value.
This is a prerequisite to allow using `objdump` when building from docker
when not having the `arm` toolchain installed.
- fcfield is located in memory at 0x400-0x40f. Its content is only read
upon reset, therefore if in presence of a bootloader and multiple
applications, the fcfield will only be read when the bootloader
is loaded. As long as we flash at IMAGE_OFFSET > 0x410 we do not
care about the fcfield content since it won't get overwritten.
This removes doing `filter-out periph_hwrng, $(FEATURES_PROVIDED)`
after processing `cpu/$(CPU)/Makefile.features`.
The current solution is a HACK as `CPU_MODEL` is currently not available
at that moment but will be in the near future.
It will allow always including `cpu/$(CPU)/Makefile.features` after
`boards/$(BOARD)/Makefile.features`.
It is a part of moving `CPU/CPU_MODEL` definitions to `Makefile.features`.
It must be evaluated in `cortexm_common` without a shell context.
The `K` is correctly handled by both the linker and `cortexm_common`.
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
Spinning for the correct time has the side effect that it may cause
infinite recursion if the callback function calls timer_set.
timer_set->callback->...->timer_set->callback->...->timer_set-> infinity
In theory, the drawback is that the callback for very short timeouts
(<2 lptmr ticks) may be delayed up to 2 lptmr ticks (61 µs)
In practice however, tests performed using tests/bench_timers shows that
this change only affects the accuracy of the timer target when timer_set
is called with a timeout of 0, which results in a delay of 30 µs.
By not forcing a fixed oversampling rate we can achieve better baud rate
accuracy than otherwise possible.
For example, when requesting 115200 with a module clock of 4 MHz,
picking an oversampling rate of 17 (instead of hardware
default 16) yields 117647 baud instead of 125000 baud as the best
matching rate. Better matching baud rate between receiver and
transmitter results in a lower probability of transmission errors.
