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,
>> [email protected] 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 [email protected].
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.
