Support Enlighten 4.1.6 revision codes

[SamyBencherif]

Recent versions of Enlighten depend on responses to two new ctrl_transfer messages: request revision code and request FPGA revision. The default implementation of pyusb-virtSpec is to return None to unknown messages, causing a device failure as Enlighten tries to parse None as hex.

This change implements a basic response to those two messages, allowing Enlighten to get past the device handshake and move on to displaying mock spectra.

To test these changes (Windows) run,

$ scripts\bootstrap.bat activate virtspec
$ run.bat

.

[mzieg]

Is wIndex being used as wLength in all of these? I know the length of an FPGA revision is 7 chars, and I see other blocks checking for 0x40 (which would be 64 bytes, the default wLength in many transactions).

[SamyBencherif]

This is what ultimately gets passed to pyusb's ctrl_transfer function. Virtspec is a direct stand in. I traced through REQUEST LINE LENGTH and it appears that 0x40 does come from wLength, simply by the fact that it does not come from Enlighten's wIndex, but the parameters seem to line up. So that's a mystery (solved by the end of this comment).

FeatureIdentificationDevice.py#L1109

def get_sensor_line_length(self):
        value = self.get_upper_code(0x03, label="GET_LINE_LENGTH", lsb_len=2)

FeatureIdentificationDevice.py#L844

def get_upper_code(self, 
                       wValue: int, # 0x03
                       wIndex: int = 0, 
                       wLength: int = 64, 
                       label: str = "", 
                       msb_len: int = None, 
                       lsb_len: int = None) -> SpectrometerResponse:
    #                       0      1       2        3        
    return self._get_code(0xff, wValue, wIndex, wLength, label=label, msb_len=msb_len, lsb_len=lsb_len)

FeatureIdentificationDevice.py#L782

def _get_code(self, 
                  bRequest: int,       #  0        
                  wValue: int = 0,     #  1
                  wIndex: int = 0,     #  2
                  wLength: int = 64,   #  3
                  label: str = "", 
                  msb_len: int = None, 
                  lsb_len: int = None) -> SpectrometerResponse:

FeatureIdentificationDevice.py#L803

  result = self.device_type.ctrl_transfer(self.device, # A
                                          0xc0,        # B   (DEVICE_TO_HOST)
                                          bRequest,    # C
                                          wValue,      # D
                                          wIndex,      # E
                                          wLength)     # F

wasatchConfig.py#L52

#                   A          B         C           D        E
def ctrl_transfer(self, dev_handle, bmRequestType, bRequest, wValue=0, wIndex=0, data_or_wLength = None, timeout = None):
        """ Here we pretend to be the device firmware """

wasatchConfig.py#L66

if dev_handle == 0xc0 and bmRequestType == 0xff and bRequest == 0x3 and wValue == 0x0 and wIndex == 0x40 and self.idProduct == 0x1000:

It looks like dev_handle gets lost in transmission.

Ah I think I see it now. It must be that ctrl_transfer is being called as a static method in virtspec, so the true dev_handle is being passed to self. I'll modify the PR at some point before Monday.

[SamyBencherif]

I was missing this layer earlier:
https://github.com/WasatchPhotonics/Wasatch.PY/blob/126f928e3f1a428da568e41b66088ccd634ea1d1/wasatch/RealUSBDevice.py#L32

dev_handle is not part of pyusb, it's part of Enlighten's abstraction.

So it should be removed from virtspec -- which is done in 98a00ef