Bauteilbibliotheken

Aktuelles

Bei Aktualisierungen den Seitencache neu laden

Bei aktuellen Downloads bitte darauf achten, dass fast alle Internet-Browser einen mehr oder weniger gut funktionierenden Seitencache haben, der die letzten Versionen aller besuchten Seiten speichert. Dies funktioniert manchmal nicht korrekt und man muss das Neuladen der Seite erzwingen. Es kann dann erforderlich sein den Seitencache zu aktualisieren.

Damit man erkennen kann ob diese Sinn macht werden die Teile der Bauteilbibliothek gekennzeichnet, die gerade aktualisiert werden. Es steht dann in der Spalte Bemerkungen das Wort "EDIT". In diesem Fall ist nur der Link auf das Datenblatt noch letzter Stand.

Welche Tasten dazu gedrückt werden müssen lese man in der Hilfe des jeweiligen Browsers nach. Bei allen Nachkommen des Mosaic-Browsers (Netscape, Firefox) drücke man auf der Tastatur die Shift-Taste und clicke gleichzeitig beim Browser auf den Reload-Button. Damit wird das Neuladen der aktuelle Seite erzwungen. Das das gewirkt hat sieht man am Datumsstempel der Lib-Dateien, welcher beim Reload auf den aktuellen Wert springt.

Bundle

Ein Bundle ist eine meist tagesaktuelle Bauteilbibliothek, die bunt gemischt alle neuen Bauteile eines Supportdienstleisters enthält, die noch nicht in der aktuellen Version von Kicad verfügbar sind, aber bereits am Elektronikmarkt gehandelt und verwendet werden. Das Revisionsdatum eines Bundles ist gleich dem Revisionsdatum des zuletzt aktualisierten Bauteils.

Erläuterung des Bibliothek-Styles

Zielsetzung

Es wurde im neuen Style RMC34LUM versucht die Bauteilbibliotheken mit einem optisch ansprechenden, durchgängigen, praxisnahen Ansatz zu vereinheitlichen.

Der Platzbedarf wurde für eine möglichst kompakte Darstellung das Schaltplanes und bezüglich Abmaßen auf ein erträgliches Minimum reduziert, denn es soll viel an Information auf eine Seite passen und trotzdem noch Leitungsverbindungen mit möglichst wenigen Knicken erlauben. Ausserdem ist das wegführen von Anschlüssen nach oben oder unten ausser in seltenen Fällen (Spannungsregler) bei GND-Anschlüssen zu vermeiden, da dort in der späteren Zeichnung sich diese mit den Busleitungen kreuzen würden.

Würde man ein Bauteil nach diesen Vorgaben erstellen, dann sieht es wie folgt aus. Bei größeren wie Mikroprozessoren werden Funktionseinheiten (Ports) mit einem Block umrahmt und die Funktionsblöcke lückenlos gestapelt und zwar so dass die Mittelline symetrisch durch einen Rasterpunkt geht. Nur so liegt der Origin in der Mitte des Bauteils und die Blöcke sind trotzdem klar und platzsparend unterteilt. (siehe auch Dummy-Symbol)

• Dummy-Symbol ohne Funktionsblock
• Dummy-Symbol mit Funktionsblock
• Mikrocontroller Xmega A4

Der RMC34LUM Style

• RMC=Das Symbol ist nach Möglichkeit rotations- und spiegelsymetrisch und dazu liegt der Drehpunkt des Symbols (der Origin) sinnvollerweise in der Mitte des Bauteils, da das Symbol andernfalls bei Spiegelungen (X,Y-Taste) und bei Rotationen (R-Taste) sprichwörtlich "um sich schlägt" und dabei halb aus dem Bild verschwindet. (rotate mirror center)

• 34=Es sind 3 Ziffern für die Pinnummer und 3 Buchstaben und vorangestellter Schrägstrich oder 4 Buchstaben pro Pinbezeichnung vorgesehen. Es sind keine Chips bekannt, die mehr als 999 Pins haben und jeder längere Text macht auch das ganze Bauteil zu groß. Deshalb ist beim Standardfont von 1,27mm bei 3 Ziffern, ein Sondersymbol für die speziellen Ein/Ausgänge und ein Leerzeichen für eine einheitliche Pinlänge von 5*1,27=6,35mm vorgesehen. Beim Text mit 4 Zeichen und einem Sondersymbol für spezielle Ein/Ausgänge wird ein Abstand von 5x1,27mm=6,35mm gewählt. Sollte dies in seltenen Fällen doch nicht ausreichen, dann kann für diese Bauteile auch einen anderen Style mit 5 Buchstaben und 6x1,27=7,62mm (Bsp: RMC35LUM) verwendet werden.

