Re: [beagleboard] Re: PRU cycle counter overflow

2021-04-21 Thread Walter Cromer 
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 
> 
>
> On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer
>  wrote:
>
> Well the solution to the overflow was actually simple.   I had used some 
> example code from TI where they use the value 0x 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 0x 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  
> 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 0x) 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,

Re: [beagleboard] Re: PRU cycle counter overflow

2021-04-21 Thread 'Mark Lazarewicz' via BeagleBoard 
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 
 
  On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer 
wrote:   Well the solution to the overflow was actually simple.   I had used 
some example code from TI where they use the value 0x 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 0x 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  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  
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 0x) 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%40googlegroups.com.
  

-- 
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

Re: [beagleboard] Re: PRU cycle counter overflow

2021-04-21 Thread Walter Cromer 
Well the solution to the overflow was actually simple.   I had used some 
example code from TI where they use the value 0x 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 0x 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  
>> 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 0x) 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%40googlegroups.com.

Re: [beagleboard] Re: PRU cycle counter overflow

2021-04-21 Thread 'Mark Lazarewicz' via BeagleBoard 
This Might be helpful Justin
 helpful 
https://e2e.ti.com/support/processors/f/processors-forum/209489/am335x-iep-interrupt

#Or does it access the IEP clock over some bus

Page 14 the block diagram in PRU Sub system pdf shows what's local to PRU so I 
would say not possible in one cycle. I also saw a list of actual PRU cycle 
times perhaps in same pdf.
What ever I looked at everything is not done in one clock cycle on PRU but I've 
looked at so many doc's I may be mistaken
Your question about clock source can be probably be best understood my reading 
the TRM clock section and looking at the the clicking sub system block diagram. 
Then maybe some code examples.
My guess is what you have is fastest for time stamps  since  the IRQ capability 
doesn't exist like Charles said that question about clock source became don't 
care.





Sent from Yahoo Mail on Android 
 
  On Wed, Apr 21, 2021 at 11:28 AM, 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  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  
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 0x) 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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5fb26840-0eed-47ba-9b21-3fa5ddd52ae4n%40googlegroups.com.
  

-- 
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

Re: [beagleboard] Re: PRU cycle counter overflow

2021-04-21 Thread Walter Cromer 
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  
> 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 0x) 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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5fb26840-0eed-47ba-9b21-3fa5ddd52ae4n%40googlegroups.com.

Re: [beagleboard] Re: PRU cycle counter overflow

2017-01-08 Thread Justin Pearson 
On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson 
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 <
> char...@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 0x) 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
>> char...@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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CABCHBh%2BFzDYAUhLsxNOm-wMfx7%3DdAnmCzVxwHNXK-fTjOinbWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU cycle counter overflow

2017-01-05 Thread Justin Pearson 
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?

Thanks,
Justin



On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler <
char...@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 0x) 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
> char...@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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CABCHBhL4oQa2sfFb8aVtio_1UEbSDZM1tt0S%3DtB6PvhBXGwYOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU cycle counter overflow

2016-12-22 Thread Charles Steinkuehler 
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 0x) 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
char...@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+unsubscr...@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.