TE 2041021 SD card connector

[mignon-p]

Datasheet.

There exists a footprint Connector_Card:SD_TE_2041021, but I could not find a symbol for it. The existing symbol SD_Card has two "SHELL" pins, but the Connector_Card:SD_TE_2041021 footprint only has one "SHELL" pin.

So, this is a copy of the SD_Card symbol, with the second "SHELL" pin removed.

In addition, I changed the electrical type of the DAT pins from Input to Bidirectional, because Input seemed wrong, according to this pinout.

The KLC script wants the VDD pin at the top, and the VSS pins at the bottom, but I think that would be weird in this case. Or at the very least, it would be a major departure from the existing SD_Card symbol.

---

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
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
• 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

[evanshultz]

Thanks!

First, having the extra pin shouldn't matter. You can use the existing symbol. But, I see no reason for pin 13 so IMO the symbol above can replace the existing one. Also:

• I agree with leaving the power pins.
• Making the DAT* pins Bidirectional makes sense to me too.
• The symbol should stay generic instead of being specific to one part.
• Pin 12 should be named SH as this is done in our library and it is a shield pin.
• Pins 10 and 11 should be named CD and WP and not numbers. Some parts may not use pin 10 and 11 (they could be swapped, for example) so using a pin name works best. Pin names has been done in a few places already but isn't widely done or managed so it's best to get other librarian input on this first.

It seems you've again pointed out where our library doesn't have enough symbols to satisfy all the parts in the market. And in this case, even a poor match between existing footprints. Sorry, but thank you!

We actually need a miniSD and microSD symbol since they have different pinouts and/or pin counts. I believe adding the CD and WP pins, along with the SH pin, are fine for parts which don't include them.

As above, let me know if you want to make any changes and I'll work to figure that out. If not, you can simply close this PR and I'll work on it.

[evanshultz]

Again, this is for my own information. After looking at datasheets for all the existing SD card footprints, we will need the following symbols:

• SD: 9 standard pins plus CD, WP, SH pins
• miniSD: 11 standard pins plus CD, WP, and SH pins
• microSD: 8 standard pins plus CD, WP, and SH pins
• microSD_DualCD: 8 standard pins plus CD_A, CD_B, WP and SH pins

Info:

• https://en.wikipedia.org/wiki/Secure_Digital#Transfer_modes
• http://portal.fciconnect.com/Comergent//fci/drawing/10067847.pdf
• http://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Customer+Drawing%7F2041021%7FB%7Fpdf%7FEnglish%7FENG_CD_2041021_B_C_2041021_B.pdf%7F2041021-1
• http://katalog.we-online.com/em/datasheet/693072010801.pdf
• https://www.hirose.com/product/en/download_file/key_name/DM3/category/Catalog/doc_file_id/49662/?file_category_id=4&item_id=195&is_series=1

[mignon-p]

OK, I've modified the existing SD_Card symbol. I like the use of non-numeric pin numbers. (The KLC used to forbid this, and I hadn't realized it had changed.)

First, having the extra pin shouldn't matter. You can use the existing symbol.

True, but I think it's nicer if the footprint shows up in CvPCB without having to de-select the pin number filter.

We actually need a miniSD and microSD symbol since they have different pinouts and/or pin counts.

There are already three Micro SD symbols.

[evanshultz]

Oh yes. I find two microSD symbols.

@poeschlr @jkriege2 @Ratfink
I'm propagating pin names instead of numbers here. Anybody want to object?

[Ratfink]

Is it okay to change pin numbers, breaking third-party footprints that match our generic symbols, while we're in a freeze? That sounds like the kind of thing freezes are there to protect against, so my vote would be "not unless there's a very good reason". And I'm not sure yet if there's a very good reason in this instance, so until I am convinced (or unless I'm told by someone above me in the chain of command that the freeze does not cover this and there will be no voting), I object.

[evanshultz]

You have an excellent point. Surveying just a few parts, pin names will be required to match things up since pin numbers don't necessarily agree for all extraneous pins.

I read a freeze on libraries being added or deleted, but it maybe includes more? That's exactly why I looped in more folks! :) Fortunately, this is a rather limited change since it wouldn't affect a huge number of our own footprints and we know exactly which ones.
@poeschlr

[evanshultz]

@poeschlr
Can we change pin numbers to names right now? It makes sense in this situation to me. (Obviously the footprints may need changes and I volunteer to do it if someone else will volunteer to review.) Also see #644.

[mignon-p]

(Obviously the footprints may need changes and I volunteer to do it if someone else will volunteer to review.)

