[Discuss-gnuradio] [UHD] Coarse roadmap for USRP E310 Software

[Martin Braun]

Hi all E310/E312/E313 users,

I would like to focus people's attention to some changes we have just
started rolling out, and will continue to roll out over the next months.

Executive Summary
=================
- For those requiring *no* RFNoC support whatsoever, just plain RX/TX
and UHD support, we recommend sticking with the 3.9 LTS version of UHD
for now (this advice is for the E310/E312/E313 only!).
- Going forward, we will be moving the E310 to a more modern RFNoC
architecture, and start incorporating things we've learned from other
embedded USRPs.
- However, this means that certain features (most importantly, network
mode) will be unavailable for the time being on newer UHD versions until
the transition is complete.


Full Story
==========
As we've rolled out the USRP N310 and other devices using embedded
Linux, we have gotten a little smarter with respect to OpenEmbedded and
other embedded-Linux related topics. For example, the USRP N310 features
the MPM architecture, which moves a lot of the hardware controls onto
the device itself, as opposed to toggling every bit in every register
from within UHD, and we have a better way of creating file systems which
makes it easier for us to upgrade to newer OE and kernel versions.

The USRP E310, even though it was released years ago, is still a great
product, with an amazing form factor. Unfortunately, its software design
hasn't kept up with the times, and the currently shipping filesystems
have fairly old kernels, among other things. Over the course of the next
few months, we intend to remedy that. We will be taking the following steps:

1. Port all RFNoC code from E310 onto master branch. This means we no
longer support different architectures between the master and
rfnoc-devel branches (note: On X310, we did this for the 3.10 release).
The main downside of this is that it will disable network mode (i.e.,
the ability to run the E310 like an N210, with UHD running on a host
computer, over Ethernet).

2. Forward-port the E310 code to the same OE release as we use for N310.
Since this entails a major kernel upgrade, it will take some time to
have all the power management up to date. There may be periods of time
where the E312 (the battery-powered version) will have reduced
capabilities. We will send out more updates when we know more.

3. Forward-port the E310 code the same UHD software architecture as the
N310. Once this is complete, network mode will be back in place, albeit
with more capabilities. For RFNoC development in particular, this will
be useful, because full RFNoC support will be made available over
network mode (the bandwidth limitations for E310 network will remain the
same, we expect a nominal sampling rate of 1 Msps over network mode).

Timeline
========
We plan to complete these steps by the end of 2018. The first step,
however, has already been completed on master branch: Here, the E310 has
already been synchronized with the code from rfnoc-devel.

Once this transition is complete, we will be able to keep providing
updates for the E310 more easily than before, and they will stay in
lockstep with the N310 filesystem releases.

Note that since we're merging all of this into master branch, there will
be intermediate releases of UHD with different feature sets for the E310.


Which branch/release should I run?
==================================
If you are using none of the RFNoC features, i.e., you are simply doing
send() and recv() calls, then we recommend sticking with the UHD-3.9.LTS
branch.
If you are doing RFNoC development, then simply move from rfnoc-devel to
master branch, and everything else stays the same.


Why do all of this on master branch?
====================================
We could have considered running a side-branch (e310-devel or something
like that) to do all of these changes. However, our experience with
rfnoc-devel was that this actually delays the release of features, and
we have the safety net of the UHD-3.9.LTS branch. Also, one of the main
reasons to do this is to share code with other USRPs, and it's a lot
easier to keep things shared when you're only developing code on the
same branch.


Please let us know if you have any questions.

Regards,
Martin Braun