You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been orienting packages such that pin 1 is near the top left, which is in line with IPC-7351 and KiCad’s rules. However, it currently isn’t part of our convention. I have dedicated an issue to it because I think this rule, even with KiCad’s exceptions, has a few implications worth discussing.
Multi-row connectors
If taken by the letter, the ‘pin 1 in the upper left corner’ implies a tall female DB-25 and a wide male DB-25 footprint. Having male and female variants of the same connector at 90° to each other isn’t really intuitive.
To solve this, I’d add a prioritised rule to prefer tall footprints rather than wide ones. This is in line with the existing packages in the pool. This additional rule would have to come after a two-terminal exception like KiCad has, though.
Right-angle parts
We already have a special rule for electro-mechanical parts, advocating a package origin in a place that makes sense mechanically. In the same vein, I’d specify that the user-facing side of right-angle parts (connectors, LEDs, potentiometer, …) should be on the left.
If the female DB-25 from the previous example were a right-angle connector, its pin 1 would now be on the bottom. However, I’d still prefer that to having male and female connectors look in different directions.
Proposed rules
In summary, I’d add the following package orientation rule set, in order of priority:
Right-angle parts must have their user-facing edge facing left.
Two-terminal devices must have their pads next to each other, with pin 1 on the left.
Prefer tall footprints to wide footprints.
Pin 1 should be near the top left corner. If that is ambiguous, prefer pin 1 on top.
Open questions
Naturally, there are a lot of different cases to consider. The rules above would, for example, lead a slightly non-intuitive orientation of a tab-down TO-220 (with the mounting hole below the 3 pads). I think, however, that these rules should cover the majority cases well enough. If I did overlook something important, please point it out!
The text was updated successfully, but these errors were encountered:
I’ve been orienting packages such that pin 1 is near the top left, which is in line with IPC-7351 and KiCad’s rules. However, it currently isn’t part of our convention. I have dedicated an issue to it because I think this rule, even with KiCad’s exceptions, has a few implications worth discussing.
Multi-row connectors
If taken by the letter, the ‘pin 1 in the upper left corner’ implies a tall female DB-25 and a wide male DB-25 footprint. Having male and female variants of the same connector at 90° to each other isn’t really intuitive.
To solve this, I’d add a prioritised rule to prefer tall footprints rather than wide ones. This is in line with the existing packages in the pool. This additional rule would have to come after a two-terminal exception like KiCad has, though.
Right-angle parts
We already have a special rule for electro-mechanical parts, advocating a package origin in a place that makes sense mechanically. In the same vein, I’d specify that the user-facing side of right-angle parts (connectors, LEDs, potentiometer, …) should be on the left.
If the female DB-25 from the previous example were a right-angle connector, its pin 1 would now be on the bottom. However, I’d still prefer that to having male and female connectors look in different directions.
Proposed rules
In summary, I’d add the following package orientation rule set, in order of priority:
Open questions
Naturally, there are a lot of different cases to consider. The rules above would, for example, lead a slightly non-intuitive orientation of a tab-down TO-220 (with the mounting hole below the 3 pads). I think, however, that these rules should cover the majority cases well enough. If I did overlook something important, please point it out!
The text was updated successfully, but these errors were encountered: