KiCad improved via management

Today I am putting out the first version of my KiCad via improvements. I created this during routing of my Nokia Retro Fit project. The board I wanted to create has this layer stack:

As you can see I want to be able to create micro vias on the layers 1,2,3 and 6,7,8. Using even the nightly builds of KiCad only allows you to place micro vias on the top or bottom to the adjacent layer below. so from 1 to  2 and 7 to 8. This where my additions come into to play.

I enhanced the user vias diameter and drill part of the Design Rules dialog. It now comes with more options.

  • Via Type (Through, Blind/Burried, Micro)
  • Start Layer
  • End Layer

The via class has those additional values as well.

Placing a micro vias during layout does not yet work as intended, but I am working on it. You can change it after placement nonetheless. So placing vias is not yet as comfortable as I would like it to be.
Editing a via after placing now gives you this dialog:

It gives you a list of all the vias created and you can double click to change the values below. It does not let you enter values that are not listed in the user via list. But you can select the „Add user via“ checkbox to add your desired values to the list of user vias.

With this modifications to the KiCad source code I think I should be able to finish routing my DDR3 signals.

The issue with measuring the tracks still is on my list of things to do. Placing micro vias in a sensible way was more important to achieve though.

To try out the changes for yourself you can find the source code here

KiCad Via Eigenschaften Dialog

Ich habe meine erste Änderung im KiCad Quelltext als Patch in die Mailingliste gegeben. Diese Änderung ermöglicht es den Via Eigenschaften Dialog dazu zu verwenden, den Via Typ, Start- und Endlage, sowie die Bohr- und Kupferdurchmesser festzulegen.

Ändern des Via Typs

Ist der Netzklassen Durchmesser der Via kleiner als der angegebene Wert, wird eine Meldung angezeigt, mit der die Größe der Netzklasse übernommen werden kann. Das ist hilfreich, wenn eine Micro-Via zur Through-Hole werden soll, denn die ist meistens größer als die Micro-Via.


Der Patch befindet sich gerade in der Diskussion und wird eventuell in leicht abgeänderter Form in der nächsten Zeit integriert.

Wer den Dialog selbst mal ausprobieren möchte, findet das Projekt hier.

KiCad Net Class Constraint Management

Ich bin gerade dabei ein relativ komplexes Design in KiCad zu entwicklen. Es handelt sich dabei um ein i.MX7 Prozessor mit DDR3 Anbindung. Für DDR3 sind einige Designrichtlinien einzuhalten. Diese sind neben der Leitungsimpedanz (50 Ω Transmission Line und 100 Ω Differantial Line) auch die Länge der einzelnen Signalgruppen und des Clock Signals. Darüber ein Überblick zu behalten ist nicht leicht. KiCad hat keine Funktion einfach diese Constraints zu checken und zu verwalten. Zum Glück handelt es sich um ein Open Source Projekt und daher habe ich den Versuch gestartet, pcbnew mit den nötigen Funktionen auszustatten. Ziel ist es einen angenehmen Routing-Vorgang solcher komplexen Schaltungen zu erhalten. Dazu gehören neben der Verwaltung der Constraints auch noch andere Features:

  • Live Tracking der Leitungslängen
  • Reporting der Constraints
  • DRC der Constraints
Der erste Schritt wird sein die Constraint Daten in die Netzklasse mit einzubinden. Dazu habe ich den Design Rule Dialog erweitert. Er hat 8 neue Spalten erhalten.
  1. Max Vias
  2. Topology
  3. Min Length
  4. Max Length
  5. Max Skew
  6. Stub Length
  7. Type
  8. Layer

Max Vias

Ein hochfrequentes Signal wird an jedem Materialeigenschaften-Übergang reflektiert und verliert Energie. Das können beispielsweise Änderungen des Leitungsquerschnitts, Bezugsmasse, Leitungsmaterials, oder anderer Umgebungsparameter sein. Eine Signalübergabe über ein Via in eine andere Lage ist genau so ein Übergang und führt zu Signalfehlern. Daher gibt es für manche Signale eine maximale Anzahl von Vias.

Topology

