PRU remoteproc Tutorial

[Mark A. Yoder]

It looks like the new way to talk to the PRUs is via remoteproc and RPMsg.  

Does anyone have pointers to some good tutorials?  Or some good debuggers?

ZeekHuge has a Google Summer of Code project (2016) that has some nice remoteproc examples, and he

built some nice tools.  

I'm putting together a wiki that shows how to setup your Bone to run his examples. (http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg).

I'm open for additions/corrections so we can have a one stop place for those using the PRUs with remoteproc.

--Mark

[William Hermans]

Hi Mark,

Are you using CCS or GCC tools ?

--
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/70e1498f-3f86-4a06-b319-a66264e9ce7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark A. Yoder]

clpru.  It's already installed on the Bone.

--Mark

[William Hermans]

Hi Mark,

Yes, that's a given. But host, or ARM( Linux ) side ?

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c6a4f466-1505-422e-bfe9-624b18a6c8ec%40googlegroups.com.

[Mark A. Yoder]

gcc.  My students are running Linux on their host and gcc is already there.

--Mark

On Monday, July 11, 2016 at 3:47:06 PM UTC-4, William Hermans wrote:

[William Hermans]

Mark,

To put it simply. I'm still waiting for someone to write up decent examples, and maybe even documentation for writing host side code using gcc toolchains. All I've seen so far is CCS examples, which won't work for me. See I guess I don't understand how the two halves work together . . . yet.

[William Hermans]

Mark,

Excellent ! I look forward to looking over your course material. Do you plan on giving a deep dive into communications between both sides. Host, and PRU ? Not sure if that fits into your course plans or not but I know I would to learn this myself. Also the PRU config files, hex files . . . not sure I'm remembering that correctly or not. But it's the config files that seem to layout stuff like .bss .data, etc . . . No idea if you plan on covering that either. But someone needs to.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2e60f2f2-d5d0-4394-b854-d5d4090ac3d0%40googlegroups.com.

[Jason Kridner]

For the ARM or PRU? I don't think gcc for PRU ships in the image, though it should. 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2e60f2f2-d5d0-4394-b854-d5d4090ac3d0%40googlegroups.com.

[William Hermans]

Hi Jason.

Well no that's not what I was getting at. I have a number of concerns. The below with GCC( not CCS ) in mind, as well as remoteproc in place of uio_pruss.

• I have not found any example code that demonstrates communications between PRU and ARM
• I have not found any example code that demonstrates loading PRU code from the ARM binary
• I have not found any example code that demonstrates how to manipulate peripherals from the PRU via remoteproc.

Also I have not seen any coherent documentation explaining this PRU config file that lays out .bss, .data, and code data segments. I think it actually does more than this too, but . . . I'm going from memory here, and I've found no documentation on the subject. So. . . I do not really know what else to say about it.

Maybe there is too much assumption happening here ? The assumption that someone should already know what is going on ? But I do not operate that way. If something is not spelled out, I do not necessarily assume anything.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/35C809CB-AE72-49F8-B834-FB035AD6492A%40gmail.com.

[Greg]

The TI training site is a bit confusing, and I'm still not sure this is the latest:

http://software-dl.ti.com/public/hpmp/sitara/building_blocks_for_pru_dev_summary/index.html

The above is a good starting point.  Homework 1?

Greg

[Greg]

One note on the compiler set-up:

ln -s `which lnkpru` .

I haven't found a reason to use the lnkpru command.  The linking is done with clpru with the -z option.

    Compile and link processes all done with a single command.  The PRU compiler manual explains the options reasonably thoroughly.

Regards,

Greg

[Greg]

Hi William-

Regarding the .bss .data etc., this may be helpful:

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

Topic 21 and 22?  Not sure if this is what you are looking for.

Less specific to the PRU, more like TI general style:

http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer

Regards,

Greg

[Greg]

A "future" remote-proc project, last commit 2015, probably not active:

 https://github.com/deepakkarki/pruspeak

