Forum: GNU Radio Raspberry Pi Activity?

Has anyone been using Gnu Radio on a Raspberry Pi lately? (just got one 
for Xmas :) )  Any special build procedures for 3.6.3?

@(^.^)@  Ed

Sent from my iPod

On 17 Jan 2013 08:57, Ed Criscuolo wrote:

> Has anyone been using
Gnu Radio on a Raspberry Pi lately? (just got one for Xmas :) ) Any
special build procedures for 3.6.3?
>
> @(^.^)@ Ed
>
> Sent from my
iPod
> _______________________________________________
>
Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

The rPI CPU is
so anemic, that running a GR stack on it doesn't make much sense.
Perhaps just a data-gathering part, connected to some hardware,
forwarding samples to somewhere else.

On 01/17/2013 08:57 AM, Ed Criscuolo wrote:
> Has anyone been using Gnu Radio on a Raspberry Pi lately? (just got one for Xmas 
:) )  Any special build procedures for 3.6.3?

Please remember the R-pi is an armv6 based processor with a vfp unit
(not a NEON SIMD unit). Do not expect much signal processing performance
from this.

Armv7 + NEON is much better.

Philip

On 1/17/13 10:35 AM, Philip Balister wrote:
> On 01/17/2013 08:57 AM, Ed Criscuolo wrote:
>> Has anyone been using Gnu Radio on a Raspberry Pi lately? (just got one for 
Xmas :) )  Any special build procedures for 3.6.3?
>
> Please remember the R-pi is an armv6 based processor with a vfp unit
> (not a NEON SIMD unit). Do not expect much signal processing performance
> from this.
>
> Armv7 + NEON is much better.
>
> Philip

I thought it has an Arm11!  From Wikipedia:

"The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),[3]
which includes an ARM1176JZF-S 700 MHz processor.... VideoCore IV
GPU,[12] and originally shipped with 256 megabytes of RAM, later
upgraded to 512MB."

Wikipedia also states:

"ARM11 is an ARM architecture 32-bit RISC microprocessor family which
introduced the ARMv6 architectural additions. These include SIMD media
instructions, multiprocessor support and a new cache architecture."

These would seem to imply that the R-Pi has SIMD instructions available.

In addition, the VideoCore IV GPU looks like it's a pretty capable
DSP in it's own, capable of running it's own applications without the
CPU.  Sounds like Volk could take advantage of it as well.

On 17 Jan 2013 11:20, Ed Criscuolo wrote:

> On 1/17/13 10:35 AM,
Philip Balister wrote:
>
>> On 01/17/2013 08:57 AM, Ed Criscuolo wrote:

>>
>>> Has anyone been using Gnu Radio on a Raspberry Pi lately? (just
got one for Xmas :) ) Any special build procedures for 3.6.3?
>> Please
remember the R-pi is an armv6 based processor with a vfp unit (not a
NEON SIMD unit). Do not expect much signal processing performance from
this. Armv7 + NEON is much better. Philip
>
> I thought it has an
Arm11! From Wikipedia:
>
> "The Raspberry Pi has a Broadcom BCM2835
system on a chip (SoC),[3]
> which includes an ARM1176JZF-S 700 MHz
processor.... VideoCore IV
> GPU,[12] and originally shipped with 256
megabytes of RAM, later
> upgraded to 512MB."
>
> Wikipedia also
states:
>
> "ARM11 is an ARM architecture 32-bit RISC microprocessor
family which
> introduced the ARMv6 architectural additions. These
include SIMD media
> instructions, multiprocessor support and a new
cache architecture."
>
> These would seem to imply that the R-Pi has
SIMD instructions available.
>
> In addition, the VideoCore IV GPU
looks like it's a pretty capable
> DSP in it's own, capable of running
it's own applications without the
> CPU. Sounds like Volk could take
advantage of it as well.
>
>
_______________________________________________
> Discuss-gnuradio
mailing list
> Discuss-gnuradio@gnu.org
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

What I've
heard, is that the GPU isn't, in any reasonable sense, "open". Which
means that it can only really be used as the video codec, and not the
GP-GPU you'd really like.

On 01/17/2013 11:20 AM, Ed Criscuolo wrote:
>>
>
> "ARM11 is an ARM architecture 32-bit RISC microprocessor family which
> introduced the ARMv6 architectural additions. These include SIMD media
> instructions, multiprocessor support and a new cache architecture."

