Hi RoSchmi, I am using the PRU with RPMsg for a school project, I have just made a documentation about how to set it up: https://github.com/PierrickRauby/PRU-RPMsg-Setup-BeagleBoneBlack
I maybe out off the track with this answer but I hope it help. Thanks Pierrick Le mercredi 6 décembre 2017 08:01:41 UTC-5, RoSchmi a écrit : > > > > Am Montag, 4. Dezember 2017 22:02:14 UTC+1 schrieb Ken Shirriff: >> >> Hi RoSchmi, >> >> My code is at >> https://github.com/shirriff/alto-ethernet-interface/tree/master/src >> I also wrote a blog post discussing interrupts: >> http://www.righto.com/2016/09/how-to-run-c-programs-on-beaglebones.html >> >> Note that it is for the 3.8.13 kernel and everything works differently in >> newer kernels. Also, I'm not an expert here so I don't guarantee that my >> code is the best way to do things. >> >> Ken >> >> Hi Ken, >> I had a look on both of your links. As you said, the programs use the old >> PRU <-> ARM communication concept. However I'd more like to use the new PRU >> remoteproc, PRMsg and intc concept. Did you already manage to set up the >> user space code to receive interrupts from the PRUs using the new concept? >> If yes, are you willing to share the code? >> Kind regards >> RoSchmi >> On Monday, December 4, 2017 at 12:35:36 PM UTC-8, dr.rolan...@gmail.com >> wrote: >>> >>> Hi Ken Shirriff, >>> could you please give a code example or a link about how to manage the >>> interrupt handling on the Linux user code side? >>> Thanks in advance. >>> RoSchmi >>> >>> Am Freitag, 10. November 2017 06:19:47 UTC+1 schrieb Ken Shirriff: >>> >>>> Thanks everyone for the suggestions. I used Dimitar's approach and it >>>> works reliably and made my code more comprehensible. >>>> >>>> I now have a single event loop that does the wait/clear/process, rather >>>> than trying to handle things semi-synchronously and expecting to get an >>>> interrupt event in response to a particular PRU request. I also made >>>> "ownership" of each buffer explicit between the PRU and the ARM. When the >>>> ARM has a buffer ready for the PRU, it marks the owner as "PRU". When the >>>> PRU is done with a buffer, it marks the owner as "ARM" and sends an >>>> interrupt. So when the ARM gets an interrupt, it doesn't assume anything >>>> is done, but checks the owner tags to see what it should do. >>>> >>>> The shorter explanation is that before I was using the interrupt event >>>> to indicate a particular task was done, which was a race condition mess. >>>> Now I use the interrupt event to indicate that something has (probably) >>>> changed and then check to see what changed. >>>> >>>> Ken >>>> >>>> On Tuesday, November 7, 2017 at 9:42:58 AM UTC-8, din...@gmail.com >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> FYI, recent remoteproc RPMSG versions have moved from mailboxes to >>>>> interrupts for communication: >>>>> https://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c >>>>> >>>>> A race-free algorithm would require the interrupts simply to wake the >>>>> peer, and rely on shared memory FIFO for handling events. AFAIK, that's >>>>> the >>>>> idea used by virtio/RPMSG. In pseudo-code: >>>>> >>>>> 1. Wait for interrupt. >>>>> 2. Clear interrupt. >>>>> 3. Drain the events-FIFO located in shared memory. >>>>> >>>>> Regards, >>>>> Dimitar >>>>> >>>>> On Tuesday, November 7, 2017 at 4:09:33 AM UTC+2, Ken Shirriff wrote: >>>>>> >>>>>> I'm trying to send information back and forth between the processor >>>>>> and the PRU, and I'm looking for suggestions on the best way to do this. >>>>>> >>>>>> Currently I'm using PRU_EVTOUT0 to send events from the PRU. The >>>>>> processor code does a select() on the PRU_EVTOUT_0 fd to find out when >>>>>> an >>>>>> event has happened. Then I do a prussdrv_pru_wait_event() and >>>>>> prussdrv_pru_clear_event() to get rid of the event. (The select is >>>>>> because >>>>>> I also want to wait for network data.) >>>>>> >>>>>> However, this is kind of a mess of race conditions, since an event >>>>>> can come in between the select and the clear. Or two events can happen >>>>>> before the select. So I have various status flags that the PRU sets in >>>>>> memory. But that leads to other race conditions. >>>>>> >>>>>> So, I'm wondering if there's a better way to handle events back and >>>>>> forth. Other people must have dealt with this and come up with good >>>>>> solutions. >>>>>> >>>>>> I've seen stuff about Remoteproc - is that the cool new technology? >>>>>> Its mailboxes seem like a good model. However, I'd rather stick with the >>>>>> UIO model instead of moving to a new kernel and rewriting everything if >>>>>> possible. >>>>>> >>>>>> My application, in case it's relevant: I'm building a network gateway >>>>>> with the PRU bit-banging a 3 megabit/second Ethernet. So the processor >>>>>> sends packets to the PRU to transmit, and the PRU tells the processor >>>>>> about >>>>>> incoming packets. The PRU needs to tell the processor when a send is >>>>>> completed, or when a packet has arrived. >>>>>> >>>>>> Thanks for any help, >>>>>> Ken >>>>>> >>>>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/12c730df-a0d0-4348-ae58-caa4258c03bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
