GPIO

[epernia]

Traigo la discusión de los mails:

Martín:

La semantinca gpioConfig( 0, GPIO_ENABLE ); es totalmente obscura, no seria mejor hacer otra funcion que se llame gpioInit o algo asi?

si hay que hacer una inicializacion, a mi lo que se me ocurre es pasarle un array con los:

typedef struct {
    uint16_t port_id;
    uint16_t flags;
} gpio_init_t;

#define GPIO_END_CONFIG  { 0, 0 }
#define GPIO_CONFIG(...) ((const gpio_init_t[])({ __VA_ARGS__ }))

void GPIO_Config(const gpio_init_t *gpio) {

 static int is_init = 0;

 int i;

    if (!is_init)
        init_gpio(GPIO);

    for(i=0; gpio[i].flags; i++)
       config_gpio(gpio[i].por_id, gpio[i].flags);
}
void main () {
    do_noting(GPIO_CONFIG(
        { GPIO8, GPIO_IN  | GPIO_PULL_UP | GPIO_FAST },
        { GPIO7, GPIO_OUT | GPIO_PULL_UP | GPIO_OC },
        { GPIO6, GPIO_IN  | GPIO_PULL_UP | GPIO_FAST },
        { GPIO3, GPIO_OUT | GPIO_PULL_DOWN | GPIO_OC },
        GPIO_END_CONFIG
    ));

    ...
}

Particularmente en los LPC de NXP GPIO_Init NO HACE NADA DE NADA.... en otros micros habilita el clock, pero eso es facil de manejar simplemente mirando que ese clock este activado y listo. Recomiendo fuertemente mirarnos como es la capa de abstracción de MBED-os:

Recomiendo fuertemente mirarnos como es la capa de abstracción de MBED-os:

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NXP/TARGET_LPC43XX/gpio_api.c#L33

Y en las que los GPIO requiere inicializacion:

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32F7/gpio_api.c#L45

En cualquier caso, fijate que en todos los proyectos, hay diez lineas minimo, efectivas a inicializar el hardware, cosa que debe hacer (y hace) Board_Init en lpcopen o su equivalente en cualquier plataforma.

Creo que es mas didactico, que main empiece con todo el hardware funcional, y en todo caso, se vayan cambiando las configuraciones de cada cosa a requerimiento.

Concuerdo en que, una vez inicializada la placa, pueda cambiarse puntualmente las configuraciones de los pines en el sentido de hacer:

gpioConfig(GPIO3, GPIO_INPUT | GPIO_PULLUP);

Codigo dependiente de la plataforma

Deberiamos evitar TOTALMENTE codigo que haga referencia a cualquier cosa particular de la arquitectura.

Cosas como esta de GPIO_INPUT_PULLUP_PULLDOWN no pintan nada ahi, es algo muy particular de ESTE micro que posiblemente futuras versiones no tengan y que obviamente, otros micros ni siquiera las implementan.

Volviendo al tema de los GPIO, tomense el tiempo de mirar esto:

https://github.com/ARMmbed/mbed-os/blob/master/hal/gpio_api.h

Que es el HAL en C plano de las librerias mbed. Es, creo yo, la mejor guía para seguir en nuestra API y tiene todo lo que comento mas arriba solucionado aunque esta orientado fuertemente a usarse dentro de clases C++ y por eso no la usaria de forma calcada.

Mi propiesta para sAPI/GPIO:

https://gist.github.com/martinribelotta/646592b5c10b66cdeccd1baa1b32c04f

Por supuesto es pulibre, y por eso escribo esto antes de hacer nada, para que me digan que opinan y que ven que se me escapa.

El OR es una opción a las multiples funciones porque permite hacer cosas como:

gpioConfig(GPIO_NAME, GPIO_INPUT);

O mas complejas como:

gpioConfig(GPIO_NAME, GPIO_INPUT | GPIO_OPENCOLLECTOR | GPIO_PULLUP);

Que tendria sentido en algunas arquitecturas y en otras no, pero al menos seria compilable en todas y produciria resultados en todas.

Eric:
Esto no me queda claro aún cómo conviene resolverlo, pero salvo los GPIO está bueno poder apagar y encender periféricos para consumir menos. Inclusive según el micro recomiendan los GPIOs no usados ponerlos en tal configuración para que consuma menos, así que esa podría ser nuestra disable u off.

Martín:
Yo creo que es un parametro mas, fijate que GPIO en algunos perifericos se puede apagar y se apagan, y otros no (STM32 arrancan apagados y LPCXXXX estan conectados al AHBLite y siempre estan prendidos)

[epernia]

@martinribelotta: Modifiqué sapi_gpio.h y .c (ver en rama develop). En particular me gustaría que mires el sapi_gpio.h a ver si estás de acuerdo como quedó, faltaría aplicarle bien esto de INLINE pero no me quedó en claro como hacerlo.

El sapi_gpio.c es más o menos lo que ya había, modificado para que funcione. La idea es que:

También me falta aplicarle comentarios doxygen.

La idea es que GPIO sea como está en este documento:

https://github.com/ciaa/firmware_v2/blob/develop/modules/sapi/documentation/docs/physical-ip-cores.md