Merge remote branch 'bitshark/burx_support' into wip/burx_support

* bitshark/burx_support:
  Once and for all, here is the properly updated Makefile.am for the apps
  Updated db_bitshark_rx.c to the proper version that includes the

Conflicts:
	usrp2/firmware/lib/db_bitshark_rx.c

diff --combined usrp2/firmware/lib/db_bitshark_rx.c
index 30d457f029b0d9806210884dd435bf3d4f82feae,669bb7c49d9faa005199d6dccff4a18320e7d68b..72cafa2e9acb72484a947accee323c57dc4f6e15
--- 1/usrp2/firmware/lib/db_bitshark_rx.c
--- 2/usrp2/firmware/lib/db_bitshark_rx.c
+++ b/usrp2/firmware/lib/db_bitshark_rx.c
@@@ -154,16 -154,30 +154,30 @@@ bitshark_rx_init(struct db_base *dbb
      /* 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 */
      
+     /* The next set of initialization commands sent to the bitshark board
+        require 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, 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. */
+ 
      /* setup the clock scheme to accept the USRP2's 100 MHz ref clk */
      set_clock_scheme(0,100000000);
- 
+     mdelay(5);
      /* initial setting of gain */
      dbb->set_gain(dbb,U2_DOUBLE_TO_FXPT_GAIN(20.0));
-     
+     mdelay(5);
      /* 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);
- 
+     mdelay(5);
      /* 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
@@@ -171,7 -185,7 +185,8 @@@
         for now, simply set the bandwidth once for the intended
         application. */
      db->extra.set_bw(dbb, 25000);  /* 25 MHz channel bw */
-     
+     mdelay(5);
++
      return true;
  }
  
@@@ -227,7 -241,7 +242,7 @@@ boo
  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[4];
+     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)) 
@@@ -236,12 -250,10 +251,10 @@@
      }
      
      memset(args,0x00,NUM_BYTES_IN_I2C_CMD);
-     memcpy(val,&bw_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];
+     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);