• LUM=Die Textausrichtung ist nach Möglichkeit linksbündig und die Beschriftung ist oberhalb des Bauteils und auch linksbündig zur linken Aussenkante des Symbols. Der Platzbedarf des Symbols ist minimiert und nach Möglichkeit nicht mehr als 10 Zeichen lang und zwei Zeilen hoch. Der Text schneidet nicht die gedachte verlängete linke Kante des Symbols. Die Bauteilreferenz steht oben, aber unter unter der Typnbezeichung, jedoch nicht nach links vor dem Text, eher einen halben Buchstaben eingerückt. Die Datenbusse werden bevorzugt von oben nach unten symmetrisch aufgeteiltt, aber immer noch alphabetisch geordnet. Dann folgen die zusammengehörigen Steuersignale (UART, SPI), dann die einzelne Steuersignale (Reset) und ganz unten die Stromversorgungen. Die Reihenfolge und die Wahl der Anordnung ob nun links oder rechts entscheidet die Gruppierung zusammengehöriger Einheiten und dann nachfolgend die Steuer- und Energieflussrichtung analog der DIN für die bevorzugte Aufteilung von Schaltanlagen, denn mehr Übersichtlichkeit ist mehr Sicherheit, also werden zuerste die von wichtigen Funktionen gruppiert und dann die weniger wichtigen Funktionen. Diese wiederum von links nach rechts und dann blockweise von oben nach unten geordnet. (left upper minimized) Bei Prozessoren hat sich die vertikale Anordnung durchgesetzt, also beispielweise erst Port A-F auf der linken Seite und dann rechts die restlichen Ports von oben nach unten damit das Chipsymbol optisch ansprechend und möglichst symetrisch aussieht.

Neue Bauteilbibliotheken

Kompatibilitäts- und Äquivalenzlisten

Unterschied Kompatibilität und Äquivalenz

Tutorial-PDF Footprintpflege Source

Es sei hier nochmals auf den vollständigen Haftungsausschluß der gesammten Webseite hingewiesen. Alle Angaben sollen bei der Auswahl helfen, bedürfen aber vorallem wegen der Einbaulage und der Geometrie der Bauteile und Pads eine fachmännische Kontrolle, vorallem wegen den Abständen zu anderen Bauteilen und zulässigen Toleranzen, die der Verwender selbst zu prüfen hat, um Mehrkosten und Ausschuss zu vermeiden.

• Ein kompatibles Footprint ermöglicht den semiprofessionellen Einsatz eines Footprint für mehrere Bauteile, falls es noch kein äquivalentes Footprint gibt, auch wenn die 3D-Ansicht und die zeichnischen Details des Bestückungsdrucks abweichen. Zur elektrischen Kompatibilität ist es hinreichend, wenn die Reihenfolge der Pinbezeichungen und die Geometrie der Pads hinreichend gut passt und der Bestückungsdruck soweit eindeutig ist, dass die Plazierung des Bauteils im allgemeinen nicht zu Problemen führt wenn die Lage und der Offset im Bestückungsautomaten entsprechend angepasst wird.
• Ein äquivalentes Footprint ist ein Footprint, welches zwar nicht die gleiche Bezeichnung hat, aber hinsichtlich der 3D-Ansicht, der zeichnischen Details und der Koordinaten im Bestückungsautomaten nahezu exakt passt oder völlig gleichwertig ist.

Footprints

• Package/Outline-Link NXP
• Package/Outline-Link TI

Links

Disclaimer: Diese Linksammlung ist eine Auflistung von im Netz frei verfügbaren Veröffentlichungen. Diese Webseite speichert diese Informationen nicht direkt, sondern bietet ledlich einen Verweis darauf an. Die Linksammlung ist kein gewerbliches Angebot und darf auch nicht dazu mißbraucht werden. Aus rechtlichen Gründen müssen wir uns aber von den verlinkten Inhalten distanzieren und klarstellen, dass wir keinen Einfluss auf die Inhalte der Links haben. Sollte es erforderlich sein diese Verweise zu ändern oder zu löschen benutzen Sie bitte den Issue-Tracker damit diese Linksammlung korrigiert und aktualisiert werden kann. Danke

Normen und Quasi-Standards

1. 2010-09-18 [1] Was bringt der neue Standard IPC-7351? - deutsch (Thanks: KS)
2. 2010-09-18 [2] Überblick über IEEE Standard 91-1984 - englisch (Thanks: Dirk Göttel )

Tutorials

• Kicad Kicad-Entwicklerseite - zur Weiterentwicklung von Kicad selbst - gehostet auf Soureforge.net
• Das Mini Tutorial ist bereits teilweise übersetzt und es werden noch viele "Freiwillige" gesucht, um es fertigzustellen. :-)

Lieferanten (alphabetische Liste)

Unterstützer von kicad-users-de

Lieferanten für elektronische Bauteile