Note the system flow diagram on the above page.

I really like the way to diagram is split into three domains.

Nicely done!

Regards,

Greg

[William Hermans]

Hi William-

Regarding the .bss .data etc., this may be helpful:

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

Yes, and no. The talker talks *about* the different sections, but doesn't really say anything that matters. However he did mention something about the compiler manual. I've read part of this, maybe I missed it in the manual.

Topic 21 and 22?  Not sure if this is what you are looking for.

Less specific to the PRU, more like TI general style:

http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer

Again. . . yes and no. This explains some of what I'm asking, but it's no where near complete.

Thanks for the reply Greg, I do appreciate the effort. However, as usual, I'm finding TI's documentation lacking, as well as spread out all over the place. However, with the last iteration of remoteproc I got the sense that the cmd file( hex file whatever it is ) is less important. I did recognize the MSP430 sections, as I've seen the file before in the wild, and in fact I'm working on an MSP430 project right now . . .

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3472d70e-6064-406b-a109-c8ec7d0a3892%40googlegroups.com.

[Mark A. Yoder]

Jason:

  I'm using gcc on the ARM and clpru on the PRU.  Both are installed.

What would you gain by using gcc on the PRU?

--Mark

[Mark A. Yoder]

William:

  I'm not sure how far I will get.  It depends on how easy it is to find the information I need.

I'd like to build a framework for simple devices.  For example make it easy to add another eQEP, PWM, or I2C device via the PRU.

What sort of examples would make good starting points?

--Mark

[Mark A. Yoder]

Greg:

  I tried removing the symbolic links and I get the following error when running make on a BeagleScope example.

Invoking: PRU Compiler

/usr/share/ti/cgt-pru/bin/clpru --include_path=/usr/share/ti/cgt-pru/include --include_path=../../../include --include_path=../../../include/am335x -v3 -O2 --display_error_number --endian=little --hardware_mac=on --obj_directory=gen --pp_directory=gen -ppd -ppa -fe gen/PRU_gpioToggle.object PRU_gpioToggle.c

make: /usr/share/ti/cgt-pru/bin/clpru: Command not found

Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed

The error goes away when I put the link back.  Maybe the BeagleScope makefiles aren't set up right.

--Mark

[William Hermans]

Hi Mark,

Well I do not know, what would be the simplest example that is close enough to the traditional hello world app ? I was thinking perhaps blinking a USR LED, since one would not have to add any additional hardware. But I looked into that a while back, and doing this would not be a trivial matter I think. Well actually . . . it depends on how remoteproc is implemented. If remoteproc can gain direct access to CPU memory addressing as can be done using uio_pruss. Then it should not be too much trouble.

So maybe an external LED example? Which would work out very close to how one would toggle a GPIO( LED ) on a bare metal platform.  So anyone having background experience with something like a TI Launchpad or Arduino should be able to understand this very easily.

Passed that . . some kind of communication example. I was thinking perhaps usrspace to PRU core 1, to PRU core 2, then back to userspace. As a way for people to get their feet wet, with something easily verifiable. Then perhaps a shared memory example.

--

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/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com.

[William Hermans]

Jason:

  I'm using gcc on the ARM and clpru on the PRU.  Both are installed.

What would you gain by using gcc on the PRU?

--Mark

Let me answer this for you Mark. You would gain nothing. The contributor of the pru gcc implementation hints that it's nothign more than a toy, and that code generated with it should be thought of nothign more than experimental. It says this right on the github project page readme.md.

[William Hermans]

heh I forgot that "readme dot md's" actually link to some random github project heh. So . .

The release is ready for cautious usage. A simulator is used to execute the GCC C regression test suite. Results for this release are:

# of expected passes           81497
# of unexpected failures       31
# of unexpected successes      1
# of expected failures         97
# of unsupported tests         1974

This message has changed some since the last time I read it but pretty much the same result. In my mind - Don't use it.

[Greg]

I see what he did differently compared to the TI example's Makefiles.  It is a matter of using the -z option with clpru or a distinct command using lnkpru.

How TI does it:
$(PRU_CGT)/bin/clpru $(CFLAGS) -z -i$(PRU_CGT)/lib -i$(PRU_CGT)/include $(LFLAGS) -o $(TARGET) $(OBJECTS) -m$(MAP) $(LINKER_COMMAND_FILE) --library=libc.a $(LIBS)

How the BeagleScope Makefile does it:
$(PRU_CGT)/bin/lnkpru -i$(PRU_CGT)/lib -i$(PRU_CGT)/include $(LFLAGS) -o $@ $^ $(LINKER_COMMAND_FILE) --library=libc.a $(LIBS)

So what BeagleScope is doing is "clpru -z" which is equivalent to the lnkpru command.

So to be able to handle this when it appears in a Makefile, it is indeed good to have the lnkpru link to /usr/bin/lnkpru.

Makes sense now!

Regards,

Greg

[Mark A. Yoder]

Greg:

  Thanks for looking into the Makefile magic.  I was just happy I had something working, without really trying to understand it.

--Mark

[Mark A. Yoder]

I made some progress today.  I modified one of the BeagleScope examples (pru_pin_state_reader[1]) to use sprintf() to

send and print debug info to the ARM[2].  One of the things I learned is if you use printf() out of the box you will run out of instruction memory.

Instead you have to use the --printf_support=nofloat flag on clpru.  It uses a smaller printf library that fits.

I'm beginning to get a feel for what's happening on the PRU side, but the ARM is a mystery to me.  I'm sure I can figure out mmap() and read the

shared memory, but I don't think that's the proper way to do it.  Rather I think you are supposed to go through the kernel drivers, but I haven't found

any simple examples.

Does anyone know how the ARM side of remoteproc works?

--Mark

[1] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader

[2] https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/beagleScope/pru_pin_state_reader

[William Hermans]

One of the things I learned is if you use printf() out of the box you will run out of instruction memory.
Instead you have to use the --printf_support=nofloat flag on clpru.  It uses a smaller printf library that fits.

Hi Mark,

Just thinking of this from an alternative angle. The PRU are essentially a Cortex M3 with no instruction cache. So in the Linux world, the Cortex M0/M0+, M3's, and M4's all use the eabi compilers in the gcc camp. Which is to say, soft float compilers. So that makes sense that using the clpru compiler that soft float should be made implicit. Well actually, I think it should be a given. but it makes sense that the clpru compiler should be using soft float versus hard float.

--
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/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com.

[John Syne]

I wish William would stop saying this. The PRU is nothing like a CortexM3. The PRU is a proprietary RISC processor created by Texas Instruments with no pipeline and instructions execute in one cycle. The CortexM3 has a 3 stage pipeline and uses an entirely different instructions set. 

@Mark

Think of Remoteproc as a firmware loader which can start and stop firmware. The communications between PRU and ARM is done via RPMSG which uses a virtual ring buffer (VRING) which allow you to post messages to this buffer and then using interrupts to notify the PRU/ARM that messages are in the buffer. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpQnt55TsRwck_r4EMNm_kCWwmFXV1aH%3DiBh0HnyYz-MA%40mail.gmail.com.

[din...@gmail.com]

Hi William,

I have marked the release as "ready for cautious usage" merely because I seem to be the only user so far :) Once I see enough non-trivial projects using it, I will remove that wording. While it may not yet have matured into a production quality toolchain, I wouldn't call pru-gcc a toy compiler.

I admit the pru-gcc port had a rough start. But I corrected this by writing real-world examples and running the GCC testsuite through a simulator. Bugs were found and fixed.

