数字 I/O 管脚控制问题
[ <<
数字上变频（DUC）
| ^
USRP FAQ 首页 ^ |
子
板 >>
]
- I am using the daughterboard’s DEBUG IO pins, and I am
connecting them to
my logic analyzer. I have to enter the threshold value in my logic
analyzer. I
can choose between TTL (1.4V) CMOS (2.5V) ECL (- 1.3V). I am not sure
which one
to choose. Right now I have it set to a user value of 3.30V, is that the
right
choice?
All the signals are LVCMOS, 0 to 3.3V. The correct threshold is 1.65V
(3.3V/2)
- I generated a signal using the usrp_siggen.py function and
tried to use
the IO pins on the basic TX board to monitor the digital output on a
logic
analyzer but it seems that no signal goes to those pins. Is there
something I
need to change in the verilog code to be able to use the debug IO pins?
There are two ways to control the I/O pins, either from the host, or
from
within the FPGA.
Method A:
To control them from the host no changes are required in
the
verilog. From python you need to tell it to "output enable" the pins you
are
interested, and then write whatever values you like to them:
From gr-usrp/src/usrp1.i: /*!
*
\brief Write direction register (output enables) for pins that go to
daughterboard.
*
* \param which_dboard [0,1] which daughterboard
*
\param value value to write into register
* \param mask which bits
of value
to write into reg
*
* Each daughterboard has 16-bits of general
purpose
i/o.
* Setting the bit makes it an output from the FPGA to the
daughterboard.
*
* This register is initialized based on a value
stored
in the
* daughterboard 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);
/*!
* \brief Write
daughterboard i/o pin value
*
* \param which_dboard [0,1] which
daughterboard
* \param value value to write into register
*
\param mask
which bits of value to write into reg
*/
bool write_io (int
which_dboard, int value, int mask);
/*!
* \brief Read
daughterboard
i/o pin value
*
* \param which_dboard [0,1] which daughterboard
*
\returns register value if successful, else READ_FAILED
*/
int
read_io
(int which_dboard);
E.g., # Assumes Basic_Tx in slot A. Do
not do
this blindly! Output enabling all the i/o pins
# on other
daughterboards
will cause problems (burn up daughterboard and/or FPGA)
u =
usrp.sink_c(0, 64)
side = 0 # side A
u._write_oe(side, 0xffff,
0xffff) #
set all i/o pins as outputs
counter = 0
while 1:
u.write_io(side,
counter, 0xffff)
counter = (counter + 1) &
0xffff
Method B:
If however, you're trying to control the debug pins from the FPGA,
you'll
need to output enable them from the host, and enable them as debug
outputs. You
do the last step by writing to the FR_DEBUG_ENABLE FPGA register:
From usrp/firmware/include/fpga_regs_common.h: // If the corresponding bit is set, internal FPGA
debug
circuitry
// controls the i/o pins for the associated bank of
daughterboard
// i/o pins. Typically used for debugging FPGA designs.
#define
FR_DEBUG_EN 14
# define bmFR_DEBUG_EN_TX_A (1 << 0) // debug
controls
TX_A i/o
# define bmFR_DEBUG_EN_RX_A (1 << 1) // debug
controls RX_A
i/o
# define bmFR_DEBUG_EN_TX_B (1 << 2) // debug controls
TX_B i/o
# define bmFR_DEBUG_EN_RX_B (1 << 3) // debug controls RX_B
i/o
These defines are available in python like this: from usrp_fpga_regs import *
u =
usrp.sink_c(0, 64)
u._write_oe(0, 0xffff, 0xffff)
u._write_fpga_reg(FR_DEBUG_EN,
bmFR_DEBUG_EN_TX_A)
- I would appreciate any suggestions on how to connect outputs
from the
FPGA to the debug pins (such as the io_tx_a output) in verilog?
Look at usrp/fpga/toplevel/usrp_std/usrp_std.v: wire [15:0] reg_0,reg_1,reg_2,reg_3;
master_control
master_control
(
.master_clk(clk64),.usbclk(usbclk),
.serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
.tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
.tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
.enable_tx(enable_tx),.enable_rx(enable_rx),
.interp_rate(interp_rate),.decim_rate(decim_rate),
.tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
.rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
.tx_empty(tx_empty),
//.debug_0(rx_a_a),.debug_1(ddc0_in_i),
.debug_0(tx_debugbus[15:0]),.debug_1(tx_debugbus[31:16]),
.debug_2(rx_debugbus[15:0]),.debug_3(rx_debugbus[31:16]),
.reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3)
);
The arguments .debug_0(...) through .debug_3(...) are the signals
that get
connected to the debug pins.
debug_0 -> TX_A
debug_1 -> RX_A
debug_2 -> TX_B
debug_3
-> RX_B
- How do I assign the pins for the FPGA? I mean the external IO
pins.
The external IO pins should not have to be mapped if you use Matt's
Quartus
II project. It will already have the pins mapped to where they have to
be
mapped.
- I have the TV_RX board in slot B and Basic RX in slot A of
the USRP. I am
trying to get the raw A/D data that comes into the FPGA, out on the
daughter
card connector. I would like to use the 16-bit general purpose debug
pins from
the FPGA on the connector on Basic RX. However, I’d like to be careful
before I
write to the direction register using the _write_oe given that an
improper
setting can cause damage. My question is whether I can have both TV_RX
and Basic
RX boards plugged in, while I use the _write_oe? If yes, what is the
precaution
that I have to follow?
You are safe with both the basic boards and the TVRX, since they
don't drive
any of the pins.
- I have an application where I will need the USRP AUX digital
I/O to
control an antenna switching network at approximately 1 kHz frequencies.
How far
up the software chain does support for the USRP AUX digital I/O go? Is
there
much support for them at the python level?
There are several ways to do this. All of the daughterboard IO pins
can be
controlled from software, all the way up to the python application
level.
However, if you want the pins to change quickly, you need to do it in
the FPGA.
There is already a mechanism for antenna switching. Look in the auto_tr
code in
db_flexrf.py. Also you can use the gr_gpio.
gr-gpio is an extension to the normal USRP firmware, implemented as
an
alternative FPGA bit stream, using the existing USRP host code. With the
gr-gpio
component you can transmit and receive a digital stream to and from the
USRP
which is aligned with the existing analog stream. Digital data is sent
to or
received from the daughterboard GPIO pins and sacrifice one bit each
from the I
and the Q analog streams to transport the digital bits. See CompGrGpio.
- I would like access to I and Q output data (12 bits each)
from ADC U601
using the debug headers from two RFX2400 daughterboards. I Know that: /* Each daughterboard has 16-bits of general purpose
i/o.
* Setting the bit makes it an output from the FPGA to the
daughterboard.
* This register is initialized based on a value stored
in
the
* daughterboard 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, 0xffff, 0xffff) #
set all
i/o pins as outputs
side1=1 # side B
u._write_oe(side1, 0xffff,
0xffff) #
set all i/o pins as outputs
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 daughterboard 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.
- To enable debug outputs, I am not sure how to safely output
enable the
debug outputs. Would 0xf do the job? u._write_fpga_reg(FR_DEBUG_EN,
??)
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.
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.
[ <<
数字上变频（DUC）
| ^
USRP FAQ 首页 ^ |
子
板 >>
]
注：Digital I/O Pins Control Questions（原文出处，翻译整理仅供参考!） |
|
