I'm attempting something very similar to what you were working on. If you are willing, please share how you eventually did this. Did you use the IEP clock or the PRU's cycle counter? I have IEP working with the iep_clk (although I'm having terrible RPMSG problems right now).
Also, I can't seem to correctly check the overflow bit in IEP_TMR_GLB_STS. I would bit 0 would be 1 if there has been an overflow but even at startup, when the counter only has maybe 1000 counts in it, the bit is 1 when I read it. Maybe I'm not reading it correctly? On Monday, January 9, 2017 at 12:45:08 AM UTC-5 [email protected] wrote: > On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson <[email protected]> > wrote: > >> Thanks Charles, that's very helpful. I didn't know about the IEP timer. >> TRM section 4.4.3.1 says I can hook up the IEP clock source to >> either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle >> counter? >> > > > Maybe a better question is: Can the PRU read the IEP clock as > deterministically as it reads its own cycle counter (always 1 cycle)? Or > does it access the IEP clock over some bus that introduces > non-deterministic delays due to contention issues (like accessing the 512MB > RAM)? I'm concerned because I'm using the cycle counter for time-stamping > sensor and actuator measurements. If I switch to the IEP clock, I'd like to > know I'll have the same timing guarantees. > > Thanks, > Justin > > > >> Thanks, >> Justin >> >> >> >> On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler < >> [email protected]> wrote: >> >>> On 12/22/2016 10:45 AM, Justin Pearson wrote: >>> > I have the same question. >>> > >>> > I'm using the PRU's 200 MHz cycle counter to timestamp sensor >>> measurements. At >>> > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to >>> notify a C >>> > program running on the 1GHz host ARM processor as soon as it overflows. >>> > >>> > *Is it possible to configure the PRU cycle counter to trigger an >>> interrupt in >>> > the host ARM when it overflows?* >>> >>> Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL >>> register bank)? If so, this counter doesn't even wrap around (it >>> automatically stops when it hits 0xFFFFFFFF) much less generate an >>> interrupt. >>> >>> > I know how to write PRU code to make the PRU trigger an interrupt in >>> the host, >>> > but that's not quite what I want, since my PRU will be busy doing >>> other things. >>> > I would like the cycle counter to trigger an interrupt automatically, >>> without >>> > the PRU having to check if it has overflowed. >>> >>> Try using the IEP timer. It will wrap automatically, and you can even >>> setup a configurable period by using compare register zero and setting >>> the CMP0_RST_CNT_EN bit. You can also route an IEP timer event >>> (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt. >>> >>> -- >>> Charles Steinkuehler >>> [email protected] >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5fb26840-0eed-47ba-9b21-3fa5ddd52ae4n%40googlegroups.com.
