>All of them are features of each ESP SoC and have not to be configured by the
board definition.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The private parts need USB definitions (and are thus preferably used
from USB_H_USER_IS_RIOT_INTERNAL compilation units). Functions like
usb_board_reset_in_bootloader do not depend on USB headers for their
definitions and are fair game throughout the application even for
generic RIOT USB devices.
Replace `$(RIOTBOARD)/$(BOARD)` with `$(BOARDDIR)`, which also works for
external boards. This allows external boards to build on top of
`$(RIOTBOARD)/common/nrf52`.
stm32f1 periph_rtc implementation gets a 1s resolution by dividing
CLOCK_LSx by 32768. This only make sense if CLOCK_LSE is set,
otherwise CLOCK_LSI=~40000, which will lead to an imprecise rtc.
nrf52 includes include $(RIOTBOARD)/$(BOARD)/Makefile.dep to know
if `nordic_softdevice_ble` is used, this changes dependency
resolution sinnce -include $(APPDIR)/Makefile.board.dep should
be resolved before.
This can be removed once #9913 is if `nordic_softdevice` is
deprecated.
This is the radio found in NXP Kinetis KW41Z, KW21Z. Only 802.15.4 mode
is implemented (KW41Z also supports BLE on the same transceiver).
The driver uses vendor supplied initialization code for the low level
XCVR hardware, these files were imported from KSDK 2.2.0 (framework_5.3.5)
This module implements the 2 functions called when requesting a board 'reset in application' and 'board reset in bootloader' actions.
This module will also configure the behaviour of bossa flasher and has a dependency on USBUS CDC ACM module for providing STDIO over USB
The Nucleo-F103RB comes with an internal SWD programmer/debugger. Thus, the JTAG
pins are not going to be used for debugging / programming anyway. The pins are
exposed on the headers, so allowing them to be used as GPIOs make a lot of
sense.
The Bluepill / Blackpill boards only expose the SWD pins on the debug header,
but the JTAG pins (not also used by SWD) are exposed on the GPIO pin headers.
Hence, exposing them as regular GPIOs seems to be a reasonable choice.
This enables OpenOCD for the CC1312 LaunchPad.
All we need is:
- The Texas Instruments version of OpenOCD
(https://git.ti.com/cgit/sdo-emu/openocd)
- Set the `PROGRAMMER` environment variable to `openocd`.
- Connect a cc1312-launchpad and play with the commands.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
This removes duplication for the jlink case (keeping only any
non-default values in the board makefiles), and opens up STK3700's
OpenOCD programmability for generic boards.
- including `avrdude.mk` and `serial.mk` is no longer needed
- the avrdude flag -F is dropped
- This allows flashing a board having an MCU different to the one
RIOT was compiled for
- It is better to let the user provide this flag manually if she/he really
wants to turn safety off, knows what she/he is doing, and accepts the
risk associated with this
- the avrdude flag -D is dropped
- This disables issuing an erase command during flashing, however this
erase cycle is strictly required to be able to program the flash
- This is only needed in case of the stk500v2 bootloader, which implicitly
does the erase cycle and fails if explicitly asked to do so
- Only for the stk500v2 bootloader this flag is now added
- Include `tools/avrdude.mk` and `tools/serial.mk` at the common place instead
for each ATmega based board individually
- Introduce the makefile variable BOOTLOADER to de-duplicate flash configs:
- Two boards using the same bootloader now just use `BOOTLOADER ?= foo`
and share the individual config
- These settings are not applied when `PROGRAMMER` is set to still allow
users to manually specify how to program their board
Instead of hard-coding the peripheral clocks to CLOCK_CORECLOCK
introduce helper functions to return the frequency of the individual
GCLKs and use those for baud-rate calculations.
This requires the GCLK to be part of the peripheral's config struct.
While this is already the case for most peripherals, this also adds
it for those where it wasn't used before.
As it defaults to 0 (CLOCK_CORECLOCK) no change is to be expected.
To simplify board definitions and for unification between samd2x and
newer models, don't use the GCLK bitmask in board definitions.
Instead use the GCLK index and generate the bitmask when needed.
Made `void board_init(void)` in the common implementation a weak symbol to
allow providing a custom board init, if the common nucleo board init misses
features.
openocd configuration file for `stm32f7` relies on probing to find out
FLASH_ADDR. On nucleo-f767zi board probing (`flash probe 0`) fails when
`srst` is asserted, but `srst` needs to be asserted to be able to flash
the `BOARD` when sleeping or after a hardfault.
To circumvent this in boards/common/stm32/dist/stm32f7.cfg we define a new
flash bank with the appropriate fash start address and specify that this is
the flash bank to be used as default configuration instead of the
default by setting FLASH_BANK=4
With the new toolchain version required to fix issue #13133, the compilation of `examples/posix_socket` fails due to a C linkage error in `atomic_base.h`. The reason is that including `drivers/include/mtd.h` in `boards/esp32/board_common.h` inside the `extern C` block finally leads to including `atomic_base.h` inside the `extern C` block which in turn to the C linkage error for the template definitions in this file.
GCC now warns when snprintf()ing a buffer that, together with the
format string, might be larger than the destination buffer.
To fix this increase the size of the destination buffer so that
the source buffer and the format string will always fit - 32 bytes
are enough.
`led_init()` is already protected by an `#ifdef`, so no need for
the weak symbol.
The problem is that the weak function does not get overridden, even when
the board provides it's own led_init(), resulting in no LEDs being
initialized.
The setter function approach makes this switchable at runtime (antenna
diversity?).
Documentation is added both to the board introduction page and the
individual pins and functions.
The particle-{argon,boron,xenon} all have a uFL connector and a PCB
antenna for 2.4GHz radio, connected by a SKY13351-378LF switch
configured by a VCTL[12] pin pair.
This sets the default configuration to use the PCB antenna, as driving
an unconnected antenna will deteriorate radio performance.
The 'msba2' common files have accumulated many empty files are files that
do nothing.
This makes reasoning about the boards needlessly difficult.
Trim down on `common/msba2/` so that it now only contains the setup for the
UART/bootloader based flashing.
This should eventuelly be moved to `makefiles/tools/`
- Move serial.inc.mk in remote and openmote-b Makefile.include before
PROG_DEV to avoid repeating OS logic check
- Add deprecation warning for PORT_BSL
This is still currently a hack to hardcode it as the value can be deduced
from the `BOARD_MODULE` daughter board name.
But it requires more cleanup and could come in a separate step.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
The board is deprecated, no need to ignore this board anymore here.
Having the `arduino` and `periph_pwm` features is now required for all
boards using 'arduino-atmega' (as it was except for that board).
If this should change in the future, it should be defined either in each
arduino board, in another board common, or per CPU_MODEL.
This change is for all boards with a sam0 cpu. This cpu just has one ADC.
It is unnecessary to have defines with ADC_0_ prefix as if multiple ADCs
are possible.
Some defines were not used, such as ADC_0_EN, ADC_0_CHANNELS,
ADC_MAX_CHANNELS, ADC_0_CLK_SOURCE, ADC_0_CHANNELS
Change all ADC_0_ prefixes to ADC_
- periph_conf_common.h contains peripherals configuration common to all mkr boards
- periph_conf.h is specific to a subset of mkr boards (mkr1000 and mkrzero)
- Created new `bluepill-128kib` as 128KiB version of the `bluepill`
- Created new `blackpill-128kib` as 128KiB version of the `blackpill`
- Updated `openocd.cfg` to allow flashing 128KiB of ROM
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
* CPU files should already have 'CPU' defined by the board.
* Do not conditionally define CPU as it is not needed.
This is part of cleanup prior to moving the CPU/CPU_MODEL to
Makefile.features.
When flashing some applications the flasher sometimes gets stuck which
prevents flashing after.
It may be from a specific firmware or operation but do not have one yet.
Connect with reset asserted fix flashing from this state.
- Moved compiler & linker flags from boards/common/msba2 to cpu/arm7_common
- Moved dependency to newlib nano to cpu/arm7_common
- Moved config to link in cpu/startup.o to cpu/arm7_common
Enable the handling of flashing `softdevice.hex` when flashing the firmware
for openocd.
However, for flashing, only the `hexfile` and `binfile` can currently be used.
The `elffile` is generated with local pages aligned to `0x10000` which makes
the program starting at `0x1f000` be flashed from `0x10000` with padding bytes
even if the `.text` section is indeed at `0x1f000`:
readelf --sections bin/nrf52dk/gnrc_networking.elf
...
[ 1] .text PROGBITS 0001f000 00f000 00f698 00 AX 0 0 16
...
readelf --segments bin/nrf52dk/gnrc_networking.elf
...
LOAD 0x000000 0x00010000 0x00010000 0x1e6a0 0x1e6a0 R E 0x10000
...
The padding bytes would go through `verify_image` in `openocd` so be expected
to not be overwritten but are by `softdevice.hex`
Using --nmagic at link time removes the local page alignement but would
need dedicated testing.
Use the new OPENOCD_RESET_USE_CONNECT_ASSERT_SRST to configure
'reset_config connect_assert_srst' when flashing and resetting only.
This removes the need for a special debug configuration and should allow
connecting to a running target again.
The boards are using `pyterm` specific options that do not work on any
other `RIOT_TERMINAL`. It is a shame this is required but at least do
not pass arbitrary arguments to the other RIOT_TERMINAL.
So use the new PYTERMFLAGS for this.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
softdevice needs the memory at 0x2000 to be initialized to 0xffffffff
according to #5893 and testing. However, the addresses [0x8bc, 0x3000[ are not
set in softdevice.hex.
So use a modified hex file with all the memory set to 0xff as it is the rom
reset value anyway.
This change updates the `.hex` file instead on relying on erasing the
memory.
When running tests using 'nordic_softdevice_ble', the 'softdevice.hex'
file must also be taken into account for the test hashing and be
uploaded to the separated murdock testing boards.
When listed as dependency from `test-input-hash` the file must have a
target, which he has not. The file is implicitly created when compiling
`ELFFILE` so declare it as order only dependency.
In practice `BASELIBS` could be enough or even `pkg-build-softdevice`
but I do not want to be depend that much on internals there.
- Boards using stm32f103xx use the same custom config for xtimer
which relies on the same underlying hardware timers that hang
when sleeping for <20us so spin when approaching that limit.
A new blue pill variant with only 32 KiB of flash (secretly coming with
64 KiB flash) instead of the use 64 KiB flash (secretly coming with 128 KiB)
is not compatible with `make flash`. This commit changes the OpenOCD config
so that both variants can be flashed.
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).
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.
Moved SPI config from boards/common/nrf52xxxdk/include/periph_config.h to
boards/common/nrf52/include/cfg_spi_default.h. This allows all nRF52 based
boards to use this SPI config if applicable and also allows nRF52*-DK boards
to use custom SPI configs, if needed.
PORT_LINUX and PORT_DARWIN are evaluated by
`makefiles/tools/serial.inc.mk` and some boards Makefile.include.
Their value does not need to be exported.
This also globally removes the line saying that the exports are needed
for flash rule.
Keep the compiled '.bin' file to remove the need to compile it when
flashing. This remove the need to have the toolchain when flashing so
allow compiling and flashing with `BUILD_IN_DOCKER=1` without a local
toolchain.
Even if it ends up storing a binary, the file is only 34 bytes.
MSPDEBUGFLAGS is evaluated only in the same file.
Its value does not need to be exported.
This will also prevent evaluating 'PORT' for MSPDEBUGFLAGS when not needed.
DEBUGGER/DEBUGGER_FLAGS/DEBUGSERVER/DEBUGSERVER_FLAGS are evaluated by the
main Makefile.include or by file included by it.
Their value does not need to be exported.
Testing
-------
`git diff --word-diff` only reports `export` being removed.
`git show --stat` reports `55 insertions(+), 55 deletions(-)`
Which is the same amount as lines that where matching
`export[[:blank::]]\+VARIABLE`.
RESET and RESET_FLAGS are evaluated by the main Makefile.include or by file
included by it. Their value does not need to be exported.
This will also prevent evaluating 'PORT' for RESET_FLAGS when not needed.
Testing
-------
`git diff --word-diff` only reports `export` being removed.
`git show --stat` reports `24 insertions(+), 24 deletions(-)`
Which is the same amount as lines that where matching
`export[[:blank::]]\+VARIABLE`.
FLASHER and FFLAGS are evaluated by the main Makefile.include or by file
included by it. Their value does not need to be exported.
This will also prevent evaluating 'PORT' for FFLAGS when not needed.
Testing
-------
`git diff --word-diff` only reports `export` being removed.
`git show --stat` reports `84 insertions(+), 84 deletions(-)`
Which is the same amount as lines that where matching
`export[[:blank::]]\+VARIABLE`.
The currently supported SAM0 MCUs (samd21, saml21, saml1x) share the same
Timer peripheral, yet each of them carries it's own copy of the Timer
driver.
This introduces a new timer driver that is common for all sam0 MCUs and
uses structs for configuration instead of defines.
UART devices are now configured using static array in header files instead of static variables in implementation to be able to define UART_NUMOF using the size of the array instead of a variable.
SPI devices are now configured using static array in header files instead of static variables in implementation to be able to define SPI_NUMOF using the size of the array instead of a variable.
I2C devices are now configured using static array in header files instead of static variables in implementation to be able to define I2C_NUMOF using the size of the array instead of a variable.
DAC pins are now configured using static arrays in header files instead of static variables in implementation to be able to define DAC_NUMOF using the size of these arrays instead of a variable.
ADC pins are now configured using static arrays in header files instead of static variables in implementation to be able to define ADC_NUMOF using the size of these arrays instead of a variable.
Moving atmega_stdio_init() to cpu_init() just before periph_init() guarantees
that stdio is available to allow DEBUG() in periph_init(). This also helps to
unify the boot up process of ATmega boards and de-duplicates the stdio init from
board_init().
Added file with clock settings for STM32-F7 CPUs with a core clock of 216MHz,
an external high speed clock of 8 MHz and external low speed clock (32.768kHz)
enabled.
Add a rule to build `lpc2k_pgm` when flashing.
It is only compiled if it is using the one in `tools`.
If overwritten to `lpc2k_pgm` if it should be taken from the path,
it is not compiled.
The compilation is still done in `boards/common/msba2/tools` as it was
the case before and this commit does not address this.
Add motor_driver driver configuration example.
The most simple motor driver type is used here (MOTOR_DRIVER_1_DIR) which
needs only one pin to work.
This example uses already configured PWM channels and 2 free GPIOS.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
A common configuration file is introduced for stm32f4 with core clock
at 168MHz with HSE at 8MHz, 2 configuration files are introduced to²:
distinguish between clock configuration with and without LSE.
- Moved code for periph_conf of all ATmega based boards to boards/common/atmega
- Added possibility to override config from individual board:
- Named file `periph_conf_atmega_common.h` and let this be included from
`board/$BOARD/include/periph_conf.h` to allow modifications
- Guarded individual periph configs by `#ifndef $PERIPH_NUMOF` ... `#endif`
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.
This commit add the connect_assert_srst which requires the SRST to be asserted before trying to connect.
Certain firmwares will cause it to get to a state where flashing fails and the reset button must be pushed at the correct time to recover.
- 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.
This adds a LED_PANIC macro which defines which LED,
or combination of LEDs should notify a panic error.
This is currently used to signal BADISR_vect errors.
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
The file always exist so no need to do '-include'.
Replaced using:
sed -i 's|-\(include $(RIOTCPU)/.*/Makefile.features\)|\1|' \
$(git grep -l '$(RIOTCPU)/.*/Makefile.features' boards)
When flashing multiple times the flasher gets stuck.
Default configuration is used that fixes running mulitple tests.
-c 'reset halt' is needed to support debug after config is changed.
For CI HIL purposes a reset is needed before running the test
target. The remote board didn't assign a RESET variable to perform
a reset, so it wasn't possible to call `make test` correctly.
By calling the flash script without arguments, a reset is performed.
iotlab-m3 boards always ended up not being able to flash after time.
This changes managed to fix and flash boards that where able to be flashed with
the deprecated `ft2232` driver and not with the `ftdi` driver used in RIOT.
It combines configuration from openocd, iot-lab, RIOT config and Alexandre
Abadie feedback
* http://repo.or.cz/openocd.git/blob/HEAD:/tcl/interface/ftdi/iotlab-usb.cfg
* ftdi configuration
* https://github.com/iot-lab/iot-lab-gateway/blob/2.4.1/gateway_code/static/iot-lab-m3.cfg
* `trst_and_srst` config
* Alexandre feedback and http://openocd.org/doc/html/Reset-Configuration.html
* 'connect_assert_srst' reset configuration
* it prevents errors in the output on first flash
* should help on boards with invalid code
* It was taken from what Alexandre found for board 'b-l072z-lrwan1'
* It requires using '-c reset halt' instead of '-c halt' before debug
* RIOT
* Keep the `configure -rtos` auto
- Use RIOT's GPIO interface to access the sensor to increase portability
- Changed API to allow more than one sensor per board
- Added `sht1x_params.h` that specifies how the sensors is connected - each
board can overwrite default settings by #defining SHT1X_PARAM_CLK and
SHT1X_PARAM_DATA
- Changed arithmetic to use integer calculations only instead of floating point
arithmetic
- Added support for checking the CRC sum
- Allow optional skipping of the CRC check to speed up measuring
- Added support for advanced features like reducing the resolution and skipping
calibration to speed up measuring
- Allow specifying the supply voltage of sensor which heavily influences the
temperature result (and use that information to calculate the correct
temperature)
- Reset sensor on initialization to bring it in a well known state
- Support for the obscure heater feature. (Can be useful to check the
temperature sensor?)
- Updated old SHT11 shell commands to the new driver interface, thus allowing
more than one SHT10/11/15 sensor to be used
- Added new shell command to allow full configuration of all attached SHT1x
sensors
- Removed old command for setting the SHT11 temperature offset, as this feature
is implemented in the new configuration command
The sensor family SHT10, SHT11 and SHT15 only differ in their accuracy (as in
calibration, not as in resolution). Thus, the same driver can be used for all.
The new driver name better reflects this fact.
