markayoder / prucookbook Goto Github PK

Hello Mark,

Your work is of a great help but when trying to run through the examples, I couldn't find the header resource_table_empty.h in the latest tpru-software-support-package.
I am running a BB AI with bullseye, IOT image found here: https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280/8
Cloud9 is no more present in this release and it seems to break a lot of things, but as mentioned, above all, the header in question seems to be gone from TI's own package.
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/

So I'm now trying to make my way through the examples provided in the latest pru-software-support-package but it lacks a blink LED sample!

Will you be updating your cookbook to get rid of the cloud9 dependencies?

I'm following steps here https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_compiling_and_inserting_rpmsg_pru

I started with bone-debian-9.5-iot-armhf-2018-08-12-4gb.img.xz

I updated the wget operation to match my kernel version

debian@beaglebone:~/PRUCookbook/docs/05blocks/code/module$ wget https://github.com/beagleboard/linux/raw/4.14/drivers/rpmsg/rpmsg_pru.c
--2019-05-07 13:58:48--  https://github.com/beagleboard/linux/raw/4.14/drivers/rpmsg/rpmsg_pru.c
Resolving github.com (github.com)... 192.30.253.112
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/beagleboard/linux/4.14/drivers/rpmsg/rpmsg_pru.c [following]
--2019-05-07 13:58:48--  https://raw.githubusercontent.com/beagleboard/linux/4.14/drivers/rpmsg/rpmsg_pru.c
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9466 (9.2K) [text/plain]
Saving to: ‘rpmsg_pru.c.1’

rpmsg_pru.c.1                            100%[=================================================================================>]   9.24K  --.-KB/s    in 0.005s

2019-05-07 13:58:49 (1.71 MB/s) - ‘rpmsg_pru.c.1’ saved [9466/9466]

I did the make operation

debian@beaglebone:~/PRUCookbook/docs/05blocks/code/module$ make
make -C /lib/modules/4.14.65-ti-r72/build M=$PWD
make[1]: Entering directory '/usr/src/linux-headers-4.14.65-ti-r72'
  AR      /home/debian/PRUCookbook/docs/05blocks/code/module/built-in.o
  CC [M]  /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_client_sample.o
  CC [M]  /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_pru.o
  Building modules, stage 2.
  MODPOST 2 modules
  CC      /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_client_sample.mod.o
  LD [M]  /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_client_sample.ko
  CC      /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_pru.mod.o
  LD [M]  /home/debian/PRUCookbook/docs/05blocks/code/module/rpmsg_pru.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.14.65-ti-r72'

The insmod step failed...

debian@beaglebone:~/PRUCookbook/docs/05blocks/code/module$ sudo insmod rpmsg_pru.ko                                                                                
insmod: ERROR: could not insert module rpmsg_pru.ko: Unknown symbol in module

I looked in the logs

debian@beaglebone:~/PRUCookbook/docs/05blocks/code/module$ dmesg | tail
[   19.437958] configfs-gadget gadget: high-speed config #1: c
[   19.846949] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[   20.041197] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   20.175895] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   26.422324] random: crng init done
[   26.422349] random: 7 urandom warning(s) missed due to ratelimiting
[ 1308.937572] rpmsg_pru: loading out-of-tree module taints kernel.
[ 1308.938008] rpmsg_pru: Unknown symbol __register_rpmsg_driver (err 0)
[ 1308.938062] rpmsg_pru: Unknown symbol unregister_rpmsg_driver (err 0)
[ 1308.938131] rpmsg_pru: Unknown symbol rpmsg_send (err 0)

Do I have the wrong version of rpmsg_pru.c?

First of all thanks for making the book freely available. Two suggestions after trying out section 4.4.

1. Should indicate FTDI cable connect to P9_24 and P9_26 properly (not just indicate in the command). The text seems to suggest connect to the FTDI pin on the board, which will confuse less experienced readers like me.

