Regards,
Stefan.

Hi Simon, Yes, it will be fine. See the SPI ADC example on the website page. The way that I generate the bit sequence for SPI is the same as what you need. I would start with the clock generator circuit. Derek.

I have a question regarding the PRU and changing the pin mode in PRU code.
Specifically, I am trying to read a DHT22 Temperature and Humidity Sensor. It uses a single cable for input and output.
To read the sensor, you need to:
1. Set the pin LOW for 500µs.
2. Set the pin High for 30µs.
the signal then changes to input, and sends to 80µs bursts [low then high] before transmitting the data.

The signal bursts are 50µs low and 26µs or 70µs high, and so needs the speed of the PRU.

Can PRU code change the pin mode after executing the initialization sequence?

I was getting the following in dmesg:

[ 5701.912888] remoteproc remoteproc1: powering up 4a334000.pru
[ 5701.913007] remoteproc remoteproc1: loading /lib/firmware/am335x-pru0-fw failed with error -22
[ 5701.913018] remoteproc remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -22

so I copied blinkLED.out file to /lib/firmware and ran
$ echo ‘blinkLED.out’ | sudo tee /sys/class/remoteproc/remoteproc1/firmware
$ echo start | sudo tee /sys/class/remoteproc/remoteproc1/state
$ cat /sys/class/remoteproc/remoteproc1/state
running

I’m still not sure why the above step was necessary but I can now get the PRUs running.
Maybe this will help others

I have the same or a similar problem, also similar to Rob’s (on June 13). The PRUs are initialized, new firmware is compiled and in the correct directory, but I cannot figure out how to bring the PRUs “online”. Is this something in the device tree?

debian@beaglebone:~$ uname -r
4.14.108-ti-r115

root@beaglebone:~# dmesg |grep pru
[ 92.427760] pruss 4a300000.pruss: creating PRU cores and other child platform devices
[ 92.471521] remoteproc remoteproc1: 4a334000.pru is available
[ 92.471648] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[ 92.483689] remoteproc remoteproc2: 4a338000.pru is available
[ 92.483821] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully

root@beaglebone:~# ls /lib/firmware/am335x-pru0-fw
blinkLED.out

root@beaglebone:~# cat /sys/class/remoteproc/remoteproc1/firmware
am335x-pru0-fw

root@beaglebone:~# cat /sys/class/remoteproc/remoteproc1/state
offline

root@beaglebone:~# echo ‘start’ >/sys/class/remoteproc/remoteproc1/state
-bash: echo: write error: Invalid argument

root@beaglebone:~# echo ‘start’ > /sys/class/remoteproc/remoteproc1/state
bash: echo: write error: No such file or directory

waht can i do?

Just for the hallibut, I decided to experiment with making system() calls from inside my user space C code to mimic the makefile commands and use remoteproc. Seems to work just fine and one can /dev/null the output and capture the return codes to deal with stuff. Of course the user space code needs to be sudo’ed.

For example (“flushprint” just prints the constant char * and calls fflush(stdout), saves me some typing):

int LoadPRU1(bool verbose)
{
int retval = 0;

if (verbose) flushprint(“\ncopy PRU code…”);
retval = system(“sudo cp ./gen/sp.out “\
“/lib/firmware/am335x-pru1-fw >>/dev/null 2>>/dev/null”);
if (verbose)
{
if (retval == 0)
printf(“\tOK”);
else
printf(“\t%s”, strerror(retval));
fflush(stdout);
}

if (verbose) flushprint(“\nload PRU code…”);
retval = system(“echo am335x-pru1-fw | sudo tee ” \
“/sys/class/remoteproc/remoteproc2/firmware >>/dev/null 2>>/dev/null”);
if (verbose)
{
if (retval == 0)
printf(“\tOK”);
else
printf(“\t%s”, strerror(retval));
fflush(stdout);
}

return retval;
}

After further experimenting, it does seem that remoteproc is a bit on the rigid side. Moving on and learning to live with it for the time being.