[beagleboard] Re: Explanation of PRU Programming in C

[Arend Lammertink]

Thanks Joseph for sharing your code.

I am working on a project involving real-time closed loop control with the 
adc of the beaglebone, using the PRUs in c:
https://github.com/l4m4re/SoakageTester

I found a pretty nice base for programming the adc's and some other 
examples, which I forked and updated the adc example:

https://github.com/l4m4re/bbb-pru

Currently, that example uses a dual buffer strategy, but one can also 
implement a ring buffer (as I have done in my project above). I will 
probably add that to these examples at some point, too. With this code, I 
can sample two channels at 800 kS/s each and hopefully do some control 
processing on the PRU, too. 

So far, I have only used one PRU for sampling, and the next step is to move 
the GPIO controls to the PRU(s) as well. When searching for examples on how 
to do this, how to do interrupts between the PRUs and/or how to work with 
the IEP timer, I found your code,  and thus I found out about the header 
files in the pru software support package (in /opt). 

So, all in all the info you shared will surely help a lot.

Best regards and thanks again for sharing,

Arend.


On Wednesday, April 26, 2017 at 10:02:47 AM UTC+2, Joseph Heller wrote:
>
> Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/
>

-- 
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/e74d1724-00e4-4927-985a-cfb19d3d42db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[William Hermans]

lol dahm text correction got me good that time "obstacle"

On Tue, May 16, 2017 at 1:26 AM, William Hermans  wrote:

>
>
> On Tue, May 16, 2017 at 1:07 AM, Joseph Heller  > wrote:
>
>> On Tuesday, May 16, 2017 at 3:27:07 AM UTC+2, William Hermans wrote:
>>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller 
>>> wrote:
>>>
 Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/

>>>
>>> I may have mentioned this before, but I think blinking a USR LED would
>>> be far more useful. Nothing to hook up, and worry about blowing the pins on
>>> the processor, etc. However, then we're talking about involving the L3
>>> interconnect, which might be what you did not want to do ?
>>>
>>> A point of contention that I have with the article however, is: How does
>>> the GPIO bank + DATA_OUT register get into the PRU's _R30 register ? This
>>> also has to be dynamic somehow. I can't imagine all registers r0-r31 are
>>> each dedicated to a single control register of *something*. Then yes, I do
>>> know that some PRU registers are reserved, I just do not know which anymore.
>>>
>>
>> I don't know yet either at the moment. The way I use it in the example
>> seems to work magically per default. Risk is that is breaks though. An
>> explanation would be helpful.
>>
>
> Ah, ok, I was afraid of that. I do know the gpio registers fairly well, so
> maybe at some point I could figure that out. If I do I'll try to relay the
> info to you. One thing I'm thinking could be an obstetrical, is that there
> is GPIO that the PRU has direct access to, and then GPIO that has to be
> accessed over the L3 interconnect. Then I noticed from your article that
> the GPIO that you're using is mode 0x05, which is obviously PRU mux mode
> for GPO I suppose if you're controlling an LED. So yeah . . . will be a bit
> different.
>

-- 
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/CALHSORqcm4j62tNajqhdBiwU0EEQd4nxO2edCi0gV_Qa-d7CFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[William Hermans]

On Tue, May 16, 2017 at 1:07 AM, Joseph Heller 
wrote:

> On Tuesday, May 16, 2017 at 3:27:07 AM UTC+2, William Hermans wrote:
>>
>>
>>
>> On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller 
>> wrote:
>>
>>> Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/
>>>
>>
>> I may have mentioned this before, but I think blinking a USR LED would be
>> far more useful. Nothing to hook up, and worry about blowing the pins on
>> the processor, etc. However, then we're talking about involving the L3
>> interconnect, which might be what you did not want to do ?
>>
>> A point of contention that I have with the article however, is: How does
>> the GPIO bank + DATA_OUT register get into the PRU's _R30 register ? This
>> also has to be dynamic somehow. I can't imagine all registers r0-r31 are
>> each dedicated to a single control register of *something*. Then yes, I do
>> know that some PRU registers are reserved, I just do not know which anymore.
>>
>
> I don't know yet either at the moment. The way I use it in the example
> seems to work magically per default. Risk is that is breaks though. An
> explanation would be helpful.
>

Ah, ok, I was afraid of that. I do know the gpio registers fairly well, so
maybe at some point I could figure that out. If I do I'll try to relay the
info to you. One thing I'm thinking could be an obstetrical, is that there
is GPIO that the PRU has direct access to, and then GPIO that has to be
accessed over the L3 interconnect. Then I noticed from your article that
the GPIO that you're using is mode 0x05, which is obviously PRU mux mode
for GPO I suppose if you're controlling an LED. So yeah . . . will be a bit
different.

-- 
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/CALHSORrapvic8sm1jeFY2cL0FG3jrTCYDpQYBzLTkQ2_wsDnWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

On Tuesday, May 16, 2017 at 1:01:55 AM UTC+2, Clark Sann wrote:
>
> Hi Joseph
>
> Nice writeup. You did a good job of explaining a complex topic...at least 
> it seems complex to me. I have however found a possible error.
>
> Shouldn't you be referring to the DEFAULT_INC value rather than the 
> CMP_INC value in your description?
>

Hi Clark, 

That's a good catch - I've corrected this.

Thanks!

-- 
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/e92ff34b-45f0-4374-ab88-23acc3b7cb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[William Hermans]

On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller 
wrote:

> Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/
>

I may have mentioned this before, but I think blinking a USR LED would be
far more useful. Nothing to hook up, and worry about blowing the pins on
the processor, etc. However, then we're talking about involving the L3
interconnect, which might be what you did not want to do ?

A point of contention that I have with the article however, is: How does
the GPIO bank + DATA_OUT register get into the PRU's _R30 register ? This
also has to be dynamic somehow. I can't imagine all registers r0-r31 are
each dedicated to a single control register of *something*. Then yes, I do
know that some PRU registers are reserved, I just do not know which anymore.

In another part of the article:

> The issue faced here is that one has to deep-dive into the workings of the
> header files, and make the relation to the defined variables in those
> header files and the PRU registers defined in the Reference Manual.
> Fortunately the header files and the reference manual closely match each
> other. *Unfortunately, you have to do the footwork to figure it out for
> each common or less common usage of the registers. For instance, here’s a
> relevant section of the pru_iep.h header file for the IEP example above:*


Then you go on to show some "pictures" from various sources, most notably
the applicable registers from the TRM. My point here is, I'm not sure what
your point is. This is pretty much standard procedure when working with any
hardware on this level. That is, *IF* you really need to know for sure,
what you're doing.

So, do not get me wrong, I'm not bashing what you've done there at all.
It's a lot more than I've done in demonstrating the PRU's to the public.
Mostly due to the fact that I do not know how to use the PRU's very well at
all.

-- 
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/CALHSORrSHOWhHF_OL7X3NeEca_GCxN9HpomoXvs7AfnoPwgQ%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[William Hermans]

Also very glad you chose to demonstrate this using UIO, instead of
remote_proc.

On Mon, May 15, 2017 at 6:26 PM, William Hermans  wrote:

>
>
> On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller  > wrote:
>
>> Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/
>>
>
> I may have mentioned this before, but I think blinking a USR LED would be
> far more useful. Nothing to hook up, and worry about blowing the pins on
> the processor, etc. However, then we're talking about involving the L3
> interconnect, which might be what you did not want to do ?
>
> A point of contention that I have with the article however, is: How does
> the GPIO bank + DATA_OUT register get into the PRU's _R30 register ? This
> also has to be dynamic somehow. I can't imagine all registers r0-r31 are
> each dedicated to a single control register of *something*. Then yes, I do
> know that some PRU registers are reserved, I just do not know which anymore.
>
> In another part of the article:
>
>> The issue faced here is that one has to deep-dive into the workings of
>> the header files, and make the relation to the defined variables in those
>> header files and the PRU registers defined in the Reference Manual.
>> Fortunately the header files and the reference manual closely match each
>> other. *Unfortunately, you have to do the footwork to figure it out for
>> each common or less common usage of the registers. For instance, here’s a
>> relevant section of the pru_iep.h header file for the IEP example above:*
>
>
> Then you go on to show some "pictures" from various sources, most notably
> the applicable registers from the TRM. My point here is, I'm not sure what
> your point is. This is pretty much standard procedure when working with any
> hardware on this level. That is, *IF* you really need to know for sure,
> what you're doing.
>
> So, do not get me wrong, I'm not bashing what you've done there at all.
> It's a lot more than I've done in demonstrating the PRU's to the public.
> Mostly due to the fact that I do not know how to use the PRU's very well at
> all.
>
>

-- 
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/CALHSORp7MJ9O-%3Do%2BSmxgqPHKND%2BaWxTrJyKtYic%3DoiA5w0EQ%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/

-- 
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/66c4d74d-914b-4729-89c0-68410bdb449f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

Thanks for the positive feedback. The TI video does not work on Mac though. 

I've now also included the hello world blink LED in C. 

> On 19 Apr 2017, at 19:38, Greg  wrote:
> 
> Excellent!  I did a couple of projects with PRU and C code, and this type of 
> tutorial is sorely needed.
> 
> I would add a link to this:
> 
> https://training.ti.com/pru-compiler-tips-tricks
> 
> So I wonder how common it is to use a C union and bit selector?
> When I first encountered this in the PRU header files, I didn't even think it 
> was C code!
> In fact, in the information provided by TI in the video and slides, they say 
> it is really warped C code.
> 
> Regards,
> Greg
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/3KjD7ULjD6M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.com.
> 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/830480A5-BD30-4277-882F-230B7BB8D387%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Greg]

Excellent!  I did a couple of projects with PRU and C code, and this type 
of tutorial is sorely needed.

I would add a link to this:

https://training.ti.com/pru-compiler-tips-tricks

So I wonder how common it is to use a C union and bit selector?
When I first encountered this in the PRU header files, I didn't even think 
it was C code!
In fact, in the information provided by TI in the video and slides, they 
say it is really warped C code.

Regards,
Greg

-- 
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/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.