2. Makefile use /tmp/pru0-gen as temporary folder, it will run into permission issue if not run at root. Suggest just put in local.

Problem
The example code for Section 6, gpio.pru0.c, does not run on the PocketBeagle. This code is first referenced in Section 3: Running a Program; Configuring Pins in the PRU Cookbook. In this section, the output for source setup.sh seems to configure P1_36 for the PocketBeagle while the subsequent execution of make seems to be running on a BeagleBone Black.

I believe the code runs correctly on the BeagleBone Black, blinking an LED attached to P9_11 (I do not have the hardware to test this). However, the code does not blink an LED attached to P1_36 on a PocketBeagle. It is possible that a different file is supposed to be used with the PocketBeagle, but I have not found such a file.

Looking at gpio.pru0.c, the reason the code is not working on the PocketBeagle is that the code is designed to blink an LED connected to GPIO0[30]. On the BeagleBone Black, this is P9_11 (as expected), but on the PocketBeagle this is not P1_36 as I initially assumed. Instead, GPIO0[30] is P2_05 on the PocketBeagle.

A seemingly simple solution would be to change source setup.sh to configure P2_05 instead of P1_36 on the PocketBeagle. Unfortunately, P2_05 is not connected to a PRU, so this will not work.

Potential Solutions
I can think of 4 potential solutions to this issue, all of which seem relatively simple.

1. I do not think is the case, but if gpio.pru0.c is not intended to be run on the PocketBeagle, this issue can be largely ignored. However, it would make sense to replace the output of source setup.sh in Section 3 with output from a BeagleBone Black to prevent confusion. Even if this is not the case, doing this might make sense for consistency.
2. A different GPIO pin (i.e. not GPIO30) can be selected for the BeagleBone Black. A GPIO pin should be selected that is connected to the PRU on both the BeagleBone Black and PocketBeagle. This would require minor modifications to gpio.pru0.c and setup.sh.
3. A separate PRU file can be written specifically for the PocketBeagle that toggles the output of GPIO3[14] (which is P1_36 on the PocketBeagle). This would require making a copy of gpio.pru0.c (e.g. gpio_pru0_pb.c) and making slight modifications to it. The user would then have to decide which file to use based on whether he/she is using a BeagleBone Black or a PocketBeagle.
4. The PRU code can be modified to behave differently when running on a BeagleBone Black vs. PocketBeagle. In particular, it would toggle GPIO0[30] when running on a BeagleBone Black and toggle GPIO3[14] when running on a PocketBeagle. This would involve modifying gpio.pru0.c.

I would be happy to draft a PR addressing this issue, I am just unsure of which of the above (or other) solutions would be best to pursue.

my device is beaglebone blue. I refer to the
when i When I execute this script :uart_setup.sh
export PRUN=0
export TARGET=uart1
echo PRUN=$PRUN
echo TARGET=$TARGET

Configure tx
config-pin P9_24 pru_uart

Configure rx
config-pin P9_26 pru_uart

then it will report error:
x$ config-pin P9.24 pru_uart
dash: echo: I/O error
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P9_24_pinmux/state
debian@beaglebone:/sys/devices/platform/ocp/ocp:P9_24_pinmux

Doesn't it need to be configured of the BBBLUE?
and how to start uart to send/receive data in bbblue？

Aim: run GCC with Clpru in BeagleBone Black.

Info:
I have BeagleBone Black and I run ws2812B LED strip with PRU. and merge/integrate other data with that to control the led pattern.

so I need help in change the compilation method or learn to integrate it into clpru.

Main code : led.pru0.c
as same : https://beagleboard.org/static/prucookbook/#blocks_neo1

second code : Data_fetch.c
This code use -l:librobotcontrol.so.1 library with GCC compiler to compile Data_fetch.c script. and have one method which provides the number of LEDs (0 to 90), this varies as per battery voltage.

