Add the MCP2210 USB-to-SPI Converter

[jonas-schievink]

In QFN, SOIC, and SSOP variants, matching other Microchip ICs.

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
  • https://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
  • A new fitting footprint must be submitted if the library does not yet contain one.
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

[evanshultz]

Just a couple quick notes since I'm not assigned to this PR:

1. The symbol looks like it can be less wide. And perhaps move the SPI pins to the left by reset since they'll probably all connector to the same processor.
2. Thermal pad pins should be on the bottom and Passive type if they aren't stacked with a ground pin. And I don't see anything in the datasheet that suggests they can be stacked.
3. Wildcard the temp in the symbol name with x like our other Microchip parts.

[jonas-schievink]

Okay, updated.

[evanshultz]

Thanks!

1. Remove the - before the wildcard in the symbol name.
2. At the end of the description, put a space before the package type and add a -20 at the end for the pincount.
3. Change the QFN's FP filter to QFN*1EP*5x5mm*P0.65mm* to force a footprint with a thermal pad.
4. Please change pin 21 on that symbol to be named EP so it's more like the datasheet.
5. Move the text down by 50mil so it's just above the symbol outline.
6. Perhaps put RST by the SPI pins?
7. Move VUSB left of VDD and move the D+/D- pins up to the top of the left side so the USB pins are closer together.
8. The OSC pins might be best at the bottom so if a crystal is used there is easy ground access for the loading capacitors.
9. Why are the GP pins not increasing when going down? This seems odd. And then can also be moved down so they're vertically balanced.

[evanshultz]

Thanks! Can you post screenshots of all symbols for ease of checking and for reference?

[jonas-schievink]

-MQ (QFN-20):

-SO (SOIC-20):

-SS (SSOP-20):

[evanshultz]

@diegoherranz
This looks good to me from a quick check, but it should get your eyes before merging.

[diegoherranz]

Thank you both for creating/updating and reviewing this. I didn't have much time lately to look into this.

My main comment would be that this is a USB<->SPI converter, so I would think of having the USB pins on one side of the chip and the SPI ones on the opposite one.

What would you think about having the USB pins on the top right above the GPx? Then RST could move to the top left and the SPI ones could move slightly up. What do you guys think about that?

That would make it somewhat more similar to the current MCP2200 symbols, and also to the duplicate PR for this symbol, #2127.

Thanks!

[diegoherranz]

Thanks for the changes. That looks good to me. What do you think, @evanshultz? (note that the symbols on the previous comment have been updated).

I've just noticed that the VUSB pin may work better as passive since it can be power input or power output, depending on the power arrangement.

Thanks!

[evanshultz]

IMO the MCP2200 symbols are so old and ugly they're a bad reference. But I'm more in favor of just getting this merged. Changing the VUSB pin type sounds OK and I think it's nicer if that pin is closer to D+/D- (so swap positions with pin 1) but then let's get this done.

[diegoherranz]

IMO the MCP2200 symbols are so old and ugly they're a bad reference.

It was more having USB on one side and SPI on the other than really making it look like the MCP2200. But coincidentally, that matches the MCP2200.
Thanks!

[diegoherranz]

Thanks, I think it looks OK now. Merging.
Thank you both!

[maximeborges]

Sorry for coming after the merge.
I think it's a bad idea to have the USB with the GPIO on the rigfht side.
This component is an USB to SPI+GPIO, so I think it would be more natural to have the USB on the left, and the SPI and GPIO on the right, and not mixing them up.
Basically, you input your USB phy, you get SPI and GPIO on the other side.
Also a quick note from the Microchip forum since the datasheet is missing this information, the EP could (and should for better thermal and electrical connection) be connected to GND: https://www.microchip.com/forums/FindPost/1114449

[diegoherranz]

I think it's a bad idea to have the USB with the GPIO on the rigfht side.
This component is an USB to SPI+GPIO, so I think it would be more natural to have the USB on the left, and the SPI and GPIO on the right, and not mixing them up.
Basically, you input your USB phy, you get SPI and GPIO on the other side.

I see your point. I guess the symbol would become a bit taller, but it may be OK. Do you want to give it a try on a different PR based on this symbol? Normally we can't move the pin locations of existing symbols to avoid breaking schematics, but this symbol hasn't made it into any stable release so I think it would be OK. Please, @KiCad/librarians, shout otherwise!

Also a quick note from the Microchip forum since the datasheet is missing this information, the EP could (and should for better thermal and electrical connection) be connected to GND: https://www.microchip.com/forums/FindPost/1114449

Yes, I guess it can be connected to GND, but to turn it into a hidden GND pin it should be clearly specified in the datasheet that it must/shall be connected to GND. I don't think it's clear enough and I would leave it as is where the user has the choice.

Thanks!

[diegoherranz]

By the way, that PR would need to happen before 5.1.5 is tagged, which may not be far :)
Otherwise, it can't be modified anymore to avoid breaking compatibility.

[maximeborges]

By the way, that PR would need to happen before 5.1.5 is tagged, which may not be far :)
Otherwise, it can't be modified anymore to avoid breaking compatibility.

Done.