Hi, Thanks Chris, it looks good if I use the prussdrv pruss_io setup. It looks like TI are pushing using rp_rpoc now instead of pruss_io, there seems to be an argument going on whether the pruss_io should be improved, or replaced with Remote Proc/Rpmsg . The kernel I have uses RpMsg/Remote Proc kernel objects.
... However if I am not having any joy with this I will try to rebuild the kernel to use prussdrv and useyour example as a guide. I'll struggle on for a day or so, it not I'll move to prussdrv. It looks as if you are doing what I need. Thanks again for replying. Cheers, Paul On Tuesday, September 13, 2016 at 6:13:23 PM UTC+1, Christopher Hopwood wrote: > > In addition, you will need to do the following to allocate some DDR memory > for the PRU: > modprobe uio_pruss extram_pool_sz=0x160000 > Keep in mind that since the PRU and ARM will now be sharing the bus, it > may slow down the system. Also I don't believe DDR memory access is > guaranteed to be deterministic like the other PRU commands. > > On Tuesday, September 13, 2016 at 12:09:09 PM UTC-5, Christopher Hopwood > wrote: >> >> Hi Paul, >> >> You may wish to see some code I wrote for a quadcopter project in >> college. One of the pieces of code used the PRU and shared DDR memory to >> transfer images from a camera to the ARM. >> >> >> https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/code/ControlAlgorithm/quadcopter_apps/camera >> >> This may be out of date information however. It has been a while since I >> used PRUs. But hopefully studying my code will be enough to get you started! >> >> Thanks, >> Chris >> >> On Tuesday, September 13, 2016 at 9:25:37 AM UTC-5, >> paulandre...@gmail.com wrote: >>> >>> Hi, >>> I am investigating the beagleboard black PRUs at the moment for data >>> acquisition and/or transmission. For context I'll explain what I want to >>> do. I want to use a 16 bit ADC/DAC at 100KSps. It is a half duplex system, >>> so I can use both PRUs to receive, then load new firmware and transmit. >>> Starting the transmission must be to 1 us accuracy. Hopefully that will >>> explain what I am trying to do. >>> >>> I am using the PRU Software package 4.0.2. My kernel is Linux >>> Beaglebone 4.4.9-ti-r25. I have the CCSv6 environment setup and I can build >>> and run examples on the PRU, and I have built a user space example (Pru Lab >>> 6 user space) and it is working fine sending strings to and from both PRUs >>> using RpMsg. Great so far.... >>> >>> I would like to extend the User space example to allow me to fill PRU >>> memory (basically Sine wave sample data to use as a carrier for modulation) >>> , or write directly from user space any samples I want to transmit. Also >>> any examples in user space using the pruss_intc.ko to send/receive >>> interrupts from the PRUs would be good. >>> >>> The data I want to fill into the PRU will fill most of the data memory >>> in the PRU, I don't want to have to load it up piece by piece through >>> RpMsg, which looks to be maximum 512 bytes per transfer. I am hoping to >>> trigger commands through RpMsg for the PRU to read/write data to shared or >>> ARM DDR memory. There are plenty of examples on the PRU side to read/write >>> to shared or DRR memory, so i should be able to plod through the examples >>> to create my code for the PRU. >>> >>> However I can't see any example on the ARM side. Is it possible for a >>> user space program to read/write to shared memory ? Or allocate a section >>> of DDR memory for the each PRU to write to that nothing else will touch ? >>> >>> Also once the ARM is through with writing to shared or DRR memory the >>> PRU generate a ARM Host interrupt (EVOUT1 to EVOUT7). Does >>> pruss_intc.kp map these interrupts to user space, or allow a callback >>> to be added ? >>> >>> I know a lot of questions, apologies if they are basic, new to this. >>> >>> Regards, >>> Paul >>> >> -- 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/f6a8935a-6128-4a76-b2df-c2a77a6609b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.