Since https://github.com/RIOT-OS/RIOT/pull/20935 gpio_write()
uses a `bool` instead of an `int`. This does the same treatment for
`gpio_read()`.
This does indeed add an instruction to `gpio_read()` implementations.
However, users caring about an instruction more are better served with
`gpio_ll_read()` anyway. And `gpio_read() == 1` is often seen in
newcomer's code, which would now work as expected.
The API was based on the assumption that GPIO ports are mapped in memory
sanely, so that a `GPIO_PORT(num)` macro would work allow for constant
folding when `num` is known and still be efficient when it is not.
Some MCUs, however, will need a look up tables to efficiently translate
GPIO port numbers to the port's base address. This will prevent the use
of such a `GPIO_PORT(num)` macro in constant initializers.
As a result, we rather provide `GPIO_PORT_0`, `GPIO_PORT_1`, etc. macros
for each GPIO port present (regardless of MCU naming scheme), as well as
`GPIO_PORT_A`, `GPIO_PORT_B`, etc. macros if (and only if) the MCU port
naming scheme uses letters rather than numbers.
These can be defined as macros to the peripheral base address even when
those are randomly mapped into the address space. In addition, a C
function `gpio_port()` replaces the role of the `GPIO_PORT()` and
`gpio_port_num()` the `GPIO_PORT_NUM()` macro. Those functions will
still be implemented as efficient as possible and will allow constant
folding where it was formerly possible. Hence, there is no downside for
MCUs with sane peripheral memory mapping, but it is highly beneficial
for the crazy ones.
There are also two benefits for the non-crazy MCUs:
1. We can now test for valid port numbers with `#ifdef GPIO_PORT_<NUM>`
- This directly benefits the test in `tests/periph/gpio_ll`, which
can now provide a valid GPIO port for each and every board
- Writing to invalid memory mapped I/O addresses was treated as
triggering undefined behavior by the compiler and used as a
optimization opportunity
2. We can now detect at compile time if the naming scheme of the MCU
uses letters or numbers, and produce more user friendly output.
- This is directly applied in the test app
The underlying peripheral can only read from RAM. This uses the
existing infrastructure (already needed to work around the lack of a
hardware support for I2C_NOSTART) to unconditionally copy any to-be-sent
data into RAM.
This commit optimizes the `gpio_conf_t` type in the following
regards:
- The "base" `gpio_conf_t` is stripped from members that only some
platforms support, e.g. drive strength, slew rate, and disabling of
the Schmitt Trigger are no longer universally available but
platform-specific extensions
- The `gpio_conf_t` is now crammed into a bit-field that is 8 bit or
16 bit wide. This allows for storing lots of them e.g. in
`driver_foo_params_t` or `uart_conf_t` etc.
- A `union` of the `struct` with bit-field members and a `bits` is used
to allow accessing all bits in a simple C statement and to ensure
alignment for efficient handling of the type
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
timer_set has no documented restriction on this being not null, other
implementations explicitly tolerate it (rpx0xx checks inside the ISR,
but doing it at init time keeps the ISR slim).
This is useful when using a timer just to read, without any action when
it triggers (the action is taken depending on read values, eg. in a
thread context).
The functions `uart_poweron()`, `uart_poweroff()` and `uart_mode()`
can share code between the UART (UART without EasyDMA) and UARTE
(UART with EasyDMA) implementations, so let's do that.
- nRF51: Use `uart_conf_t` for consistency with nRF52
- nRF52832: Use UARTE (UART with EasyDMA) over UART (without DMA), as
done for all other nRF52 family members
- use `UARTE_PRESENT` to detect whether an UARTE can be used, rather
than family names
19634: tree-wide: mixed box of compilation fixes with clang r=benpicco a=maribu
### Contribution description
As the title says: This should increase the number of apps being able to build with clang quite a bit.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19804: cpu/nrf{53,9160}: add periph_rtt support r=benpicco a=dylad
### Contribution description
This PR enables support for `periph_rtt` on both nRF9160 and nRF53.
This PR is based on #19803
I was only able to test on nrf5340dk-app as I don't have access to any nrf9160-based board.
Here is `test/periph/rtt` output for reference on `nrf5340dk-app`:
### Testing procedure
flash `tests/periph/rtt` on `nrf9160dk` or `nrf5340dk-app` and check the results.
```
s
2023-07-06 16:11:16,471 # START
2023-07-06 16:11:16,479 # main(): This is RIOT! (Version: 2023.07-devel-765-g02c65-cpu/nrf53/add_rtt_support)
2023-07-06 16:11:16,480 #
2023-07-06 16:11:16,482 # RIOT RTT low-level driver test
2023-07-06 16:11:16,483 # RTT configuration:
2023-07-06 16:11:16,485 # RTT_MAX_VALUE: 0x00ffffff
2023-07-06 16:11:16,487 # RTT_FREQUENCY: 1024
2023-07-06 16:11:16,487 #
2023-07-06 16:11:16,494 # Testing the tick conversion (with rounding if RTT_FREQUENCY is not power of 2)
2023-07-06 16:11:16,498 # Trying to convert 1 to seconds and back
2023-07-06 16:11:16,501 # Trying to convert 256 to seconds and back
2023-07-06 16:11:16,505 # Trying to convert 65536 to seconds and back
2023-07-06 16:11:16,509 # Trying to convert 16777216 to seconds and back
2023-07-06 16:11:16,514 # Trying to convert 2147483648 to seconds and back
2023-07-06 16:11:16,514 # All ok
2023-07-06 16:11:16,514 #
2023-07-06 16:11:16,517 # Initializing the RTT driver
2023-07-06 16:11:16,835 # This test will now display 'Hello' every 5 seconds
2023-07-06 16:11:16,835 #
2023-07-06 16:11:16,836 # RTT now: 4
2023-07-06 16:11:16,840 # Setting initial alarm to now + 5 s (5124)
2023-07-06 16:11:16,841 # rtt_get_alarm() PASSED
2023-07-06 16:11:16,846 # Done setting up the RTT, wait for many Hellos
2023-07-06 16:11:16,852 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 404 }]}
2023-07-06 16:11:21,833 # Hello
2023-07-06 16:11:26,831 # Hello
2023-07-06 16:11:31,830 # Hello
2023-07-06 16:11:36,828 # Hello
2023-07-06 16:11:41,826 # Hello
2023-07-06 16:11:46,825 # Hello
2023-07-06 16:11:51,823 # Hello
2023-07-06 16:11:56,821 # Hello
2023-07-06 16:12:01,821 # Hello
2023-07-06 16:12:06,819 # Hello
2023-07-06 16:12:11,817 # Hello
2023-07-06 16:12:16,815 # Hello
2023-07-06 16:12:21,813 # Hello
2023-07-06 16:12:26,811 # Hello
```
### Issues/PRs references
based on #19803
19807: boards/esp32s2-lilygo-ttgo-t8: fix display configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the display configuration for the ESP32-S2 LilyGO TTGO T8 (also known as LilyGo T-Display S2) which uses a ST7789 as display driver IC that is compatible with the ST7735.
For that purpose the ST7735 driver is extended by a pseudomodule definition `st7789` for the ST7789 which is enabled by the board and enables automatically the `st7789` (f57b6b70b8). Vise versa, board's `Makefile.dep` enables automatically the `st7789` pseudomodule if the `st7735` is used. The pseudomodule `st7789` is just used to increase the upper limit for supported lines.
### Testing procedure
```
BOARD=esp32s2-lilygo-ttgo-t8 make -C tests/drivers/st7735/ flash
```
should work:
### Issues/PRs references
19809: cpu/nrf53: add usbdev support r=benpicco a=dylad
### Contribution description
This PR enables `periph_usbdev` support on nRF5340DK-app board. Since the IP is the same as nRF52, the driver and its related data and structs were moved from `cpu/nrf52` to `cpu/nrf5x_common`
### Testing procedure
Test any USBUS related test application on `nrf5340dk-app`
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make BOARD=nrf5340dk-app -C tests/sys/usbus_msc flash`
dmesg output:
```
[ 7466.262760] usb 1-2.1: new full-speed USB device number 16 using xhci_hcd
[ 7466.483916] usb 1-2.1: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[ 7466.483925] usb 1-2.1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 7466.483928] usb 1-2.1: Product: nrf5340dk-app
[ 7466.483931] usb 1-2.1: Manufacturer: RIOT-os.org
[ 7466.483933] usb 1-2.1: SerialNumber: AD0FD4AE806080C2
[ 7466.487010] usb-storage 1-2.1:1.0: USB Mass Storage device detected
[ 7466.487348] scsi host2: usb-storage 1-2.1:1.0
[ 7467.516789] scsi 2:0:0:0: Direct-Access RIOT-OS RIOT_MSC_DISK 1.0 PQ: 0 ANSI: 1
[ 7467.517152] sd 2:0:0:0: Attached scsi generic sg3 type 0
[ 7467.517501] sd 2:0:0:0: [sdd] 64 512-byte logical blocks: (32.8 kB/32.0 KiB)
[ 7467.517732] sd 2:0:0:0: [sdd] Write Protect is off
[ 7467.517733] sd 2:0:0:0: [sdd] Mode Sense: 03 00 00 00
[ 7467.517906] sd 2:0:0:0: [sdd] No Caching mode page found
[ 7467.517910] sd 2:0:0:0: [sdd] Assuming drive cache: write through
[ 7467.532159] sd 2:0:0:0: [sdd] Attached SCSI removable disk
```
I also tested `tests/sys/usbus_cdc_ecm` and `tests/sys/usbus/usbus_hid` succesfully.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The I2C peripheral's shortcuts are used with the read and write register
to automatically stop the I2C transaction or to continue with the next
stage.
With simple I2C read and write bytes these shorts are not used, but are
also not cleared by the function in all cases, causing it to use the
shortcut configuration set by a previous function call. This patch
ensures that the shorts are always set by the read and write functions
This makes life easier when calling e.g. `saul_reg_write()` with data
stored in flash.
As now the signatures for reading and writing differ (in that `const`
qualifier only), `saul_notsup()` is split into `saul_write_notsup()`
and `saul_read_notsup()`. However, one is implemented as a symbol alias
of the other, so that ROM consumption remains unchanged.
Modify the periph_temperature implementation to expose the full
resolution of the temperature sensor. The accuracy of the sensor will
likely be less than 0.25 °C, but typically temperature sensors have
a precision in the order of their resolution. Exposing the full
resolution can therefore be useful to monitor relative temperature
changes.
