Hi ross thanks for the response, I had the hope that is not necessary to build the dev driver :( Moreover I think I found a possible workaround, https://www.youtube.com/watch?v=XJbEn_-hjYc This video shows how to program a red pitaya in bare metal and if I remember correctly SDK provide libraries to handle the interrupts directly in the C-code (like any micro).
I want to store ADC data in the SD card or in an USB drive at the higher sample rate the system could achieve, so I think the right way to do it's to use a DMA with an interruption code that tells the PS the RAM addresses to write in the SD/USB. El jue., 25 jun. 2020 a las 15:17, Ross Martin (<[email protected]>) escribió: > 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 > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG4nf72NtFypC7Ly7SnJwvGpOrQAVgO0atr7LNVYaQrT9XM%3Duw%40mail.gmail.com?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/CAASoV%3DPqQghbVh3ALoDT_RN-049xO%3DM59WYksUqq5UuM2nPXjw%40mail.gmail.com.
