Measurements show that the time from pin edge until return from
interrupt is reduced from 22 us to 6.1 us for KW41Z running at
41.94 MHz. The measurements used a no-op GPIO callback for testing and
were measured using an external logic analyzer.
cpu.c and startup.c were redundant in most platforms, except for
atmega256rfr2. The common code is now in cpu/atmega_common/cpu.c
and cpu/atmega_common/startup.c. cpu_conf.h is also removed as
it's now in cpu/atmega_common/include thus shared by all atmega
based platforms.
Removes duplicated code for atmega platforms. They were all
basically the same, only with the exception of atmegarfr2,
for which there is an #if statement to use the code in the
same file.
Some ESP32 boards (like my SparkFun ESP32 Thing) have a main clock
crystal that runs at 26MHz, not 40MHz. RIOT appears to assume 40MHz.
The mismatch causes the UART to not sync properly, resulting in
garbage written to the terminal instead of log output.
I’ve added:
* A new board configuration constant ESP32_XTAL_FREQ that defaults
to 40, but can be overridden by a board def or at build time to
force a specific value (i.e. 26).
* Some code spliced into system_clk_init() to check this constant and
call rtc_clk_init() to set the correct frequency.
* A copy of the rtf_clk_init() function from the ESP-IDF sources.
Fixes#10272
Errors flags could not clear making the i2c unusable after error.
This fix removes the error check in start so the error flags can clear and does proper checking for status bits before _bus_check.
The problem seemed to be a pipelining problem of write and read instructions when swapping the context. An isync instruction when returning from a context switch solves the potential pipelining problem.
Reason for the problem was that tast_exit function in thread_arch.c tried to release the thread a second time although it was already released in sched_task_exit. A simple check whether the thread is already released (sched_active_thread == NULL) solved the problem.
Xtensa newlib version requires pthread_setcancelstate as symbol. Therefore, the module pthread was always used, which in turn requires the module xtimer. The xtimer module, however, uses TIMER_DEV(0). Therefore, tests/timers failed for TIMER_DEV(0).
The `periph_flash_common` feature was only defined here to trigger
inclusion of a source file with common functions.
It even only defines private symbols `_lock` and `_unlock` so no reason
to expose it to the build system.
And in practice, all stm cpus providing `periph_flashpage` or
`periph_eeprom` were required to provide `periph_flash_common` to allow
including it.
The previous implementation was only parsing in the modules were in
`FEATURES_REQUIRED` wich did not take cases of `FEATURES_OPTIONAL` into
account.
And also, in the same time, as the dependencies was declared in
`Makefile.include` it was processed before `Makefile.dep` so never handled
cases where a module could depend on `periph_flashpage` or
`periph_eeprom` feature.
It is replaced by selecting the common source file when module using it
are included.
The now useless feature `periph_flash_common` is removed from
`FEATURES_PROVIDED`.
`cpu/stm32_common/Makefile.dep` was never included by the global
`Makefile.dep`, so declaring this `USEMODULE +=` here was never shown to
the build system and never exported as `MODULE_PERIPH_I2C_X` variables.
In fact, `USEMODULE` was only used to trigger the `periph.mk`/`SUBMODULES`
mechanism to add matching source files names to `SRC` and so select
the implementation for each CPU type.
It is replaced by just explicitly selecting the right source file.
The commit
- improves the timing of the SDA and SCL signals that fixes communication problems with some slaves (#10115),
- introduces the internal function _i2c_clear which clears the bus when SDA line is locked at LOW, and
- renames internal _i2c_*_sda and _i2c_*_scl functions to function names that are more clear, e.g., _i2c_clear_sda to _i2c_sda_low.
It is the role of boards based on 'cpu/fe310' to give the configuration
for the rtc/rtt.
The fe310/periph/rtc implementation depends on having periph/rtt configured
by the board so depends on the board 'providing' the periph_rtt feature
and declaring the required macros.
It should not simply depend of the 'periph_rtt' module as this does not
enforce having a configuration for the module in the board.
In practice, when compiling, it would result in undefined 'RTT' symbols,
instead of the build system detecting it.
