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 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/e038332a-cd91-4d1a-be0c-10d53fd6ef64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
