am335x_pru_package's Introduction
The USB-powered BeagleBoard is a low-cost, fan-less single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines.
am335x_pru_package's People
Forkers
derzzle modmaker jonnew thecankaya johndahl jaechoon2 cncbasher nycresistor rjw245 sagedevices urbov tmcguc pranjalv123 melhytec fhunleth rpaulo kevintlam roybellingan peter-washington ayonga jadonk gilen wizkidorg tstellanova moto-timo 2000db donny3000 dlitz olsonse vmayoral gburca rascalmicro tommy3001 n8vi beaglepilot lnagl mikelikespie manunited olemis gungorbasa dgesswein drahnr dkwey possiblybhavin rvega anilsakral andrecurvello celsopadilha oxullo liv-dumea hypnoagus rluckom anselbelisle hajmousa kkwekkeboom daniko outer-space-sounds kganev isalameh tingzhi muthmano-dev hzeller vishal64 yu1019594136 praisethefonz suresh-personal vorne slootsky hudsonwerks adamatom microdruid karteek-yv arielfernando dbolotin morely credentiality lmhualv shrabani1 shotspotter wensunshine iseguel ericxliu1990 fablab-leoben chadizzm zeekhuge sansci trigrass2 mirkix l4m4re wphermans glneo e-matteson jerryyip tadtruex cdsteinkuehler giuliomoro yifanz zultron xiexiaoji jiuzhuaxiongam335x_pru_package's Issues
speed of IEP clock (chapter 9 PRU_ICSS)
root@bbb22:~/BBB/hbridge/IEP# git remote -v
origin https://github.com/gomer-grondin/bbbiep.git (fetch)
origin https://github.com/gomer-grondin/bbbiep.git (push)
my BBB is a rev C.
above code seems to me to indicate that the clock on the IEP is closer to 1Ghz than 200Mhz as documented in the PRU_ICSS chap 9.
can anyone verify? or show me where my error is.
is anyone else working on / willing to collaborate on coordinating both PRU's on this clock?
thanks .. gomer
PRU to ARM interrupts are fired twice
Note: This is from http://e2e.ti.com/support/arm/sitara_arm/f/791/t/239735.aspx
Hi,
Maybe someone has seen this before, but I could not find it in any post. As far as I can see there is a bug in prussdrv.c in the git repository: https://github.com/beagleboard/am335x_pru_package.git
The problem is that when an interrupt is sent from a PRU to the ARM processor (using a beaglebone -> AM3359), the interrupt is first disabled in kernel-space, in uio_pruss.c/pruss_handler(). After the interrupts is delivered as an event to the user-space lib (prussdrv.c) the interrupt is enabled again, before it is cleared. I have in the attached patch moved the re-enabling of the interrupt from prussdrv_pru_wait_event() to prussdrv_pru_clear_event() right after the interrupt is cleared. This prevents duplicate interrupts. The implemetation in the patch is such that there is a linear search in the struct used to configure interrupts, to find the host number from the system event number. Maybe this is not good from a performance perspective ? Comments on the patch are appreciated from someone more familiar with the pruss driver/lib.
Attached is also a demo application that reproduceses the fault. When running strace on the PRU_demo application, one can clearly see that there are two returns from the read() call in prussdrv_pru_wait_event() for each interrupt sent from the PRU, if the patch is not applied.
As said before, any comments appreciated.
br Håkan
prussdrv_open() fails if filedescriptor=0 is the first available file descriptor in system.
If all file-descriptors are closed (say, we're running as daemon and have closed all file descriptors), prussdrv_open()
fails.
The reason is a flaw in the assumptions in the implementation of prussdrv.c
( https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c ): file-descriptors (prussdrv.mmap_fd and prussdrv.fd[i]) are initialized with zero and considered not opened/invalid when they are zero.
Of course, this assumption fails if all files have been closed before, thus the very first file descriptor in the system is, in fact, zero, so an open("/dev/uio0")
returns FD 0. This results in prussdrv_open()
to fail.
The whole file has to be changed so that the assumption of 'invalid filedescriptor' is changed to '-1' instead of 0. There are various ways to do that, so I let the maintainers choose what they prefer without suggesting patch for now.
(this was, indeed, a real world problem that surfaced in BeagleG. I've worked around it by re-opening file descriptors
hzeller/beagleg@042d1c4
)
To replicate
Here is a little test-program. With the close(0)
call in place, it will fail.
#include <stdio.h>
#include <unistd.h>
#include <prussdrv.h>
int main() {
// Close file-descriptor 0
close(0);
int ret = prussdrv_open(PRU_EVTOUT_0);
fprintf(stderr, "Return code=%d ", ret);
if (ret == 0) {
fprintf(stderr, "SUCCESS\n");
} else {
fprintf(stderr, "FAILURE\n");
}
return ret;
}
prussdrv_open open failed in BBGW
I got prussdrv_open open failed
when I run sudo ./PRU_memAcc_DDR_sharedRAM
.
How can I enable my pru on Beaglebone Green Wireless??
Ps: I have edit the device tree file and compile it
pruss@4a30000 {
....
status = "disabled";
....
};
Thanks
cross compiling with pru package
Hello there,
I was introduced to you package when reading Derek Molloys book.using hes instructions I have downloaded it and installed on my bbb. I could then compile c userspace code with yoir library on bbb and connect to the pru.
My problem is that I am using a remote system woth cross compiller and eclipse for app deployment and debugging. I havw copied the header and c filea to the eclipse project. I have also copied the 4 generated lib files tp my xcompiller lib folder. After that I was able to use lprussdrv linker flag.
The problem is that when I run the crossconpiled code, i get segfault when trying to open the .bin file within the code. When compilled on pru, that part od code works.
Could you please tell me what did I do wrong? How can i use the package from eclipse? I would really be gratefull for your help!
Fatal Error: base filename too long
When building the example_apps using the following command:
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps# make CROSS_COMPILE=""
I received the error:
PRU Assembler Version 0.84
Copyright (C) 2005-2013 by Texas Instruments Inc.
PRU_memAccess_DDR_PRUsharedRAM.p(64) Fatal Error: base filename too long in 'PRU_memAccess_DDR_PRUsharedRAM/PRU_memAccess_DDR_PRUsharedRAM.hp'
Aborting...
Pass 1 : 1 Error(s), 0 Warning(s)
When I shortened the length of the file
"PRU_memAccess_DDR_PRUsharedRAM.hp"
to
"PRU_memAcc_DDR_sharedRam.hp"
I received the better output:
PRU Assembler Version 0.84
Copyright (C) 2005-2013 by Texas Instruments Inc.
Pass 2 : 0 Error(s), 0 Warning(s)
Writing Code Image of 16 word(s)
I'm using a beaglebone black with kernel version:
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps# uname -a
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps#
where is the function "prussdrv_start_irqthread"?
From the API http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide#prussdrv_start_irqthread
i can find the function "prussdrv_start_irqthread", but I can't find it from the code, So how I can make a interrupt handler in my C code which running in ARM.
error: too few arguments to function 'prussdrv_pru_clear_event'
When making the example_apps
i get the following:
make CROSS_COMPILE=
mkdir -p bin
for dir in PRU_memAccess_DDR_PRUsharedRAM PRU_memAccessPRUDataRam PRU_PRUtoPRU_Interrupt; do make -C $dir CROSS_COMPILE="" LIBDIR_APP_LOADER="../../app_e
make[1]: Entering directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM'
gcc -Wall -I../../app_loader/include -D__DEBUG -O2 -mtune=cortex-a8 -march=armv7-a -c -o obj/PRU_memAccess_DDR_PRUsharedRAM.o PRU_memAccess_DDR_PRUshared
PRU_memAccess_DDR_PRUsharedRAM.c: In function 'main':
PRU_memAccess_DDR_PRUsharedRAM.c:162:5: error: too few arguments to function 'prussdrv_pru_clear_event'
../../app_loader/include/prussdrv.h:182:9: note: declared here
make[1]: *** [obj/PRU_memAccess_DDR_PRUsharedRAM.o] Error 1
make[1]: Leaving directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM'
make[1]: Entering directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam'
gcc -Wall -I../../app_loader/include -D__DEBUG -O2 -mtune=cortex-a8 -march=armv7-a -c -o obj/PRU_memAccessPRUDataRam.o PRU_memAccessPRUDataRam.c
PRU_memAccessPRUDataRam.c: In function 'main':
PRU_memAccessPRUDataRam.c:148:5: error: too few arguments to function 'prussdrv_pru_clear_event'
../../app_loader/include/prussdrv.h:182:9: note: declared here
make[1]: *** [obj/PRU_memAccessPRUDataRam.o] Error 1
make[1]: Leaving directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam'
make[1]: Entering directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt'
gcc -I../../app_loader/include -D__DEBUG -O2 -mtune=cortex-a8 -march=armv7-a -c -o obj/PRU_PRUtoPRU_Interrupt.o PRU_PRUtoPRU_Interrupt.c
PRU_PRUtoPRU_Interrupt.c: In function 'main':
PRU_PRUtoPRU_Interrupt.c:175:5: error: too few arguments to function 'prussdrv_pru_clear_event'
../../app_loader/include/prussdrv.h:182:9: note: declared here
PRU_PRUtoPRU_Interrupt.c:181:5: error: too few arguments to function 'prussdrv_pru_clear_event'
../../app_loader/include/prussdrv.h:182:9: note: declared here
make[1]: *** [obj/PRU_PRUtoPRU_Interrupt.o] Error 1
make[1]: Leaving directory `/root/pru/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt'
make: *** [all] Error 2
Tried on a BeagleBone (white) running kernel 3.8.13-bone35.2
and using Ubuntu FS. The whole process is described here.
Has anybody experienced this before? is there a workaround?
Thanks
Beaglebone blue: kernel 4-19 can't load/find PRU drivers
I can't seem to get the PRU modules loaded in a Beaglebone blue running recommended image "AM3358 Debian 10.3 2020-04-06 4GB SD IoT" from https://beagleboard.org/latest-images
I've followed instructions at
https://poushtickcoder.wordpress.com/2018/03/12/quadcopter-fc-dobby-beaglebone-blue-pru-tutorial-by-a-dummy-configuration/
and https://catch22eu.github.io/website/beaglebone/beaglebone-pru-uio/ and have tried various combinations of
- updating /opt/source/dtb-4.19-ti with git pull, make, make install
- updating /boot/uEnv.txt to set "dtb=am335x-boneblue.dtb"
- update-intramfs -u
- update_bootloader.sh
- updating /boot/uEnv.txt to set either
- uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
or also tried - uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
- uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
- creating /etc/modprobe.d/pruss-blacklist.conf with lines
blacklist pruss
blacklist pruss_intc
blacklist pru-rproc
In /var/log/syslog I get the errors
beaglebone systemd-modules-load[491]: Failed to find module 'pru_rproc'
beaglebone systemd-modules-load[491]: Failed to find module 'pruss_soc_bus'
rc_test_drivers gives
Kernel: 4.19.135-bone-rt-r55
BeagleBoard.org Debian Buster IoT Image 2020-04-06
Debian: 10.5
PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
PASSED: pwm0
PASSED: pwm1
PASSED: pwm2
PASSED: eqep0
PASSED: eqep1
PASSED: eqep2
ERROR: pru-rproc driver not loaded
PASSED: uart1
PASSED: uart2
PASSED: uart4
PASSED: uart5
PASSED: i2c1
PASSED: i2c2
PASSED: spi
PASSED: LED
ERROR: ADC iio driver not loaded
Currently running on a:
MODEL_BB_BLUE
Robot Control library Version:
1.0.5
sudo /opt/scripts/tools/version.sh
gives
git:/opt/scripts/:[20c080bc91f243ef852a704758788a31083b0f9e]
eeprom:[A335BNLTBLA21717EL001263]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-gc9b3922522]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblue.dts]
kernel:[4.19.135-bone-rt-r55]
nodejs:[v10.21.0]
device-tree-override:[dtb=am335x-boneblue.dtb]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C1-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
pkg:[bb-customizations]:[1.20200826.0-0~buster+20200826]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 1.038243] remoteproc remoteproc0: wkup_m3 is available
[ 1.169429] remoteproc remoteproc0: powering up wkup_m3
[ 1.169447] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[ 1.171550] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 0.748065] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[ 0.949847] pinctrl-single 44e10800.pinmux: pin PIN102 already requested by 48300180.eqep; cannot claim for ocp:P9_30_pinmux
[ 0.961134] pinctrl-single 44e10800.pinmux: pin-102 (ocp:P9_30_pinmux) status -22
[ 0.971344] pinctrl-single 44e10800.pinmux: could not request pin 102 (PIN102) from group pinmux_P9_30_spi_pin on device pinctrl-single
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
I'm not sure what else to test to try to get this working.
ERROR: pru-rproc driver not loaded
I've solve this issue before but I can't seem to figure it out with the latest images. There are several posts about this here but none of the solutions have worked for me. Well I haven't tried to blacklist anything but I'm hoping to avoid that. I have also ran the update_kernal.sh script but things don't work before or after.
Here is my output from version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBLA21712EL002897]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblue.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
kernel:[4.19.94-ti-r42]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-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.14.20200403.0-0rcnee0buster+20200403]buster+20200322]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0buster+20190327]buster+20200305]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 9.462088] remoteproc remoteproc0: 4a334000.pru is available
[ 9.471125] remoteproc remoteproc1: 4a338000.pru is available
[ 56.647658] remoteproc remoteproc2: wkup_m3 is available
[ 58.708194] remoteproc remoteproc2: powering up wkup_m3
[ 58.708229] remoteproc remoteproc2: Booting fw image am335x-pm-firmware.elf, size 217168
[ 58.708514] remoteproc remoteproc2: remote processor wkup_m3 is now up
dmesg | grep pru
[ 9.462088] remoteproc remoteproc0: 4a334000.pru is available
[ 9.462284] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[ 9.471125] remoteproc remoteproc1: 4a338000.pru is available
[ 9.471310] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[ 0.886191] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[ 1.095120] pinctrl-single 44e10800.pinmux: pin PIN102 already requested by 48300180.eqep; cannot claim for ocp:P9_30_pinmux
[ 1.106540] pinctrl-single 44e10800.pinmux: pin-102 (ocp:P9_30_pinmux) status -22
[ 1.114131] pinctrl-single 44e10800.pinmux: could not request pin 102 (PIN102) from group pinmux_P9_30_spi_pin on device pinctrl-single
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
pasm macro line counting is broken
When reporting an error in a macro pasm lists two line numbers: line where the macro is being expanded, and the macro line where error occurred (counting from the beginning of macro). The latter is not very useful - a direct file line number to jump to is what is needed. This is further compounded by the number being wrong, as the counting omits empty and comment-only lines.
BeagleBone Black - PRU; prussdrv_pru_clear_event (PRU_EVTOUT_1, PRU0_ARM_INTERRUPT);
Hello everyone,
I have an issue with clearing event using prussdrv_pru_clear_event (PRU_EVTOUT_1, PRU0_ARM_INTERRUPT); It does not clear the corresponding register.
I am not sure if it is on the HOST-side or the PRU-side. I found some posts reporting the same problem:
https://groups.google.com/forum/#!topic/beagleboard/e-Nqdngv9mo
https://e2e.ti.com/support/embedded/linux/f/354/t/477657
https://e2e.ti.com/support/arm/sitara_arm/f/791/t/479917
My HOST-code:
//
// testPRU.c
// gcc testPRU.c ‐o testPRU ‐lpthread ‐lprussdrv
//
// program to drive a sensor and display the sensor output in Linux userspace by sending an interrupt.
// written by Derek Molloy for the book Exploring BeagleBone Black and modified by me.
//
#include <stdio.h>
#include <stdlib.h>
#include <prussdrv.h>
#include <pruss_intc_mapping.h>
#include <pthread.h>
#include <unistd.h>
#define PRU_NUM 0
static void *pru0DataMemory;
static unsigned int *pru0DataMemory_int;
void *threadFunction(void *value){
do {
int notimes = prussdrv_pru_wait_event (PRU_EVTOUT_1);
unsigned int prudata = *(pru0DataMemory_int+2);
int num = ((int)prudata / (1 * 1));
int pruclear = prussdrv_pru_clear_event (PRU_EVTOUT_1, PRU0_ARM_INTERRUPT);
printf("%d %d %d\n",notimes, pruclear, num);
} while (1);
}
int main (void)
{
if(getuid()!=0){
printf("You must run this program as root. Exiting.\n");
exit(EXIT_FAILURE);
}
pthread_t thread;
tpruss_intc_initdata pruss_intc_initdata = PRUSS_INTC_INITDATA;
// Allocate and initialize memory
prussdrv_init ();
prussdrv_open (PRU_EVTOUT_0);
prussdrv_open (PRU_EVTOUT_1);
// Map PRU's INTC
prussdrv_pruintc_init(&pruss_intc_initdata);
// Copy data to PRU memory - different way
prussdrv_map_prumem(PRUSS0_PRU0_DATARAM, &pru0DataMemory);
pru0DataMemory_int = (unsigned int *) pru0DataMemory;
// Use the first 4 bytes for the number of samples
*pru0DataMemory_int = 10;
// Use the second 4 bytes for the sample delay in ms
*(pru0DataMemory_int+1) = 100000000;
// Load and execute binary on PRU
prussdrv_exec_program (PRU_NUM, "./testPRU.bin");
if(pthread_create(&thread, NULL, &threadFunction, NULL)){
printf("Failed to create thread!");
}
int n = prussdrv_pru_wait_event (PRU_EVTOUT_0);
printf("PRU program completed, event number %d.\n", n);
// printf("The data that is in memory is:\n");
printf("- the number of samples used is %d.\n", *pru0DataMemory_int);
printf("- the time delay used is %d.\n", *(pru0DataMemory_int+1));
unsigned int prudata = *(pru0DataMemory_int+2);
printf("- the last distance sample is %d.\n", prudata);
// raw_distance is in 10ns samples
// distance in inches = time (ms) / 148 according to datasheet
// float distin = ((float)raw_distance / (100 * 148));
// float distcm = ((float)raw_distance / (100 * 58));
// printf("-- A distance of %f inches (%f cm).\n", distin, distcm);
/* Disable PRU and close memory mappings */
prussdrv_pru_disable(PRU_NUM);
prussdrv_exit ();
return EXIT_SUCCESS;
}
My PRU-code:
// pasm -b testPUR.p
//
// PRUSS program to drive a HC-SR04 sensor and store the output in memory
// that can be read by a Linux userspace program when an interrupt is sent
// Writen by Derek Molloy for the book Exploring BeagleBone and modified by me.
.origin 0 // offset of start of program in PRU memory
.entrypoint START // program entry point used by the debugger
#define INS_PER_US 200
#define INS_PER_LOOP 2
#define SAMPLE_DELAY_1MS (1000000 * INS_PER_US) / INS_PER_LOOP
#define PRU0_R31_VEC_VALID 32;
#define PRU_EVTOUT_0 3
#define PRU_EVTOUT_1 4
#define PRU0_ARM_INTERRUPT 19
// Using register 0 for all temporary storage (reused multiple times)
START:
// Read number of samples to read and inter-sample delay
MOV r0, 0x00000000 //load the memory location, number of samples
LBBO r1, r0, 0, 4 //load the value into memory - keep r1
// Read the sample delay
MOV r0, 0x00000004 //the sample delay is in the second 32-bits
LBBO r2, r0, 0, 4 //the sample delay is stored in r2
MOV r3, 0
MAINLOOP:
// at this point the echo is now low - write the value to shared memory
MOV r0, 0x00000008 // going to write the result to this address
SBBO r3, r0, 0, 4 // store the count at this address
MOV r0, r2 // need a delay between samples
SAMPLEDELAY: // do this loop r2 times (1ms delay each time)
SUB r0, r0, 1
QBNE SAMPLEDELAY, r0, 0
// MOV R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_1
MOV R31.b0, PRU0_ARM_INTERRUPT+17
ADD r3, r3, 1 // increment the counter by 1
QBLT MAINLOOP, r1, r3 // loop if the no of iterations has not passed
END:
// MOV R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_0
MOV R31.b0, PRU0_ARM_INTERRUPT+16
HALT
My System:
root@beaglebone:~# uname -or
4.4.30-ti-r64 GNU/Linux
root@beaglebone:~# lsb_release -irc
Distributor ID: Debian
Release: 8.6
Codename: jessie
root@beaglebone:~# cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.4.30-ti-r64
#uuid=
#dtb=
##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb
dtb=am335x-boneblack.dtb
##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb
##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb
##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb
##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb
##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb
##cape-universale
#cmdline=coherent_pool=1M quiet cape_universal=enable
cmdline=coherent_pool=1M quiet
#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet cape_universal=enable video=HDMI-A-1:1024x768@60e
##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
uuid=1ee84d4f-1ca6-4df1-8272-2b712b64643e
root@beaglebone:~/dtb-rebuilder/src/arm# cat am335x-boneblack.dts
/*
Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
*/
/dts-v1/;
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
/* #include "am33xx-overlay-edma-fix.dtsi" */
#include <dt-bindings/display/tda998x.h>
/* #include "am335x-bone-jtag.dtsi" */
/* pruss: pick one: */
/*
/etc/modprobe.d/pruss-blacklist.conf
blacklist uio_pruss
*/
#include "am33xx-pruss-rproc.dtsi"
/*
/etc/modprobe.d/pruss-blacklist.conf
blacklist pruss
blacklist pruss_intc
blacklist pru-rproc
*/
/* #include "am33xx-pruss-uio.dtsi" */
#include "am33xx-pruss-uio.dtsi"
/ {
model = "TI AM335x BeagleBone Black";
compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
};
&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;
};
&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_pins>;
bus-width = <8>;
status = "okay";
};
&cpu0_opp_table {
/*
* All PG 2.0 silicon may not support 1GHz but some of the early
* BeagleBone Blacks have PG 2.0 silicon which is guaranteed
* to support 1GHz OPP so enable it for PG 2.0 on this board.
*/
oppnitro@1000000000 {
opp-supported-hw = <0x06 0x0100>;
};
};
&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */
AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */
AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_vsync.lcd_vsync */
AM33XX_IOPAD(0x8e4, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_hsync.lcd_hsync */
AM33XX_IOPAD(0x8e8, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_pclk.lcd_pclk */
AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en */
>;
};
nxp_hdmi_bonelt_off_pins: nxp_hdmi_bonelt_off_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */
>;
};
mcasp0_pins: mcasp0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_ahcklx.mcasp0_ahclkx */
AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2*/
AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
AM33XX_IOPAD(0x990, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a11.GPIO1_27 */
/* added */
AM33XX_IOPAD(0x834, 0x6) /* p8_11 pin13 */
>;
};
};
&lcdc {
status = "okay";
/* If you want to get 24 bit RGB and 16 BGR mode instead of
* current 16 bit RGB and 24 BGR modes, set the propety
* below to "crossed" and uncomment the video-ports -property
* in tda19988 node.
*/
blue-and-red-wiring = "straight";
port {
lcdc_0: endpoint@0 {
remote-endpoint = <&hdmi_0>;
};
};
};
&i2c0 {
tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
/* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
/* video-ports = <0x234501>; */
#sound-dai-cells = <0>;
audio-ports = < AFMT_I2S 0x03>;
ports {
port@0 {
hdmi_0: endpoint@0 {
remote-endpoint = <&lcdc_0>;
};
};
};
};
};
&mcasp0 {
#sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&mcasp0_pins>;
status = "okay";
op-mode = <0>; /* MCASP_IIS_MODE */
tdm-slots = <2>;
serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
0 0 1 0
>;
tx-num-evt = <32>;
rx-num-evt = <32>;
};
/ {
clk_mcasp0_fixed: clk_mcasp0_fixed {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <24576000>;
};
clk_mcasp0: clk_mcasp0 {
#clock-cells = <0>;
compatible = "gpio-gate-clock";
clocks = <&clk_mcasp0_fixed>;
enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
};
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "TI BeagleBone Black";
simple-audio-card,format = "i2s";
simple-audio-card,bitclock-master = <&dailink0_master>;
simple-audio-card,frame-master = <&dailink0_master>;
dailink0_master: simple-audio-card,cpu {
sound-dai = <&mcasp0>;
clocks = <&clk_mcasp0>;
};
simple-audio-card,codec {
sound-dai = <&tda19988>;
};
};
};
Migrate to remoteproc
All examples need to migrate to using the mainline kernel and remoteproc.
pasm_2.exe for windows
The last versión of pasm_2.exe (0.84) is not compatible with windows.
pasm: command not found
I wonder if this is the correct way of installing pasm & prussdrv
- root@beaglebone:/home/debian# git clone https://github.com/beagleboard/am335x_pru_package.git
- root@beaglebone:/home/debian# cd am335x_pru_package/
- root@beaglebone:/home/debian/am335x_pru_package# make
I've done this but then when I tried to run a blink.p file, it says, "pasm: command not found"
prussdrv_open open failed
I've been able to compile everything following these steps but i get the following error when trying to run the examples:
./PRU_memAccessPRUDataRam
INFO: Starting PRU_memAccessPRUDataRam example.
prussdrv_open open failed
`prussdrv_exec_program()` sometimes crashes if binary is larger than PRUSS_MAX_IRAM_SIZE
If you attempt to exec a binary larger than PRUSS_MAX_IRAM_SIZE
(8192 bytes) using prussdrv_exec_program()
, bad things happen.
Sometimes the exec appears to succeed, the loader program continues running, and (some part of) the binary runs on the PRU. Sometimes the loader program crashes.
I think the solution is to check the file size in prussdrv_exec_program_at()
and return -1 if it's too large. I can submit a pull request with that change, but I'm not sure how to compile and test the new version, so note that it is untested.
Simplified install
Any thoughts of splitting off a simplified pasm and lib release that you can just make install, like https://github.com/n8vi/bbb-pru?
"Instruction illegal with specified core version"
Jason, you asked me to file an issue here regarding some assembler problems I found.
Since then, I've done some more research and came to a rather disappointing
conclusion: The assembler does implement some of the new instructions (as described
in the TRM rev C), but most generate an error like:
"Instruction illegal with specified core version".
Disassembling the generated code shows the new instructions that are not
rejected to be aliases to old (V1) opcodes. E.g. the FILL instruction generates
a sequence of LDI instructions instead of only one XFR instruction.
This might explain why it has taken so much time to release the assembler,
code and documentation: It looks like all new functionality of the PRUSS (as
documented in the TRM rev C) is being revoked.
The question that remains is whether this is because the silicon has problems,
or that TI wants to keep this information confidential. And somehow, because of
the way this subject has been handled, I don't think we'll get an honest answer
on that question. Reminds me of the Intel Pentium floating point bug, way back!
Jason, thanks again for all the effort you've taken the get this information
accessible for the open source community, only to find yourself stuck between
a rock and a hard place...
-- Bas Laarhoven (aka ncbas, aka modmaker)
Linking error when attempting to run example app
I ran the following code:
cd am335x_pru_package/pru_sw/app_loader/interface
CROSS_COMPILE="" make
cd ../../utils/pasm_source
./linuxbuild
mv ../../utils/pasm ../../utils/pasm_2
cd ../../example_apps/
CROSS_COMPILE="" make
echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots
modprobe uio_pruss
cd bin
./PRU_memAccess_DDR_PRUsharedRAM
and on the last command I'm seeing the following linking error and I have no idea how to deal with it.
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps/bin# ./PRU_memAccess_DDR_PRUsharedRAM
./PRU_memAccess_DDR_PRUsharedRAM: error while loading shared libraries: libprussdrv.so: cannot open shared object file: No such file or directory
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps/bin#
And Yes, my PRU is enabled:
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps/bin# cat /sys/devices/bone_capemgr.8/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BeagleG
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01
root@beaglebone:~/am335x_pru_package/pru_sw/example_apps/bin#
PRU to ARM interrupts are fired twice (debian)
I'm noticing the latest-image (Debian 4-23-14 on BBB) has not fixed issue #3 but the patch is applied.
From the PRU I signal the host application with the following:
MOV r31.b0, PRU0_ARM_INTERRUPT + 16
In C I have a pthread listening as follows:
int c = 0;
int stop = 0;
void *EVT_0() {
do {
prussdrv_pru_wait_event(PRU_EVTOUT_0);
c++;
prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);
} while (stop == 0);
}
When printing 'c' the number of interrupts are doubled what they should be. Using 'cat /proc/interrupts' confirms the interrupts are doubled
prussdrv_pru_clear_event swap parameters
I had a problem using this function.
The function definition is:
int prussdrv_pru_clear_event (unsigned int host_interrupt, unsigned int eventnum);
and the example is
prussdrv_pru_clear_event ( PRU0_ARM_INTERRUPT, PRU_EVTOUT0 );
but this example doesn't work. To make it work I had to swap the parameters:
prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);
Thanks
Do we have to open an interrupt in order for the PRU to work?
int prussdrv_open(unsigned int host_interrupt)
expects that we pass an interrupt
number, but what if our program does not need interrupts at all, or if these are handled differently? However, if we do not call prussdrv_open
, then the internal __prussdrv_memmap_init()
will not be called and so further calls may fail.
So currently, my workaround is to call prussdrv_open(PRU_EVTOUT_0)
and then ignore the interrupt. I'd argue we should not be forced to open an interrupt fd
.
Or am I missing something?
where to register errata to am335xPruReferenceGuide.pdf
I've noticed but not noted at least a half dozen typo's / errors in this guide (June 2013). I'd be happy to record them for you if there is a definitive place for them. First example is page 58 where there is no difference in 'Operation' of MIN and MAX, and the only difference in the 'Definition' is the opcode.
o to slots permission denied
filenames mangled in *.dbg output
The *.dbg file output generated by this version of pasm mangles the filenames, making it cumbersome to use debugging utilities (which search for and cannot find the incorrectly named files). A simple test case is provided, which results in the following incorrect filenames in the test.dbg file:
Filename | test.dbg Filename |
---|---|
test.p | .test.p |
a.h | .a.h |
../b.h | ./..b.h |
machinekit@beaglebone:~$ mkdir PRU-Test
machinekit@beaglebone:~$ cd PRU-Test/
machinekit@beaglebone:~/PRU-Test$ touch a.h
machinekit@beaglebone:~/PRU-Test$ touch ../b.h
machinekit@beaglebone:~/PRU-Test$ echo -e '#include "a.h"\n#include "../b.h"\nMAIN: JMP MAIN\n' > test.p
machinekit@beaglebone:~/PRU-Test$ pasm -b -L -d -V2 test.p
PRU Assembler Version 0.86
Copyright (C) 2005-2013 by Texas Instruments Inc.
test.p(3) Warning: Using default code origin of 8
Pass 2 : 0 Error(s), 1 Warning(s)
Writing Code Image of 9 word(s)
machinekit@beaglebone:~/PRU-Test$ strings test.dbg
MAIN
.test.p
.a.h
./..b.h
machinekit@beaglebone:~/PRU-Test$
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.