Chris Johns commented on a discussion on cpukit/include/dev/gpio/gpio.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159819 > + * > + * What a pin reads as before rtems_gpio_pin_configure() is called on it, > + * and what it returns to after rtems_gpio_pin_release(). > + */ > + RTEMS_GPIO_DIRECTION_NONE = 0, > + > + /** > + * @brief This enumerator indicates that the pin is an input. > + */ > + RTEMS_GPIO_DIRECTION_INPUT, > + > + /** > + * @brief This enumerator indicates that the pin is an output. > + */ > + RTEMS_GPIO_DIRECTION_OUTPUT > +} rtems_gpio_direction; The BSP manages the initialization and default state for the hardware. The hardware will be in a state either by reset or BSP initialization so this state only about the API control. I suspect an app that configures and so enables a pin then disables it will already be holding state information about the pin or does not care. Note, this API is not about the BSP level initialization and set up of the GPIO hardware. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159819 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-b6k5bvjvxrvi3qroqonjumjt5-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
