The TMP006 driver has been renamed to TMP00x, as it (now) supports both
TMP006 and TMP007 infrared thermopile sensors. However, the board
configuration was never updated to match the new names. This fixes the
issue.
19014: boards/qn9080dk: add TTY_BOARD_FILTER r=kaspar030 a=maribu
### Contribution description
With `MOST_RECENT_PORT=1` the TTY interface of the most recently connected board with an embedded NXP debugger is selected. If only a single board with an embedded NXP debugger is selected, this will automatically connect to the correct board using:
```
make term MOST_RECENT_PORT=1
```
### Testing procedure
Run `make term MOST_RECENT_PORT=1` with a qn9080dk board and some non-NXP boards attached. It should reliably select the qn9080dk regardless of TTY names and order they were connected.
### Issues/PRs references
None
19094: dist/tools/doccheck: Reduce noise r=benpicco a=maribu
### Contribution description
This adds central documentation of driver initialization parameters in `driver/foo/include/foo_params.h` where missing for drivers used by the Hamilton board. In addition, the macros to overwrite the default parameters are no longer expected to be documented by adding generic exclude patterns. The reasoning is that having the macros documented once is sufficient.
### Testing procedure
Static tests should pass
### Issues/PRs references
Required to get https://github.com/RIOT-OS/RIOT/pull/19090 in
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
17919: board/microbit: increase testtimeout for emulated testing r=benpicco a=kfessel
### Contribution description
this increases the timeout for tests run by murdock on emulated microbit (accounting for startup of qemu)
### Testing procedure
murdock
### Issues/PRs references
#17894
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19037: sys/usb, pkg/tinyusb: move USB board reset from highlevel STDIO to CDC ACM r=dylad a=gschorcht
### Contribution description
The USB board reset function `usb_board_reset_coding_cb` can be used on any CDC-ACM interface, even if the CDC ACM interface is not used as high-level STDIO. Therefore, this PR provides the following changes:
- The call of the board reset function `usb_board_reset_coding_cb` from USBUS stack has been moved from the STDIO CDC ACM implementation to the CDC ACM implementation and is thus a feature of any USBUS CDC ACM interface which does not necessarily have to be used as highlevel STDIO.
- The call of the board reset function `usb_board_reset_coding_cb` from tinyUSB stack been moved from module `tinyusb_stdio_cdc_acm` to module `tinyusb_contrib` and is compiled in if the `tinyusb_class_cdc` module is used together the `tinyusb_device` module. Thus, it is now a feature of the tinyUSB CDC ACM interface, which does not necessarily have to be used as highlevel STDIO.
- The `usb_board_reset` module defines the `usb_board_reset_in_bootloader` function as a weak symbol to be used when reset in bootloader if no real implementation of this function is compiled in and the `riotboot_reset` module is not used. It only prints an error message that the reset in bootloader is not supported. This is necessary if the module `usb_board_reset` is used to be able to restart the board with an application via a USB CDC ACM interface, but the board's bootloader does not support the reset in bootloader feature.
- A test application has been added that either uses the highlevel STDIO `stdio_acm_cdc` or creates a CDC-ACM interface to enable board resets via USB. If the `usbus_dfu` module is used, it also initializes the DFU interface to be able to work together with the `riotboot_dfu` bootloader.
### Testing procedure
1. Use a board with a bootloader that supports the reset in bootloader via USB, but don't use the highlevel STDIO to check that it works with `usbus_cdc_acm`, for example:
```python
USEMODULE=stdio_uart BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
After reset in application with command
```python
stty -F /dev/ttyACM0 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with RIOT's test VID/PID:
```python
dmesg
[1745182.057403] usb 1-4.1.2: new full-speed USB device number 69 using xhci_hcd
[1745182.160386] usb 1-4.1.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[1745182.160390] usb 1-4.1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[1745182.160392] usb 1-4.1.2: Product: arduino-mkr1000
[1745182.160393] usb 1-4.1.2: Manufacturer: RIOT-os.org
[1745182.160395] usb 1-4.1.2: SerialNumber: 6B6C2CA5229020D8
[1745182.170982] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
After reset in bootloader with command
```python
stty -F /dev/ttyACM0 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with vendor VID/PID:
```python
[1746220.443792] usb 1-4.1.2: new full-speed USB device number 70 using xhci_hcd
[1746220.544705] usb 1-4.1.2: New USB device found, idVendor=2341, idProduct=024e, bcdDevice= 2.00
[1746220.544708] usb 1-4.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1746220.553471] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
2. Test the same as in 1., but this time use the highlevel STDIO to check that there is no regression and it still works with `stdio_cdc_acm`, for example:
```python
BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
3. Use a board that supports `riotboot_dfu` but doesn't use the highlevel STDIO and flash the `riotboot_dfu` bootloader, for example:
```python
BOARD=stm32f429i-disc1 make -C bootloaders/riotboot_dfu flash term
```
Once the bootloader is flashed, command `dfu-util --list` should give something like the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="6591620BCB270283"
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="6591620BCB270283"
```
If the output gives only
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
an application is already running in DFU Runtime mode. Use `dfu-util -e` to restart it in bootloader DFU mode.
Then flash the test application, for example:
```python
FEATURES_REQUIRED=riotboot USEMODULE='usbus_dfu riotboot_reset' \
BOARD=stm32f429i-disc1 make -C tests/usbus_board_reset PROGRAMMER=dfu-util riotboot/flash-slot0
```
Once the test application is flashed, command `dfu-util --list` should give:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
Now, use command
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in application. Command `dfu-util --list` should give again the following:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
That is, the application is running in DFU Runtime mode. Then use command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in bootloader DFU mode. Command `dfu-util --list` should now give the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="7D156425A950A8EB"
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="7D156425A950A8EB"
```
That is, the bootloader is in DFU mode and another application can be flash.
4. After a hard reset of the board under 3., try the commands `reboot` and `bootloader`.
5. To check the same for tinyUSB, use the existing tinyUSB application with a CDC ACM interface and add module `usb_board_reset`, for example:
```python
USEMODULE=usb_board_reset BOARD=stm32f429i-disc1 make -C tests/pkg_tinyusb_cdc_msc flash term
```
After flashing, it should be possible to restart the application with command:
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
When using command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
the following error message should be shown in terminal
```python
[cdc-acm] reset in bootloader is not supported
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18756: drivers/usbdev_synopsys_dwc2: add EFM32 support r=chrysn a=gschorcht
### Contribution description
This PR provides the changes for the Synopsys USB OTG IP core DWC2 driver for EFM32 MCUs. It also provides the changes of the board definition for `stk3600` and `stk3700` for testing.
### Testing procedure
`tests/usbus_hid` should work on the EFM32 boards `stk3600` (EFM32LG family) and `stk3700` (EFM32GG family).
It is already tested for a `sltb009a` board (EFM32GG12 family).
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19023: pkg/tinyusb: fix Kconfig problems r=maribu a=gschorcht
### Contribution description
This PR tries to fix the [problems with `tinyUSB` in nightlies](https://ci.riot-os.org/details/d11b383ba0cd45048ed6f8d98abbc0de).
- The `tinyusb_device` feature had to be moved from `boards/common/arduino-zero` definition to the `boards/arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
- The `tinyusb_device` feature had to be removed from Kconfig of board `stm32f429i-disco` since it uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19012: boards/arduino-mega2560: add TTY_BOARD_FILTER r=gschorcht a=maribu
### Contribution description
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
### Testing procedure
```
make BOARD=arduino-mega2560 MOST_RECENT_PORT=1 -C examples/default flash term
```
Should automatically select the TTY of the most recently connected Arduino Mega2560, even if a board of a different type is connect more recently.
### Issues/PRs references
- [x] depends on (and includes) https://github.com/RIOT-OS/RIOT/pull/19011
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
Note: Unless `ARDUINO_MEGA2560_COMPAT_WITH_CLONES` is set to `0`,
this will fall back to detecting any cheap USB UART bridge typically
found in Arduino Mega 2560 clones if no genuine Arduino Mega is found.
The `tinyusb_device` feature introduced with PR #18689 has to be moved from `common/arduino-zero` definition to the `arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses `highlevel_stdio` feature via the `stdio_cdc_acm` module.
With `MOST_RECENT_PORT=1` the TTY interface of the most recently
connected board with an embedded NXP debugger is selected. If only
a single board with an embedded NXP debugger is selected, this will
automatically connect to the correct board using:
```
make term MOST_RECENT_PORT=1
```
weact-f4xcx boards have only a single USB-C connector that is used for `highlevel_stdio` via USBUS CDC ACM so that it conflicts with tinyUSB for the moment.
The `channels` member should not be set to the number of hardware
channels *n*, but to *n* - 1 instead. The last channel is implicitly
used in `timer_read()`. Hence out of *n* hardware channels, only *n* - 1
are available to the application.
This fixes a bug introduced by 4d02e15247
which incorrectly set the channel number to *n* rather than to
*n* - 1.
- All nRF52 timers support 32 bit mode, so use that
- All nRF52 timers support at least 4 channels, the timers NRF_TIMER3
and NRF_TIMER4 even support 6 channels.
- Add a warning that `TIMER_DEV(1)` is used by the IEEE 802.15.4 driver
The peripheral configuration has been completely reworked to resolve
pin conflicts while provided as much of the peripherals as possible.
The changes include:
- Move `I2C_DEV(0)` from PB6/PB7 to PB8/PB9 to solve pin conflict with
`QDEC_DEV(2)`.
- Use pins PB0, PB1, PB4, and PB5 for PWM instead PA8, PA9, PA10, and
PA11
- PA9 and PA10 is in pin conflict with `UART_DEV(0)` which is used
for stdio with `stdio_uart`, PA8 was in conflict with
`QDEC_DEV(0)`, PA11 was in conflict with USB D-
- Use PB6, PB7 as `QDEC_DEV(0)` (previously `QDEC_DEV(2)`), as this is
the only completely conflict free setting
- Use PB4/PB5 instead of PA6/PA7 for QDEC_DEV(1)
- This fixes a pin conflict with `SPI_DEV(0)` MISO (and
`ADC_LINE(4)`)
- Only provide QDEC at PB4/PB5 when PWM is not used to avoid conflict
- Only provide QDEC at PA8/PA9 when UART is not used to avoid conflict
- Use SPI2 (PB15, PB14, PB13, PB12) as `SPI_DEV(0)` instead of SPI1,
use SPI1 (PA7, PA6, PA5, PA4) as `SPI_DEV(1)`
- Only provide `SPI_DEV(1)` if the ADC is not in used to resolve a
pin conflict
- Move PB0 and PB1 at the end of the ADC lines (previously
`ADC_LINE(6)` and `ADC_LINE(7)`, now `ADC_LINE(8)` and `ADC_LINE(9)`)
- Only provide them when PWM is not in use (to resolve pin conflict
with PWM)
- Also do not provide them for the Blackpill boards, which are
missing pins PB0 and PB1 on the headers
To make life of users easier, a Pinout diagram with the new
configuration was added.
Nightlies are failing due to kconfig mismatch.
It would seem this is a result of bringing in the USB stuff.
I assume that this uses ztimer periph_timer as a backend as periph_timer is already selected.
However, kconfig only resolves one and not recursively making it hard to match.
For not a hack is added to override for these boards.
The `fs` in the file name means that on-chip FS PHY is configured for USB OTG HS. The file is renamed to `cfg_usb_otg_hs_phy_fs.h`
- to clarify that USB OTG HS is just configured with PHY FS and not HS and FS,
- to allow a configuration of USB OTG FS and HS in one file called `cfg_usb_otg_hs_fs.h` or whatever, and
- to allow a configuration of USB OTG HS with ULPI PHY in a file called `cfg_usb_otg_hs_phy_ulpi.h`.
f
LED LD1 has no special function on the board STM32F746-DISCO and therefore can be used freely. This LED is also defined as ARDUINO LED pin D13 in the schematic.
The board definition of the `nrf52dk` was likely created for some clone
board. However, an official board name nRF52 DK provided by Nordic
also exists. This resulted in previous contributors in confusing this
with the official board and "fixing" the board definition to match
the nRF52 DK board.
Or maybe it always has been meant to be the official board and someone
just added a wrong image to it.
In either case, this brings the documentation back in alignment with
the code by replacing references to some random clone board and the
image of the random clone board with those to/of the official Nordic
nRF52 DK board.
Due to the lack of new official avr-libc releases (which includes the
vendor header files needed to support different version of MCUs),
support for new MCUs was lacking. Distributions such as Debian addressed
this by extending the upstream code with vendor header files directly
obtained from Atmel / Microchip, but without paying attention to
details. As such, a naming inconsistency (ASIZE vs ASPACE) between
officially supported MCUs and new MCUs was introduced.
Now that avr-libc 2.1.0 is officially released, hardware support for new
MCUs is provided by upstream out of the box and only ASIZE is used as
name. This commit adds a bit of glue code to create aliases for ASIZE on
older avr-libc versions where needed. This fixes compilation with the
new avr-libc release and results in more consistent code.
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
The inverted and non-inverted `LED<num>_ON` and `LED<num>_OFF` macros
are swapped. This didn't reveal in testing as the
`LED<num>_IS_INVERTED` macros where not properly evaluated, due to a
typo in the check. This fixes both.
Using the common STM32 board makefile provides all supported
programmers for STM32 boards. This allows e.g. to flash with
stm32flash via `make BOARD=im880b PROGRAMMER=stm32flash flash`.
Using `UART_DEV(0)` (UASRT1) for stdio allows to use the same TTL
adapter that is used for programming via `stm32flash` to be used for
serial, without re-wiring after flashing.
Let boards only define the port and pin number of each LEDs. The common
definitions in `stm32_leds.h` will provide `LED<x>_ON`, `LED<x>_OFF`,
`LED<x>_TOGGLE`, `LED<x>_PIN`, `LED<x>_MASK` and `LED<x>_PORT`.
In addition to code de-duplication, this also makes it easier to use
LEDs in GPIO LL, which can be beneficial for super low overhead
debugging output - e.g. when a bug is timing sensitive and `DEBUG()`
would spent to much time for stdio to reproduce a bug.
This is a verbatim copy of the PWM config of `boards/nucleo-f746zg`.
However, those boards are almost identical. I successfully tested
the configuration via https://github.com/RIOT-OS/RIOT/pull/18392
The former FLASH_MODE_{DOUT,DIO,QOUT,QIO} defines are replaced by the corresponding CONFIG_FLASHMODE_{DOUT,DIO,QOUT,QIO} and CONFIG_ESPTOOLPY_FLASHMODE_{DOUT,DIO,QOUT,QIO} as used by the ESP-IDF. This is also needed for the migration of defining flash mode in Kconfig.
In the board definition of `esp32_wrover_kit` default values for `ESP_WIFI_EAP_USER` and `ESP_WIFI_EAP_PASS` had to be defined because this board was used in the CI to compile the optional module `esp_wifi_enterprise`. Now that the CI compilation for the `esp_wifi_enterprise` module is realized by an external board definition `esp32-ci`, these default values should be removed to make the compilation fail if the user did not define these variables.
We can't use PB13/PB12 which would be the 'standard' UART pins on
the -xpro EXT connectors since only SERCOM4 can map to those - and
that's already used on EXT1.
So use the adjacent PA08/PA09 with SERCOM0.
Only default to uniflash as default programmer if UNIFLASH_PATH is
set. If this isn't the case, `make flash` fails complaining about
missing `UNIFLASH_PATH` anyway.
