Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convention for Packages, Symbols, etc. #8

Open
carrotIndustries opened this issue Jan 5, 2018 · 11 comments
Open

Convention for Packages, Symbols, etc. #8

carrotIndustries opened this issue Jan 5, 2018 · 11 comments

Comments

@carrotIndustries
Copy link
Member

KiCad folks have the kicad library convention: http://kicad-pcb.org/libraries/klc/ Let's see what we can leverage.

@fruchti
Copy link
Contributor

fruchti commented Jan 25, 2018

It looks like GitHub's wikis don't allow pull requests, so I created a repository for my draft: https://github.com/fruchti/horizon-library-convention. This also has the advantage that issues in this dedicated repository can be used as a place for discussions on controversial subjects so they won't have to be here anymore ;)

For now, basically everything interesting or useful is missing but you can have a look at what I thought the general structure of the convention might look like. My next steps would to find suitable naming conventions for footprints (KiCAD has a lot of them), detail the silkscreen and schematic symbol rules and to include some images for clarification.

@carrotIndustries
Copy link
Member Author

Awesome! You really got the idea of the pool :)

Some aspects that caught my eye:

In case you haven't come across it yet: http://www.pcblibraries.com/downloads/Guidelines%21PCB_Design_Optimization_Starts_in_the_CAD_Library.asp Appears to be the closest thing to IPC-7351 that you get for free.

@fruchti
Copy link
Contributor

fruchti commented Jan 27, 2018

Thanks!

I fixed the default text size. The 1.2 mm come from http://www.ocipcdc.org/archive/What_is_New_in_IPC-7351C_03_11_2015.pdf page 18. Interestingly the PDF you linked to says 1 mm. I didn't find a date in the former so I don't know which is the newer revision.

Frankly, I didn't really bother to look into all the existing reference designator conventions yet so I copied the KLC's table as a starting point. I actually disagree both with the KLC and the IPC's table on some points, namely:

  • KiCAD proposes Z for zener diodes. This doesn't seem all too common to me.
  • From the IPC's convention I'd omit AR for amplifiers and VR for voltage regulators, because they create areas of ambiguity.
  • I don't really like separate designators for terminals, plugs and receptacles the way IPC-7351 handles it. A male and a female connector often don't differ much (often not at all) in their PCB footprint and use and I think different designators would confuse more than they would help. I like KiCAD's way much better because I think the difference in loose and fixed end is much clearer.

The table in the IPC slides looks more like a enumeration of the typically used designators than a recommendation to me, e. g. because it lists both D and CR for diodes. Yes, both are common but I'd expect either one or the other from a convention.

@carrotIndustries
Copy link
Member Author

I didn't find a date in the former so I don't know which is the newer revision.

Looks yours is newer. I also asked my copy of "PCB library expert for IPC", looks like it also produces 1.2mm pin 1 indicators, so let's settle on that one.

KiCAD proposes Z for zener diodes. This doesn't seem all too common to me.

I don't like this one either.

From the IPC's convention I'd omit AR for amplifiers and VR for voltage regulators, because they create areas of ambiguity.

Ok, I'm with you, these should be "U" as every other IC.

I don't really like separate designators for terminals, plugs and receptacles the way IPC-7351 handles it.

The fact that the the Entities "Generic 13 pin connector" and friends are supposed to be used equally for jacks and plugs makes this distinction even more pointless, so let's use J for both.

@fruchti
Copy link
Contributor

fruchti commented Jan 28, 2018

Nice to see we're on the same page! I changed the designator table and also left out those:

  • GN for general network. I thank that'd lead to confusion and we'd have dual transistors or diodes as GN.
  • X for sockets. IMO a fuse in a socket should just be F.
  • TZ for TVS diodes. Or is there a reason why they shouldn't be D?

Another idea to think about: X for connectors instead of J. It isn't really common but I've seen it a few times. The main advantage would be that it makes the distinction between jumpers and connectors clear. I think they shouldn't both be J.

I'll open new issues for topics needing clarification in my repository from now on because I think the issues here should be about individual parts and not the general rules.

@carrotIndustries
Copy link
Member Author

Another idea to think about: X for connectors instead of J. It isn't really common but I've seen it a few times.
How about P? That's at least somewhat connector-related in the IPC standard.

TZ for TVS diodes. Or is there a reason why they shouldn't be D?
D is fine.

@fruchti
Copy link
Contributor

fruchti commented Jan 29, 2018

Or JP for jumpers and J for connectors.

@atoav
Copy link
Contributor

atoav commented Apr 11, 2018

We definitly should try to put all rules we come up with into one central place (wiki?), as a guide for pool contributers.

@fruchti
Copy link
Contributor

fruchti commented Apr 11, 2018

@carrotIndustries could link to my repository in the pool's readme (as soon as he thinks it's mature enough), or Horizon could become an organisation. I really like using a repository with a readme instead of GItHub's wiki for the convention as long as it is work in progress, because there are a lot more options for contribution. With a repository, a suggestion can be a pull request and all discussion on rules can happen in the issues, where it's well-ordered and all in one place.

@atoav
Copy link
Contributor

atoav commented Apr 12, 2018

@fruchti Okay that's a much better idea : )

@niclashoyer
Copy link

+1 for organization

@github-actions github-actions bot mentioned this issue Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants