search

KiCad / kicad-website

This is the official website source for KiCad [moved to https://gitlab.com/kicad]
http://kicad.org
Other
62 stars 114 forks source link

Improve S4.2 examples #478

Open cpresser opened 4 years ago

cpresser commented 4 years ago

Rework examples for input- and output-pin grouping/positioning (S4.2)

Related: https://github.com/KiCad/kicad-website/issues/423

chschlue commented 4 years ago

I always read that rule to roughly mean "stuff that stays on the board (and is a symbol in the schematics) to the left, stuff that's outside (and is a label in the schematics) to the right" (when applicable, e.g. bridge drivers and such. Not, say, logic symbols which have a clear direction). So processor --(UART)--> transceiver --(RS232)--> external bus actually made more sense to me than processor --(Enable)--> charge regulator --(ChargeFinished)--> processor

Edit: Not sure if it's clear what I mean. To employ the second example again: To me ChargeFinished belongs to the Control (left) side while Controlled (right) is the battery.

cpresser commented 4 years ago

The common denominator for this rule seems to be a left-to-right flow in the schematic. Similar to writing text in most languages.

I dislike the UART/RS232-example since there is no clear indication of the flow. It can be used in both directions and thus is not a unambiguous example. The same applies for any kind of bidir transceiver. That's why I want more examples that are not transceivers.

How about I change the patch to keep the UART example but also add the new ones?

chschlue commented 4 years ago

Perhaps we should split the examples into subsections. Like Logic (A, B on the left; Q, ~Q on the right) (which we probably universally agree upon) and Transceivers, motor drivers, charge regulators, ... that have distinct "sides" yet cannot simply be split by input and output pin types (which possibly requires further discussion). Thoughts?

cpresser commented 4 years ago

While we are at it we could also add voltage-regulators where we currently allow KLC violations. Thats a point that always bugs me.

I find the idea appealing to have more distinct examples. But on the other hand KLC is already pretty big, keeping it short and simple as design-goal would be violated by adding more special cases.

I personally are in favor of more examples/subsections for this rule.

chschlue commented 4 years ago

Good idea. Instead of violating KLC for voltage regulators as a rule, we might as well have a rule exempting them :)

We can't expand KLC to catch every conceivable corner case, but I'm all in favor of overhauling S4.2.

chschlue commented 4 years ago

Oh, and let's not forget about MCUs and such. Splitting sides by function isn't usually possible without creating really awkward outlines.