Explanation of PRU Programming in C

[Joseph Heller]

Hi guys, after a deep dive, I've found how to program to PRU in C (instead of Assembly). Here's my contribution:

http://catch22.eu/omnirobot/beaglebone-pru-c/

Feel free to comment on this forum!

[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

[John Syne]

I have a Mac and the videos work just fine for me on the Chrome browser.

Regards,

John

On Apr 20, 2017, at 4:44 AM, Joseph Heller <joseph.h...@gmail.com> wrote:

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. 

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

[Joseph Heller]

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

[Clark Sann]

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?

[William Hermans]

On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller <joseph.h...@gmail.com> 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.

 

[William Hermans]

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

[Joseph Heller]

Hi Clark,

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

Thanks!

[Joseph Heller]

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 <joseph.h...@gmail.com> 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.
 

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.

Okay, I've rephrased that part a bit. Thanks for the feedback.

[William Hermans]

On Tue, May 16, 2017 at 1:07 AM, Joseph Heller <joseph.h...@gmail.com> 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 <joseph.h...@gmail.com> 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.

[William Hermans]

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

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