Hi Sebastian, It is *much* easier to poll for PL events in your program, and avoid interrupts if you can. I recommend you think hard about whether you really need an interrupt.
You could avoid using an interrupt by having your program be multithreaded using pthreads, for example, and have one thread check a PL register periodically to see if an event has occurred. So your program's secondary thread has a loop where it sleeps for a certain amount of time, then reads the PL register. If necessary it takes some action based on what it read, and then it sleeps again. This could also be in the main program thread in some cases. This won't work if you have really low latency requirements, because the sleep call would need to be too short, and thus the frequent starting and stopping of the thread would use too much CPU time. In that case, you might be able to get away with a userspace interrupt. Here's a page where someone used this approach: https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt.html I don't know all the options for userspace interrupts, nor do I know their history. You should check them out carefully before you use this approach, to see if there are other similar options, and to make sure they are likely to be around and stable for the next few years. If you really need the ultimate in performance, you'll need to write your own kernel device driver. There you can directly access the interrupts and you clearly have the power to do what you need with them. However, there's a steep learning curve to this. It's been a long time since I've written a kernel driver, and I think it's become more difficult. (Although examples and documentation are better than they used to be.). If you do end up writing a kernel driver, you'll also probably need to add a lot of extra code. The kernel driver won't be able to do things that are easy in userspace, like manipulating files or talking to the network or talking to a user terminal. For that you'll need your userspace program. The kernel driver will need an interface to talk to your program, and your program will need an interface that talks to the kernel driver. So there are a lot of extra things to write. Just debugging it is difficult. I strongly recommend that you poll for the PL event if you can, and avoid using interrupts. It's a lot easier. Regards, Ross On Fri, Jun 19, 2020, 10:13 AM Sebastian Antonio Jorquera Tapia < [email protected]> wrote: > > Hello casperites, > I am thinking to use the pl-ps interruption in order to tell to the ps > that some data is available, but I have no idea how to handle the > interruption in the linux enviroment of the red pitaya.. Should I make a > kernel module to look at the interruption? And if thats true, the > interruption would be located in the proc/irq directory? > > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/a4f105e0-6589-44c5-92de-3b5d102d92d7n%40lists.berkeley.edu > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/a4f105e0-6589-44c5-92de-3b5d102d92d7n%40lists.berkeley.edu?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG4nf72NtFypC7Ly7SnJwvGpOrQAVgO0atr7LNVYaQrT9XM%3Duw%40mail.gmail.com.
