Chris Johns commented on a discussion on cpukit/include/dev/gpio/gpio.h: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159817

 > + *
 > + * The pin must already be configured with a trigger other than
 > + * #RTEMS_GPIO_TRIGGER_NONE.
 > + *
 > + * @param fd is the descriptor for the controller's device node.
 > + *
 > + * @param pin is the logical pin whose interrupt to deliver.
 > + *
 > + * @param handler is the handler to call.
 > + *
 > + * @param arg is the argument to pass to the handler.
 > + *
 > + * @retval 0 Successful operation.
 > + * @retval -1 An error occurred.  The errno is set to indicate the error.
 > + */
 > +int rtems_gpio_pin_irq_enable(int fd, uint32_t pin,

Is an interrupt API for GPIO pins the same as a GPIO API that support 
interrupts on a pin?

This API is an abstraction to control IO by applications. It is not attempting 
to be a way to wrap GPIO pads for use in a BSP or other drivers. That should be 
handled within a BSP. I see the interrupt support with this API being a way for 
an application to synchronize to an edge or level transition on a GPIO pin.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159817
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-83p4vyksugrrzq9u6gf7pr9ck-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

Reply via email to