Click Analyzer - driver installation

[VCC]

Hi,
hoping this helps..
The board comes with no driver installation instructions, but when plugging it in, it appears in Windows as a new harddrive. That drive contains an html file, pointing to http://microchip.com/mcp2221a, where the driver should be.
Before installing the driver, the board appears like this in Device Manager:

Analyzer_NoDriver.png (5.17 KiB) Viewed 2733 times

The Microchip driver inf file does not list this particular board, so it has to be manually edited (mchpcdc.inf).
Under the DeviceList and DeviceList.NTamd64 sections, please add the following lines:

Code: Select all

%DESCRIPTION%=DriverInstall,USB\VID_2DBC&PID_4803&MI_01
%DESCRIPTION%=DriverInstall,USB\VID_2DBC&PID_4803&REV_0001&MI_01
%DESCRIPTION%=DriverInstall,USB\VID_2DBC&PID_4803

After saving the file, right click the "MikroE Composite Device" item in Device Manager and update the driver. You have to manually point to the directory where the mchpcdc.inf file is located.

After installing the driver, the board should appear as (likely a different COM number):

Analyzer_ComPort.png (7.91 KiB) Viewed 2733 times

Analyzer_CompositeDevice.png (6.92 KiB) Viewed 2733 times

[TimCruise]

Can this Click Analyzer show protocol which is running on each pin?

[VCC]

It doesn't seem to be protocol aware. It is more like a lightweight aquisition device.

[TimCruise]

VCC,
This click board is very difficult for designer. It requires you to input text commands.

Is there any click board which can show protocol connection?

[VCC]

Hi,
I put up together a small UI for this board: https://libstock.mikroe.com/projects/vi ... nalyzer-ui
It is not able to display the protocol, only the measured signals as they are. Judging by it capabilities, this board would require a direct connection from click's SPI, I2C or UART buses to the onboard PIC's peripherals (18F26K42), to properly decode the protocols. In its current state, it is left to the UI to decode the signals, by simulating the PIC's peripherals. But, this implies data sinchronization and state initialization. I could 'write' such peripherals in the UI app, but they would be useless if the acquired data would be only a snapshot somewhere in the middle of a signal. Imagine the two I2C signals in the middle of a transmission, without the start condition. Or, the SPI signals without the CS line going low. If the UI peripherals would receive such data, they would be undecodable. This is why the protocol analysis has to be done in hardware. Probably, for I2C, this would be a bit more difficult, because the onboard PIC should not act as a I2C device, only as a "protocol listener".
The onboard PIC has PPS, so the mentioned peripherals can be enabled on the appropriate click pins. It just needs a newer firmare to enable all these.
Anyway, I proposed a firmware upgrade, to have oscilloscope-like trigger. This would be a good step towards enabling a state intialization of the simulated peripherals. See viewtopic.php?f=44&t=78194
Another limitation of the onboard PIC is the small amount of RAM, 4KB. This greatly limits the number of acquired samples, so this is another reason to decode the data in hardware.

As for another low-cost protocol decoder, you can have a look at PICKit Serial Analyzer, from Microchip: https://www.microchip.com/Developmentto ... s/DV164122.

[TimCruise]

COOL!!!

VCC, you can apply any job in top IC factories!!!

[VCC]

Not sure how/what worked in the past, but now, installing the driver in a 64-bit Windows does not work with the above mentioned steps. It seems that Windows doesn't like modifying the inf file (it displays an error about invalid hash).
The board can be installed as a different device though, with the following settings. Right click the device in Device Manager, then "Update Driver Software...":

Drv1.png (21.57 KiB) Viewed 488 times

Drv2.png (23.8 KiB) Viewed 488 times

Drv3.png (31.85 KiB) Viewed 488 times

Click Next
HTH