developing driver to use new hardware in GNU Radio

[Card, Stu]

(cross-posted to the 3 different sub-communities with relevant driver architectures)

I would very much like to use GNU Radio as a real time signal analysis environment with some Altera FPGA based hardware (not a general purpose SDR, more a test probe in a comm system).

Searching for information on porting GNU Radio to new hardware, I found
https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00535.html

That contains some good pointers, but was 4 years ago, so I wonder if there are any other places I should be looking for information on how to write a driver for my hardware, so I can drop a corresponding source block into GRC and get started with my signal processing?

My signal analysis will typically start with a scrolling spectrogram, such as is provided by fosphor (original GPU based gr-fosphor or later FPGA based rfnoc-fosphor). We can do the high rate (FFT, magnitude, log) in the FPGA: this would incline me to start with the rfnoc-fosphor software stack; but my hardware is not Ettus, it does not have a UHD interface, it is not Xilinx. So that pushes me towards writing a driver to go underneath gr-osmosdr: then I think I also would need to extend gr-osmosdr itself to make calls to that library, unless there is some sort of device driver abstraction with a dispatcher to different actual drivers? Searching for a framework that cleanly isolates the hardware specific device driver code from the higher layers, I found  SoapySDR: reviewing the description on the web, it looks very nice, and under active development; but as someone new to much of this, I am not yet competent to assist with that development, and am not clear on how complete and usable (by a n00b such as myself) SoapySDR is yet?

Thanks for any tips!

-- Stu Card <stu....@axenterprize.com>

[Josh Blum]

> framework that cleanly isolates the hardware specific device driver code
> from the higher layers, I found SoapySDR: reviewing the description on the
> web, it looks very nice, and under active development; but as someone new
> to much of this, I am not yet competent to assist with that development,
> and am not clear on how complete and usable (by a n00b such as myself)
> SoapySDR is yet?
>

Hi Stu,

One one of the reasons I made SoapySDR was to help out projects just
like this. With SoapySDR, devices are supported through support modules,
and once you write, build, and install said module -- your device is
usable in a bunch of different environments and APIs. The goal is to
give a lot of utility for doing a hardware wrapper once. Hopefully the
eases the burden on application and hardware developers.

GrOsmosdr comes with SoapySDR support, so any Soapy modules installed on
the system can be used within the GrOsmosdr source and sink blocks in
GNU Radio. In fact - quite a few of the hardware drivers supported
directly in GrOsmosdr are also supported through SoapySDR as well.

SoapySDR is a more than a gateway into GrOsmosdr, its also an API for
device users. So any supported device can be used in C, C++, python, and
network access. Given that, we also have multiple API hooks for low
level peripherals like GPIO, registers, SPI, etc -- In many cases, a
SoapySDR module has been an acceptable replacement for a low-level C
driver. And I have personally made great use of the python and network
hooks for developing and debugging embedded designs.

As far as streaming support goes, the streaming API should suit well as
it supports any number of independent multi or single channel streams.
We have a stream API for both read/write socket style and direct access
API for underlying DMAs or buffer queues. The data type can be anything
from contiguous samples to bounded packets of bytes.

In terms for usability, there are multiple hardware projects using and
relying on SoapySDR as an entry point into the SDR application
ecosystem, and using it directly under one of the API hooks. Also, the
current release of SoapySDR should be perfectly acceptable to develop
new hardware with. And most of the ongoing development is focused on API
additions for more low-level hooks to better support hardware
development and debugging.

I encourage you to checkout the list of modules on the sidebar of the
main wiki page. Some projects are quite simple, and are only composed of
several files (control and streaming hooks), and should stand as a good
example: https://github.com/pothosware/SoapySDR/wiki

If you have any questions feel free to ask, and please consider this
list a support resource for active development.

Thanks,
-josh

[Ian Buckley]

Stu,

It's very useable and well structured to help with a new H/W port. Actively being used on a number of commercial projects currently, including ones using Altera FPGA's

-Ian

_______________________________________________
Discuss-gnuradio mailing list
Discuss-...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Card, Stu]

Is there somewhere a list of the minimal set of functions that must be written in the device driver, to enable a device to be not only utilized within the SoapySDR framework, but also wrapped by the framework as a gr-osmosdr source block for use in GNU Radio?

[Josh Blum]

On 05/08/2016 09:08 PM, Card, Stu wrote:
> Is there somewhere a list of the minimal set of functions that must be
> written in the device driver, to enable a device to be not only utilized
> within the SoapySDR framework, but also wrapped by the framework as a
> gr-osmosdr source block for use in GNU Radio?
>

Hi Stu,

I put together a driver guide for this purpose:
https://github.com/pothosware/SoapySDR/wiki/DriverGuide

I hope it clarifies things.
Thanks,
-josh