New SVN commits

I've committed some more code to the svn repo at
svn://svn.geekisp.com/opensdr/beagle-sdr :

spi-utils contains some modified versions of spidev_test. dump_data
reads bytes from stdin and sends them over the SPI port while
simultaneously reading bytes over SPI and writing them to stdout.
peek_poke lets you read or write control registers on the AD9860/9862
ADC if you connect it to a SPI port. I'm not convinced that I have the
byte order absolutely (or portably) right in these, so use them at
your own risk.

gr-spi contains two blocks for GNU Radio: gr_spi.spi_source_s and
gr_spi.spi_srcsink_ss. They both provide a method called
open_spi(const std::string &device, int speed) to open a specified
device file for SPI transfers at a maximum rate of speed Hz, and
close_spi() to close the device. Their output is 16-bit shorts read
over SPI. spi_srcsink_ss also has an input port to let you send a
stream of data over SPI, while spi_source_s provides a method called
send_spi_command(const std::string &command) to let you feed it bytes
without having to connect it to a signal source.

gr-spi/misc contains simple flow graphs in Python using spi_source_s
and spi_srcsink_ss, and a .bb file for cross-compiling gr-spi under
OpenEmbedded. Put gr-spi_0.1.bb in a directory under
$OE_HOME/openembedded/recipes along with the tarball created by `make
dist-bzip2`, then bitbake gr-spi.

eastwood contains code for the FPGA on the (still-unnamed) board we're
building. Compile it with eastwood.vhd as the top-level entity, and it
will send samples from the ADC straight through to the DAC, while

Making use of the DSP on the BeagleBoard

Re: Making use of the DSP on the BeagleBoard

Hello, I'm new on this list! My name is João Felipe and I am also
working with the Beagleboard for SDR applications.

We are using another method to run code on the DSP. We use the
dspbridge module on Linux and libdspbridge to make GPP applications
communicate with the DSP. This method is described here [1] (the
"simplified" method). I wonder if anybody here used this method and
has comments or pros/cons on using it. For me, it looked easier than
having to adapt your DSP application to CodecEngine. A dummy
application is available here [2].

[1] http://elinux.org/BeagleBoard/DSP_Howto#Simplified
[2] http://github.com/felipec/dsp-dummy/tree/master

-- João

On Mon, Jul 6, 2009 at 6:51 PM, Ravi Mehra<ravishi@...> wrote:
> Srujan and I at MPRG have made some headway with using the DSP on the
> BeagleBoard.  The two predominant methods of using the DSP is either
> bitbaking Codec Engine which will install DSPLink or to install DSPLink from
> source.  The codec engine installation includes video and audio processing
> applications which are not needed for SDR work.  Additionally, the codec
> engine does not provide the tools needed to compile user applications.
> Therefore, installing DSPLink from source is the most efficient method.
>
> I have created a wiki which may be useful to anyone who wants to get started
> using the DSP.   The wiki shows how to install DSPLink, run it, and run some
> sample applications.  Once finished, the host system will have all the tools
> necessary to compile your own GPP/DSP applications.
>
> http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_DSPLink
>
> Please contact me if you have any questions or comments on the wiki.
>
> Ravi Mehra
>

FFT on NEON

Hello everyone,

I'm porting my software GPS receiver on the OMAP, therefore I need fast
signal processing libraries, and in particular FFTs.

I have somehow adapted an open source library to do radix2 butterfly using
ARM assembly. It works, but my 256 points fixed point 16 bit FFT still
takes about 60us. That's 12 times slower than 4.7us advertised with NEON!

Frustrated, I downloaded and compiled with the evaluation version of RVCT
the openMAX libraries, but I don't manage to link the object file with
code compiled with the CodeSourcery gnu toolchain.

I tried to translate the assembly, but unfortunately it's a very
challenging task for me.

Can someone point me in the right direction on this subject?
Should I keep working on my fixed point 16 bit FFT? Should I buy the ARM
toolchain and port all the software? Should I just give up and try using
the DSP maybe?

Thank you in advance for any reply, and good luck with the OpenSDR, which
I'm watching very closely.

Cheers,
Michele

Re: FFT on NEON

On 07-07-09 00:19, Michele Bavaro wrote:

> Should I buy the ARM
> toolchain and port all the software?

*Never* pay money for an opensource toolchain, and more to the point: 
codesourcery toolchains are broken.

regards,

Koen

Re: FFT on NEON

Hello Koen,

thank you for the reply. Do you have any evidence of the codesourcery
toolchains being broken?
If I understand correctly, your suggestion is then to buy RVCT and use
openMAX.

Cheers,
Michele

> On 07-07-09 00:19, Michele Bavaro wrote:
>
>> Should I buy the ARM
>> toolchain and port all the software?
>
> *Never* pay money for an opensource toolchain, and more to the point:
> codesourcery toolchains are broken.
>
> regards,
>
> Koen
>
>

Re: FFT on NEON

On 07-07-09 10:13, Michele Bavaro wrote:
> Hello Koen,
>
> thank you for the reply. Do you have any evidence of the codesourcery
> toolchains being broken?

Have a look at 
http://hardwarebug.org/2008/11/28/codesourcery-fails-again/ for the tip 
of the iceberg.

> If I understand correctly, your suggestion is then to buy RVCT and use
> openMAX.

No, use plain old gcc, that works fine

Re: FFT on NEON

Koen,

I've experienced small problems in converting a float to unsigned int, but
I thought that was quite a difficult explicit cast to translate.

Isn't the official gcc for arm the CodeSourcery toolchain? Did you build
the cross-compiler yourself? Can you link the assembly optimised openMAX
with gcc?

Please forgive the questions, but I've not much experience with this
subject yet.

Thank you for the collaboration,
Mic

> On 07-07-09 10:13, Michele Bavaro wrote:
>> Hello Koen,
>>
>> thank you for the reply. Do you have any evidence of the codesourcery
>> toolchains being broken?
>
> Have a look at
> http://hardwarebug.org/2008/11/28/codesourcery-fails-again/ for the tip
> of the iceberg.
>
>> If I understand correctly, your suggestion is then to buy RVCT and use
>> openMAX.
>
> No, use plain old gcc, that works fine
>
>

Re: FFT on NEON

Michele Bavaro wrote:
> Hello everyone,
> 
> I'm porting my software GPS receiver on the OMAP, therefore I need fast
> signal processing libraries, and in particular FFTs.
> 
> I have somehow adapted an open source library to do radix2 butterfly using
> ARM assembly. It works, but my 256 points fixed point 16 bit FFT still
> takes about 60us. That's 12 times slower than 4.7us advertised with NEON!

What open source FFT library? You could try posting the code and seeing 
if anyone has any suggestions. (Post the code the Beagle list also, 
there are some good NEON people there)

> Frustrated, I downloaded and compiled with the evaluation version of RVCT
> the openMAX libraries, but I don't manage to link the object file with
> code compiled with the CodeSourcery gnu toolchain.

What user space are you using? Angstrom or something else. You'll need 
to use a tool chain that matches your user space.

Philip

> 
> I tried to translate the assembly, but unfortunately it's a very
> challenging task for me.
> 
> Can someone point me in the right direction on this subject?
> Should I keep working on my fixed point 16 bit FFT? Should I buy the ARM
> toolchain and port all the software? Should I just give up and try using
> the DSP maybe?
> 
> Thank you in advance for any reply, and good luck with the OpenSDR, which
> I'm watching very closely.
> 
> Cheers,
> Michele
> 
> 
> 

Re: FFT on NEON

Hello Philip,

thank you for coming back on this subject.
I modified the library developed by Gregory Heckler, the source code is here:

http://github.com/gps-sdr/gps-sdr/tree/6153c01317f34a26b2fb41926505b9d97f764e90/objects

To give you an example, the DIT butterfly looks like this:

#define BUTTERFLY_FWD(_A, _B, _W)					\
  __asm__ ("LDR    r0, [%0]            \n\t"				\
	   "LDR    r2, [%1]            \n\t"				\
	   "MOV    r3, #0              \n\t"				\
	   "SHADD16  r0, r0, r3        \n\t"				\
	   "SHADD16  r2, r2, r3        \n\t"				\
	   "LDR    r3, [%2]            \n\t"				\
	   "SMUADX r5, r2, r3          \n\t"				\
	   "SMUSD  r4, r2, r3          \n\t"				\
	   "ADD    r5, r5, #8192       \n\t"				\
	   "ADD    r4, r4, #8192       \n\t"				\
	   "ASR    r4, r4, #14         \n\t"				\
	   "PKHBT  r3, r4, r5, LSL #2  \n\t"				\
	   "QSUB16 r2, r0, r3          \n\t"				\
	   "QADD16 r0, r0, r3          \n\t"				\
	   "STR    r0, [%0]            \n\t"				\
	   "STR    r2, [%1]            \n\t"				\
	   ::"r" (_A), "r" (_B), "r" (_W)				\
	   :"r0", "r2", "r3", "r4", "r5", "memory")

and just uses ARM assembly (NEON is complicated to use with this basic
radix2 implementation).

As user space, I am using the Angstrom image v0.92:

http://www.gumstix.net/overo-gm-images/v0.92/

on my Overo Water. I use the CodeSourcery 2009q1 free toolchain, even
though today I've been suggested to try something else by Koen.

Regards,
Michele

> Michele Bavaro wrote:
>> Hello everyone,
>>
>> I'm porting my software GPS receiver on the OMAP, therefore I need fast
>> signal processing libraries, and in particular FFTs.
>>
>> I have somehow adapted an open source library to do radix2 butterfly
>> using
>> ARM assembly. It works, but my 256 points fixed point 16 bit FFT still
>> takes about 60us. That's 12 times slower than 4.7us advertised with
>> NEON!
>
> What open source FFT library? You could try posting the code and seeing
> if anyone has any suggestions. (Post the code the Beagle list also,
> there are some good NEON people there)
>
>> Frustrated, I downloaded and compiled with the evaluation version of
>> RVCT
>> the openMAX libraries, but I don't manage to link the object file with
>> code compiled with the CodeSourcery gnu toolchain.
>
> What user space are you using? Angstrom or something else. You'll need
> to use a tool chain that matches your user space.
>
> Philip
>
>>
>> I tried to translate the assembly, but unfortunately it's a very
>> challenging task for me.
>>
>> Can someone point me in the right direction on this subject?
>> Should I keep working on my fixed point 16 bit FFT? Should I buy the ARM
>> toolchain and port all the software? Should I just give up and try using
>> the DSP maybe?
>>
>> Thank you in advance for any reply, and good luck with the OpenSDR,
>> which
>> I'm watching very closely.
>>
>> Cheers,
>> Michele
>>
>>
>>
>