Previously, `UNIT_G` was used for g-force with the correct symbol `g`,
`UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which
would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs`
(which is an uncommon but correct symbol).
To avoid confusion between G-Force, Gauss, and Gram the units have been
renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition,
gram now uses the correct symbol `g` and Gauss uses `G`.
19278: gnrc_dhcpv6_client_simple_pd: select upstream based on type/index r=benpicco a=benpicco
19290: sys/crypto: make AES_KEY struct private & rename it r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
* riot-wrappers:
* Fix infinite loop when using a Mutex
* Make ValueInThread Copy/Clone
* riot-sys:
* Export xxx_DEV (eg. I2C_DEV) C macros as functions
* Add auto_init_utils.h
19142: sock_dtls: move common code into sock_dtls_establish_session() r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19287: boards/esp32s2-lilygo-ttgo-t8: fix STDIO selection in Kconfig r=benpicco a=gschorcht
### Contribution description
This PR fixes the default STDIO selection in Kconfig in case the USB port is connected to the USB to UART bridge which is then used for STDIO (default). It solves the compilation problems in the nightly build.
The PR also includes a very small documentation fix.
### Testing procedure
Green CI.
The compilations that caused problems in nightly build should pass:
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/pkg_tinyusb_cdc_msc -b esp32s2-lilygo-ttgo-t8 -j8
```
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/sys_fido2_ctap/ -b esp32s2-lilygo-ttgo-t8 -j8
```
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/usbus_board_reset/ -b esp32s2-lilygo-ttgo-t8 -j8
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19269: cpu/gd32v/periph_i2c: interrupt based driver r=gschorcht a=gschorcht
### Contribution description
This PR provides an interrupt-driven version of the I2C low-level driver.
The existing I2C low-level driver for GDVF103 uses a busy-waiting approach where the status register is continuously polled while waiting for a certain status when sending or receiving. The MCU is thus occupied the whole time during a send or receive operation.
The driver provided with this PR uses an interrupt-driven approach. This is, while waiting for a certain status when sending or receiving, the calling thread is suspended and woken up by interrupts.
Since the I2C controller allows to receive up to two bytes before the application has to react, receiving a single byte, two bytes or more than two bytes needs a different handling for correct receiption. This requires a tricky implementation which distinguish a number of different case. There the driver requires 860 byte more ROM and 8 byte more RAM.
### Testing procedure
The driver should work with any I2C sensor/actuator. It was tested with
- `tests/driver_bmp180`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
BMP180 test application
+------------Initializing------------+
Initialization successful
+------------Calibration------------+
AC1: 8448
AC2: -1208
AC3: -14907
AC4: 33310
AC5: 24774
AC6: 19213
B1: 6515
B2: 49
MB: -32768
MC: -11786
MD: 2958
+--------Starting Measurements--------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.49
Pressure at see level [hPa]: 1025.55
Altitude [m]: 157
+-------------------------------------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.56
Pressure at see level [hPa]: 1025.58
Altitude [m]: 157
+-------------------------------------+
```
</details>
- `tests/driver_ccs811`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
CCS811 test application
+------------Initializing------------+
+--------Starting Measurements--------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
```
</details>
- `tests/driver_sht3x`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
SHT3X test application
+------------Initializing------------+
Initialization successful
+--------Starting Measurements--------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.50
+-------------------------------------+
Temperature [°C]: 21.47
Relative Humidity [%]: 54.53
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.48
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.47
+-------------------------------------+
```
</details>
- `tests/driver_l3gxxxx`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-375-g75547-cpu/gd32v/periph_i2c_interrupt_driven)
L3GXXXX gyroscope driver test application
Initializing L3GXXXX sensor
[OK]
gyro [dps] x: +0, y: -1, z: -2
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: -1, y: +0, z: +4
gyro [dps] x: +0, y: +0, z: -21
gyro [dps] x: +0, y: +0, z: +6
gyro [dps] x: -43, y: +0, z: -13
gyro [dps] x: -21, y: -2, z: +0
gyro [dps] x: +0, y: +1, z: +3
gyro [dps] x: +25, y: +0, z: +0
```
</details>
- `tests/driver_hd44780` with `pcf8574a` I2C interface
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19027: sys/fmt: optimize scn_u32_dec scn_u32_hex r=benpicco a=kfessel
### Contribution description
Improves the compilation result for `scn_u32_dec` `scn_u32_hex` especially on `cortex-m` reducing either stack usage and or code size.
This makes use of unsigned int overflow (slightly less better without doing that `hexn`).
See godbolt (original versions got an `o` attached, modified versions got `k`s) all functions are marked `_S_` defined to `static`
by assigning the global at end the compiled function can be changed (`deco deck hexo hexk hexkk hexn`)
this PR is `hexkk` and `deck`
### Testing procedure
run unit-test/test-fmt
```
<RIOT>/tests/unittests$ make tests-fmt
<RIOT>/tests/unittests$ make term
```
### Issues/PRs references
[godbolt](https://godbolt.org/z/MzT1zh4q1)
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19284: boards: support for the LILYGO TTGO T8 ESP32-S2 board r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the LILYGO TTGO T8 ESP32-S2 board which has a OLED display (not yet supported) and a SD-Card slot on board.
The board is equipped with a USB-C connector that connects either to a USB-to-UART bridge or to the USB-OTG/JTAG interface of the ESP32-S2 via some DIP switches.
The PR includes a very small fix of printf format string in `tests/malloc`. I can split it off.
### Testing procedure
t.b.d.
### Issues/PRs references
19286: cpu/esp_common: use generic WIFI_SSID/WIFI_PASS defines r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19258: drivers/mtd_flashpage: implement pagewise API, don't use raw addresses r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE
### Contribution description
The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.
### Testing procedure
Any application using MTD in conjunction with a board with an at24cxxx.
19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1
### Contribution description
Hi! 🦎
When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.
### Testing procedure
Before this patch:
Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
#0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
#1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
#2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
#3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
```
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.
Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19272: gcoap: Do not send responses from multicast addresses r=benpicco a=chrysn
### Contribution description
Since https://github.com/RIOT-OS/RIOT/pull/18026, CoAP requests to multicast addresses (eg. `ff02::1`) came back from that exact address, which Linux rightfully just drops.
The fix uses the existing multicast check from https://github.com/RIOT-OS/RIOT/pull/17978 (thanks `@benpicco` for making me write this as dedicated function, I just had to generalize it removing one struct layer), and foregoes setting the source address when responding to multicasts.
### Testing procedure
* Run the gcoap example
* Send a CoAP request to a multicast address RIOT listens to, eg. `./aiocoap-client coap://'[ff02::1%tapbr0]'/.well-known/core --non`
Before, this got no response (while you see it arrive on wireshark). After, you get a correct response with two lines of note:
```
WARNING:coap:Sending request to multicast via unicast request method
Response arrived from different address; base URI is coap://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core
```
(The former is aiocoap telling us that we're not using the nonexistent multicast API so it's really more of an anycast, the latter is useful factual information).
Co-authored-by: chrysn <chrysn@fsfe.org>