• Conrad - durchsortiertes Vollsortiment
• Digikey - durchsortiertes Vollsortiment
• Farnell - durchsortiertes Vollsortiment
• Kemo - Bausätze
• Mercateo - durchsortiertes Vollsortiment
• Oppermann - Spezialbauteile, HF-Bauteile
• Pollin - Neuteile und preiswerte Restposten
• Reichelt - durchsortiertes Vollsortiment
• Voelkner - durchsortiertes Vollsortiment

Lieferanten für Werkzeuge

• Westfalia - Werkzeugversand

Dienstleister (alphabetische Liste)

Unterstützer von kicad-users-de

• Tarnsat - Kicad-Anwender, getarnte Satantennen, Elektronikentwicklung, Schaltschränke, Schaltaktoren, Webmasterdienste, Musterbau

Leiterplattenfertiger

• Bilex-lp - verarbeitet Eagle und Gerberdaten
• PCB-Pool - verarbeitet Eagle und Gerberdaten

sonstige Dienstleister

Developer

Arbeit mit dem SVN

Grundsätzliches zu SVN

SVN ist ein Versionsverwaltungsystem, welches es ermöglich, dass viele Entwickler quasi gleichzeitig und unabhängig an einem Projekt arbeiten können.

SVN fügt die lokalen Änderungen bei jedem Entwickler lokal zu einer funktionierenden Einheit zusammen. Dies funktioniert aber nur, wenn sich die Entwickler dabei an einige sinnvolle Regeln bei der Benutzung des SVN halten. Es ist also erforderlich, dass der komplette Dateibaum unterhalb von ./src jederzeit und klaglos und ohne alle Fehler und Warnungen kompiliert.

Nur wenn das der Fall ist, dann wird der Stand mit dem Befehl "svn commit" bei allen anderen Entwickler "scharf geschaltet". Aus diesen Grund ist eben eine gewisse Disziplin nötig. Eine zusätzliche Sicherheit ist dann gegeben, wenn jeder "sein File" selbst editiert, denn da weiss er was er tut und was er falsch gemacht hat. Dazu ist sinnvoll sich oben im File zu verewigen.

Grundregeln:

1. Ändere nur wenige und überschaubare Zeilen.
2. Teste es erst aus.
3. Erst wenn es sauber läuft, dann ein "svn commit" mit aussagekräftigem Kommentar in englisch absetzen.
4. Nur ein neues, halb leeres File kann mit "initial Revision" commitet werden.
5. Zuviele Änderungen auf einmal übersieht man nicht so gut und englisch ist nötig damit auch Entwickler aus anderen Ländern die Änderungen verstehen und mit durchsehen können.

fremdes File und commit

Niemand mag es wenn jemand ins Büro kommt, ohne ein Wort zu sagen, sich ein paar Aktenordner greift, darin rumändert und paar Seiten durch den Schredder jagt und die Ordner wortlos irgendwo ablegt.

Genau das gleiche passiert aber im SVN wenn man gedankenlos fremde Files ändert oder verschiebt ohne sich vorher mit dem Fileowner zu verständigen. Der Fileowner steht oben in jedem File. Bei Emailzusendungen von Files oder wenn das nicht der Fall sein sollte steht zumindest der letzte Comitter im SVN, also der, der das File selbst geändert oder für den Fileowner hochgeladen und commitet hat.

Der Regelfall ist folgender: Man macht sich zunächst bei einem Änderungswunsch eine zweite Arbeitskopie und zwar in einem separaten Verzeichnis und ändert dort in das File schrittweise rein und versieht jede Änderung mit Kommentaren, wer, wann, warum was geändert hat. Wie das geht kann man sich in den Kernelsourcen von Linux beispielhaft ansehen.

Änderungen werden nicht sofort commitet, da sonst das SVN einen Stand haben könnte der sich nicht mehr kompilieren lässt, sondern nach jedem Schritt mit Diff -Nru <alte Datei> <neue Datei> > <neue Datei>.diff zunächst ein Diff-Patch erzeugt und dies kriegt der Fileowner mit ein paar Erklärungen per Email geschickt, um es sich selbst anzusehen.

Dabei sollten die Änderungen schrittweise, also mit mehreren Patches erfolgen, um evl. Seiteneffekte rechtzeitig zu erkennen. Wenn alles geht und die Wirkung der Änderung jedem klar ist, dann erst wird der Fileowner den Patch bei sich in einer zweiten Arbeitskopie selbst einspielen, es nochmals testen und dann erst commitet er das File.

eigenes File und commit

Bei eigenen Files ist die Sache deutlich einfacher. Man ändert einfach solange bis das Modul läuft und sich die komplette Anwendung ohne Fehler klaglos durchkompilieren lässt. Erst wenn man sich sicher ist, dass alles durchkompiliert, dann erst wird ein Commit gemacht.

