--- /dev/null
+/*
+ * Copyright 2010 Free Software Foundation, Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include "db_bitshark_rx.h"
+#include <memory_map.h>
+#include <db_base.h>
+#include <hal_io.h>
+#include <mdelay.h>
+#include <lsdac.h>
+#include <clocks.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <string.h>
+#include <i2c.h>
+
+/* Note: Thie general structure of this file is based on the db_wbxng.c
+ codebase for the wbx daughterboard. */
+
+/* The following defines specify the address map provided by the
+ Bitshark USRP Rx (BURX) board. These registers are all accessed over I2C. */
+#define RF_CENTER_FREQ_REG 0x00
+#define RF_CHAN_FILTER_BW_REG 0x01
+#define RF_GAIN_REG 0x02
+#define BB_GAIN_REG 0x03
+#define ADF4350_REG 0x10
+#define SKY73202_REG 0x11
+#define CLOCK_SCHEME_REG 0x20
+
+/* The following table lists the registers provided by the Bitshark board
+ that are accessible over I2C:
+ --------------------------------------------------------
+ |RegAddr: 0x00-RF Center Freq register |
+ |4-bytes 0x00|
+ |4-byte unsigned RF center freq (in KHz)|
+ |RegAddr: 0x01-RF channel filter bandwidth register |
+ |4-bytes 0x00|
+ |4-byte unsigned RF channel filter bw (in KHz)|
+ |RegAddr: 0x02-RF gain register |
+ |7-bytes 0x00|
+ |1-byte signed RF gain (in dB)|
+ |RegAddr: 0x03-Baseband gain register |
+ |4-bytes 0x00|
+ |4-byte signed baseband filter gain (in dB)|
+ |RegAddr: 0x10-ADF4350 register |
+ |4-bytes 0x00|
+ |4-byte ADF4350 register value (actual ADF4350 reg addr embedded
+ within 4-byte value)|
+ |RegAddr: 0x11-SKY73202 register |
+ |5-bytes 0x00|
+ |1-byte reg 0 of SKY73202 |
+ |1-byte reg 1 of SKY73202 |
+ |1-byte reg 2 of SKY73202 |
+ |RegAddr: 0x20-Clock Scheme |
+ |3-bytes 0x00|
+ |1-byte indicating clocking scheme:
+ -0x00 -> BURX local TCXO off, BURX accepts ref clock from
+ USRP2 (freq of USRP2's ref clock specified in bytes 2-5)
+ -0x01 -> BURX local TCXO on, BURX uses its local TCXO as its ref
+ clock, TCXO signal output for use as phase lock for USRP2 |
+ |4-byte USRP2 ref clock freq in hz (only needed if byte 1 set to 0x00) |
+
+ ---------------------------------------------------------------------------
+
+ As an example, lets say the client wants to set an RF center freq of
+ 1000 MHz. In KHz, this translates to 1000000 (resolution is only down to
+ steps of 1 KHz), which is 0x000F4240 in hex. So the complete 9-byte I2C
+ sequence that the client should send is as follows:
+ byte 0: 0x00-register 0x00 is the target of the write operation
+ bytes 1-4: 0x00 (padding)
+ byte 5: 0x00 (MSB of the 1000000 KHz value, in hex)
+ byte 6: 0x0F
+ byte 7: 0x42
+ byte 8: 0x40 (LSB of the 1000000 KHz value, in hex)
+
+ How about another example...lets say the client wants to setup the clock
+ scheme to use scheme #1 where the 26 MHz TCXO on the BURX board is enabled,
+ and is provided to the USRP2 for it to phase lock to it as an external ref.
+ 26 MHz (i.e. 26 million), in hex, is 0x18CBA80.
+ So the complete 9-byte I2C sequence that the client should send is as follows:
+ byte 0: 0x20-register 0x20 is the target of the write operation
+ bytes 1-3: 0x00 (padding)
+ byte 4: 0x01 (indicating that clock scheme #1 is wanted)
+ byte 5: 0x01 (MSB of the BURX ref clk freq)
+ byte 6: 0x8C
+ byte 7: 0xBA
+ byte 8: 0x80 (LSB of the BURX ref clk freq)
+
+ Note: The endian-ness of 4-byte values used in I2C cmds is different on
+ USRP2 compared to USRP1.
+
+*/
+
+#define NUM_BYTES_IN_I2C_CMD 9
+#define I2C_ADDR 0x47
+
+bool bitshark_rx_init(struct db_base *dbb);
+bool bitshark_rx_set_freq(struct db_base *dbb, u2_fxpt_freq_t freq, u2_fxpt_freq_t *dc);
+bool bitshark_rx_set_gain(struct db_base *dbb, u2_fxpt_gain_t gain);
+bool bitshark_rx_set_bw(struct db_base *dbb, uint16_t bw);
+
+static bool set_clock_scheme(uint8_t clock_scheme, uint32_t ref_clk_freq);
+
+/*
+ * The class instances
+ */
+struct db_bitshark_rx db_bitshark_rx = {
+ .base.dbid = 0x0070,
+ .base.is_tx = false,
+ .base.output_enables = 0x0000,
+ .base.used_pins = 0x0000,
+ .base.freq_min = U2_DOUBLE_TO_FXPT_FREQ(300e6),
+ .base.freq_max = U2_DOUBLE_TO_FXPT_FREQ(4000e6),
+ .base.gain_min = U2_DOUBLE_TO_FXPT_GAIN(0),
+ .base.gain_max = U2_DOUBLE_TO_FXPT_GAIN(42),
+ .base.gain_step_size = U2_DOUBLE_TO_FXPT_GAIN(6),
+ .base.is_quadrature = true,
+ .base.i_and_q_swapped = true,
+ .base.spectrum_inverted = false,
+ .base.default_lo_offset = U2_DOUBLE_TO_FXPT_FREQ(0),
+ .base.init = bitshark_rx_init,
+ .base.set_freq = bitshark_rx_set_freq,
+ .base.set_gain = bitshark_rx_set_gain,
+ .base.set_tx_enable = 0,
+ .base.atr_mask = 0x0000,
+ .base.atr_txval = 0,
+ .base.atr_rxval = 0,
+ .base.set_antenna = 0,
+ .extra.bw_min = 660, /* in KHz, so 660 KHz */
+ .extra.bw_max = 56000, /* in KHz, so 56 MHz */
+ .extra.set_bw = bitshark_rx_set_bw
+};
+
+bool
+bitshark_rx_init(struct db_base *dbb)
+{
+ struct db_bitshark_rx_dummy *db = (struct db_bitshark_rx_dummy *) dbb;
+
+ clocks_enable_rx_dboard(true, 0);
+ /* hal_gpio_write( GPIO_RX_BANK, ENABLE_5|ENABLE_33, ENABLE_5|ENABLE_33 ); */
+ /* above isn't needed, since we don't have any GPIO from the FPGA */
+
+ /* setup the clock scheme to accept the USRP2's 100 MHz ref clk */
+ set_clock_scheme(0,100000000);
+
+ /* initial setting of gain */
+ dbb->set_gain(dbb,U2_DOUBLE_TO_FXPT_GAIN(20.0));
+
+ /* Set the freq now to get the one time 10ms delay out of the way. */
+ u2_fxpt_freq_t dc;
+ dbb->set_freq(dbb, dbb->freq_min, &dc);
+
+ /* set up the RF bandwidth of the signal of interest...Note: there
+ doesn't appear to be a standard way of setting this bandwidth
+ in USRP2-land (compared to USRP1-land, where we have the
+ straight-forward set_bw() method). Not sure why this is, but
+ for now, simply set the bandwidth once for the intended
+ application. */
+ db->extra.set_bw(dbb, 25000); /* 25 MHz channel bw */
+
+ return true;
+}
+
+bool
+bitshark_rx_set_freq(struct db_base *dbb, u2_fxpt_freq_t freq, u2_fxpt_freq_t *dc)
+{
+ struct db_bitshark_rx_dummy *db = (struct db_bitshark_rx_dummy *) dbb;
+ unsigned char args[NUM_BYTES_IN_I2C_CMD];
+ unsigned char val[4];
+ uint32_t freq_in_khz = (uint32_t)(u2_fxpt_freq_round_to_uint(freq)/1000);
+
+ if(!(freq>=db->base.freq_min && freq<=db->base.freq_max))
+ {
+ return false;
+ }
+
+ memset(args,0x00,NUM_BYTES_IN_I2C_CMD);
+ memcpy(val,&freq_in_khz,4);
+ args[0] = RF_CENTER_FREQ_REG;
+ args[5] = val[3];
+ args[6] = val[2];
+ args[7] = val[1];
+ args[8] = val[0];
+
+ i2c_write(I2C_ADDR, args, NUM_BYTES_IN_I2C_CMD);
+ /* Add a brief delay after each command. This only seems to be
+ necessary when sending a sequence of commands one after the other.
+ This issue appears to be specific to the USRP2, since it isn't
+ necessary on the USRP1. The 5 mS delay is a bit of
+ an emperical compromise: too short (say, 1 mS), and every once
+ in a great while a command will still be magically dropped on its
+ way out...too long (say, 500 mS) and higher-level apps such as
+ usrp2_fft.py seem to choke because the init sequence is taking
+ too long. So 5 mS was tested repeatedly without error, and deemed
+ reasonable. Not sure if this is an issue with the I2C master
+ code in the microblaze or some place else, and I hate magic
+ delays too, but this seems to be stable. */
+ mdelay(5);
+
+ *dc = freq;
+ return true;
+}
+
+bool
+bitshark_rx_set_gain(struct db_base *dbb, u2_fxpt_gain_t gain)
+{
+ struct db_bitshark_rx_dummy *db = (struct db_bitshark_rx_dummy *) dbb;
+
+ unsigned char args[NUM_BYTES_IN_I2C_CMD];
+ uint8_t final_gain = (uint8_t)(u2_fxpt_gain_round_to_int(gain));
+
+ if(!(gain >= db->base.gain_min && gain <= db->base.gain_max))
+ {
+ return false;
+ }
+
+ memset(args,0x00,NUM_BYTES_IN_I2C_CMD);
+ args[0] = RF_GAIN_REG;
+ args[5] = final_gain;
+
+ i2c_write(I2C_ADDR, args, NUM_BYTES_IN_I2C_CMD);
+ /* Add a brief delay after each command. This only seems to be
+ necessary when sending a sequence of commands one after the other.
+ This issue appears to be specific to the USRP2, since it isn't
+ necessary on the USRP1. The 5 mS delay is a bit of
+ an emperical compromise: too short (say, 1 mS), and every once
+ in a great while a command will still be magically dropped on its
+ way out...too long (say, 500 mS) and higher-level apps such as
+ usrp2_fft.py seem to choke because the init sequence is taking
+ too long. So 5 mS was tested repeatedly without error, and deemed
+ reasonable. Not sure if this is an issue with the I2C master
+ code in the microblaze or some place else, and I hate magic
+ delays too, but this seems to be stable. */
+ mdelay(5);
+
+ return true;
+}
+
+bool
+bitshark_rx_set_bw(struct db_base *dbb, uint16_t bw_in_khz)
+{
+ struct db_bitshark_rx_dummy *db = (struct db_bitshark_rx_dummy *) dbb;
+ unsigned char val[2];
+ unsigned char args[NUM_BYTES_IN_I2C_CMD];
+
+ if(!(bw_in_khz >= db->extra.bw_min && bw_in_khz <= db->extra.bw_max))
+ {
+ return false;
+ }
+
+ memset(args,0x00,NUM_BYTES_IN_I2C_CMD);
+ memcpy(val,&bw_in_khz,2);
+ args[0] = RF_CHAN_FILTER_BW_REG;
+ args[5] = val[1];
+ args[6] = val[0];
+
+ i2c_write(I2C_ADDR, args, NUM_BYTES_IN_I2C_CMD);
+ /* Add a brief delay after each command. This only seems to be
+ necessary when sending a sequence of commands one after the other.
+ This issue appears to be specific to the USRP2, since it isn't
+ necessary on the USRP1. The 5 mS delay is a bit of
+ an emperical compromise: too short (say, 1 mS), and every once
+ in a great while a command will still be magically dropped on its
+ way out...too long (say, 500 mS) and higher-level apps such as
+ usrp2_fft.py seem to choke because the init sequence is taking
+ too long. So 5 mS was tested repeatedly without error, and deemed
+ reasonable. Not sure if this is an issue with the I2C master
+ code in the microblaze or some place else, and I hate magic
+ delays too, but this seems to be stable. */
+ mdelay(5);
+
+ return true;
+}
+
+static bool
+set_clock_scheme(uint8_t clock_scheme, uint32_t ref_clk_freq)
+{
+ /* Set the clock scheme for determining how the BURX
+ dboard receives its clock. For the USRP2, there is really only
+ one way of doing this, which is to use the 100 MHz ref clk
+ on the USRP2 as its reference. However, it is possible to
+ use the BURX's 26 MHz TCXO as the external reference input to
+ the USRP, which would provide phase lock between our oscillator
+ and the USRP's 100 MHz oscillator. And since the BURX board
+ provides the ability to warp the oscillator, this may be
+ useful to some folks. Otherwise, the BURX board will always
+ just take the 100 MHz reference from the USRP2 as its reference.
+ */
+
+ unsigned char args[NUM_BYTES_IN_I2C_CMD];
+ char val[4];
+
+ if (clock_scheme > 1)
+ {
+ return false;
+ }
+
+ memcpy(val,&ref_clk_freq,4);
+ args[0] = CLOCK_SCHEME_REG;
+ args[4] = clock_scheme;
+ args[5] = val[3];
+ args[6] = val[2];
+ args[7] = val[1];
+ args[8] = val[0];
+
+ i2c_write(I2C_ADDR, args, NUM_BYTES_IN_I2C_CMD);
+ /* Add a brief delay after each command. This only seems to be
+ necessary when sending a sequence of commands one after the other.
+ This issue appears to be specific to the USRP2, since it isn't
+ necessary on the USRP1. The 5 mS delay is a bit of
+ an emperical compromise: too short (say, 1 mS), and every once
+ in a great while a command will still be magically dropped on its
+ way out...too long (say, 500 mS) and higher-level apps such as
+ usrp2_fft.py seem to choke because the init sequence is taking
+ too long. So 5 mS was tested repeatedly without error, and deemed
+ reasonable. Not sure if this is an issue with the I2C master
+ code in the microblaze or some place else, and I hate magic
+ delays too, but this seems to be stable. */
+ mdelay(5);
+
+ return true;
+}
+
projects / debian / gnuradio / blobdiff