Merge branch 'master' of http://gnuradio.org/git/gnuradio into uhd

1 files changed, 337 insertions, 0 deletions

diff --git a/usrp2/firmware/lib/db_bitshark_rx.c b/usrp2/firmware/lib/db_bitshark_rx.c
new file mode 100644
index 000000000..4c126de9b
--- /dev/null
+++ b/usrp2/firmware/lib/db_bitshark_rx.c
@@ -0,0 +1,337 @@
+/*
+ * 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;
+}
+