Due to the RIOT_EPOCH of 2020 this overflow will happen in year 2084. It would be scary if IoT devices are still around then.
We can save RAM and ROM. Furthermore, this overflow handling should block BACKUP power mode in order to keep track of the reference year.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
The source / destination address of the SDHC transfer needs to be
word-aligned.
Use the mtd buffer to fix the alignment if `mtd_write_page` is used,
otherwise return -ENOTSUP.
`rtt_get_counter()` already waits for syncbusy before reading the time,
but we also have to do this in RTC mode (`rtc_get_time()`) to avoid
reading old values.
Thus, always wait for syncbusy to clear when accessing the COUNT register.
On SAM L21 only 8 EXTWAKE pins can wake the CPU from Backup sleep.
Handle this analogous to the RTC tamper pins on SAM D5x/E5x where
configuring them as an interrupt will also cause them to wake the
device from Deep Sleep.
The sam0 rtt busy loops for 180us every time an alarm is set or
the counter is read, this propagates and leads to timing errors
on ztimer_msec that are higher than > +-1msec.
The same goes for fe310.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
Setting up a DMA transfer can take longer than sending out a buffer
byte by byte if the buffer is small.
DMA only shows advantages for large buffers, using it for every transfer
will cause a net slowdown.
Since we did not come up with a good way to determine the treshold based
on the SPI frequency, just use a fixed buffer for now so that DMA can be
used without slowing things down overall.
In Asynchronous Fractional baud rate mode, the baud rate can not be
greater than the source frequency divided by the oversampling (8, 16).
Currently we are always using 16x oversampling.
This makes it impossible to e.g. set a 2 MHz UART baud rate on the 16 MHz
`saml10-xpro`.
With this change, the oversampling is automatically reduced to 8x which
allows us to set 16 MHz / 8 -> 2 MHz baud rate.
SERCOM5 on SAM L21 does not support fractional baud rate mode.
Instead of special-casing it, just use arithmetic baud rate mode
in general on this CPU, as I'm not sure what the advantages of fractional
baud rate mode are.
fixes#16692
In case of network heavy traffic on the Ethernet, interrupts
fire faster than the netdev thread can process them and we
run out of buffers. With this commit, we now check if we
don't have buffers available, so we can flush everything and
restart reception properly even if we did drop a few in the
operation
When using the I2C_NOSTOP flag the bus should remain in control.
The current check assumes it must go to idle when reading.
This adds a condition checks if the nostop flag is active
and expects the bus status to be the owner of the bus.
This reverts commit 585dc15f99.
I did misunderstand this feature: This only inverts the data
bits (instead of `c` uart will transmit `~c`), not the whole
line level.
This is not very useful on it's own, so revert it.
The RTT overflow callback is not available on all RTT implementations.
This means it is either a no-op or `rtt_set_overflow_cb()` is a no-op
or it will overwrite the alarm set with `rtt_set_alarm()`.
This adds a feature to indicate that proper overflow reporting is available.
This allows to use the sam0 RTT together with the rtt_rtc module.
The idea is to use RTT as a monotonic counter, but still keep track
of the time with the virtual RTC module.
If we configure TAMPCTRL early, GPIO events will set bits in the
TAMPCTRL register.
That means that after a wake-up, we can't tell if the bit was set
because it was the wake-up source or if it was already set by a
run-time GPIO event.
Some periph_rtt implementations do not provide `rtt_set_counter()`. This
adds `periph_rtt_set_counter` as feature to allow testing for its
availability. The feature is provided at CPU level if periph_rtt is
provided by the board for all CPUs implementing `rtt_set_counter()`.
Some periph_rtt implementations do not provide `rtt_set_counter()`. This
adds `periph_rtt_set_counter` as feature to allow testing for its
availability. The feature is provided at CPU level if periph_rtt is
provided by the board for all CPUs implementing `rtt_set_counter()`.
The ADC SYNCBUSY.SWTRIG gets stuck to '1' after wake-up from Standby Sleep mode.
Ignore the ADC `SYNCBUSY.SWTRIG` status bit, this functionality is not used by
the driver anyway.
Errate 2.17.4 says:
> Upon enabling the RTC tamper detection feature, a false tamper
> detection *can* be reported by the RTC.
It turns out that this spurious event is not always generated.
If RTC alarm is used and the CPU was previously woken from hibernate
by RTC, it *can* happen that the false tamper event is *not* generated.
In this case, we will block indefinitely on the mutex.
To solve this, add a timeout to the event.
Also poll the event instead of using a mutex, as we have already set
`PM->SLEEPCFG.bit.SLEEPMODE` at this point.
The DAC can have some start-up delay.
If we try to write to it before it's ready, it will get stuck.
This happens now that `tests/driver_dac_dds` immediately sets a DAC
value after init.
The samd2x class of MCUs doesn't have this bit, but a quick test on
samd10 shows that it might not be nececary there - the DAC does not
get stuck when writing to it immediately after init.
`flashpage_write_raw()` got renamed to `flashpage_write()`.
Now `sam0_flashpage_aux_write_raw()` is the only remaining 'raw'
function, even though it behaves just like `flashpage_write()`.
So let's also rename that for consistency.
On samd5x only the RTC can wake the CPU from Deep Sleep (pm modes 0 & 1).
The external interrupt controller is disabled, but we can use the tamper
detection of the RTC.
If an gpio interrupt is configured on one of the five tamper detect pins,
those can be used to wake the CPU from Deep Sleep / Hibernate.
The Cortex-m0 based ATSAM devices can use the Single-cycle I/O Port for
GPIO. This commit modifies the gpio_t type to use this port when
available. It is mapped back to the peripheral memory space for
configuration access. When it is not available, the _port_iobus() and
_port() functions behave identical, which is the case for the samd51.
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_
If we disable an external interrupt, GPIO events that would generate an interrupt will still set the interrupt flag.
That means once we enable the interrupt again, a stale interrupt will be triggered.
This is surprising and probably not what the user wants, unfortunately the API documentation is not very clear about what to expect.
There is however no way to drop those intermediate interrupts with the current API.
Ignoring the events that occurred while the GPIO interrupt were disabled is probably the right (and expected) thing to.
