Re: [Discuss-gnuradio] sparc <--> x86 data exchange

[Lamar Owen]

On Tuesday 20 December 2005 01:04, Eric Blossom wrote:
> I disagree.  But we can have the best of both worlds.
> When logging lots of binary diagnostic data to files, the last thing I
> want is for it to take longer.

The time to swap bytes or words in the output stream will be insignificant by 
three or four orders of magnitude compared to the disk's write performance. 
Yes, three or four orders of magnitude; byte-swapping is a single 
instruction, typically.  Disk write performance is the killer, and one or 
even a hundred instructions in the pipe aren't going to make a dent in the 
slow speed of disk.  And this is regardless of the caching used by the disks: 
I found by experimentation with a dual Xeon 3 GHz box, with a PCI Express 
caching U320 SCSI RAID controller, that the system is I/O (disk and USB, 
which have to share the same processor bus, unfortunately) bound, even when 
performing work on the data in the pipe.  

> There's nothing stopping anyone from writing:

>   gr_file_sink_big_endian
>   gr_file_sink_little_endian
>   gr_file_source_big_endian
>   gr_file_source_little_endian

Certainly.  But if I save a file on one arch it should be able to be played 
back on another without me having to write anything.  One of the keys of 
GNUradio is the fact that the scripts themselves are arch agnostic and 
portable across platforms; requiring different I/O blocks per platform breaks 
that.  

I mean, I could easily see something like an Xscale or MIPS embedded processor 
running a stripped down kernel and GNUradio for a portable software radio 
device.  A USB2 capable pocket PC or similar could actually have something 
like the SSRP or a half-USRP embedded, and with a color LCD could become a 
portable spec-an/oscope/etc.

So I think the byte-ordering thing is important, and I further think that 
regardless of platform that the input and output files always have the same 
byte order regardless of platform.

> Did a lot of it, long ago.  (Wrote a complete WYSIWYG editor for
> Unix in the days when a 25 MIPS workstation was a very cool thing to
> have).  Not the kind of work I'm particularly interested in doing
> these days.  Maybe it was the 90 hr work weeks ;)

The toolkits today are much better, but I agree with you.  My frontpanels on 
equipment I have made aren't works of art; the circuits inside might be, but 
the frontpanels certainly are not.

> Sounds like a good application to emulate.  Volunteers?

FWIW, I can provide screenshots of SpectraVue in operation.  Given time I 
might be able to emulate it; but I'd like to go past it, and that's where my 
abilities in graphics design fall apart.  And I'm more of a backend person, 
too, and much more interested in the radio astronomy aspects, which aren't 
even necessarily GUI in nature.

I did have a brainstorm early this morning, in that a GUI block-building app 
would be way cool, something like those Lego building apps where you can drag 
and drop blocks around.  Doing that for GNUradio would be seriously cool.  I 
don't have the foggiest idea at this point how to implement such a thing, but 
it would still be cool.  An IDE for GNUradio, with the Boa Constructor GUI 
builder, and a backend flowgraph builder that would let you wire GUI elements 
to block signals, or something like.  What one would do is be able to choose 
from a pallet of blocks, wire them together, and have the app generate the 
code to plug the GUI into.  

What I envision is something like what Xcircuit does for schematic capture and 
SPICE analysis (Xcircuit can generate the netlists to feed spice)... hmmm, 
Xcircuit is scriptable in Python...perhaps Xcircuit is already the frontend, 
but needs glue to tell it how to generate a flow graph rather than a spice 
netlist.  Take the circuit emulation of GNUradio to the next level, and 
design using circuit-level tools.  Of course, GNUradio is much higher level 
than spice, but I think the analogy holds pretty well.

> > manufacturers.  Frontpanel and functionality design are non-trivial.  But
> > with its solid foundation, GNUradio has the potential to make the guts
> > less of an issue, and the frontpanel/functionality can become the prime
> > goal.

> Nicely put.

Thank you.  

What I see GNUradio's niche, as the code currently stands, is a kit of lots of 
parts that you can wire together.  You need to learn how to solder (Python), 
you need to learn what each component does, and you need to a have a grasp of 
what you want the result to do.  Building devices from parts is non-trivial; 
image having to build those parts.  GNUradio is like a kit of IC's ready made 
that you need to wire together and solder (and test, and package, and...).  
It makes software radio easier to do, but it is still a kit.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu