Christian Mauderer commented on a discussion on cpukit/include/dev/gpio/gpio.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159823 > + * > + * 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, Maybe I'm a bit biased because my applications are usually quite low level. But at least in my experience, it's not that uncommon that an application adds additional peripherals to some base BSP. In that case, a user wants to write drivers for these peripherals. And for these, it's useful to have an interrupt-like API so you don't have to write the drivers with a completely different approach than you would write other drivers. And I think that leads back to the original question in the thread: I think an interrupt API like suggested in the MR is quite useful. I would only suggest allowing to add multiple handlers instead of just one. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159823 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-ahgood8ly4i3hoxt50yhivgey-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
