callback hook

[Ekkehard]

This isn’t really a new idea, and the old idea wasn’t mine…. But the Python interface gpiod formerly had a hook for a callback functionality. That appears to be gone now. In my mind, device drivers really need that to respond relatively quickly to incoming signals from sensors without bringing the whole application to a squeaking halt while waiting for that signal that may come only the next day (literally) and potentially missing others while doing that. Granted, it isn’t hard to spawn off a thread to do just that, but if most gpiod users need to do it, it might be a good idea to put that callback support back in. It would also keep the changes to code that sits on top of (older versions of) gpiod to a minimum, at least at an architectural level, if that part of the API would be maintained.

What do the maintainers think?

[brgl]

What is the exact problem you're facing? I'd like to help you solve it with the existing API.

[Ekkehard]

Thanks for answering so quickly Bart! At the surface, I want to maintain a very thin abstraction layer between all the different Raspberry Pi (and Raspberry Pi Pico and eventually Jetson Nano) packages and my Python device drivers. So far, all of the lower level Python packages on the RB Pi, each excelling at different things, have offered a callback hook. Having to provide that functionality in my abstraction layer would mean a more substantial change than just changing a few function names around. Of course, it could be done—even with what I would call reasonable effort, especially since with the advent of the RB Pi 5 all the packages I used so far have become obsolete, and my abstraction layer needs an overhaul anyway. But here is my real (slightly simplified) use case so you can assess better why I feel a callback hook would be beneficial in general and IIMHO would make your package more complete: I run an experiment with various sensors that measure physical data on an RB Pi. The RB Pi also runs a Deep Leaning network (i.e. in essence Tensor Flow) to make sense out of the data and then transfer much more abstract and compressed information to another computer via WiFi. When which datum arrives at which sensor hooked up to the RB Pi is not known a priori. I have callback functions for each sensor that handle the handshake with the sensors and stick the incoming data in a buffer for the NN model to take care of whenever a full new set (a new complete feature vector) is complete. So the data may (and usually does) arrive when the model is computing or data are being transferred via WiFi. Running Tensor Flow and even communication via WfFi can tolerate the little time it takes to collect new data from a sensor and stick them in the buffers. I hope that all made some sense to you since I don't know your background. And just so you know: I was REALLY happy to see an effort that uses general Linux libraries to handle GPIO—not just something that runs only on the RB Pi, since I would like to also use an NVIDIA Jetson Nano for more demanding Tensor Flow applications in the future. My abstraction layer can be so much simpler when the RB Pi and the Jetson Nano can use the same lower level Python package. So thanks for taking on this project. You should know that it is highly appreciated! Cheers Ekkehard

…

On Dec 9, 2024, at 01:38, Bartosz Gołaszewski ***@***.***> wrote: What is the exact problem you're facing? I'd like to help you solve it with the existing API. — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWV4UBSCRIKHQCTMALLRUD2EVQJFAVCNFSM6AAAAABTHZUUN6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJQGU4TOMY>. You are receiving this because you authored the thread.

[brgl]

This is all very high-level and we need to agree on the naming convention. What are the "python device drivers" you're referring to exactly? I presume these are some programs that make use of whatever low-level libraries interacting with the hardware to control some components from user-space?

Could you point me to a snipped showing the "callback functions" you're mentioning so that we're on the same page as to what it is that you want to achieve?

In any case: my goal for libgpiod v2 was to make it minimal and very simple. I'm not opposed to making some pure-python, higher-level abstraction though.

[Ekkehard]

OK Bart, I probably should not have called those "device drivers"—I see how, depending on your background, that could be very confusing. Those are, as you suspected, small Python functions (obviously in user space) that interact with GPIO lines to read and write electrical signals to and from mostly custom hardware. Not device drivers in a Nix-sense, which would live in kernel space. So my code does what "regular" device drivers would do functionally, but it is written in Python, resides in user space, and would even sit on top of your package. So in that sense it is far from a regular Linux device driver. Here is a very small example I just snitched off the Interwebs with an older API of gpiod (I think it was later than version 1 though). def interrupt_handler( event ): print( 'Interrupt triggered!' ) return chip = gpiod.Chip( '/dev/gpiochip0' ) # Chip constructor wants full path button_line = chip.get_line( 18 ) # Chip object has no attribute get_line button_line.set_direction( gpiod.LINE_REQ_DIR_IN ) button_line.event_request( edge=gpiod.LINE_EVENT_EDGE_RISING, handler=interrupt_handler ) try: while True: time.sleep( 0.1 ) # Keep the program running except KeyboardInterrupt: print( 'exiting...' ) Here too, naming the function "interrupt_handler" might be a little questionable (albeit this time that naming isn't mine), but I hope the idea is still clear. Obviously, where this code just sleeps, mine would be doing rather elaborate stuff, and instead of just printing a message, my "interrupt_handler" function would be doing some handshaking with the hardware and sticking the new datum into a buffer. Your attempt to keep things simple and clean is certainly appreciated. Also, no hard feelings should you decide to not provide "callback" functionality in v2 and above. I just thought this functionality might accommodate quite a few people, especially those from the "bare metal" (no OS) embedded community (PIC, Arduino, STM32, …) who are used to interrupt-driven GPIO interactions. Cheers Ekkehard

…

On Dec 9, 2024, at 12:52, Bartosz Gołaszewski ***@***.***> wrote: This is all very high-level and we need to agree on the naming convention. What are the "python device drivers" you're referring to exactly? I presume these are some programs that make use of whatever low-level libraries interacting with the hardware to control some components from user-space? Could you point me to a snipped showing the "callback functions" you're mentioning so that we're on the same page as to what it is that you want to achieve? In any case: my goal for libgpiod v2 was to make it minimal and very simple. I'm not opposed to making some pure-python, higher-level abstraction though. — Reply to this email directly, view it on GitHub <#118 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWV4UGZ2HEVTRNKTGD6H7L2EX7JLAVCNFSM6AAAAABTHZUUN6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJRGMYDAOI>. You are receiving this because you authored the thread.

[brgl]

The existing code exposes the file descriptor numbers for both Chip and LineRequest which is much more versatile IMO. You can use whatever polling mechanism of choice instead of a rather rigid callback interface.

In general: callbacks make sense if they are part of a larger framework that forms the base of your program. Think GObject and its event loop. I don' think it makes much sense for libgpiod and especially its python bindings.

[Ekkehard]

Thanks Bart, of course, I respect your viewpoint even though I don't share it. With this choice, every user of your package needs to learn a lot more about the inner workings of libgpiod than they ever wanted to. But your package, your call. As I said, I personally can live with it, as long as the API stays table from now on. Thanks for looking into it Ekkehard

…

On Dec 10, 2024, at 04:55, Bartosz Gołaszewski ***@***.***> wrote: The existing code exposes the file descriptor numbers for both Chip and LineRequest which is much more versatile IMO. You can use whatever polling mechanism of choice instead of a rather rigid callback interface. In general: callbacks make sense if they are part of a larger framework that forms the base of your program. Think GObject and its event loop. I don' think it makes much sense for libgpiod and especially its python bindings. — Reply to this email directly, view it on GitHub <#118 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWV4UDRLS5QDZPETZMYAY32E3QFVAVCNFSM6AAAAABTHZUUN6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJSGA3TGMA>. You are receiving this because you authored the thread.