I've successfully tested both writeManufacturerDesc() and writeProductDesc(). Mind that the attached program will effectively write over the existing descriptors.

Now, I'll have to implement functions to get and set individual GPIOs, and also cover the interrupts.

 

Finally tested the remainder of the NVRAM functions (those that are there so far, that is). Attached is the source code of the program that I've used. This program will keep the initial settings that are stored in the NVRAM.

 

Finally, I've made, and also tested, the GPIO functions. I think it would be interesting to add a convenience toggleGPIO() function to toggle a single GPIO, but this can be easily done with the existing functions.

Anyway, I've attached the most recent version of the class, along with the source code of a small program that allows you to switch GPIOs on and off, at will. Note that there is no input validation and, naturally, the program will fail on invalid input (which means that the class is doing its verification).

I guess that next I can take care of the functions that deal with the event counter, but I don't know how to test them.

 

I've implemented toggleGPIO(). It could be simply implemented as setGPIO(gpio, !getGPIO(gpio, errcnt, errstr), errcnt, errstr). However, that solution will require a total of three HID transfers (one for getting and two for setting, because setGPIO() also gets the GPIO values). So, I had to put in more code in toggleGPIO() to make it more efficient. Thus, like setGPIO, only two HID transfers are made, which corresponds to a total of 4 interrupt transfers or 8 USB request/response packets. That's a 33% reduction when compared to the code above.

I've also implemented functions to get and write the USB parameters, like VID, PID and power settings.

Next, as promised, I will take care of the interrupt related functions. This C++ class is still halfway but, so far, it works great. Thanks to the lessons learned during the implementation of the CP2130 class.

 

Here is the latest version. I've implemented and tested interrupt related functions getEventCount() and resetEventCounter(). Both work fine according to the test program that is also attached.

Next I will deal with SPI transfers. However, I've been taking care of other tasks lately. Concurrently, I'm developing an application to interact with the CP2130 from Silicon Labs. Since I'm at the finish line, I'll give maximum priority to that.

Off topic, here is a screenshot:

 

Finally, I have implemented a function to perform simple SPI transfers. I've attached the class, and the updated blink program as well. I think I'm ready to release version 1.0.0 . Password support will be added in a later version. It cannot be added now, due to the risk of bricking a chip while replacements are not available.

 

Here are some test programs for the evaluation board. I'm having an issue, though, where after repeating the execution of any chosen program, I start getting errors after a while. The MCP2210 gets messed up.

@nsaspook Do you have any clue? Have you encountered this issue?

 

As an update, I've compiled two programs to measure temperature and get the reading from the ADC, but on repeat. The temperature always reads correctly. The readings from the ADC, though, get messed up after a while. I guess that this is due to timings. However, this is very different from the result I usually get when doing while loops externally, via the terminal.

 

Guess I would take a good look at the CS timing to the MCP3204 ADC chip.

The CS /SHDN pin is used to initiate communication
with the device when pulled low and will end a
conversion and put the device in low power standby
when pulled high. The CS /SHDN pin must be pulled
high between conversions

 

Guess I would take a good look at the CS timing to the MCP3204 ADC chip.

Indeed. It is not clear what mode it requires. Also, there might be other factors at play. Anyway, there are simpler ADCs that don't require such timings, and I've used one of those. For example, the LTC2312CTS8-12. However, I've never tried it with the MCP2210.

As for the previous problem, it is solvable if I define every chip setting, instead of letting some bytes flapping in the breeze. I've managed to run the attached programs via a while loop running in the terminal, and I don't get the "Failed to obtain..." messages. The MCP2210 works pretty well.

 

By the way, here is the first official release at GitHub: https://github.com/bloguetronica/mcp2210.

 

After ranting, one more time, on GitHub about the stupidity of systemd (and after the bug being closed because apparently it was "too heated"), Yu Watanabe presented this link via e-mail: https://www.microchip.com/forums/m/tm.aspx?m=1051283&p=1.

Basically, instead of editing "/etc/udev/rules.d/z010_mchp_tools.rules" as I did, this solution requires these steps:
- In a terminal, enter "sudo systemctl edit systemd-udevd";
- Add the following lines:

[Service]
IPAddressAllow=localhost

- Save and reboot.

After all, either directly or indirectly, this is caused by systemd. I suggested posting this solution as an answer to my bug case, because it is a trap for the 99% of the people that happen to have MPLABX installed. Why they won't admit that this is a bug, is beyond me, because the localhost should have the override already set, being that the case.

 

There is a new version of the library available on GitHub. Version 1.1.1, as well as the previous version 1.1.0, both recently launched, provides password and NVRAM lock related functions. You can see the project at https://github.com/bloguetronica/mcp2210.

 

Here is the updated LED blinker program for the MCP2210 evaluation kit (MCP2210 Breakout Board + MCP2210 SPI slave Motherboard). Now it blinks all LEDs without skipping. It uses the newest version of the library, which is version 1.1.2.