This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
Both tests/pthread_tls and tests/prng_sha256prng fail without this, but
other platforms run fine with their defaults. Lets consider the higher
value a better default.
- Updated to inline-able IRQ API
- Improved robustness of functions
- Added memory barrier to prevent the compiler from moving code outside of
a critical section guarded by irq_disable() ... irq_restore()
- Reduced overhead of `irq_disable()`
- After clearing the global interrupt enable (GIE) bit, IRQs remain enabled
for up to one CPU cycle
- The previous implementation just added a nop to fill that cycle
- This implementation uses the cycle for masking the return value
- Reduced overhead of `irq_restore()`
- Now only one CPU cycle is needed
- `irq_disable()`, `irq_restore()`, and `irq_enable()` work now in constant time
- TI documentation for msp430f1xx is ambiguous regarding length
of some memmory sectors. For some cpu's the acual size is 1/4 byte
smaller than advertised and one of the sectors is actually 256b and
not 512.
ref: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/798838/2962979#2962979
- Remove the first 256b sector from usage since there is not support for
variable sized pages
- Fix msp430f2617 FLASHPAGE_NUMOFF to represent accesible memory
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.
For this purpose, adapted AVR libc functions are used. When used, malloc and free functions require 304 additional bytes of code compared to the oneway_malloc module.
`void cpu_switch_context_exit(void)` assigns `sched_active_thread` just before
calling `sched_run()`. This is unneeded, as `sched_run()` will updated that
anyway. Also generally speaking, changing internal scheduler data from outside
the scheduler is a risky thing to do.
