After having the compiled the file, and from what I’ve read throughout the internet, I thought that in order to run a program into the PRU I should simply do:
What version of the linux kernel are you using? It makes a large
difference as the kernel interfaces have changed.
My experience may not apply to your’s but I can share it with you.
I have a beagle board black. The board booted fine and then I installed
the latest at the time “debian 9.4 lxqt”. The board booted fine. The PRU
compilers where already installed. However, I could not access the PRU
from the device tree. From https://markayoder.github.io/PRUCookbook/
In Mark’s excellent guide, I was able to see the following instructions
in the Makefile.
“”"
I could not see these addresses despite modifications to the uEnv.txt file. I finally discovered that despite booting from the SD card,
the boot process would use information from the built-in flash chip. Once I zeroed out the on-board flash chip, (using the following)
sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k
I could make changes to the uEnv.txt file and everything started working as one would expect.
What version of the linux kernel are you using? It makes a large
difference as the kernel interfaces have changed.
My experience may not apply to your's but I can share it with you.
I have a beagle board black. The board booted fine and then I installed
the latest at the time "debian 9.4 lxqt". The board booted fine. The PRU
compilers where *already* installed. However, I could not access the PRU
from the device tree. From PRU Cookbook
In Mark's excellent guide, I was able to see the following instructions
in the Makefile.
"""
# Lookup PRU by address
ifeq ($(PRUN),0)
PRU_ADDR=4a334000
endif
ifeq ($(PRUN),1)
PRU_ADDR=4a338000
endif
I could not see these addresses despite modifications to the uEnv.txt file. I finally discovered that despite booting from the SD card,
the boot process would use information from the built-in flash chip. Once I zeroed out the on-board flash chip, (using the following)
sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k
I could make changes to the uEnv.txt file and everything started working as one would expect.
Typically (unless the bootloader on the microSD also tries to load
from eMMC), you can hold down the BOOT/SD/S2 button when applying
power (release right after applying power) and it will force the
bootloader on the eMMC to be ignored.
Thank you very much for your answer.
I think we are running similar versions of the kernel since our PRU configurations seem to be about the same.
So, I installed the Debian 9.5 2018-10-07 4GB SD IoT image and I am using the 4.14 kernel version.
I took a look at the article from you have sent me and it seems to work. In the section “02start” I could set the USR3 led blinking, although in the section “06io” I couldn’t
set the P9.11 LED blinking, I follow his instructions and it didn’t work, do you have any inkling what might I do wrong?
From what I have seen, he separates the registers by addresses, as described above:
#define GPIO0 0x44e07000 // GPIO Bank 0 #define GPIO1 0x4804c000 // GPIO Bank 1 #define GPIO2 0x481ac000 // GPIO Bank 2 #define GPIO3 0x481ae000 //GPIO Bank 3
He says to check the Table 2.2 of TRM, do you know where it is? I think the failure might be in the address for accessing the GPIO0, which might be different on my kernel version.
Additionally, can you tell me what you’ve done with PRU? … What I do want to achieve is to build an SPI slave interface (for reading data from image sensors).
Fred:
It’s odd that you have the code from chapter 2 working, but not the code in chapter 6. How is the LED wired to P9_11?
Did you config-pin P9_11 for gpio and not pruout? Is P9_11 configgid for output?
Oh, sorry, my bad. It was related with the pin’s configurations.
Can you tell me what’s the difference between using the OCP interface or usual PRU interface? Both allow to controlling the pins at the same speed rate?
Fred:
Using the PRU interface is faster. I think my students measured it as being a couple times faster. Using the PRU interface you can toggle a pin every 5ns.
PRU writes to the direct I/O are 8 times faster than writing to a GPIO
pin via the OCP (40 ns for the GPIO vs. 5 ns for direct I/O). Note
that while the write competes on the PRU side within 40 ns, it takes
about another 100 nS until the actual GPIO pin value is updated (this
is the time needed for the write transaction to flow through the
interconnect fabric and actually update the GPIO register).
Reads, however are much worse, since they are not posted by the
interconnect fabric and stall the PRU until the read value is
returned. Reading from a GPIO pin via the OCP port takes apx. 165 ns
vs. 5 ns for a direct I/O read.
I did some tests and measurements of this when I was writing the PRU
code for Machinekit, and documented the details in some comments:
Also note that using GPIO0 pins is slower and more unpredictable that the other GPIO’s, particularly with the TI kernel. The power management stuff is in the interconnect as GPIO0 so anything that triggers any sort of PM activity can cause longer delays for any action with GPIO0. In particular, the CPU idle state driver can add an extra 150ns or more delay to writing things to GPIO0. You can limit that by using “cpupower idle-set -d 1” to disable the idle states that take a long time to transition in/out of, but it’s still not perfect.