The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, packages must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, tests must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, drivers must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, drivers and other modules must first be changed so that they use the inline comparison functions.
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_
The Watchdog on the CC2538 only supports 4 intervals (2ms, 16ms, 250ms & 1s).
Since the watchdog timer API specifies a `max_time`, the interval equal or
below that time is selected.
E.g. for `max_time=125ms` the 16ms interval would be selected.
This is outside the tolerance of the `tests/periph_wdt` test.
Co-authored-by: Thomas Geithner <thomas.geithner@dai-labor.de>
The rv32imac supports the A (atomic) extensions containing
read-modify-store operations. This commit modifies the GPIO code to use
these for all bitwise operations. The atomic operations are emitted with
relaxed ordering as they do not require multiprocessor synchronization.
This decreases the duration of the gpio operations from 59 ns to 50 ns
per call. depending a bit on the type of operation.
Just because a user pulls in the DNS client (`sock_dns`) doesn't mean
they want to pull in RDNSS option support as well. Besides, since
`gnrc_ipv6_nib_dns` depends on `gnrc_ipv6_nib`, this forms a circular
dependency that really isn't necessary.
The other applications using `sock_dns` do it too
(`tests/gnrc_sock_dns` and `tests/gnrc_ipv6_nib_dns`) and besides it
doesn't make much sense to include RDNSS option support
(aka `gnrc_ipv6_nib_dns`) just because someone uses the DNS client
(aka `sock_dns`). This dependency will be removed in a later commit.
This is a small optimization to the RISC-V trap handler. By splitting
the call to sched_run from the trap_handle call, loading the previous
thread ptr can be delayed until after it is determined that a schedule
run is required. This shaves of a few cycles during regular interrupts
that do not trigger the scheduler.