Die Routing Topologie ist die Art und Weise, wie das Signal von der Quelle zu einer Senke, oder mehrerer Senken übertragen wird. Es werden folgende Topologien erkannt:

  • STAR
    Das Signal geht von der Quelle sternförmig zu jeder Senke mit einer eigenen Leitung.
  • T
    Das Signal teilt sich (auch mehrmals) in jeweils zwei gleichlange Äste auf.
  • FLYBY
    Hier wird das Signal von der Quelle aus an jeder Senke vorbei geführt, ohne sich aufzuteilen. Alle Zwischenstücke sind gleichlang ausgelegt.
  • HORIZONTAL
    Alle Signale sollen horizontal geführt werden.
  • VERTICAL
    Alle Signale sollen vertikal geführt werden.
  • SIMPLE_DAISY_CHAIN
    Das Signal geht von der Quelle zur ersten Senke, von dort zur zweiten und so weiter. Vergleichbar mit der FLYBY Topologie.
  • MIDDRIVEN_DAISY_CHAIN
    Bei dieser Topologie geht das Signal von der Quelle nach beiden Seiten an mindestens zwei Senken. Dies ist eine Kombination aus eine Ebene T und FLYBY.
  • MULTIPOINT_TOPOLOGY
    Das Signal wird an vielen Stellen verbunden. (Niederfrequente Signale oder Spannung/Ground)

Min/Max Length

Signale, die laufzeitbegrenzt sind, oder in Relation mit anderen Signalen stehen, müssen eine gewisse Länge einhalten. Diese beiden Werte geben das Längenfenster an, in dem sich alle Signale der Netzklasse befinden dürfen.

Max Skew

Ähnlich wie die Min/Max Länge ist der Skew eine Toleranzangabe für die Länge aller Signale der Netzklasse. Beispielsweise muss ein Bus mit 8 Signalen maximal nur 60mm lang sein. Die 8 Signale sind aber auf einem Skew von 2mm begrenzt. So kann die Gruppe an sich in der Länge variieren, die einzelnen Signale sind aber strikter reglementiert.

Stub Length

Ein Stub ist eine Abzweigung des Signals. Am Ende der Leitung wird das Signal reflektiert und zurück geworfen. Das kann bei zu langen Stubs zu Problemen führen. Daher werden für diese Fälle maximale Stublängen angegeben.

Type

Hier kann zwischen den Leitungstypen Signal, Power oder Mixed gewählt werden. Diese werden an den globalen Layer Einstellungen gemessen.

Layer

Der Type Wert kann manuell überschrieben werden um die Lage in der die Leitung geführt werden darf weiter zu beschränken, oder weiter aufzulösen. Manchmal dürfen Signale nicht auf die andere Seite der Leiterkarte übertragen werden. Das kann mit dieser Einstellung konfiguriert werden.

Der aktuelle Stand ist, dass die Werte in die Tabelle eingetragen werden und mit dem Projekt abgespeichert werden können. Ich erweitere gerade die Tabelle dahin, dass die Werte schöner angezeigt werden und es für die Topologie, und Type Felder eine Dropdown-Liste gibt. Das Layer Feld soll eine Auswahlliste bekommen, in der die erlaubten Layer markiert werden können.

Live Tracking der Leitungslängen

Ein weiteres großen Feature soll das messen der Leitungslänge in Echtzeit sein. Dazu gehören mehrere Elemente. Einerseits soll auf der rechten Seite des Fensters zwischen Zeichenfeld und Toolbar eine Liste mit den zu messenden Leitungen eingeblendet werden können. Das soll ebenso wie der Layer-Dialog entweder fest am Fenster verankert, oder frei beweglich im Fenster verschoben werden können.
Andererseits soll ein weiteres Element eine Statusbar-Anzeige sein, die in Echtzeit zeigt, ob die Leitung zu lang oder zu kurz ist. Idealerweise kann hier schon eine Prognose eingebaut werden, die versucht zu ermitteln, ob mit der Länge das Ziel überhaupt erreicht werden kann. Hier werde ich am Anfang auf die „Luftlinie“ zurückgreifen und den direkten Weg als Grenze nehmen.

Reporting der Constraints

Dieses Feature ist relativ einfach zu realisieren. Alle Netze mit Constraints in der Netzklasse werden in einem Report ausgegeben und stehen als Textdatei zur Verfügung.

