Open joehohman opened 11 years ago
How did you compile this? I ran the linuxbuild from pasm/pasm_source, popped back up to the root directory and ran make. Did the modprobe and tried to run the dmx binary, but got an error message: prussdrv_open open failed.
Also, in dmx.c you changed the #define DMX_PIN? To what? For what pin? I tried (15) for GPIO_1_15, but it didn't make any difference in my execution of the dmx binary.
Any help is certainly appreciated. Thanks ahead of time.
Ok, so since my last post, I was able to get it working, although to be honest I hacked my way through it and there is probably a much easier way. Most of what I did came from adapting the following article to this project...
It seems that most of the issue I was having was due to the device tree on the BBB. To get past where you are stuck, I believe you need to enable the PRU in the device tree. (Step 1 in the article).
Also in step 1 (and elaborated in step 4) they describe how to enable pins for direct PRU output. I modified the pinctrl-single line to include "0x030 0x06" to change the pin mux of P8_12 to mode 6. Then I connected that pin to the input of the IC.
Now, here's where things get hack-ey, and hopefully boxysean can find a better way to do this when he gets his BBB, but I modified the dmx.p file to talk directly to the pin instead of going through GPIO. I did this by following each of his "MOV r6, GPIO1 | GPIO_CLEARDATAOUT" and "MOV r6, GPIO1 | GPIO_SETDATAOUT" lines with a "CLR r30.t14" and "SET r30.t14" line (respectively).
After this, I rebuilt and ran the binary and everything worked.
One issue I am still running into, however, is that if I attempt to send a large number of channels (somewhere over 300), the program in the PRU crashes. Not a big deal though since I only need to control 12 channels right now :)
Good luck, hope this helps!
Nice. It certainly did help. Now to write a nice pretty front-end, in a language in which I'm not nearly as clueless.
Many thanks - I'll be interested to see what needs to change once boxysean gets a hold of his BBB.
I am having issues with the Makefile in the Example_apps folder of the latest am3335x_PRU_package. I have a BBB running Angstrom 3.8.11 , May 8, 2013. When following closely all the steps in this blog (http://blog.boxysean.com/2012/08/12/first-steps-with-the-beaglebone-pru/), i get the following error:
Here is the log output when i try to execute this line:
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps# make CROSS_COMPILE=""
The result is the following , with an error that pops up at the end of the Makefile...
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_loader/lib" LIBDIR_EDMA_DRIVER="" INCDIR_APP_LOADER="../../app_loader/include" INCDIR_EDMA_DRIVER="" BINDIR="../bin"; done
make[1]: Entering directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM' make[1]:
../bin/PRU_memAccess_DDR_PRUsharedRAM' is up to date.
make[1]: Leaving directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM' make[1]: Entering directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam'
make[1]: ../bin/PRU_memAccessPRUDataRam' is up to date. make[1]: Leaving directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam'
make[1]: Entering directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt' make[1]:
../bin/PRU_PRUtoPRU_Interrupt' is up to date.
make[1]: Leaving directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt' for a_file in PRU_memAccess_DDR_PRUsharedRAM/PRU_memAccess_DDR_PRUsharedRAM.p PRU_memAccessPRUDataRam/PRU_memAccessPRUDataRam.p PRU_PRUtoPRU_Interrupt/PRU_PRU0toPRU1_Interrupt.p PRU_PRUtoPRU_Interrupt/PRU_PRU1toPRU0_Interrupt.p ; \ do \ ../utils/pasm_2 -V3 -b $a_file ; \ done ; \ mv *.bin bin 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_loader/lib" LIBDIR_EDMA_DRIVER="" INCDIR_APP_LOADER="../../app_loader/include" INCDIR_EDMA_DRIVER="" BINDIR="../bin"; done make[1]: Entering directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM'
make[1]: ../bin/PRU_memAccess_DDR_PRUsharedRAM' is up to date. make[1]: Leaving directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM'
make[1]: Entering directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam' make[1]:
../bin/PRU_memAccessPRUDataRam' is up to date.
make[1]: Leaving directory /home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam' make[1]: Entering directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt'
make[1]: ../bin/PRU_PRUtoPRU_Interrupt' is up to date. make[1]: Leaving directory
/home/root/Desktop/am335x_pru_package/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt'
for a_file in PRU_memAccess_DDR_PRUsharedRAM/PRU_memAccess_DDR_PRUsharedRAM.p PRU_memAccessPRUDataRam/PRU_memAccessPRUDataRam.p PRU_PRUtoPRU_Interrupt/PRU_PRU0toPRU1_Interrupt.p PRU_PRUtoPRU_Interrupt/PRU_PRU1toPRU0_Interrupt.p ; \
do \
../utils/pasm_2 -V3 -b $afile ; \
done ; \
mv .bin bin
/bin/sh: line 2: ../utils/pasm_2: No such file or directory
/bin/sh: line 2: ../utils/pasm_2: No such file or directory
/bin/sh: line 2: ../utils/pasm_2: No such file or directory
/bin/sh: line 2: ../utils/pasm2: No such file or directory
mv: cannot stat `.bin': No such file or directory
make: *\ [all] Error 1
I'm new to the BBB, Any ideas on how to fix this ?
Cheers guys, Jean-Francois
Ok, i've found the makefile bug... in the line 8:
PASM?=../utils/pasm_2 (original)
should be replaced with:
PASM?=../utils/pasm_linuxintel (new)
It now works ok!
This seems to be working on my BBB: https://github.com/boxysean/beaglebone-DMX/issues/2
Correction in my code must be: PASM?=../utils/pasm
but the execution step gives the error (prussdrv_open open failed). which can be removed by following this article: http://github.jfet.org/BBKNotes2.html look at "Getting the PRUSS working" section
All examples worked on BeagleBone Black except DMX. DMX example compiled and run with no errors, but no output on pin 3, any idea why?
I will try and reproduce what joehohman has done. He connected the input to pin 7 on P8 (GPIO 66) because pin 3 is used by the eMMC on the Black.
Ok I got this working on the BeagleBone black by changing 3 basic things.
Again, this was to work around a BeagleBone black dependency on P8 pin 3 for the emmc flash to work properly, something the original BeagleBone never had.
I took a fresh BeagleBone Black running Angstrom 3.8.13 out of the box, enabled PRUSS in the device tree. (from the other issues thread)
Then in /src/dmx.c
Change the DMX_PIN define from (6) to (12). Also change LOCAL_export_pin(38) to (44) to change the gpio numbers correctly. Also change the unexport.
Now for both BeagleBone white and black it "just works" off header P8 pin 12 (instead of P8 pin 3 from the original design).
I will post a video of this working shortly...
Both issues can be closed as far as I am concerned, several solutions have been posted.
BBB doing DMX on P8 pin 12: http://www.youtube.com/watch?v=zv1aAT-f78c
I will work on getting the README and dmx.c updated for others to use.
Hello! First of all, thank you so much for sharing this project!
I'm trying to implement this project on the BeagleBone Black, and I'm running into an issue. I'm able to run the "dmx" application without any errors, however, my DMX dimmer pack isn't receiving any signal. I've built the circuit to your specifications, with the exception of using larger sized components to fit into a breadboard. I also connected the input to pin 7 on P8 (GPIO 66) because pin 3 is used by the eMMC on the Black. After doing this, I edited dmx.c and recompiled. To troubleshoot, I connected the outputs to some LED's, and they do light-up when the "dmx" application is launched. They do seem to be lighting-up opposite each other; when the input wire is plugged-in, one is lit, when it's unplugged the other is lit. I imagine this is the correct behavior. Any ideas on what could be going wrong? Any help would be appreciated! I've spent the better part of a day tinkering with this in an attempt to get it working.