BI might be interested in having an I2C master for the reconfiguration of LpGBTx. For the implementation the following options might be feasible; a proof-of-concept is needed for confirmation.
A. JTAG-like implementation
- Similar to the JTAG feature: bitbanging of 124-bytes after the reception of a full WorldFIP frame
- Reception of a complete variable, regardless of the node configuration i.e. stand-alone or not
- Data storage in the memory
- Dedicated pins and clock generation internally in nanoFIP
- Impact on hw/ gw/ sw:
- gw & sw: addition of new variable or possibly tweaking of the JTAG variable
- sw: library for the generation of the frames-containing-I2C
- gw: driving/receiving the I2C signals
- hw: no impact; use of spare FMC lines
B. Using the DAT_O/I pins
- Use of nanoFIP DAT_O/I pins in standalone mode:
- DAT_O pins: SCL_O, SDA_O, SDA_OE_O
- DAT_I pins: SDA_I
- Carrier board to combine the unidirectional nanoFIP I/Os to the bidirectional I2C SDA
- SCL: we assume that having it unidirectional, coming from the FMC-nanoFIP and not supporting clock stretching, would be sufficient
- Use of one WorldFIP frame for every I2C bit
- Max estimated speed: 0,5 KHz on the I2C SCL (one clock transition per macrocycle; macrocyle dedicated to one node)
- Impact on hw/ gw/ sw:
- No gw changes in nanoFIP
- Sw library for the generation of the frames-containing-I2C
- Hw on the carrier to combine uni-directional signals to bidirectional
Open questions:
- Access to the I2C interface out of the normal operation of the bus (with dedicated mactrocycle)
- Frequency and timeouts on the LpGBTx I2C interface
- Number of LpGBTx
- General interest -by other nanoFIP users- for the I2C-master feature
- Teams and timelines