DRC der Constraints

Der Design Rule Check soll um die Constraints erweitert werden und mit den Fehlerklassen Report, Warning, Error über die Constraints berichten.

KiCad auf Ubuntu selbst kompilieren

Ich möchte einige Änderungen in KiCad einfügen und dazu will ich mir die aktuellste Version aus dem Sourcecode übersetzen. Das ganze werde ich mit Ubuntu 17.4 durchführen. Dazu benötigen wir aber erst mal ein paar zusätzliche Funktionen

sudo apt install build-essential libwxbase3.0-dev libwxgtk3.0-dev libglew-dev libglm-dev libcurl4-gnutls-dev libcairo2-dev libboost-all-dev swig python-wxgtk3.0-dev doxygen libssl-dev git cmake

Mit all diesen Bibliotheken können wir nun anfangen den Code herunterzuladen, für unser System zu konfigurieren und zu übersetzen. Dazu laden wir den aktuellsten Code vom Git Repository herunter:

git clone -b master https://git.launchpad.net/kicad

Danach legen wir einen Ordner an in dem wir die Übersetzung vornehmen möchten und konfigurieren unsere Umgebung:

cd kicad
mkdir -p build/debug
cd build/debug
cmake -DCMAKE_BUILD_TYPE=Debug \
 -DKICAD_SCRIPTING=ON \
 -DKICAD_SCRIPTING_MODULES=ON \
 -DKICAD_SCRIPTING_WXPYTHON=ON ../..

Wenn das dann durchgelaufen ist, können wir die eigentliche Übersetzung starten:

make

Der Prozess kann je nach Systemleistung einige Zeit dauern.  Bei mir waren es ca. 30 Minuten. Nach Fertigstellung der Programme stehen sie in dem aktuellen Ordner zur Verfügung. Installieren kann man dann KiCad mit dem Befehl

sudo make install

Das nächste mal schauen wir dann, wie wir den Quellcode bearbeiten können um ein weiteres Menüfenster hinzuzufügen.

Nokia 3210 Retro Fit Board Teil 4

Ich versuche gerade ein Android Image für den i.MX7 auf meinem Nokia Retro Fit Board zu bauen. Das Buildsystem für Android ist gigantisch. Es besteht aus über 100 Git repositories, die mit Hilfe eine Tools heruntergeladen werden. Dazu benötigt man über 90GB Festplattenspeicher! Zusätzlich zu Android benötigt man auch noch den Linux Kernel und die passenden Patches um das originale Android und Kernel auf die CPU anzupassen auf der das System später laufen soll. Das alles dauert eine ganze Zeit, bis es einmal steht. Anschließend muss das System aus dem Quellcode kompiliert werden. Damit man nicht jede einzelne Datei selbst kompilieren muss, gibt es auch hierfür ein Tool, dass den Prozess automatisiert. Dieses Tool, mit dem Namen ‚lunch‘ geht durch die Verzeichnisstruktur und sammelt alle Informationen, welche Dateien für welches System wann kompiliert werden sollen. Danach wird noch ermittelt, welche Dateien zum System Image hinzugefügt werden sollen und zum Schluss in welchem Format das System Image erzeugt werden soll. Wenn das alles fertig ist, dann kann der Prozess starten, der aus dem Android Open Source Project ein Firmware Image erstellt, dass auf einem Embedded System lauffähig ist.

Ich habe den Prozess, wie man zu der passenden Buildsystem kommt hier dokumentiert:
https://github.com/DasBasti/NokiaRetrofitAplications

Jetzt bin ich dabei herauszufinden, wie man das Android anpasst, sodass es nicht für das Sabre Board baut, sondern für meine Hardware mit meinen Treibern und meiner Boot Konfiguration. Danach werde ich versuchen, das System auf Android Wear umzustellen, da das für so kleine Bildschirme wie ich ihn verwenden möchte optimiert ist. Wie das geht weiß ich noch nicht. Aber ich werde es versuchen.

Hardware

