- EOP bit is cleared by writing 1 to the register.
- Guard EOP bit clear for STM32F2, STM32F4, STM32F7
and STM32L4 EOP bit is only set if EOPIE is enabled.
Since this is not the case for any platform we exclude
it when not needed.
The softdevice is only verified to be working on nrf52832-based
boards. This feature prevents the softdevice from being build for
other, similar targets (e.g. nrf52840-based boards).
- With this PR, On start up all GPIOs are configured as AIN. For stm32l0/4
this is done by default. Doing this saves the consumption of the input Schmitt
trigger in STOP mode which can reduce the consumption in at least 70%
from current master.
When reworking the reception of IPv6 packets I reset a previously set
`ipv6` snip as follows when the IPv6 extension handler returns a
packet (see first hunk of this commit):
```C
ipv6 = pkt->next->next
```
With `gnrc_ipv6_ext` this makes *somewhat* sense, `pkt->next` was
previously equal to `ipv6` and after the function call `pkt->next`
is the marked extension header, while `pkt->next->next` is the IPv6
header. However, since `ipv6` is already write-protected i.e.
`ipv6->users == 1` (see ll. 665-675), any additional call of
`gnrc_pktbuf_start_write()` [won't][start-write-doc] duplicate the
packet. In fact, the only `gnrc_pktbuf_start_write()` in
`gnrc_ipv6_ext` is used to send the *result* to the subscribers of that
extension header type, leaving the original packet unchanged for the
caller. As such `ipv6` remains the pointer to the IPv6 header whether
we set it in the line above or not. So we actually don't need that
line.
However, the extension header handling also returns a packet when
`gnrc_ipv6_ext` is not compiled in. In that case it is just a dummy
define that returns the packet you give provide it which means that
this still holds true: `pkt->next == ipv6`.
So setting `ipv6` in this case is actually harmful, as `ipv6` now
points to the NETIF header [following the IPv6 header][pkt-structure]
in the packet and this causes the `user` counter of that NETIF header
`hdr` to be decremented if `hdr->users > 1` in the write-protection I
removed in hunk 2 of this commit:
```C
/* pkt might not be writable yet, if header was given above */
ipv6 = gnrc_pktbuf_start_write(ipv6);
if (ipv6 == NULL) {
DEBUG("ipv6: unable to get write access to packet: dropping it\n");
gnrc_pktbuf_release(pkt);
return;
}
```
But as we already established, `ipv6->users` is already 1, so we don't
actually need the write protection here either.
Since the packet stays unchanged after the `ipv6` snip, we also don't
need to re-search for `netif_hdr` after the other two lines are
removed.
[start-write-doc]: https://doc.riot-os.org/group__net__gnrc__pktbuf.html#ga640418467294ae3d408c109ab27bd617
[pkt-structure]: https://doc.riot-os.org/group__net__gnrc__pkt.html#ga278e783e56a5ee6f1bd7b81077ed82a7
When subscribing to IPv6 packets on a router for sniffing, the NETIF
header is released prematurely, because of a wrong
`gnrc_pktbuf_start_write()` call. This test aims to reproduce this
error case.
- The previous implementation wrongly assumes that sx1272 and 1276
use the same logic level for triggering a reset.
- The timeout values were to short to guarantee proper reset when
coming from POR.
- The PNB in FLASH_CR wasn't cleared before every erase operation
and the new value was just stacked on top. After a couple of erase
the PNB written was overlapping with old ones failing to erase the
correct page.
This change allows callers to receive the job list of individual apps in
chunks (instead of all at once after all appdirs have been processed),
if run as dwq job itself.
E.g.,
$ dwqc ./.murdock get_compile_jobs
would previously run "get_compile_jobs()" as one job, collecting all the
output from "get_app_board_toolchain_pairs()" subjobs, then return the
combined output as job result.
By using subjobs, the job returns right away, but has previously sent
the "get_app_board_toolchain_pairs" jobs as subjobs ti the initial
instance, which will also wait for all of them to complete, but
already print subjob output as it is received.
Previously, get_app_board_toolchain_pairs() took the appdir as only
parameter and produced "$appdir $board:$toolchain" tuples.
This commit makes get_app_board_toolchain_pairs() prefix each tuple with
any additional args, e.g.,
get_app_board_toolchain_pairs() tests/hello_world ./murdock compile
->
./murdock compile tests/hello_world samr21-xpro:gnu
This allows getting rid of the xargs call in get_compile_jobs().
Introduce and use a common/remote/Makefile.features.
The boards were already using the common `Makefile.include` and
`Makefile.dep`.
This makes 'include $(RIOTCPU)/cc2538/Makefile.features' be done in
the same module where 'CPU' is defined.
Preparation for moving 'CPU' definition to Makefile.features.
Introduce and use a common/msba2/Makefile.features.
The boards were already using the common `Makefile.include` and
`Makefile.dep`.
This makes 'include $(RIOTCPU)/lpc2387/Makefile.features' be done in
the same module where 'CPU' is defined.
Preparation for moving 'CPU' definition to Makefile.features.
