2021-08-27 22:59:43 +02:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Freie Universität Berlin
|
|
|
|
* 2017 OTA keys S.A.
|
|
|
|
*
|
|
|
|
* This file is subject to the terms and conditions of the GNU Lesser
|
|
|
|
* General Public License v2.1. See the file LICENSE in the top level
|
|
|
|
* directory for more details.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @ingroup cpu_stm32
|
|
|
|
* @ingroup drivers_periph_gpio_ll
|
|
|
|
* @{
|
|
|
|
*
|
|
|
|
* @file
|
|
|
|
* @brief CPU specific part of the Peripheral GPIO Low-Level API
|
|
|
|
*
|
|
|
|
* @author Hauke Petersen <hauke.petersen@fu-berlin.de>
|
|
|
|
* @author Vincent Dupont <vincent@otakeys.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef GPIO_LL_ARCH_H
|
|
|
|
#define GPIO_LL_ARCH_H
|
|
|
|
|
|
|
|
#include "architecture.h"
|
|
|
|
#include "periph_cpu.h"
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef DOXYGEN /* hide implementation specific details from Doxygen */
|
|
|
|
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
#define GPIO_PORT_NUMBERING_ALPHABETIC 1
|
|
|
|
|
|
|
|
#ifdef GPIOA_BASE
|
|
|
|
# define GPIO_PORT_0 GPIOA_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOB_BASE
|
|
|
|
# define GPIO_PORT_1 GPIOB_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOC_BASE
|
|
|
|
# define GPIO_PORT_2 GPIOC_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOD_BASE
|
|
|
|
# define GPIO_PORT_3 GPIOD_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOE_BASE
|
|
|
|
# define GPIO_PORT_4 GPIOE_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOF_BASE
|
|
|
|
# define GPIO_PORT_5 GPIOF_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOG_BASE
|
|
|
|
# define GPIO_PORT_6 GPIOG_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOH_BASE
|
|
|
|
# define GPIO_PORT_7 GPIOH_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOI_BASE
|
|
|
|
# define GPIO_PORT_8 GPIOI_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOJ_BASE
|
|
|
|
# define GPIO_PORT_9 GPIOJ_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef GPIOK_BASE
|
|
|
|
# define GPIO_PORT_10 GPIOK_BASE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static inline gpio_port_t gpio_port(uword_t num)
|
|
|
|
{
|
2021-08-27 22:59:43 +02:00
|
|
|
#if defined(CPU_FAM_STM32MP1)
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
return GPIOA_BASE + (num << 12);
|
2021-08-27 22:59:43 +02:00
|
|
|
#else
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
return GPIOA_BASE + (num << 10);
|
2021-08-27 22:59:43 +02:00
|
|
|
#endif
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
}
|
2021-08-27 22:59:43 +02:00
|
|
|
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
static inline uword_t gpio_port_num(gpio_port_t port)
|
|
|
|
{
|
2021-08-27 22:59:43 +02:00
|
|
|
#if defined(CPU_FAM_STM32MP1)
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
return (port - GPIOA_BASE) >> 12;
|
2021-08-27 22:59:43 +02:00
|
|
|
#else
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
return (port - GPIOA_BASE) >> 10;
|
2021-08-27 22:59:43 +02:00
|
|
|
#endif
|
drivers/periph_gpio_ll: change API to access GPIO ports
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
2024-04-29 13:32:24 +02:00
|
|
|
}
|
2021-08-27 22:59:43 +02:00
|
|
|
|
|
|
|
static inline uword_t gpio_ll_read(gpio_port_t port)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
return p->IDR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uword_t gpio_ll_read_output(gpio_port_t port)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
return p->ODR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_set(gpio_port_t port, uword_t mask)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
p->BSRR = mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_clear(gpio_port_t port, uword_t mask)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
2023-03-17 14:34:44 +01:00
|
|
|
/* The STM32F4 vendor header files do include defines for accessing the
|
|
|
|
* BRR register, but do not have a BRR register.
|
|
|
|
* See https://github.com/STMicroelectronics/cmsis_device_f4/pull/7 */
|
|
|
|
#if defined(GPIO_BRR_BR0) && !defined(CPU_FAM_STM32F4)
|
|
|
|
p->BRR = mask;
|
|
|
|
#else
|
2023-05-25 23:04:38 +02:00
|
|
|
/* The first half-word sets GPIOs, the second half-world clears GPIOs */
|
|
|
|
volatile uint16_t *brr = (volatile uint16_t *)&(p->BSRR);
|
|
|
|
brr[1] = (uint16_t)mask;
|
2023-03-17 14:34:44 +01:00
|
|
|
#endif
|
2021-08-27 22:59:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_toggle(gpio_port_t port, uword_t mask)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
unsigned irq_state = irq_disable();
|
|
|
|
p->ODR ^= mask;
|
|
|
|
irq_restore(irq_state);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_write(gpio_port_t port, uword_t value)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
p->ODR = value;
|
|
|
|
}
|
|
|
|
|
2024-08-02 19:57:36 +02:00
|
|
|
#ifdef MODULE_PERIPH_GPIO_LL_SWITCH_DIR
|
|
|
|
static inline uword_t gpio_ll_prepare_switch_dir(uword_t mask)
|
|
|
|
{
|
|
|
|
/* implementation too large to always inline */
|
|
|
|
extern uword_t gpio_ll_prepare_switch_dir_impl(uword_t mask);
|
|
|
|
return gpio_ll_prepare_switch_dir_impl(mask);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_switch_dir_output(gpio_port_t port, uword_t pins)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
unsigned irq_state = irq_disable();
|
|
|
|
p->MODER |= pins;
|
|
|
|
irq_restore(irq_state);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_ll_switch_dir_input(gpio_port_t port, uword_t pins)
|
|
|
|
{
|
|
|
|
GPIO_TypeDef *p = (GPIO_TypeDef *)port;
|
|
|
|
unsigned irq_state = irq_disable();
|
|
|
|
p->MODER &= ~pins;
|
|
|
|
irq_restore(irq_state);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2021-08-27 22:59:43 +02:00
|
|
|
static inline gpio_port_t gpio_get_port(gpio_t pin)
|
|
|
|
{
|
|
|
|
return pin & 0xfffffff0LU;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint8_t gpio_get_pin_num(gpio_t pin)
|
|
|
|
{
|
|
|
|
return pin & 0xfLU;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline gpio_port_t gpio_port_pack_addr(void *addr)
|
|
|
|
{
|
|
|
|
return (gpio_port_t)addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void * gpio_port_unpack_addr(gpio_port_t port)
|
|
|
|
{
|
|
|
|
if (port < GPIOA_BASE) {
|
|
|
|
return (void *)port;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool is_gpio_port_num_valid(uint_fast8_t num)
|
|
|
|
{
|
|
|
|
switch (num) {
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
#ifdef GPIOA_BASE
|
|
|
|
case 0:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOB_BASE
|
|
|
|
case 1:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOC_BASE
|
|
|
|
case 2:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOD_BASE
|
|
|
|
case 3:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOE_BASE
|
|
|
|
case 4:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOF_BASE
|
|
|
|
case 5:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOG_BASE
|
|
|
|
case 6:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOH_BASE
|
|
|
|
case 7:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOI_BASE
|
|
|
|
case 8:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOJ_BASE
|
|
|
|
case 9:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOK_BASE
|
|
|
|
case 10:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOL_BASE
|
|
|
|
case 11:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOM_BASE
|
|
|
|
case 12:
|
|
|
|
#endif
|
|
|
|
#ifdef GPION_BASE
|
|
|
|
case 13:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOO_BASE
|
|
|
|
case 14:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOP_BASE
|
|
|
|
case 15:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOQ_BASE
|
|
|
|
case 16:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOR_BASE
|
|
|
|
case 17:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOS_BASE
|
|
|
|
case 18:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOT_BASE
|
|
|
|
case 19:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOU_BASE
|
|
|
|
case 20:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOV_BASE
|
|
|
|
case 21:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOW_BASE
|
|
|
|
case 22:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOX_BASE
|
|
|
|
case 23:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOY_BASE
|
|
|
|
case 24:
|
|
|
|
#endif
|
|
|
|
#ifdef GPIOZ_BASE
|
|
|
|
case 25:
|
|
|
|
#endif
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* DOXYGEN */
|
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* GPIO_LL_ARCH_H */
|
|
|
|
/** @} */
|