MacPorts just upgraded SDCC from 2.9.0 to 3.0.0, which seems to have
changed the install names of various of the executables including the
one required by USRP: asx8051 -> sdas8051. I haven’t verified that
these executables work equivalently; I’ll try to do that tonight. Has
anyone tried doing this version yet with GNU Radio? - MLD
On 11/22/2010 01:07 PM, Elvis D. wrote:
Hi Michael,
On Nov 23, 2010, at 1:02 AM, Michael D. wrote:
MacPorts just upgraded SDCC from 2.9.0 to 3.0.0, which seems to have changed
the install names of various of the executables including the one required by
USRP: asx8051 -> sdas8051. I haven’t verified that these executables work
equivalently; I’ll try to do that tonight. Has anyone tried doing this version
yet with GNU Radio? - MLDIs SDCC really necessary to work with the UHD drivers on Mac OS X ?
For UHD, binaries to all FPGA and firmware images are posted online. The
library does not require anyone to build them to use a USRP device.
Now, the gnuradio usrp driver does have this requirement. I might
suggest that somebody take the sdcc requirement out of the driver and
just check-in the built images (they have not changed in years).
-Josh
Hi Michael,
On Nov 23, 2010, at 1:02 AM, Michael D. wrote:
MacPorts just upgraded SDCC from 2.9.0 to 3.0.0, which seems to have changed the
install names of various of the executables including the one required by USRP:
asx8051 -> sdas8051. I haven’t verified that these executables work equivalently;
I’ll try to do that tonight. Has anyone tried doing this version yet with GNU
Radio? - MLD
Is SDCC really necessary to work with the UHD drivers on Mac OS X ?
Elvis D.
On Mon, Nov 22, 2010 at 5:19 PM, Josh B. [email protected] wrote:
required by USRP: asx8051 → sdas8051. I haven’t verified that these
that somebody take the sdcc requirement out of the driver and just check-in
the built images (they have not changed in years).-Josh
In the meantime, you can remove the problem for any personal installs
people are having by commenting out line 51 in config/grc_usrp.m4.
Michael, let me know what you find about about the new names, please.
Josh, we should talk next week on the specifics about removing this
dependency. It might be appropriate to wait for the mythical GRAND
RESTRUCTURE that’s been being kicked around.
Tom
Looks like the 3.0 series changes SDCC itself. Doing “make” in USRP
(after building dependencies) using SDCC 3.0 results in:
Making all in lib
sdcc -mmcs51 --no-xinit-opt -I…/…/…/…/…/usrp/firmware/include -c
…/…/…/…/…/usrp/firmware/lib/delay.c -o delay.rel
…/…/…/…/…/usrp/firmware/lib/delay.c:27: syntax error: token ->
‘_naked’ ; column 21
…/…/…/…/…/usrp/firmware/lib/delay.c:29: warning 197: keyword ‘_asm’
is deprecated, use ‘__asm’ instead
…/…/…/…/…/usrp/firmware/lib/delay.c:31: warning 197: keyword
‘_endasm’ is deprecated, use ‘__endasm’ instead
Other keywords it wants to “__” include {at, sbit, xdata, and sfr}.
It doesn’t seem like pursuing this path is useful since SDCC 2.4 through
2.9 work just fine with the current USRP and UHD will be replacing it
anyway. Seems like Josh’s solution will be the most robust as a current
solution, so that’s what I’d vote for.
That said: the replacement 8051 assembler (“sdas8051”) is used only in
“usrp/firmware/src/usrp2/Makefile”, but it does seem to work correctly.
- MLD