On Mon, Apr 23, 2007 at 11:17:59PM -0400, Nikhil wrote:
Hello,
I would like access to the I and Q output data (12 bits each) from ADC U601
using the debug headers from two RFX2400 daughterboards and was wondering if
someone could assist my understanding and tell me if what I am doing is
right or wrong prior to my actually implementing this on the USRP. Specific
questions are labelled with a Q in what follows.
Based on a couple of mailing list discussions I was able to figure out the
following. Output enable all the general purpose i/o pins referred to below:
* Each d'board has 16-bits of general purpose i/o.
* Setting the bit makes it an output from the FPGA to the d'board.
* This register is initialized based on a value stored in the
* d'board EEPROM. In general, you shouldn't be using this routine
* without a very good reason. Using this method incorrectly will
* kill your USRP motherboard and/or daughterboard.
*/
bool _write_oe (int which_dboard, int value, int mask);
u = usrp.sink_c(0, 64)
side0 = 0 # side A
u._write_oe(side0, 0x, 0x) # set all i/o pins as outputs
side1=1 # side B
u._write_oe(side1, 0x, 0x) # set all i/o pins as outputs
Oops! You've now smoked two RFX-2400 boards and/or the FPGA ;)
The daughterboard and the FPGA are both driving at least pin 2.
Though the pins are called general purpose i/o, that doesn't mean
the user should mess with all of them. Some of them are used by the
daugtherboard code to control or read status from parts on the
daughterboards. Which pins are safe for the user to mess with depends
on the design of the given daughterboard. Hence our scary warning on
_write_oe.
Step one: Look at the schematics for the RFX-2400 board and figure
out which of the 16 i/o pins are actually used by the Tx and Rx halves
of the transceiver daughterboard, and which ones are available for
your use. See which of the i/o pins actually makes it to the header
on the board.
Step two: Look again and check your work.
Step three: Look at the daughterboard code (db_flexrf.py). See what
it's doing to the various output enables and i/o pins. Does this
match your understanding of which pins are available for your use?
Step four: Confirm again which pins are safe for you to be messing with.
(I _believe_ that the high 7-bits are available for your use. It might
be 8, but I haven't looked at the schematics in a _long_ time. I'm not
kidding when I say _you_ should check the schematics.)
Now figure out new values for the calls to u._write_oe(...), that only
change the OE values of the pins that make it to the header and aren't
used for some other purpose by the code that's controlling the
daughterboard.
Next output enable the debug pins and enable them as debug outputs.
u._write_fpga_reg(FR_DEBUG_EN, ??) -- Q. I am not sure how to safely
output enable the debug outputs. Would 0xf do the job?
All the output enables are controlled using _write_oe.
FR_DEBUG_EN determines whether the debug pins are routed to the i/o
pins or whether the normal write_io and auto T/R values
make it to the header. See the bottom of master_control.v for the
details.
Given what you'll find out after you look at the schematics, no value
of FR_DEBUG_EN except for 0 is safe when you're using two RFX-2400 boards.
Q. I am also not sure how to assign the 12 I bits and the 12 Q bits
from U601 across
the daughterboard headers. Would the following in usrp_std.v
(master_control) do the trick?
.debug_0(rx_a_a[11:4]),.debug_1(rx_a_a[3:0]),
.debug_2(rx_b_a[11:4]),.debug_3(rx_b_a[3:0]),
);
Q. I was a little confused about the RX Nets beside J24 and TX
Nets beside J101 in the
2400 receiver and transmitter schematics, respectively. Can someone
please explain?
Thanks very much in advance!
-Nikhil
If you can get by with a single RFX-2400, my suggestion is that you
put it on the A-side, and then put a Basic Tx and a Basic Rx on the
B-side. Then you've got a total of 32 uncommitted i/o pins on the
B-side.
The FR_DEBUG_EN register wasn't designed to solve every possible
problem. It solved the one we had, which was getting debug info out
to a Basic Rx and/or Basic Tx ;)
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