The pru-gcc test results you pointed are actually pretty good. The 31 unexpected failures are due to reasons like: broken features that are not applicable to PRU, code optimizations that were not applied. I am not aware of any wrong-code-generation bugs. I'm also working on cleaning up the report to avoid further confusion (issue #16). You can compare the pru results against the mainline gcc test report for x86: https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00235.html

Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right now CCS generates a bit more optimized code than pru-gcc. And CCS has received more testing than pru-gcc.

Regards,

Dimitar

[John Syne]

The PRU sends and receives messages to/from the ARM using the following functions pru_rpmsg_send and pru_rpmsg_receive.

 

https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/bf955a05d3733ebe52d5783a1212b457b6e2f55c/lib/src/rpmsg_lib/pru_rpmsg.c#line29

Look at the following examples to see how this is done:

https://git.ti.com/pru-software-support-package/pru-software-support-package/trees/master/examples/am335x

From the ARM side, there is only one example which sends and receives 100 messages, but it does give you the idea on how this works:

https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c

Regards,

John

-- 
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/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com.

[William Hermans]

 
Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right now CCS generates a bit more optimized code than pru-gcc. And CCS has received more testing than pru-gcc.

This is also true for the MSP430 port of gcc versus CCS' compiler. It's been this way for years, and I do not see it changing. Well especially now that the better gcc toolchain that I use is old ( built back in 2012 or longer ago ). It's also a very good and solid gcc port, but TI always seems to know their processors just  bit better ;)

Granted, now, I've read that redhat was contracted to build a newer gcc port a few years back, and that this gcc is actually used by CCS now days( for the MSP430 toolchain ). It is purported to support the newer MSP430G2 variants, among others, but still is not as reliable as the gcc toolchain it was meant to replace.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/08fbb391-c5c7-4f99-a1bd-74f0b5143dfd%40googlegroups.com.

[Przemek Klosowski]

On Wed, Jul 13, 2016 at 11:09 AM, William Hermans <yyr...@gmail.com> wrote:
>
> Granted, now, I've read that redhat was contracted to build a newer gcc port
> a few years back, and that this gcc is actually used by CCS now days( for
> the MSP430 toolchain ). It is purported to support the newer MSP430G2
> variants, among others, but still is not as reliable as the gcc toolchain it
> was meant to replace.

Well, it replaced both CCS and the old MSP430 GCC, and I think the
concensus is that it's for the good. There were issues in the
beginning, but now it's being worked on by both RedHat and TI, and
nobody recommends the old stuff for use any more.

The usual argument for GCC is that it's relentlessly getting better;
proprietary alternatives tend to lose their initial advantage because
GCC contributors have a look at the differences and implement the
improvements. Look how far Dimitar got it, working on his own.

[William Hermans]

Well, it replaced both CCS and the old MSP430 GCC, and I think the
concensus is that it's for the good. There were issues in the
beginning, but now it's being worked on by both RedHat and TI, and
nobody recommends the old stuff for use any more.

The usual argument for GCC is that it's relentlessly getting better;
proprietary alternatives tend to lose their initial advantage because
GCC contributors have a look at the differences and implement the
improvements. Look how far Dimitar got it, working on his own.

Well the msp430-gcc-4.6.3 is still the go to to tool chain for many in the gcc cap for the msp430G2 family MCU's. At least the ones meant to be used in the MSP430G2 v1.5 launchpad. There are some newer MCU's like the MSp430G2955 that have more flash and more RAM than the older G2's, end require the newer compilers. Something to do with memory addressing I believe, but it's been a long time since I've worried about all that. My personal favorite MSP430 is the G2553 . . .

This is also the same compiler that comes with Debian I believe but perhaps that one was also P.A. Bigot's. The compiler I prefer to use actually comes with Energia, which also may be a port of P.A. Bigot's original project? Not sure.

--
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/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com.

[William Hermans]

Anyway, you can find the history behind the different toolchian for the MSP430's, and all that on the 43oh.com forums. From which I've been a member since around January 2013. All the gory details of TI, gcc, and redhat etc and all that.