This isn't directly from TI but I found essentially the same code on in a TI lab or online somewhere.
https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/12/beaglebone-pru-timer-functionality On Wednesday, April 21, 2021 at 4:07:31 PM UTC-4 lazarman wrote: > Hello Walter > > Which TI PRU examples are you using I've seen so many examples I've lost > track. I've seen the archive that contains the labs1 to labs 6. > > > > Sent from Yahoo Mail on Android > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer > <wal...@edenconceptsllc.com> wrote: > > Well the solution to the overflow was actually simple. I had used some > example code from TI where they use the value 0xFFFFFFFF to clear the IEP's > counter. That didn't really make sense to me except of course if your very > next instruction was to start the timer which would cause it to overflow > immediately and start counting in the main processing sequence at 0. In > my case, my next step, also borrowed from their examples, was to reset the > overflow event flag. Which, of course was immediately set back high > because the counter incremented AFTER this reset instruction and not > before. So when I issued the overflow event reset, the counter was still > at 0xFFFFFFFF which caused an immediate overflow event. > > Ugh. Live and learn. > > On Wednesday, April 21, 2021 at 12:28:14 PM UTC-4 Walter Cromer wrote: > > 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 justin....@gmail.com > wrote: > > On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson <justin....@gmail.com> > 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 < > cha...@steinkuehler.net> 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 > cha...@steinkuehler.net > > > -- > 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...@googlegroups.com. > > 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 beagleboard...@googlegroups.com. > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/beagleboard/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/e59e0dd2-0ef1-4918-8bd2-de43e448bf58n%40googlegroups.com.