ARM11 uses armv6 instruction set. Not sure where wikipedia is getting
the SIMD bit from. The Cortex-AX series uses armv7, an updated arm ISA
(instruction set architecture).

>
> These would seem to imply that the R-Pi has SIMD instructions available.
>
> In addition, the VideoCore IV GPU looks like it's a pretty capable
> DSP in it's own, capable of running it's own applications without the
> CPU.  Sounds like Volk could take advantage of it as well.
>

The GPU stuff is most likely closed source, so Volk will not be able to
use it.

Once again, the R-Pi is not an exciting new ARM processor. It is based
on older ARM technology. GNU Radio will run on it, but be prepared to do
a lot of work getting performance out of it. Your time would be better
spent improving GNU Radio on more modern ARM devices such as the
Cortex-A{8,9} processors.

Yes the R-Pi is cheap, but it is not a state of the art ARM device for
doing signal processing work.

Philip

On Thu, Jan 17, 2013 at 11:20 AM, Ed Criscuolo
<edward.l.criscuolo@nasa.gov> wrote:
> I thought it has an Arm11!  From Wikipedia:
>
> "The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),[3] which
> includes an ARM1176JZF-S 700 MHz processor.... VideoCore IV GPU,[12] and
> originally shipped with 256 megabytes of RAM, later upgraded to 512MB."

The architecture is ARM11 - the instruction set is ARMv6.

> "ARM11 is an ARM architecture 32-bit RISC microprocessor family which
> introduced the ARMv6 architectural additions. These include SIMD media
> instructions, multiprocessor support and a new cache architecture."
>
> These would seem to imply that the R-Pi has SIMD instructions available.

There are indeed SIMD instructions available for integer operations,
and the Pi may be fairly capable in fixed point operation. For
floating point, the VFPv2 coprocessor has a vector mode that speeds up
certain operations, but still runs serially. From a DSP architecture
standpoint, the floating point unit is dated and not particularly
interesting.

> In addition, the VideoCore IV GPU looks like it's a pretty capable
> DSP in it's own, capable of running it's own applications without the
> CPU.  Sounds like Volk could take advantage of it as well.

Access issues aside, that is the way the Raspberry Pi should be used.
The big, powerful GPU is the exciting part and there just happens to
be a usable ARM processor attached on the side.

  Thomas

On 17/01/13 14:53, mleech@ripnet.com wrote:
>
> The rPI CPU is so anemic, that running a GR stack on it doesn't make
> much sense.  Perhaps just a data-gathering part, connected to some
> hardware, forwarding samples to somewhere else.

I tested that using a TCP/UDP source/sink for bigger iron to connect to.
(USRP Source -> TCP Sink, TCP Source -> USRP Sink)

Better results than I expected. At native speed, I was able to do 250kHz
full duplex, with very few under/overflows.

I'm convinced that if I'd overclocked it, then it would have been
fine. This was on an original model B with only 256Mb of RAM, the
B2 models with 512Mb I haven't had the chance to test with gnuradio
(yet.)

As far as special build instructions go, I followed a post on this
list, and everything built fine. I don't know if the "extra" ./configure
flags etc have made it into the build system.


Best Regards

Iain

Marcus, Phillip, Thomas, Aylons, & Iain,

   Thanks for all the good ARM info.  Obviously ARM is not
my area of expertise.

   As for the R-Pi, yes its a toy.  I'm just casting about
for interesting things to do with it, and wondered if it,
combined with a B100 or a USRP1, might make up a low-power/
low-cost transceiver with just enough capability to make it
suitable for a small spacecraft.

  Hopefully, someone with time on their hands will feel challenged
enough to try and reverse-engineer the GPU driver code to the
point where it can be incorporated into volk.

   Meanwhile, it sounds like the Beagle Bone would be a better choice.


@(^.^)@  Ed

>
>  Hopefully, someone with time on their hands will feel challenged
> enough to try and reverse-engineer the GPU driver code to the
> point where it can be incorporated into volk.
>
>   Meanwhile, it sounds like the Beagle Bone would be a better choice.
>
>
I wonder if, like on x86-type systems, the GPU interface is high enough
latency that its tremendous throughput is tempered quite significantly 
by
   the high latency and "setup" costs.

There's good reasons that there haven't been any really
spectacularly-successful integrations of GPUs into GR flows -- it
doesn't actually work
   that well from a performance perspective.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org