Ich bin im Schaltplan ein wenig weiter gekommen, auch wenn ich noch kein Update in das Repository übertragen habe. Ich bin im Moment dabei die Ladeschaltung für den originalen NiMH Akku zu zeichnen. Zusätzlich wird ein LiPo Akku anschließbar sein. Ich weiß noch nicht, wie viel Strom der i.MX7 benötigt und wie lange dann der original Akku hält. Er ist mit 1200mAh angegeben. Das ist einiges, wenn man bedenkt, dass das kleine Display nur 30mA benötigt, wenn es an ist. Eine detaillierte Stromverbrauchsrechnung ist auch in Arbeit, die wird zeigen, ob die Verwendung der originalen Batterie überhaupt ein gangbarer Weg ist.

Nokia 3210 Retro Fit Board Teil 2

Ich bin dabei ein Mainboard zu designen, dass sich als Nachrüstbausatz in ein Nokia 3210 einbauen lässt. Es wird das Nokia mit Android versorgen und ein OLED Display mitbringen. Anders als in einem früheren Beitrag werde ich kein STM32 Mikrocontroller, sondern einen Applikationsprozessor mit allem was dazugehört verwenden. Ziel dieser Übung ist es ein i.MX7 Board zu designen, zu layouten und mit Software in Betrieb zu nehmen.
In den letzten Tagen habe ich das Github Repository umgestellt, um die Symbole, Footprints und Software nicht im Board Repository zu haben. Ich hoffe so lässt es sich besser verwalten.

DDR3L Schaltung für das Retro Fit Board

Schaltplan für PMIC und DDR3 sind fertig. Alles andere muss noch vom Schaltplan für den STM32 chip konvertiert und neu verdrahtet werden. Diesmal wird das TI-BLE/WIFI Modul WL1807MOD wieder zum Einsatz kommen. Die aktuellen Daten sind bei Github zu finden. Außerdem poste ich Updates auch auf meinem Hackaday.io Profil.

Nokia 3210 Retro Fit Board

Ich hatte früher ein Nokia 3210. Heutzutage ist es allerdings ein wenig außer Mode geraten. Nagut, es ist eigentlich nicht mehr benutzbar. Deshalb habe ich begonnen ein Mainboard zu designen, dass in die Mechanik des alten Nokia Knochens passt.

Frontansicht der Retrofit Platte (es fehlen noch viele Bauteile)

Das ganze Projekt wird auf Github zur Verfügung stehen. Die aktuelle Version umfasst folgende Features:

  • STM32F439 MCU
  • 160×128 OLED Display
  • Audio Codec LM4930
  • Stereo Mikrofon
  • Haptic Feedback Engine
  • A7 GSM/GPRS Mobile Radio Module
  • ESP8266 WiFi Module
  • µSD-Card Interface

Allerdings bin ich mir bei der MCU nicht sicher, da ich gerne ein Android als Betriebsystem verwenden möchte. Dazu würde ich die MCU durch einen Prozessor tauschen. Genauer würde ich gerne den i.MX7 von NXP einsetzen. Dieser ist ein Dual Core Prozessor mit bis zu 1,2GHz. Das ist für ein Android ausreichend.
Weiterhin hätte ich auch gerne Bluetooth mit an Board. Dazu habe ich die TI WiLink Module ins Auge gefasst.

 Das Board kann nach Fertigstellung dann in die Mechanik eines Nokia 3210 eingebaut werden. Also nicht wie los und noch schnell eins der letzten kaufen.

Ein Blick auf KiCad [Fertige Leiterplatte]

Wie in den letzten Wochen bereits beschrieben haben wir eine Schaltung in KiCad eingegeben, danach eine Liste der verwendeten Bauteile angelegt und anschließend die Leiterplatte erstellt und die Fertigung in Auftrag gegeben. Heute schauen wir uns das Ergebnis an und betrachten, was alles im Prozess der Entwicklung einer solchen Baugruppe schief gehen kann.

Links – benötigte Bauteile zur Bestückung der Platte
Rechts – unbestückte Leiterplatten

Die Leiterplatten werden in einer Vakuumverpackung angeliefert. Auf den ersten Blick sind die einwandfrei und so wie wir uns das fertige Produkt vorgestellt werden. Doch der Teufel liegt im Detail. Nach bestücken und Verlöten der Bauteile, sind einige Fehler im Schaltplan, sowie in den Layoutdaten aufgefallen.

