There are two examples, one for PRU0 and another for PRU1. So you will get rpmsg_pru30 for PRU0, and rpmsg_pru31 for the other.
So if you are seeing rpmsg_pru31, this is a major step forward and you have it working!!!
Also note the “c” at the first column of the ls; this indicates a character device. It’s good news.
So I think the scripts prumodin and prumodout must be looking for the wrong file names. It is probable they are not consistent as kernel changes are rolled out.
So:
ls /sys/bus/platform/devices
Do you see PRU related entries as shown in the set-up documentation? There are probably small differences which are breaking the scripts.
So I think I have it mostly working, I can see rpmsg_pru31 and rpmsg_pru30 in the /dev folder and I saw that prumodin was already enabled, I had to do prumodout first and then prumodin then the script didn’t error out. I see P9_42 toggle for a second and then the pin stays high. Is that what is supposed to happen? If that is what is supposed to happen then great! But I do have some questions about why you did certain things during the installation. Let me know how far off I am.
Thanks,
Ashwini Bhat
So exactly which firmware are you using? In my docs, for set-up purposes I suggest the PRUmsg Echo Lab 5.
So this example does not intentionally toggle any GPIO. The idea is that if you can get this lab to work, the PRU RemoteProc kernel drivers are completely functional.
The final thing to do with this example is to compile the user-space C program and run it.
I think the Makefile handles this, but compiling any C program for user-space is easy:
gcc main.c -o pru_msg_test
or something like that.
Running the user-space test program does a simple exercise of the RemoteProc messaging character devices.
Lab 6 toggles an LED using the PRU and uses the same character device mechanism to control the PRU.
Let me know if you have any more questions. I think you have gained a lot of capability to experiment with the PRUs.
I did the Echo Lab 5 and everything seemed to go fine. I ran prumsg and all I saw was a quick squarewave and then the pin would stay high.
Ok, I played with it some more and I am trying to get /home/debian/pru-software-support-package/examples/am335x/PRU_gpioToggle example to work. And as you guessed I am not seeing anything toggle for P8_11 under PRU0. I see that P8_11 is on pruout (when doing config-pin P8_11) as is defined by https://www.cs.sfu.ca/CourseCentral/433/bfraser/other/2016-student-howtos/PRU_GPIO_guide.pdf I am not using P8_27 due to having to load in a new overlay and I don’t know if its going to load cape-universala is going to boot of the SD card or not, so I didn’t want to risk it. Anyways, everything goes and I hit no errors. I copied the out file into am335x-pru0-fw. So I am confused here. I don’t know where the issue is coming from, why I can’t see the GPIO pin being toggled on the scope. I was also going through your directions and had some questions,
Why include am33xx-pruss-rproc.dtsi? Does this mean I have to include some other files for the
Why did you have blacklist certain files? Do I have to blacklist certain files too?
As I am reading through you previous emails maybe I will give my hand at Lab 6 and see if I can see anything toggle in the meantime. Let me know your thoughts. This is really helpful, but there is so much going on I am having a hard time wrapping my head around everything that is happening, I don’t know if its just me thats having such a hard time…
Thanks again for you time and your patience.
-Ashwini
The am33xx-pruss-rproc.dtsi file has to included to activate the RemoteProc framework.
I don’t have any good links to the details, however, there are two frameworks for working with the PRUs that I know of:
UIO
RemoteProc
UIO is far more mature, and from reading various postings here it seems to have some performance advantages.
There are kernel space drivers, and RemoteProc is an example.
There are user-space drivers, and the UIO framework is an example.
You have to start drilling into operating system details, but don’t ask me as I am going up the learning curve on this stuff slowly.
If you do some searching there is tons of material to read.
This is good stuff, but there are thousands of details.
Anyway, since some are using UIO, and some are using RemoteProc, it is left to the user to select the active PRU driver framework.
So that is why you have to edit the dts file and re-compile.
Be cautious when loading overlays. There is lots of obsolete info out there. You should edit uEnv.txt in the boot directory to accomplish this.
Don’t try to use config-pin or the echo slot method which you will find all over the web.
It might work, or it might not, but it is not worth messing with it. Just edit uEnv.txt and you will get the job done.