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.

Herbert Mk3: An der Wand

Das neue und offizielle Raspberry Pi Touchscreen mit DSI Anbindung und kapazitivem Touch ist endlich auch für mich lieferbar gewesen. Nachdem ich fast einen Monat darauf gewartet habe kann ich die Schaltzentrale für meine Wohnung jetzt endlich an den Nagel hängen…

Raspberry Pi 7″ TFT Gehäuse: Modell

Mit einem eigenenen 3D-gedruckten Gehäuse hängt der Raspberry Pi 2 mit Display jetzt im Flur. Mit an Board ist ein BLE Dongle, zwei WLAN Sticks und ein 64GByte Massenspeicher. Auf dem System läuft ein Raspbian mit LXDE und Iceweasel Browser als Frontend und openhab, mogodb, mosquitto, HerbertScanner und HerbertNode im Backend.

Openhab mit mosquitto habe ich ja bereits in älteren Posts bereits erwähnt und mongodb als Datenbank ist auch keine Besonderheit. Die zwei interessanten Softwarekomponenten sind HerbertScanner und HerbertNode.

HerbertScanner ist eine Applikation, die mit dem BLED112 von BlueGiga kommuniziert und die Advertisement Pakete der BLE Buttons im Umkreis registriert. Ein Advertisement Paket im richtigen Format wird an mosquitto, also als MQTT Nachricht weitergeleitet. So werden Daten von BLE Endpunkten a die openhab Zentrale geleitet.
Die Konfiguration der BLE Geräte muss zur Zeit manuell durchgeführt werden. Dazu muss der MQTT Kanal ‚/Herbert/#‚ abonniert werden.  Dort werden alle Nachrichten abgeliefert. Neue Geräte erscheinen da dann auch und können mit der ID registriert werden.

HerbertNode ist eine Applikation, die für das Konfigurieren der WLAN Endpunkte eingesetzt wird. HerbertNode scannt die WLAN Netzwerke in der Umgebung und findet die Accesspunkte von ESP2866 Geräten. Diese starten, wenn sie keine Konfiguration besitzen, oder das konfigurierte Netzwerk nach 30 Sekunden nicht gefunden wurde in den Accesspoint Modus. Sobald HerbertNode eine ESP2866 SSID sieht, verbindet er sich mit dem AccessPoint und stellt eine HTTP Anfrage nach ‚/info‘. Das Gerät gibt dann Informationen über sich im JSON-Format an HerbertNode weiter. HerbertNode hat eine Liste der verfügbaren Geräte im Umkreis. Vom Benutzer kann in dieser Liste das Gerät ausgewählt und dem Netzwerk hinzugefügt werden, dazu wird dem Gerät die SSID und der Zugangsschlüssel für das Herbert-WLAN übertragen.

Der Code wird im Laufe der nächsten Wochen noch verfeinert und stabilisiert. Es treten teilweise noch Fehler auf, die noch behoben werden müssen, bevor Herbert zum ersten mal veröffentlicht wird.

USB Geräte über IP tunneln (usbip)

Das usbip Projekt ist seit kurzem als stabiler Bestandteil des Linuxkernels bestimmt worden. Das bedeutet, dass die Funktionalität standartmäßig in die Kernels der großen Distributionen kompiliert werden. Es herrscht allerdings noch einige Unklarheiten wie das Paket ausgeliefert werden soll. Der aktuelle (3.16) Kernel des Ubuntu 14.10 (Utopic Unicorn) hat die Module für usbip bereits dabei. Es draf bloß nicht der Fehler gemacht werden und das ‚usbip‘ Paket aus dem Paketmanager isntalliert werden; dieses enthält eine sehr alte Version des Projekts. Vielmehr muss nur das Paket ‚usbip-utils‘ installiert werden.

Wenn die benötigten Pakete geladen sind kann der usbip Server gestatet werden. Dieser lautet ‚usbipd‘ und kann entweder als Programm oder im Hintergrund geladen werden.

basti@localhost:~$ sudo usbip

oder

basti@localhost:~$ sudo usbipd -D 

Um  USB Geräte über diesen Server zur Verfügung zu stellen, müssen die Kernelmodule ‚usbip_core‘ und ‚usbip_host‚ sowie ‚vhci_hcd‘ geladen werden.

