SDCC 2.9 versus 3.0

Hello:

Currently GNU Radio 3.3 only supports SDCC 2.9. It does not yet support
SDCC 3.x. Why is this? What changed in the newer 3.x releases of SDCC?
What would need to change in GNU Radio to enable support for SDCC 3.x?
Is it worth doing that work? What would GNU Radio gain by supporting
SDCC 3.x? There must be some new features or capabilities in SDCC 3 that
would be useful to GNU Radio…

Steve McMahon

On 16/05/2011 10:50 AM, Steve M. wrote:

Hello:

Currently GNU Radio 3.3 only supports SDCC 2.9. It does not yet support SDCC
3.x. Why is this? What changed in the newer 3.x releases of SDCC? What would need
to change in GNU Radio to enable support for SDCC 3.x? Is it worth doing that
work? What would GNU Radio gain by supporting SDCC 3.x? There must be some new
features or capabilities in SDCC 3 that would be useful to GNU Radio…

Steve McMahon

SDCC is used only to compile the code for the FX2 for the USRP1. That
codebase is fairly static, and SDCC 3.0 doesn’t really bring much to the
table for that. The main change between SDCC 2.X and SDCC 3.X is that
some intrinsic 8051-specific type-qualifiers changed syntax between 2.X
and 3.X,
and the command names changed.

It’s fairly straightforward to mechanically convert between 2.X and 3.X
syntax–I’ve done that experimentally for FX2LIB, but I seriously don’t
have
the bandwidth at the moment to do this for the USRP1 code, and
realistically, that’s up to Ettus.

On Mon, May 16, 2011 at 3:50 PM, Steve M.
[email protected]wrote:

It’s unlikely that SDCC 3.x brings anything to the table that we need.
Since, as Marcus already said, SDCC is only used in the USRP code, it
has
very little impact on the project, especially considering that we are
moving
towards UHD, which does not depend on SDCC.

Tom

On Mon, May 16, 2011 at 4:42 PM, Marcus D. Leech [email protected]
wrote:

A minor clarification. You’d still need SDCC if you wanted to compile
the firmware image yourself that is in …/uhd/firmware/fx2. But most people
just use the as-distributed FX2 firmware images supplied by Ettus. It
looks like the code in …/uhd/firmware/fx2 is compatible with SDCC 2.X,
since
intrinsics like “xdata” haven’t been converted to “__xdata”, etc.

Good point, thanks. (I was thinking mostly on how it impacts GNU Radio
directly.)

Tom

On Mon, May 16, 2011 at 04:45:42PM +0100, Tom R. wrote:

Tom
Now I’m more confused. If SDCC is needed for the USRP1 firmware, it
should
be required to generate that. Otherwise, the test for SDCC should be
moot if
the firmware is available. Why does the build demand SDCC 2.9 if it is
not
required?


LRK
gr-user . ovillatx.sytes.net

On 16/05/2011 11:32 AM, Tom R. wrote:

It’s unlikely that SDCC 3.x brings anything to the table that we need.
Since, as Marcus already said, SDCC is only used in the USRP code, it
has very little impact on the project, especially considering that we
are moving towards UHD, which does not depend on SDCC.

Tom

A minor clarification. You’d still need SDCC if you wanted to compile
the firmware image yourself that is in …/uhd/firmware/fx2. But most
people
just use the as-distributed FX2 firmware images supplied by Ettus.
It looks like the code in …/uhd/firmware/fx2 is compatible with SDCC
2.X, since
intrinsics like “xdata” haven’t been converted to “__xdata”, etc.

What is SDCC used for? I just want to sure that I understand this
correctly. I think it’s used to compile the firmware that runs on the
Xilinx MicroBlaze CPU on the FPGA inside the USRP, USRP2, and USRP
N200/N210. (all USRPs have FPGAs inside with Xilinx MicroBlaze CPUs on
them) Normally, you don’t need to do this. Users download the latest
binary firmware image from the Ettus website and burn it to the SD
memory card (USRP2) or flash memory (USRP N200/N210) and run it. You’d
only really need SDCC if you want to modify the firmware and run a
customized version of it.

Could you please correct me where I’m wrong/inaccurate?

Thanks.

On 16/05/2011 12:58 PM, LRK wrote:

Now I’m more confused. If SDCC is needed for the USRP1 firmware, it should
be required to generate that. Otherwise, the test for SDCC should be moot if
the firmware is available. Why does the build demand SDCC 2.9 if it is not
required?

Matt could clarify the history on this, but “historical reasons”.

In the “classic” USRP1 days, the assumption was that you’d compile the
firmware from source, but the FPGA image was included in the
source tree, since not everyone would have the Altera FPGA compiler.

I’m not sure, but think the FPGA/Firmware for non-UHD USRP1 and UHD
USRP1 are the same.

What is SDCC used for? I just want to sure that I understand this correctly. I
think it’s used to compile the firmware that runs on the Xilinx MicroBlaze CPU on
the FPGA inside the USRP, USRP2, and USRP N200/N210. (all USRPs have FPGAs inside
with Xilinx MicroBlaze CPUs on them) Normally, you don’t need to do this. Users
download the latest binary firmware image from the Ettus website and burn it to
the SD memory card (USRP2) or flash memory (USRP N200/N210) and run it. You’d only
really need SDCC if you want to modify the firmware and run a customized version
of it.

Could you please correct me where I’m wrong/inaccurate?

Thanks.

You only need SDCC (or the equivalent ZPU version of GCC for USRP2/N2xx
under UHD) if you want to compile custom firmware.

SDCC is used only for the USRP1, which uses an 8051-variant called an
FX2, which has a built-in hardware USB implementation that
“goes real fast”.

Normally, you simply use the pre-compiled firmware and FPGA images that
you get from Ettus’ website.

In the early days I think Matt didn’t bother distributing the firmware
images, since you could always compile them from the source code
that came with Gnu Radio, using the SDCC 2.X compiler. With the
advent of binary-only packages for Gnu Radio, there had to be
a mechanism for the firmware images to be made available to you.

So, the firmware and fpga images are now always available from the Ettus
website. The matching source-code is part of a standard
UHD “git” checkout–but again, you can only rebuild them yourself if
you have the correct toolchains. So the overwhelming majority
of users just use the pre-built images. Users who want to do their
own custom firmware and FPGA will need to acquire the appropriate
toolchain, and compile.

My “build-gnuradio” script downloads the latest matching firmware
images, and installs them in the “right place”
(/usr/local/share/uhd/images),
along with fetching/building the latest UHD and GnuRadio.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium