KiCad 7, offener Emitter / Kollektor ERC

[Holger L. (symetron)]

Moin

Ich verzweifle gerade an den ERC. Schaltplan beiliegend.

Meine Frage bezieht sich auf das KiCad-eigene Symbol für den MAX7221 
(LED-7-Segmenttreiber) und die LED-Anzeige.

https://www.analog.com/media/en/technical-documentation/data-sheets/MAX7219-MAX7221.pdf

Die 8 Segmente beim IC sind als "Offener Emitter" definiert, liefern 
also Strom, die 8 Digits als "Offener Kollektor", sind also Stromsenken.

Egal welchen Pintyp ich im (selbst erstellten)  LED-Symbol nutze, die 
ERC beschwert sich über Eingänge, Ausgänge, Stromversorgung und 
Stromausgang.

Außer ich definiere die Anoden/Kathoden der LED auch als "offenen 
Kollektor / Emitter".  Was jetzt mit LED so gar nichts zu tun hat...

Wäre das jetzt das richtige Vorgehen, weils funktioniert?

Ich finde ein "Stromausgang" und ein "offener Kollektor" passen ganz 
hervorragend zusammen...

Gruß
Holger

[Jörg W. (dl8dtl) (Moderator)]

Der ERC ist schlicht nicht in der Lage, so detaillierte Situationen 
überhaupt abzubilden.

Das fängt doch aber schon bei normalen GPIOs von Controllern an: die 
können Ausgänge oder Eingänge oder offene Drain/Source oder auch alles 
sein. Wie willst du das in einem ERC ordentlich abbilden, wie du jetzt 
einen bestimmten GPIO konfiguriert hast? Noch schlimmer: du schaltest 
vielleicht 3 GPIOs eines Ports parallel, um daraus die abschaltbare 
Stromversorgung für eine nachgeordnete Baugruppe zu bilden.

DRC ist in der Tat ein nützliches Werkzeug, und DRC-Fehler sollte man 
beseitigen. ERC ist oft genug von eher zweifelhaftem Nutzen. Workarounds 
für ERC-Fehler wie deinen würde ich nicht suchen. Man schaut sich den 
Fehler an, denkt drüber nach, ob eigentlich alles korrekt ist – und 
macht weiter.

[Bernd W. (berndwiebus)]

Hallo Jörg.

Jörg W. schrieb:

> Der ERC ist schlicht nicht in der Lage, so detaillierte Situationen
> überhaupt abzubilden.

Richtig.

> Das fängt doch aber schon bei normalen GPIOs von Controllern an: die
> können Ausgänge oder Eingänge oder offene Drain/Source oder auch alles
> sein. Wie willst du das in einem ERC ordentlich abbilden, wie du jetzt
> einen bestimmten GPIO konfiguriert hast? Noch schlimmer: du schaltest
> vielleicht 3 GPIOs eines Ports parallel, um daraus die abschaltbare
> Stromversorgung für eine nachgeordnete Baugruppe zu bilden.
>

Konkret: Die Vorgaben für den ERC sind auf einmal von der Programmierung 
des Controllers abhängig, und nicht nur vom Schaltplan, den der ERC 
nutzt.


> DRC ist in der Tat ein nützliches Werkzeug, und DRC-Fehler sollte man
> beseitigen. ERC ist oft genug von eher zweifelhaftem Nutzen. Workarounds
> für ERC-Fehler wie deinen würde ich nicht suchen. Man schaut sich den
> Fehler an, denkt drüber nach, ob eigentlich alles korrekt ist – und
> macht weiter.

Hier wäre eventuell eine spezielle Notiz oder Kommentarfunktion 
interessant, damit man diese Überlegungen
A) dem ERC in passender Form zur Verfügung stellen kann und
B) um selber eine Erinnerungsstütze zu haben, damit man dieses 
Nachdenken nicht bei jeder Revision neu machen muss.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

[Stefan F. (Gast)]

Warum haben manche Verbindungen einen grünen Punkt und andere nicht?

Ich erwarte and jeder T und + förmigen Verbindung einen Punkt. Sonst 
sind sie elektrisch nicht verbunden.

Oder sieht man Punkte nur nicht, weil die Linien dicker sind?

Ich würde es auf jeden Fall ändern, damit der Plan eindeutig wird. 
Insbesondere links oben von C6 und über C1 sieht es sonst sehr falsch 
aus.

[Jörg W. (dl8dtl) (Moderator)]

Stefan F. schrieb:
> Oder sieht man Punkte nur nicht, weil die Linien dicker sind?

Wäre jetzt auch meine Vermutung.

[Jörg W. (dl8dtl) (Moderator)]

Bernd W. schrieb:
> Konkret: Die Vorgaben für den ERC sind auf einmal von der Programmierung
> des Controllers abhängig, und nicht nur vom Schaltplan, den der ERC
> nutzt.

Yep, und dadurch kann man die ERC-Eigenschaften nicht mehr im Symbol 
unterbringen. Noch schlimmer: sie können sich zur Laufzeit des Programms 
ändern …