Hi Sebastian, Interrupts can be easier to work with in bare metal, so using bare metal might be a good idea as one way to get interrupts to work without as much difficulty. On the other hand, many other things are harder in bare metal. Just programming and debugging is harder.
For a Linux application that does polling, the issue with the polling isn't the speed of copying the data but rather how long the application might wait between polls. If your application isn't doing anything else but copy ADC data, then you could make the polling interval quite short without performance consequences. You could also have multiple buffers for the ADC data in the PL, to hold data for a while when the application doesn't get to it in a timely manner. Then when the application gets around to copying the data it can empty all the buffers out before it starts polling again. Regarding DMAing directly to the SD card -- this alarms me. I'd be surprised if that's achievable. You'd essentially have to write your own filesystem and device drivers for the SD card, I would think. If you find that it's possible, it would be interesting information. It shouldn't be hard to do some speed tests to see how fast you can write to the SD card from either Linux or bare metal. Note that some SD cards are faster than others, so you should make sure yours has a fast write speed. Hopefully it's fast enough without writing your own filesystem. Regards, Ross On Sun, Jun 28, 2020, 5:44 PM Sebastian Antonio Jorquera Tapia < [email protected]> wrote: > 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 > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DPqQghbVh3ALoDT_RN-049xO%3DM59WYksUqq5UuM2nPXjw%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/CAG4nf72Eeyr9-vO3uug2g5Qw0Vaeor6EpHMEPrubQZJP1n07bw%40mail.gmail.com.
