Thank you for all of the help Greg, I was finally able to get one of the examples to compile and execute. I'm still doing a bit of reading with regards to the reference manuals to figure out the proper registers and values for everything. I did have a few left over questions though.
1) Is "config-pin" able to override the HDMI allocation on pin header 8 or is that something that needs to be taken care of in the master device tree that gets loaded? It seems whenever I activate the HDMI/emmc disable portion of the uEnv.txt it disables my ability to start and stop the PRUs with the echo command. The device is just no longer found, but if I can simply override those pin settings and switch them to PRU outputs without having to use anything in the uEnv.txt then that works just as well, even better if I don't have to mess with the device tree again haha. 2) My second question, is there a better way to execute tasks at specific timing intervals that having one PRU count and set bits in shared memory for the other PRU? I guess I am asking if there are internal timer interrupts that I could use to trigger events or ISRs? 3) Has anyone ever put a simplified RTOS on the PRUs or are they not capable of handling that? Seems like you could use a combination of both PRUs to accomplish some pretty cool timing or interrupt driven real time tasks. Thanks again for all of the help, I couldn't have done it with you guys! On Friday, November 18, 2016 at 12:51:05 PM UTC-5, Greg wrote: > > Go into the PRU support package examples directory. See if you can get > the PRU_Halt to compile. This is the simplest possible C program for the > PRU. > All you have to do is the command make, and this will kick off the process. > > You will need to have the PRU_CGT environment variable set and also a very > simple addition to the PRU compiler library directory (add a bin directory > and link to clpru). > I've got this covered in my PDF file. > > After these two changes, the Makefile included with the project should > successfully compile and produce a firmware binary. This will create a gen > directory. In the gen directory, there will be a .o file which you rename > to am335x-pru0-fw, and then copy this to /lib/firmware. You should be able > to rmmod pru_rproc, then modprobe pru_rproc, and then look at dmesg and see > a successful start of the firmware. > > You can look at the Makefile and reverse engineer the options used with > the clpru compiler to create a working firmware. > You can run clpru at the command line with all the options, but it is a > real mess! > Get out the PRU C Compiler manual to decode what all of the options do. > Then you can make a shell script to run the compiler. I used a shell > script initially, and then made it into a primitive Makefile. > I really could have stuck with the shell script, but I wanted to learn > about the make system. > > You will be developing your own "tool chain" which I don't think is too > different from that used to develop a "bare metal" C program. > You also get to deal with kernel modules and also the Linux operating > system. I think if you work through this, you will have > a good introduction to Linux embedded system design. Be warned that it > can really eat up hours and hours of your time! > > On Friday, November 18, 2016 at 10:39:06 AM UTC-5, Zach B wrote: >> >> ooooh that's my problem. I was only using >> pasm -b blink2.asm >> which doesn't link against anything. I had missed that because most of >> the other examples that I had read where using the UIO pru loader, which >> doesn't require any linking of the remoteproc. I had planned on switching >> to C in the future but I was using my simple assembly program to start. I >> guess I will just try modifying the example pru code gpio_toggle to toggle >> the pin I want as a first attempt. What is the proper way to link those >> files in during the assembly compilation process? >> >> Sorry if some of these questions are pretty basic I'm learning as I go >> through all of this. >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/68652736-9b08-449a-8ac4-116aa388a8f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