Stellt man fest, dass bei anderen Modulen es Fehler oder Warnungen gibt, dann ist es fair und anständig dem betreffenden Fileowner eine Email zu schicken sich die Fehler anzusehen.

Dazu gibt es eine einfache Möglichkeit mit dem Befehl script filename.log die ganze Compilesitzung mitzuschneiden. Wenn der Fehler sich gezeigt hat, dann bricht man das Log mit exit ab. Die für den Fehler wichtigen Stellen kopiert man in eine Email und hebt aber das komplette Log für Nachfragen auf, denn der Fehler könnte seine Ursache irgendwo weiter vorn im Log haben. Es ist gut wenn man später nochmal nachsehen kann.

Arbeitsumgebung für SVN unter Windows

Für Developer empfiehlt sich bei Benutzung des SVN die Cygwin-Umgebung zu benutzen, die auch alle anderen Tools passend zu Windows integriert hat. Deshalb vorab ein Hinweis zum Aufsetzen der Cygwin32-Umgebung.

Es muss nach der Installation von Cygwin zunächst im Homeverzeichnis meist c:\cygwin32\home mit dem Befehl ls -la kontrolliert werden ob da ein File .profile bereits existiert, falls nicht, dann muss es neu angelegt werden. In diesem File wird die Variable SVN_EDITOR mit dem export-befehl gesetzt. Da die Belegung sehr nutzerspezifisch ist wurde dies nicht im configure-File festgelegt. Wer es mit dem Windows-Explorer versucht, der sollte unter "Extras/Ordneroptionen/Ansicht" die Einstellungen kontrollieren.

Andernfalls wird nur nachfolgende Befehlszeile ergänzt, um nicht jedes mal die Variable SVN_EDITOR händisch setzen zu müssen. Dieses File wird beim Start der bash-Shell einmalig gestartet und erledigt das in Zukunft automatisch.

Unter Linux springt dem Nutzer meist und ungefragt der vi oder vim ins Gesicht, auch nicht immer beglückend. Raus kommt man mit <Einf>-Taste, dann den Kommentar für das SVN schreiben und anschließend <ESC-Taste>:wq!. Das wars den Rest erledigt dann das SVN. Man fragt sich nur warum wurden die vi-Befehle nicht gleich undokumentiert verschlüsselt. Das Rätselraten für den Einsteiger dauert dann bestimmt genau so lange.

Für Windows sollte ein leicht bedienbarer Editor gewählt werden, der Syntax-Hervorhebungen und Linux-Zeichensatz beherrscht. Empfohlen wird Scintilla mit Zeilennummern und TAB's, denn das erspart die Nutzung des Editors im mc. Mit anderen Worten die Bash-console dient nur den Kommandoeingaben, also ./configure.sh oder make all Wenn Scintilla auf dem Laufwerk C: installiert wird am Ende der .profile im Homeverzeichnis folgende Eintrag ergänzt:

Analog wenn Scintilla auf anderen Windows-Laufwerken installiert ist, dann eben den Buchstaben anpassen, also...

Auschecken - erste Schritte mit SVN

Es gibt im Internet eine gute Beschreibung, die eine Menge Erklärungsaufwand erspart und zwar: http://www.informatik.uni-mainz.de/lehre/dsea/Support/svn-howto.pdf

Falls die bash-Shell noch nicht neu gestartet worden ist, dann gibt man eben einmal noch die export-Befehlszeile händisch ein.

Anschließend sollte man im Homeverzeichnis ein Unterverzeichnis anlegen ./SVN und in dieses wechseln.

Falls der lokale Nutzename nicht mit dem Login in Origo übereinstimmt, dann wird der Loginname von Origo und das gesetzte Passwort nach einem ersten Fehlversuch erneut abgefragt.

Compilation

Sollte es Probleme geben, dann bitte dies bei "Issues" melden.

Arbeit mit dem Wiki

Hilfe bei Wikimedia

Zum Editieren der Wikiseiten muss man Gruppenmitglied und online sein. Eine Hilfe gibt es bei Wikipedia.

Hinweis: Das 'wild-wütende Umwerfen und Löschen ganzer Artikel' wird bei Wikipedia als Editwars bezeichnet und mit Verwarnung belegt. Man kann zwar alles wieder rücksetzen, aber es ist jedes mal ein erheblicher Aufwand.

Empfehlung: Für Kicad-users-de wird empfohlen die Artikel mit dem Admin per Email oder im Chat absprechen, der das Wiki sowieso ständig aktualisiert.

• Formatierungen
• Links

bekannte Probleme

Beim Editieren der Artikel bitte darauf achten, dass vor dem Abspeichern die Leetzeilen am Ende des Textes jedes mal entfernt werden die Origo automatisch anfügt. (scheint ein Bug zu sein)