[USRP-users] Problems using dsplink on E100
alfayez at aol.com
Tue Feb 21 14:59:33 EST 2012
Well a more appropriate solution might be to have the GPP transfer the data to memory already accessible to the DSP instead of moving data to the DSP memory space directly would mean having to redo the device driver and Philip has already done a pretty good job writing a GPP driver :) DSPLink buffers are kind of slow I'm hoping to start looking at the CMEM (Continuous Memory) module soon as an alternative. The bad thing about CMEM, if I'm understanding it correctly, it provides just memory mapping which means you would be forgoing things such as automatic cache coherence and data structures for the GPP/DSP communications. If you want to go down this path you might find it helpful to look at some of the work I've done based on dsplink for reference sake
this link is for a general wiki for gpp/dsp omap3530 stuff and if you access my main github branch you can download all the code. If you want to do something from scratch it's worth looking in Syslink, which wasn't available when I first started this work, but it's supposed to have similar performance to dsplink except it can support non-shared memory interfaces basically TI has released and plans to continue releasing multi-core processors which don't necessarily have a shared memory region between there processors which renders dsplink obsolete for future processors. Basically if you use dsplink you're fine using USRP E100 and E110 since they're OMAP3530 based, but if a future USRP E series uses a multicore processor or you switch to a difference platform using such processors you'll need to switch to syslink.
Almohanad (Al) Fayez
From: Philip Balister <philip at balister.org>
To: Stefano Speretta <s.speretta at isispace.nl>
Cc: usrp-users <usrp-users at lists.ettus.com>
Sent: Tue, Feb 21, 2012 12:17 pm
Subject: Re: [USRP-users] Problems using dsplink on E100
On 02/21/2012 12:04 PM, Stefano Speretta wrote:
> Actually we are just started playing with the E100. I tried using the
> ARm while also running a demodulation routine and
> it uses quite a lot of CPU, so we where thinking about offloading part
> of the computation to the DSP.
> In the short term I was thinking of using UHD to receive samples and
> pushing them straight to the DSP but we may also try
> to directly map the FPGA pins to the DSP and play directly there.... The
> second option is definitely interesting but I fear it
> requires quite a lot of work ... I tried googling around to see if
> somebody actually did something similar but I had no success.
This would be the best solution. However it means you need to learn a
lot about the DSP. You will also need to modify the device driver so the
ARM does not use the pins from the FPGA to start data transfers.
> On 2/21/2012 5:38 PM, Andre Puschmann wrote:
>> On 02/21/2012 04:24 PM, Stefano Speretta wrote:
>>> Here is the output:
>>> i-dsplink - 1:1_65_00_03-r0i.9
>>> ti-dsplink-examples - 1:1_65_00_03-r0i.9
>>> ti-dsplink-module - 1:1_65_00_03-r0i.9
>>> We also tried the module you sent us and it works!
>> Great! What was special about it Philip? I guess you've compiled it for
>> your kernel?
>> Stefano, you mentioned you wanted to use the DSP for off-loading stuff.
>> Are you just beginning or have you or anybody else already done
>> something? Is the memory used by the FPGA to exchange bits between GPP
>> and FPGA accessible by the DSP already? Are there any UHD changes
USRP-users mailing list
USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users