Issue:
So the issue is: The main code compiler is clpru and the second code use GCC compiler for execution. So how do I communicate both codes? or shared resources.

Thank you I will appreciate your response.

Hi. Are there any plans to update this great resource for the BB AI, with its extra PRU units?

thank

Hi,

neo4.pru0.c and neo4.pru1.c build without any issue.

# turning neopixel on and off via /dev/rpmsg_pru30 work's
echo 10 10 10 0 > dev/rpmsg_pru30 ; echo -1 > /dev/rpmsg_pru30

# turning neopixel on and off via /dev/rpmsg_pru31 has no efffect
echo 10 10 10 0 > dev/rpmsg_pru31 ; echo -1 > /dev/rpmsg_pru31

active entries in uEnv.txt

grep ^[^#] /boot/uEnv.txt
uname_r=4.19.94-ti-r42
enable_uboot_overlays=1
disable_uboot_overlay_video=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
enable_uboot_cape_universal=1
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet

check P9_29 used by neo4.pru0.c and P9_16 used by neo4.pru1.c

config-pin -q P9_29
Current mode for P9_29 is:     pruout

config-pin -q P9_16
Current mode for P9_16 is:     default

config-pin  P9_16  pruout
ERROR: write() to /sys/devices/platform/ocp/ocp:P9_16_pinmux/state failed, No such device

What am I missing to make the second neopixel strip via pru1 work too?

Hello!
While looking at Table 4 in PRUCookbook/docs/05blocks/blocks.adoc, there are some strange pin#s in "Table 4. Mapping bit positions to pin names" in the "Black pin" column: "P9_92" and "P9_91". The P8 and P9 connectors only have 46 pins, so 92 and 91 seem out of range.

I got next errors while making Blinking a LED example:
root@beaglebone:/home/debian/PRUCookbook-master/docs/02start/code# make
Makefile:1: *** missing separator. Stop.

After the first error i had copied makefile from "../../03details/code/Makefile" manually and tried to use "make" command again:

root@beaglebone:/home/debian/PRUCookbook-master/docs/02start/code# make

• Stopping PRU 0
  stop
  CC hello.c
  "resource_table_empty.h", line 1: warning #1-D: last line of file ends without a newline
  "resource_table_empty.h", line 1: error #171: expected a declaration
  "hello.c", line 12: warning #12-D: parsing restarts here after previous syntax error
  "hello.c", line 28: error #20: identifier "GPIO1_CLEAR" is undefined
  2 errors detected in the compilation of "hello.c".

Compilation failure
Makefile:56: recipe for target '/tmp/pru0-gen/hello.obj' failed
make: *** [/tmp/pru0-gen/hello.obj] Error 1

Is it only new BeagleBone Black Kernel's problems?

version.sh :
git:/opt/scripts/:[73593ebe3b7d3cc381eeb502d45ccb33a6ec5e78]
eeprom:[A335BNLT00C02814BBBK2738]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-08-30]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.03-00002-gac9cce7 c6a]:[location: dd MBR]
kernel:[4.14.67-ti-r73]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI- 00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20180803.0-0rcnee0stretch+20180804]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0stretch+20180517]
pkg:[kmod]:[23-2rcnee1stretch+20171005]
pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0stretch+20180830]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev us ers systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/m mcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 1.109119] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 1.121264] gpio-of-helper ocp:cape-universal: ready
END

UPDATE:

In the end, I copied the resource_table_empty.h and Makefile files from the 03details and 05blocks folders , which paths were codded in the simillar files but in the 02start folder. After all of that, the compilation was completed, but now I get the following warning every time i try to run Makefile:
make: Warning: File 'Makefile' has modification time 2162757 s in the future

In the neo-rainbow.py example it looks like asterisks are getting translated to resulting in invalid python code.

Aim: Implement pthread.h (embedded c language) in beaglebone black using pru.

I implement PRUCookbook/docs/06io/code/gpio.pru0.c in BeagleBone Black(BBB).