I've submitted a PR for the SD_TE_2041021 footprint. I think this is the only SD card footprint currently in the library, although there are several MicroSD footprints.

[poeschlr]

You can change fully specified symbols but please do not change generic symbols that have many possible footprints (at least not the pin numbers and pin count of them. graphical changes are possible) [Edit: to clarify if you change a fully specified symbol you must also change its footprint]

I checked the footprint docu from the pull request for the fitting footprint and it uses pin numbers. So i really do not see the reason why we should use names instead of numbers (As manufacturers seem to use numbers in their documentation as well.)

[evanshultz]

Related to and KiCad/kicad-footprints#598.

So we had pin numbers on symbols and footprints which were OK with just a single type of card holder. As I wrote above, there are seemingly standard pinouts for the data pins. But any other pads needed for the footprint (write protect, separate card detect, mounting pins, etc.) are not standardized with regards to number. That's why I proposed names.

https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Customer+Drawing%7F2041021%7FB%7Fpdf%7FEnglish%7FENG_CD_2041021_B_C_2041021_B.pdf%7F2041021-1 does not give numbers to the two other pins. @poeschlr The leftmost two pins on page 1 do not have numbers so I don't know what you're referring to. Can you clarify?

https://www.hirose.com/product/en/download_file/key_name/DM3/category/Catalog/doc_file_id/49662/?file_category_id=4&item_id=195&is_series=1 may have two separate card detection pins without pin numbers.

http://katalog.we-online.com/em/datasheet/693072010801.pdf only has mounting pins and the function of the card detect isn't mentioned (assume it switches to ground).

http://portal.fciconnect.com/Comergent//fci/drawing/10067847.pdf has two other pins without numbers.

So as you can see, there isn't any agreement amongst manufacturers and using pin names, instead of letters, lets us abstract that away and use one common set of symbols for any footprint.

---

Related to #644.

But with combo connectors, like https://www.molex.com/pdm_docs/sd/1041681620_sd.pdf and https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=2295782&DocType=Customer+Drawing&DocLang=English&DocFormat=pdf&PartCntxt=2295782-1 we run into a different bit of trouble.

We need SIM pins and SD pins for these connectors but various companies disagree on how to name the pins. They do agree on a letter prefix to the combo connectors to differentiate them, allowing the standard numbering to be appended after the letter. #644 (comment) has a nice table.

Here is my proposal: S# for the SIM card (S for SIM) and C# for the card (could be CD, microSD, CF, etc. card).

[evanshultz]

Somehow I submitted the comment too soon. Please read above to see the whole thing.

[evanshultz]

@poeschlr
Can you help me understand your comment about pin numbering above? See my comment yesterday where I'm not seeing how we are supposed to get a consistent set of numbers from the vendors, but pin names are common and also provide intelligence to the pins.

[evanshultz]

@poeschlr
Please read above and answer.

[evanshultz]

@poeschlr
Please read the above and respond. I would really like to finally wrap this up and come to a conclusion.

[antoniovazquezblanco]

@poeschlr ping!

[poeschlr]

I don't have a particular preference for this. The only thing i feel strongly about is that we should not break anything during v5 development. So it might be a good idea to add new symbols instead of replacing existing ones.

I fear that we will not be able to find a way to have one single symbol for everything. Maybe we can make one that covers most things as a generic symbol and then add a library where we can add fully specified symbols for specific components.

[evanshultz]

Alright. Thank you. Then I'm not seeing an issue with the plan I outlined above. We can keep the standard pins for each card type with numbers, in the same location as they are currently, and then add named (not numbered) pins for special features that allow abstracting away symbols for individual PNs.

If an existing symbol has only the standard numbered pins, they can be modified. Otherwise new symbols will be needed or updating symbols will have to wait.

[antoniovazquezblanco]

Given that the corresponding footprint PR has been reverted I am postponing this to after 5.0.2

[myfreescalewebpage]

@ppelleti @evanshultz what is the status here ?

[mignon-p]

@myfreescalewebpage I'm just waiting for some clear instructions on what to do. There have been a lot of comments from a lot of people, and discussion about SD card symbols in general, but I'm not sure where that leaves this PR specifically.

[myfreescalewebpage]

@ppelleti thanks.
@evanshultz I think you're the best to answer this question.

[evanshultz]

We can use pin names now, making our symbols more generic. So please follow the suggestions at #592 (comment). Does that work? I would also accept any other changes, like perhaps making the symbol just look like SD card with all pins on one side instead of the style above.

This applies to the footprint as well.