Um die Fehler der Schaltung verstehen zu können muss erst einmal die Funktion erklärt werden. Die Baugruppe soll nach betätigen des ‚Enable‘ Tasters ein Magnetventil mit einer Anzugsspannung versorgen. Diese Spannung soll eine kurze Zeit anliegen und danach selbstständig in eine PWM umgewandelt werden. Diese soll so lange erhalten bleiben, bis der ‚Enable‘ Taster nicht mehr betätigt ist.

Fertig bestückte Platine

Fail #1

Der Enable Eingang schaltet lediglich das Delay zur Logik dazu, startet dieses jedoch nicht. das Delay wird sofort nach Anlegen der Betriebsspannung gestartet und ist bei betätigen des Tasters bereits abgelaufen.
Fix: Spannungsteiler auflösen, mit Fädeldraht an ‚Enable‘ löten.

Fail #2 

Der Pfostenstecker für das Magnetventil ist nicht korrekt angeschlossen. Beim verschieben des Steckers ist eine neue Leitung auf der Bottom Seite hinzugekommen, allerdings wurde die Kupferfläche nicht erneut ausgefüllt und ist somit direkt mit dem Signal verbunden. Das DRC hat diesen Fehler nicht gefunden!
Fix: Mit Skalpell die Verbindung auftrennen und mit Fädeldraht korrekt verbinden.

Fail #3 

Zum Messen mit dem Oszilloskop befinden sich kaum Massepunkte auf der Platte. Um mit dem Oszilloskop sinnvoll Signale auf einer Baugruppe zu messen, ist es wichtig naheliegende, also kurze Verbindungen zur Masse zu bekommen. Es ist durchaus akzeptabel wenn für diese Baugröße nur ein solcher Verbindungspunkt bestünde. Tut er aber nicht.
Fix: Mit Skalpell den Lötstopplack der Massefläche entfernen und ein Stück Draht dranlöten.

Fazit

KiCad eignet sich hervorragend zur Erstellung von kleinen Projekten sowie Erzeugung von Stücklisten und Fertigungsdaten. Es wird sich zeigen wie die Entwicklung voranschreitet. Spannend wird auch bleiben, wie die Verwaltung von Stücklisten in den nächsten Versionen gehandhabt wird. Bis dahin wird aber noch einige Zeit vergehen.

Ein Blick auf KiCad [Design zur Fertigung]

Wir haben uns in den letzten beiden Wochen angeschaut, wie eine Schaltung in KiCad erstellt und die benötigten Daten zur Erstellung der Leiterplatte generiert werden. Der Prozess, der aus einem Schaltplan eine Leiterplatte macht beginnt mit der Auswahl eines Herstellers. Denn von Beginn an ist es wichtig zu wissen, welche physikalischen Grenzen dem Leiterplattendesign gesetzt sind. Dazu zählt der Mindestabstand zwischen Leiterbahnen, die Mindestgröße von Bohrungen für Durchkontaktierungen und die Mindestbreite der Aussparungen im Lötstopplack für die Lötpads.
Alle diese Werte werden von dem Fertiger festgelegt und können auf dessen Webseite gefunden werden. Einer dieser Anbieter ist Multi-cb. Bei Multi-cb gibt es jede Menge Hinweise dazu, wie die Grenzen der Leiterplatte festzulegen sind, wenn man keine Sonderanfertigung wünscht. Für die Meisten Projekte wird auch keine Sonderanfertigung von Nöten sein, es kann also der kostengünstige Pool für die Fertigung der Leiterplatten gewählt werden.

Der Leiterplatten Kalkulator gibt auch einige Hilfestellungen, was die optimale Bestellauslegung betrifft. Zuerst legt man ein Projektname fest, gibt an, welche Größe und welche Oberfläche gewünscht ist. Daraus kann die erste Ermittlung des Preises gewonnen werden. Meistens bekommt man dann angezeigt, dass die Fertigungsdauer ohne Aufpreis wesentlich kürzer (5AT) sein kann als 20AT. Die Oberfläche HAL bleifrei ist die günstigste. Diese Oberfläche besteht aus einer Zinnoberfläche, die mit Heißluft auf die blanken Kupferflächen aufgebracht wird.
Wie bei der Oberfläche gesehen sind die voreingestellten Werte die günstigsten. Jede Änderung im Fertigungsprozess führt dazu, dass die Platte eventuell aus dem Pooling Prozess herausfällt und als Einzelcharge angefertigt werden muss. Der Pooling Prozess bedeutet, dass viele verschiedene Designs auf einem Nutzen, also eine große Platte, untergebracht werden und somit die Rüst-, Arbeits- und Verwurfskosten auf alle Pooling Teilnehmer umgelegt werden können.