As per my application get input parallel from gpio pin so I want to use thread.

I have to try to debug Makefile from /var/lib/cloud9/common/Makefile and add in LDFLAGS and also CFLAGS as
--lpthread , but is shows:- fatal error #1965: cannot open source file "pthread.h" due to in cfg-pru _pthread.h which support CPP. I am unable to understand this _pthread.h file.

Guide me:

1. how i use _pthread.h header file as same pthread.h file, any example.
2. how to add pthread.h header file in /var/lib/cloud9/common/Makefile .

Thank you I will Appreciate your Response.

Hmmm...is there a source for the cloud9 makefile?

debian@BeagleBone:~/PRUCookbook/docs/07more/code$ make
Makefile:1: /var/lib/cloud9/common/Makefile: No such file or directory
make: *** No rule to make target '/var/lib/cloud9/common/Makefile'. Stop.

Thanks!

I think a section on compiling and using Starterware on PRUs would be very useful.

For example, on this page the "prudebug - A Simple Debugger for the PRU" link points to https://markayoder.github.io/PRUCookbook/04debug/debug.html.html#debug_prudebug (incorrect) instead of https://markayoder.github.io/PRUCookbook/04debug/debug.html#debug_prudebug (correct).

I'm not familiar with Asciidoctor, but this looks like an error in the generation or link syntax in the .adoc files.

There are a handful of cases:

grep -ir '.html.html' .
./docs/05blocks/blocks.html:(<a href="../04debug/debug.html.html#debug_prudebug">prudebug - A Simple Debugger for the PRU</a>)
./docs/05blocks/blocks.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for configuring
./docs/05blocks/blocks.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for all
./docs/05blocks/blocks.html:(<a href="../01case/case.html.html#case_rgb_matrix">1.4. RGB LED Matrix - No Integrated Drivers</a>) and want to know
./docs/03details/details.html:<p>See <a href="../04debug/debug.html.html#_dmesg_hw">dmesg -Hw</a> to see how to tell if the PRU
./docs/04debug/debug.html:<p><a href="../05blocks/blocks.html.html#_memory_allocation">Memory Allocation</a> gives examples
./docs/04debug/debug.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for configuring
./docs/book.html:<a href="../05blocks/blocks.html.html#blocks_pwm">PWM Generator</a> for an example.</p>
./docs/book.html:<p>See <a href="../04debug/debug.html.html#_dmesg_hw">dmesg -Hw</a> to see how to tell if the PRU
./docs/book.html:<p><a href="../05blocks/blocks.html.html#_memory_allocation">Memory Allocation</a> gives examples
./docs/book.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for configuring
./docs/book.html:(<a href="../04debug/debug.html.html#debug_prudebug">prudebug - A Simple Debugger for the PRU</a>)
./docs/book.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for configuring
./docs/book.html:<p>See <a href="08ai/ai.html.html">Configuring pins on the AI via device trees</a> for all
./docs/book.html:(<a href="../01case/case.html.html#case_rgb_matrix">1.4. RGB LED Matrix - No Integrated Drivers</a>) and want to know
./docs/book.html:<a href="../05blocks/blocks.html.html#blocks_mapping_bits">Mapping bit positions to pin names
./docs/01case/case.html:<a href="../05blocks/blocks.html.html#blocks_pwm">PWM Generator</a> for an example.</p>
./docs/06io/io.html:<a href="../05blocks/blocks.html.html#blocks_mapping_bits">Mapping bit positions to pin names

Thanks for all your efforts. Just wanted to suggest that while discussing the PRU_UART (just as a mere debugging tool), mentioning the routing of PRU_software_UART (Tx) -> Hardware_UART (Rx) would be helpful.

Also, each PRU boasts 3 UARTs. The sample codes uart1.pru1_0.c and uart2.pru1_0.c don't specify how the software UARTs are selected (out of 3 per PRU), in the code.

Thanks