Features must be provided by the board if they're actually
available on board. Other features might be provided by the
CPU.
Some grouping is also removed as it is not necessary.
Leverages common flasher (avrdude) and removes unnecessary exports.
Moreover, a reuse of serial.inc.mk is perfomed from the same
atmega_common/Makefile.include
Currently only tested boards provide the feature riotboot.
Potentially all boards embeding a cortex-m0+/3/4/7 are
able to have riotboot as a feature, but other dependencies
need to be met, e.g. usage of cortexm.ld linker script,
double initialisation of cpu_init(), etc. See doc in
bootloaders/riotboot.
This commit fixes configuration problems when trying to use i2c pins that need to be remapped.
All B8 and B9 pins for STM32F1 need to be remapped, so a check is done if the remappable pins are selected.
With the canned recipe for flashing, flash dependencies should be
added to FLASHDEPS, instead of writing `flash: dependencies`. This
ensures that both flash and flash-only depend on the same prerequisites.
- correct number of timers for atmega328p from 2 to 1
- correct number of timer channels for atmega328p from 3 to 2
- adapt atmega periph timer implementation accordingly
Boards should not set PORT and should not have code conditional on
PORT as that causes PORT to be evaluated and the build to fail even
if this varible is not needed.
Exporting has the same effect.
This fixes the MSBA2 board by declaring PORT_LINUX and PORT_DARWIN
instead.
In commit e90f2b439e the I2C config has been
adapted to the new I2C API. However, the pins of I2C_DEV(0) have been changed
from PB6 and PB7 to PB8 and PB9. While PB8 and PB9 also can be used for I2C1
by remapping I2C1, this is not done. As a result, I2C1 was unusable. This
commit restores the default I2C1 pins for I2C_DEV(0), resulting in I2C_DEV(0)
becoming usable again.
The STM32F103C8 secretly comes with 128KiB flash instead of 64KiB. Still, only
64KiB of it are tested and guaranteed to work. However, most of the times the
whole 128KiB flash works just fine. In the BluePill documentation this fact is
already documented and by using
$ make BOARD=bluepill CPU_MODEL=stm32f103cb
the whole 128 KiB can be used by RIOT. When using this hack routinely, it easier
to use environment variables instead. But allowing to overwrite CPU_MODEL via
environment variables seems to be a bad thing, as it is easy to forget to clear
that environment variable when changing the BOARD variable.
This commit introduces the new STM32F103C8_FLASH_HACK variable, which unlocks
the 128KiB FLASH when set to "1". The BluePill documentation has been updated
accordingly.
