Add commands to Firefly task and set startup behavior.

[pwittich]

Add a few commands to the samtec firefly task.

1. add recv disable command. The receivers can also be disabled (like the transmitters currently are) to save more power. On the ECU014 parts this is control bytes 54 and 55). Need to look it up on other parts.
2. all firefly channels should be disabled by default to minimize the board power draw.
3. add a command to read out the status bytes
   • do we want to alarm on errors on these status bytes

Some more background about the SamTec Firefly code and how the board is organized.

There are a few different types of Firefly devices on the command module.

• 4 channel 25 G transceivers
• 12 channel 14 G transmitters
• 12 channel 14 G receivers
• 12 channel 25 G transmitters
• 12 channel 25 G receivers
  The 12 channel devices can be either the 25 G or 14 G speeds. The 4 channel transceivers are always 25 G. Each transceiver is connected to one of the two FPGAs.

The register maps are different on all these devices, so we have to be aware of what kind of a device we are talking about.

There are two separate I2C controllers used to control the Firefly modules: one to control those connected to the KU15P and one to control those connected to the VU7P. The I2C modules also sit behind I2C bus expanders since many of them have the same I2C address. The addressing for the devices is defined in this code location.

cm_mcu/projects/cm_mcu/FireFlyTask.c

Lines 50 to 76 in 79dfaba

	struct dev_i2c_addr_t ff_i2c_addrs[NFIREFLIES] = {
	{"K01 12 Tx GTH", 0x70, 0, 0x50}, //
	{"K01 12 Rx GTH", 0x70, 1, 0x54}, //
	{"K02 12 Tx GTH", 0x70, 2, 0x50}, //
	{"K02 12 Rx GTH", 0x70, 3, 0x54}, //
	{"K03 12 Tx GTH", 0x70, 4, 0x50}, //
	{"K03 12 Rx GTH", 0x70, 5, 0x54}, //
	{"K04 4 XCVR GTY", 0x71, 0, 0x50}, //
	{"K05 4 XCVR GTY", 0x71, 1, 0x50}, //
	{"K06 4 XCVR GTY", 0x71, 2, 0x50}, //
	{"K07 12 Tx GTY", 0x71, 3, 0x50}, //
	{"K07 12 Rx GTY", 0x71, 4, 0x54}, //
	{"V01 4 XCVR GTY", 0x70, 0, 0x50}, //
	{"V02 4 XCVR GTY", 0x70, 1, 0x50}, //
	{"V03 4 XCVR GTY", 0x70, 2, 0x50}, //
	{"V04 4 XCVR GTY", 0x70, 3, 0x50}, //
	{"V05 4 XCVR GTY", 0x70, 4, 0x50}, //
	{"V06 4 XCVR GTY", 0x70, 5, 0x50}, //
	{"V07 4 XCVR GTY", 0x71, 0, 0x50}, //
	{"V08 4 XCVR GTY", 0x71, 1, 0x50}, //
	{"V09 4 XCVR GTY", 0x71, 2, 0x50}, //
	{"V10 4 XCVR GTY", 0x71, 3, 0x50}, //
	{"V11 12 Tx GTY", 0x70, 6, 0x50}, //
	{"V11 12 Rx GTY", 0x70, 7, 0x54}, //
	{"V12 12 Tx GTY", 0x71, 4, 0x50}, //
	{"V12 12 Rx GTY", 0x71, 5, 0x54}, //
	};

The first field is a name; those devices that start with KU are connected to the Kintex KU15P and those that start with VU are connected to the VU7P.

Currently there are several different parts to the FireFlyTask.c code that do the following.

• loop over all firefly devices and read out the registers that need to be monitored continuously
• handle incoming messages, which can trigger individual registers read/write commands. The current list of commands that are handled are
  1. enable CDR register on one or all devices
  2. disable CDR register on one or all devices
  3. enable transmitters on one or all devices
  4. disable transmitter on one or all devices
  5. read or write an arbitrary control byte

Here is a proposed plan of action

• Do the first task to disable receivers by modeling the code on the transmitter disable code.

  cm_mcu/projects/cm_mcu/FireFlyTask.c

  Line 295 in 79dfaba

  static int disable_transmit(bool disable, int num_ff) // todo: actually test this

  Trigger this code by the same messages for enable/disable as shown here:

  cm_mcu/projects/cm_mcu/FireFlyTask.c

  Lines 438 to 443 in 79dfaba

  	case FFLY_DISABLE_TRANSMITTER:
  	disable_transmit(true, channel);
  	break;
  	case FFLY_ENABLE_TRANSMITTER:
  	disable_transmit(false, channel);
  	break;

  (Rename the FFLY_DISABLE_TRANSMITTER just as FFLY_DISABLE and similar for the enable.)
• call the disable functions at the start of the task, before the infinite loop.
• Extend the monitoring (which currently just reads out the temperature on each device) to include the status bytes.
  • figure out what status bytes are on each devices. If they are the same we are good. If they are different then we need to do something smarter.
  • adapt the code to go from monitoring only one piece of information to many
  • adapt the command line interface to make this data available
    • do we also need to send this to the Zynq?

[pwittich]

Resolved by #81