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/35ae1649-227f-46be-b0d0-31d8b62f58f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