basti@localhost:~$ sudo modprobe usbip_core
basti@localhost:~$ sudo modprobe usbip_host
basti@localhost:~$ sudo modprobe vhci_hcd

Die Liste der verfügbaren USB Geräte kann mit ‚basti@localhost:~$ usbip list -l‚ angezeigt werden. Die Ausgabe sieht dann zum Beispiel so aus:

 – busid 1-2 (05dc:b051)
   Lexar Media, Inc. : unknown product (05dc:b051)

Um das gewünschte Gerät zu exportieren wird dem Kernelmodul das USB Gerät übergeben. 

basti@localhost:~$ usbip bind -b 1-2

Wenn ein USB Gerät an den usbip Treiber weitergegeben wurde, steht es dem System nicht mehr zur Verfügung. Es kann allerdings mit usbip auch lokal wieder eingebunden werden. Und genau das müssen wir zuerst tun, bevor wir mit Windows die Interfaces des USB Gerätes sehen können. Weshlab das so ist, ahbe cih noch nicht herausgefunden, lediglich dass es so ist.

basti@localhost:~$ usbip list -r 127.0.0.1
Exportable USB devices
======================
 – 127.0.0.1
        1-2: Lexar Media, Inc. : unknown product (05dc:b051)
           : /sys/devices/pci0000:00/0000:00:06.0/usb1/1-2
           : (Defined at Interface level) (00/00/00)

basti@localhost:~$ sudo usbip attach -r 127.0.0.1 -b 1-2
basti@localhost:~$ usbip list -r 127.0.0.1
Exportable USB devices
======================
 – 127.0.0.1
        1-2: Lexar Media, Inc. : unknown product (05dc:b051)
           : /sys/devices/pci0000:00/0000:00:06.0/usb1/1-2
           : (Defined at Interface level) (00/00/00)
           :  0 – Mass Storage / SCSI / Bulk-Only (08/06/50)

 
Wie man an der Ausgabe sieht, erscheint das Interface erst, nachdem das Gerät einmal eingebunden wurde. Um es auf einem anderen Computer einzubinden muss es aus dem lokalen Rechner gelöst werden.


basti@localhost:~$ sudo usbip detach -p 0

Damit wird das Gerät wieder frei um von der Windows Seite her eingebunden zu werden. Das ReactOS Projekt hat für Windows signierte Treiber erstellt. Diese können auf der Webseite des usbip Projektes heruntergeladen werden. Die mit den Treibern ausgelieferte Version 0.2.0.0 von usbip.exe ist allerdings zu alt um mit dem aktuellen usbip-Server zu arbeiten. Die Quellcodes sind allerdings offen und man kann sich eine Version kompilieren, oder ihr könnt euch meine kompilierte Version von hier herunterladen. Es handelt sich dabei um die aktuellste Version des SVN Repositories.

Unter Windows muss der usbip Enumerator Treiber installiert werden. Unter Windows 7 kann das über den Gerätemanager erfolgen. Im Gerätemanager klickt man auf den lokalen Computer mit der rechten Maustaste und wählt Legacyhardware hinzufügen.

Im folgenden Dialog wählt man die manuelle Metode aus und ‚Alle Geräte anzeigen‘. Der Button ‚Datenträger…‘ lässt dann zu den Ordner der usbip-Treiber auszuwählen. Installiert nun den ‚USB/IP Enumerator‘.

Der Treiber kann jetzt verwendet werden. Über die Kommandozeite (cmd.exe) führen wir die usbip.exe aus und binden das entfernte USB-Gerät ein.

C:\Release>usbip -l 192.168.0.1
– 192.168.0.1
   1-2: Lexar Media, Inc. : unknown product (05dc:b051)
        :
/sys/devices/pci0000:00/0000:00:06.0/usb1/1-2
        : (Defined at Interface level) (00/00/00)
        :  0 – Mass Storage / SCSI / Bulk (Zip) (08/06/50)

C:\Release>usbip -a 192.168.0.1 1-2
new usb device attached to usbvbus port 1

Receive sequence:    46600

Das Gerät wird von Windows wie ein lokal angestecktes Gerät gesehen und die Treiber werden lokal installiert. Um das Gerät wieder freizugeben wird mit ‚usbip.exe -d 0‘ das Gerät entbunden und kann andersweitig wieder verwendet werden.

Zu beachten ist, dass ein Gerät immer nur an einem PC eingebunden sein kann.