Die einzige Ausnahme ist der Topseitige Positionsdruck. Der ist standardmäßig nicht ausgewählt, kostet allerdings auch nichts extra. Man muss mit den Werten ein wenig spielen um die Ideale Konfiguration zu erreichen. Grundsätzlich gilt, wenn ein extra Fertigungsschritt dazu kommt, wird die Platte teurer.

Anhand der ausgewählten Parameter werden die verschiedenen Grenzen der Design-Regeln festgelegt. Im Kalkulator haben wir festgelegt, dass die kleinste Leiterbahnbreite 150µm sei. Diese Größenbegrenzung gilt für alle Leiterbahnen, alle Vias und den Abstand zwischen den Leiterbahnen.
Wir legen also 0,15mm als Untergrenze für die Leiterbahnbreite fest. Leiterbahnen, die Strom führend sind, werden mit dieser Breite unter Umständen sehr heiß. Der PCB Kalkulator von KiCad kann dazu mehr Auskunft geben. Dementsprechend sollten Leiterbahnenbreiten festgelegt werden.
Wie in den anderen Teilen dieser Serie gehen wir davon aus, dass das Design bereits anhand der ausgewählten Designregeln erstellt wurde. Das kann zum Beispiel wie folgt aussehen:

Fertiges PCB Design

Die hier erstellte Platte hat die angegebenen Abmaße von 45mm x 45mm und ist mit zwei Lagen vollständig entflochten. KiCad bietet zur Vorschau der Leiterplatte eine 3D Ansicht der CAD Daten. Diese kann unter Ansicht -> 3D Darstellung angezeigt werden. Mit Hilfe der Vorschau kann zum Beispiel die Lesbarkeit des Siebdrucks bestimmt werden, oder ob Gehäuse leicht bestück- und lötbar sind.

3D Vorschau der Leiterplatte

Gerberdaten erzeugen

Um aus dem Design die zur Herstellung der Leiterplatte notwendigen Dateien zu generieren muss festgelegt werden, welche Lagen des Designs für die Herstellung notwendig sind. Jede dieser Lage wird in einem eigenen Arbeitsgang hergestellt. Das gängigste Format, in dem die Fertigungsdateiein abgelegt sind ist das Gerber Format. Dieses wird in einem Standard festgelegt und von allen Leiterplatten Herstellern unterstützt.

In unserem Projekt benötigen wir zwei Lagen Kupfer und zwei Lagen Lötstopplack. sowie Siebdruck für die obere Lage. Weiterhin benötigen wir die Kanten-Lage, auf der die Grenzen der Leiterplatte eingezeichnet sind. Mit einem Druck auf „Plotten“ werden die ausgewählten Daten erzeugt und in dem angegebenen Ordner gespeichert.
Es fehlen jetzt nur noch die Daten für die Bohrmaschine. Diese können unter
Datei -> Fertigungsdateien -> Bohrdatei *.drl erzeugt werden. Multi-cb benötigt metrische Angaben. Darauf ist unbedingt zu achten, damit die Bohrungen passend zu den Footprints sind.

Ansicht der Gerberdaten zur Verifizierung vor der Bestellung

Nachdem alle Fertigunsdateien erstellt wurden, kann das Ergebnis mit dem ebenfalls in KiCad enthaltenen GerbView angezeigt werden. In diesem Programm werden alle erzeugten Gerberdateien übereinandergelegt und Fehler werden sofort sichtbar.

Um die Bestellung der Platte abzuschließen werden die Produktionsdateien in ein Zip-Archiv gepackt und über die Webseite zu multi-cb hochgeladen. Die Produktion der Leiterplatte beginnt jetzt. Es ist auch der Zeitpunkt gekommen alle Bauteile der BOM zu bestellen und bereitzulegen.