Yocto Tricks

Posted on by Platinenmacher Leave a comment

Ich arbeite gerade an eine Projekt, das viele verschiedene Hardwaren mit einem Yocto build bedienen will. Dabei habe ich ein paar Tricks gefunden, die ich hier gerne teilen möchte.

VSCode Settings automatisch erstellen

Mit dem kleine Script oe-setup-vscode könnt ihr VSCode zur Verwendung mit Yocto konfigurieren. Wenn ihr euere Yocto Umgebung ertellt habt, müsst ihr lediglich folgenden Befehl ausführen

build oe-setup-vscode <path to .vscode folder> <yocto build directory>
You had no /home/bastian/Projects/yocto/.vscode configuration.
These configuration files have therefore been created for you.

Damit wird die Extension yocto-bitbake vorgeschlagen, Python Vorschläge mit poky Code gefüttert, Dateiendungen .conf und .inc mit bitbake Syntax gehighlightet und VSCode so eingestellt mit den vielen Dateien eines Yocto Projekts klar zu kommen.

Überblick über die erzeugten Pakete

Mit dem Tool oe-pkgdata-browser könnt ihr sehen, welche Pakete von welchem Rezept gebaut wurden.

Auch die zu dem Paket gehörigen Dateien die im Image installiert werden sind aufgelistet

Warum wurde ein Paket installiert?

Wenn ihr für euer Image eine .dot Datei erstellt habt, könnt ihr mit oe-depends-dot herausfinden welches Paket dazu geführt hat ein anderes zu installieren.

oe-depends-dot -k busybox -w task-depends.dot
Because: core-image-minimal packagegroup-core-boot
core-image-minimal -> packagegroup-core-boot -> busybox

Testergebnisse des OEQA Tests aufbewahren und vergleichen

Nachdem ihr ein ptest Lauf ausgeführt habt, könnt ihr mit Hilfe von resulttool Die Testergebnisse direkt in ein git repository comitten. So fallen Änderungen im Testergebnis direkt auf.

resulttool store tmp/log/oeqa/testresults.json ../tests
INFO: Reading files from tmp/log/oeqa/testresults.json
INFO: Found 1 revisions to store
INFO: Storing test result into git repository ../test
INFO: Read local tags only, some remote tags may be missed
INFO: Committing data into to branch master
INFO: Updating /home/bastian/Projects/yocto/test HEAD to latest commit
INFO: Creating tag master/75102-g28fd497a26bdcc12d952f81436a6d873d81cd462/0

Um zu so einem Testergebnis zu kommen müsst ihr in eurer Konfiguration beispielsweise der local.conf diese Optionen hinzufügen

EXTRA_IMAGE_FEATURES ?= "debug-tweaks ptest-pkgs"
IMAGE_INSTALL += "ptest-runner"

Um den Test direkt im Anschluss eines Builds durchzuführen könnt ihr diese Optionen einschalten

IMAGE_CLASSES += "testimage testsdk"
TESTIMAGE_AUTO:qemuall = "1"

Anschließend wird nach einem bitbake-Lauf das erstelle Image in qemu gestartet und der Test durchgeführt. Das Testergebnis liegt dann in build/tmp/logoeqa/testresults.json.

Gibt es updates für meine Pakete?

Um herauszufinden ob es neuer Versionen der Softwarepakete gibt, kann das Werkzeug devtool eingesetzt werden. Entweder es wird ein spezielles Paket angegeben, oder es werden alle bekannten Pakete in allen Layern überprüft.

devtool check-upgrade-status

Das läuft für eine ganze Weile und gibt dann eine Liste der Pakete, die bereits eine neuere Version haben.

Schmartwatch [15]: Python Support

Posted on by Platinenmacher Leave a comment

Vor einigen Jahren wurde Python auf Mikrocontrollern portiert. Damit ist die Programmierung von embedded Applikationen wesentlich einfacher und schneller möglich. Applikationslogik kann auf dem PC getestet werden, bevor sie auf das Target gespielt wird. Testen ist auf dem PC auch wesentlich einfacher und schneller als auf der echten Hardware. Somit spricht eigentlich nichts dagegen, Python auch für die Schmartwatch zu bauen.

Eine funktionierende Schmartwatch mit flexibler Leiterplatte ist leider immer noch nicht komplett bestückt. Das liegt einerseits daran, dass auf den flexiblen Leiterplatten der DCDC Konverter, (6 Bällchen, 2×3 mm) sehr schlecht bestückbar ist, andererseits aber auch daran, dass ich auf noch keiner manuell gelöteten Platte das Funkmodul ansprechen konnte. Diese Tatsache verzögert alles auf eine ungewisse Zeit, bis ich den Prozess der Lötung unter Kontrolle habe. Genügend Bauteile habe ich, es fehlt lediglich die Zeit für langwierige Versuche. In der Zwischenzeit habe ich mich mit einem anderen Aspekt des Projekts beschäftigt. Wir versuche also diesmal den Python Interpreter in der Micropython nRF52 Variante auf der Schmartwatch zu installieren.

Code downloaden

Dazu Klonen wir das Projekt aus dem Github Repository, laden die Module und starten den Prozess.

$ git clone https://github.com/micropython/micropython.git micropython
$ cd micropython
$ git submodule update --init
$ make -C mpy-cross

Jetzt baut das Projekt einmal komplett durch, das dauert einige Zeit. Wenn das Grundsystem steht, wechseln wir in den Pfad mit der nRF Portierung.

$ cd ports/nrf/
$ make

Wenn es hier zu einem Fehler kommt, ist wahrscheinlich der arm-gcc nicht installiert. Wie das geht kann man zum Beispiel hier nachlesen.

Standartmäßig wird die Portierung für das PCA10040 Board gebaut, darauf befindet sich ein nRF52832, also genau der Chip, der auch auf der Schmartwatch das Sagen hat. Somit ist eigentlich schon alles erledigt und mit einem simplen flash Befehl kann der Chip programmiert werden.

$ make flash

Code anpassen

Die Platformspezifischen Konfigurationen befinden sich in dem Ordner boards/pca10040, also kopieren wir diesen

$ cd boards
$ cp pca10040 schmartwatch -r

Hier kann die Modulauswahl und Pinbelegung angepasst werden. Dazu bearbeiten wir die mpconfigboard.h entsprechend der Schmartwatch Konfiguration

#define MICROPY_HW_BOARD_NAME       "Schmartwatch"
#define MICROPY_HW_MCU_NAME         "NRF52832"
#define MICROPY_PY_SYS_PLATFORM     "nrf52-DK"
#define MICROPY_PY_MACHINE_UART     (0)
#define MICROPY_PY_MACHINE_HW_PWM   (1)
#define MICROPY_PY_MACHINE_HW_SPI   (1)
#define MICROPY_PY_MACHINE_TIMER    (1)
#define MICROPY_PY_MACHINE_RTCOUNTER (1)
#define MICROPY_PY_MACHINE_I2C      (1)
#define MICROPY_PY_MACHINE_ADC      (1)
#define MICROPY_PY_MACHINE_TEMP     (1)
#define MICROPY_PY_RANDOM_HW_RNG    (1)
#define MICROPY_HW_HAS_LED          (1)
#define MICROPY_HW_LED_COUNT        (1)
#define MICROPY_HW_LED_PULLUP       (0)
#define MICROPY_HW_LED1             (8) // Frontlight LED
// SPI0 config
#define MICROPY_HW_SPI0_NAME        "SPI0"
#define MICROPY_HW_SPI0_SCK         (27)
#define MICROPY_HW_SPI0_MOSI        (25)
#define MICROPY_HW_PWM0_NAME        "PWM0"
#define MICROPY_HW_PWM1_NAME        "PWM1"
#define HELP_TEXT_BOARD_LED         "1"

Somit haben wir die Bedingungen geschaffen, die Basisfunktionen der Schmartwach nutzen zu können. Jetzt müssen wir den Kompiliervorgang noch für unsere Hardware durchführen, das geht auch wieder mit make.

$ make BOARD=schmartwatch

Das nächste mal betrachten wir, wie der Code dann auf der Schmartwatch sinnvoll einsetzbar ist, denn es gibt zum Beispiel keine UART, die über die Schmartwatch nach außen geschaltet ist. Wir müssen also das Projekt so bearbeiten, dass es die REPL anstatt über die UART Peripherie über Semihosting ausgibt.

NAGCL [I]

Posted on by zeRapha 5 Comments

In dem Eingangsartikel zu meinem Software-Projekt NAGCL (das habe ich jetzt als Interimsnamen auserkoren) bin ich kurz auf die angedachten Features des Programms eingegangen, sowie auf die Historie und Motivation dazu.
In diesem Artikel möchte ich ein kurzes Update zum aktuellen Stand des Projekts geben, sowie ein paar Implementierungsdetails vorstellen.

Für die wichtigsten Elemente des Programms bestehen mittlerweile erweiterbare Gerüste. Das trifft vor allem auf die Benutzung im Shell-Modus und auf die Übergabe von Parametern beim Programmaufruf zu.
Ebenfalls kann bereits eine Textdatei mit Pfaden zu git-Repositories eingelesen werden. Diese Pfade werden auf Existenz, Zugriffsrechte und ob diese auf ein gültiges git-Repository zeigen geprüft.

Um alle Einträge der Textdatei verwalten zu können, werden diese in einer einfach verlinkten Liste (Linked List) abgelegt. Diese Liste wird bei jedem Programmaufruf bzw. -start neu angelegt.
Im Shell-Modus bzw. als Parameter beim Programmaufruf können Elemente der Liste hinzugefügt oder entfernt werden. Ob die Liste verändert wurde, wird beim Beenden des Programms dem Nutzer gemeldet. Als letzter Schritt wird die Textdatei – sofern eine Änderung der Liste vorgenommen wurde – aktualisiert, d.h. Pfade von Repositories werden hinzugefügt oder entfernt. Die Implementierung einer einfach verlinkten Liste war notwendig um einen dynamischen Datentyp zur Verwaltung der Repositories zur Laufzeit zu erhalten. Die Implementierung ist allerdings bei Weitem nicht so elegant wie die von Linus Torvalds‘ Liste in der Kernel-Implementierung. Eine derart generische Implementierung einer Liste wird an dieser Stelle von mir aber auch nicht benötigt.

Aktuell arbeite ich daran, den Log (entspricht dem Befehl git log) eines git-Repositories auszugeben sowie den ersten Versuchen einer GUI-Implementierung. Die Implementierung der git-Funktion erfolgt mit der API libgit2, die Implementierung der GUI-Funktionen mittels der Bibliothek ncurses.

Die größte Veränderung für mich selbst war die Umstellung von Makefile zu cmake als Build-Setup.
Der Hauptgrund für den Wechsel des Build-Setups war, mich mit cmake auseinander zu setzen und einzuarbeiten. Aktuell kann das Projekt mit allen benötigten Bibliotheken gebaut und verlinkt werden, wenngleich das Setup im Moment unübersichtlich ist und noch nicht dem gewünschten Stand entspricht.
Im endgültigen Stand sollen alle benötigten Bibliotheken heruntergeladen und mitkompiliert werden. Zudem soll die Erstellung der Dokumentation mittels Doxygen unterstützt werden, sowie Testcases zur Überprüfung der korrekten Ausführen der Software bei der Installation.
Als Editor benutzte ich vim zusammen mit cscope und dem Plugin Conque-GDB zum graphischen Debuggen des Programms.

Zuletzt möchte ich erwähnen, dass ich noch offen bin für Namensvorschläge und wie immer gilt:
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Nicht noch ein GIT-Client

Posted on by zeRapha Leave a comment

Vor ein paar Jahren hatte ich ein Bash-Skript geschrieben um git-Repositories automatisiert zu aktualisieren, also ein git pull auf dem aktuell ausgecheckten Branch des Repositories.
Das Skript funktioniert mit einer Textdatei in der die Pfade zu den Repositories angegeben sind und aktualisiert diese, sofern keine Konflikte vorhanden sind.
Die Ausgabe der Informationen welche Repositories überprüft werden und welche aktualisiert wurden, werden nicht nur über das Terminal angezeigt, sondern auch in einer Log-Datei gespeichert. Dieses Log kann entweder immer wieder neu erzeugt werden bei jedem Aufruf des Skripts oder als fortlaufende Datei.

Um mich in Python einzuarbeiten hatte ich im Anschluss einen Wrapper für das Bash-Skript implementiert, mit welchem man die Repository-Liste zur Aktualisierung bearbeiten kann (Reposietories hinzuügen oder entfernen) und in einem Shell-Modus läuft. Zusätzlich kann das Python-Program das Bash-Skript aufrufen, die Log-Infos der Repositories anzeigen und ein neues Terminal-Fenster mit dem Pfad eines gewünschten Repository öffnen (zumindest für die gängigsten Unix-Terminal-Programme). Letzte Funktion hat den Zweck einfach zwischen den Repositories wechseln zu können und git per CLI zu bedienen.
Da das Python-Programm im Shell-Modus läuft, habe ich zusätzlich eine Auto-Komplettierung für Repositories und Befehle implementiert.
Das Bash-Skript sowie das dazugehörige Python-Programm sind auf Github veröffentlicht und über die Jahre gab es doch den Einen oder Anderen clone des Projekts. Darüber freue ich mich auch, aber ich habe bisher leider keine Rückmeldung zur Nutzbarkeit erhalten.

Nun ist es so, dass ich persönlich kein großer Fan von Python bin und habe daher beschlossen ein C-Programm zu implementieren, dass die Funktionalitäten des ursprünglichen Bash-Skripts und des Python-Programms beinhaltet.
Das neue Programm kann als Terminal-Befehl, im Shell-Modus und mit einem Terminal-UI (ncurses) ausgeführt werden. Zusätzlich sollen weitere grundlegende Funktionalitäten implementiert werden um einen git-Client zu erhalten.
Der größte Unterschied stellt wohl die Art und Weise wie mit git von den Programmen aus interagiert wird dar. Während beim Bash-Skript und dem Python-Programm die git-Befehle als Systembefehle in einem Subprozess ausgeführt werden, soll das bei der C Implementierung mittels API funktionieren. Dazu verwende ich libgit2.
Über den aktuellen Status und die Implementierungsdetails gehe ich in Folgebeiträgen ein. Veröffentlich wird das Projekt auf Github, wenn ich die ursprüngliche Funktionalität fertig implementiert habe, also die Auto-Aktualisierung von Repositories in einer Liste.
Aktuell trägt das Projekt noch den unkreativen Namen gitmanager, aber ich denke über eine Umbenennung in yagcl (Yet Another Git CLient) oder nagcl (Not Another Git CLient) nach. Für kreative Vorschläge bin ich offen (bitte nicht Git McGitFace).

Links:

OSICs – Open Source Integrated Circuits

Posted on by zeRapha Leave a comment

In der sechsten Folge der Kurzschluss Junkies habe ich mit Basti und Chris über FPGA- und
ASIC-Entwicklungen gesprochen. In dieser Beitragsreihe möchte ich Open Source Software zur IC-Enticklung vorstellen und auf deren Fähigkeiten, bzw. Möglichkeiten eingehen.

Ein Beispiel, dass mit freier Software ein IC erstellt werden kann, ist die Realisierung eines auf einem RISC-V basierenden SoCs. Der verwendete Softcore ist der PicoRV32 in einem QFN-48 Package der mit ADCs, DACs und einer seriellen Schnittstelle (SPI) erweitert und bei efabless gefertigt wurde.
Die Toolchain die dafür hauptsächlich verwendet wurde heißt Qflow und verbindet Tools zur Synthese, Logikminimierung, Placement und Routing von Standardzellen-Logik. Die Firma efabless bietet die Möglichkeit eigene Designs zu realiserun und hostet eine Toolchain die selbst teilweise auf Qflow basiert.

Der Hauptentwickler von Qflow heißt Tim Edwards und dieser hat bei eeweb.com ein Interview gegeben in dem er seine Arbeit und Philosophie zur freien Software für den Chip Entwurf vorstellt und erklärt. Der Aufbau von Qflow ist auf opencircuitdesign.com in Detail beschrieben, dennoch möchte ich nachfolgend einen kurzen Abriss über die wichtigsten Elemente der eingebundenen Software geben.

Qflow nutzt zur Synthese yosys, eine offene Synthessuite für FPGAs und ASICS, die von Clifford Wolf entwickelt wurde. Diese synthetisiert Verilog Designs und bietet – bei vorhandener Bibliothek – nicht nur eine Logikminimierung an, sondern auch ein Mapping auf Standardzellen. Die Logikminimierung erfolgt mittels abc, einem Tool das bei der Universität von Berkley entwickelt wurde und auch eine Verifikation von Logikschaltungen zur Verfügung stellt. Die Stärke von yosys liegt in den implementierten Durchläufen zur Synthese und Verifikation. Diese können je nach Anforderung adaptiert werden um so die Optimierungdurchläufe auf mögliche Besonderheiten anzupassen. Solche Besonderheiten können zum Beispiel der Standardzellenbibliothek des Herstellers geschuldet sein.
Eine weitere Stärke ist die Möglichkeit yosys über Skripte bedienen zu können.

Die Platzierung erfolgt mit graywolf, einem Tool das mittels Simulated Annealing Standardzellen plaziert. graywolf ist ein Fork des mittlerweile kommerziellen Tools Timberwolf, das für eine Lizenz einen Preis von 50k USD ausruft und in Yale entwickelt wurde.

Qrouter schließlich verbindet die Standardzellen mittels dem Lee-Algorithmus und unterstütz bis zu sechs Metalllagen. Damit lassen sich, wie das Beispiel des RISC-V basierenden SoCs zeigt, recht komplexe und große Designs realiseren.
Abgerundet wird die Toolchain mit einem LVS-Checker (netgen) swoie einem Layout-Editor mit der Fähigkeit zum DRC (magic).

Die größten limitierenden Faktoren stellen letztlich die Bauteilbibliothek und die Zieltechnologie dar. Die Bauteilbibliothek insofern, als dass diese von den einzelnen Halbleiterherstellern i.d.R. gekauft werden muss und die Zieltechnologie dahingehend, dass es eine Sache ist, ein Design mit einer 120nm-Struktur oder größer zu realisieren oder 90nm und kleiner. Die Hauptschwierigkeit stellt hier die Abschätzung der Laufzeitverzögerungen dar. Wer sich aber einfach für Chip-Entwicklung, Algorithmen und DIY-Realisierungen mit offenen (beispielhaften) Bibliotheken interessiert, oder gar mit einem Start-Up/kleinem Unternehmen Chips realiseren möchte, bekommt mit diesen Projekten einen wunderbaren Einstieg und nützliche Software an die Hand mit der wirklich etwas realisiert werden kann. Dank Quelloffenheit können diese Programme sogar angepasst und erweitert werden.

Abschließend möchte ich erwähnen, dass diese Projekte nicht nur einen tiefgehenden Einblick in die Herausforderungen für CAE-Tools zur Realisierung von integrierten Schaltungen bietet, sondern auch exzellente Beispiele für gut implementierten und dokumentierten Code sind (überwiegend C und C++).

In weiteren Beiträgen möchte ich die erwähnten Algorithmen genauer vorstellen, sowie weitere freie Software für den Chip-Entwurf sowie eine freie, erweiterbare Suite für Xilinx FPGAs. Auch kleine Tutorials und Anleitungen zur Nutzung der Software sind angedacht.
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Links:

Knöpfchenspiel 1 – Systemübersicht

Posted on by Platinenmacher Leave a comment

Heute beschreibe ich das Knöpfchenspiel. Wie bereits im Podcast erzählt, ist das primäre Ziel das Spiel bis April fertig zu bekommen. Daher gibt es bereits einige fertige Komponenten.

Das originale Knöpfchenspiel steht meistens in Spielhallen und kann dort gegen Geldeinwurf gespielt werden. Dazu müssen die leuchtenden Knöpfe gedrückt werden. Jeder Knopfdruck gibt einen Punkt. Wenn ein nicht leuchtender Knopf gedrückt wird, wird ein Punkt abgezogen. Das sieht dann so aus:

Das von mir geplante System ist ähnlich aufgebaut. Nur dass die Spieler nicht gegenüber, sondern nebeneinander spielen und dass die Punkteanzahl an einem großen Fernseher dargestellt wird und nicht auf einer 7-Segementanzeige. Dazu wird das System in mehrere Submodule aufgeteilt.

 
  • System-Controller (Raspberry-Pi)
  • Bus-Interface (Differenzieller I²C Bus Treiber)
  • Knöpfchen-Controller (STM32F030)
  • Knöpfchen
  • LED-Band-Controller
  • Power Supply

System-Controller

Der Raspberry Pi übernimmt die Steuerung des Spiels und die Anzeige der Punkte am Bildschirm. Dazu wird das HDMI Interface in maximaler Auflösung (1920×1080) betrieben. Weiterhin hängt am Pi noch eine Webcam (USB) mit der die Spieler für die High-score Liste fotografiert werden.
Auf dem Raspberry steckt die DIIC Baugruppe. Das Bus-Interface Board
Bus-Interface

Bus-Interface

Um einen stabilen I2C Bus über alle Baugruppen zu bekommen, habe ich mich für einen Differenziellen Bustreiber entschieden. Dieser ist in der Lage die Eindraht-Signale der I2C Strecke auf zwei differenzielle Signale aufzuteilen. Diese sind wesentlich unempfindlicher gegenüber elektromagnetischer Störung. Das Bus-Interface Board besitzt die nötigen Stecker für den Knöpfchenspiel Bus, ein RJ45 Stecker, der über normale LAN-Kabel miteinander verbunden werden kann.

Knöpfchen

Das Knöpfchen ist ein 60mm durchmessender Plastik Druckknopf (Schließer), der von hinten beleuchtbar ist. Die Beleuchtung wird von einer weißen LED übernommen.

 

Knöpfchen Controller

Die 16 Knöpfchen sind an dem Knöpfchen-Controller angeschlossen. Der Controller ließt den Schaltzustand der Knöpfchen ein und vergleicht ihn mit den Lampen. Wenn die Lampe an war, wird der Punktestand um eins erhöht, wenn die Lampe aus war, wird der Punktestand reduziert, bis er bei 0 angekommen ist.
Auf dem Knöpfchen-Controller Board ist ein DC/DC Wandler, der die 12V Bus-Spannung auf 5V herab setzt. Die 5V werden dann mit einem linear Regler auf 3,3V für den Controller heruntergesetzt. Die Knöpfchen und Lampen in den Knöpfchen können mit 12V, 5V, oder 3,3V versorgt werden.
Der Controller besitzt ein I2C Slave-Interface, dass die Spielinformationen an den Spiel-Controller übertragen kann.

LED-Band-Controller

Um das Spiel von Außen attraktiver zu gestalten, habe ich vor eine LED-Leiste an der Kante anzubringen, ähnlich wie bei der oben gezeigten Variante. Dafür habe ich WS2812 LEDs als Leitungsband vorgesehen. Gesteuert werden die LEDs von einem eigenen Controller. Wahrscheinlich der Arduino Nano, den ich schon für die Bühnenkulisse verwendet habe. Den kann man über die USB -> UART Brücke auf dem Arduino vom Raspberry Pi ansprechen.
Für das System werden zwei AC/DC Netzteile eingesetzt. Ein 5V und ein 12V Netzteil. Das 5V Netzteil ist für die Versorgung des Raspberry Pis und LED-Band vorgesehen. Das 12V Netzteil übernimmt die Versorgung des Bus-Systems, Knöpfchen-Controller Boards und der Knöpfchen. Beide werden über den gleichen Kaltgeräte-Stecker angeschlossen und abgesichert.

Schmartwatch [11]: Neue Hardware

Posted on by Platinenmacher Leave a comment

Die erste Version der Hardware hatte einige kleine Bugs. Darunter war ein Fehler in der Booster Schaltung für VCOM des E-paper Displays, Kondensatoren, die nicht spannungsfest genug waren und kein Piezo Piepser. Alles das ist in der zweiten Version der Hardware vorhanden. Mit der Bestellung habe ich eine ganze Weile gewartet, da ich erst alle Teile der Hardware, die bereits vorhanden ist und funktioniert testen wollte. Das ist jetzt geschehen und die zweite Version kann hergestellt werden.

Die alte Version der Hardware hat einige Pinbelegungen anders als die Neuere. Daher ist die Software bereits dafür ausgelegt, die richtige Header Datei einzubinden, wenn für die eine oder andere Hardware kompiliert wird.

Hier eine Übersicht der aktuellen Funktionen.
Links oben befindet sich der Piezo Buzzer. Um dafür Platz zu machen, ist der Bewegungssensor U4 und der Mikrocontroller U3 weiter nach rechts gewandert. Die RTC, die unabhängig vom Controller läuft, ist ein wenig weiter nach unten gewandert und sitzt jetzt rechts oberhalb der Batteriehalterung. Unterhalb der Batterie befindet sich der Teil der E-paper Ansteuerung. Im Gegensatz zur Version 1 ist hier die Schaltung mit 0603 Bauelementen ausgelegt. Daher können Kondensatoren mit höheren Spannungsfestigkeiten eingesetzt werden. Ein zusätzliches Feature ist die Beleuchtung des Displays. Dafür ist ein weiterer Flat-Flex-Stecker vorgesehen: J4.

Das PCB, das ich bestellt habe wird aus 0,4 mm dickem FR4 hergestellt und kommt damit der Dicker eines Flex-Boards mit Stiffner nahe. Eventuell ist sie auch flexibel genug um für das Handgelenk gebogen zu werden. Der Stecker sollte zwar mit einem 0,3 mm dicken Flex-Board verwendet werden, aber vielleicht passt das 0,4 mm dicke ja trotzdem.

Auch hier ist die Wahl wieder auf FR4 als Boardmaterial gefallen, da die Flex Boards alle viel teurer sind. Wenn mehr als 5-10 PCBs bestellt werden können, weil ich mir sicher bin, dass es das endgültige Design ist, dann ist Flex wieder nicht zu teuer. Bis dahin wird FR4 genügen müssen.

Einer der nächsten Schritte wird es sein, die Hardware und die Software für die Veröffentlichung vorzubereiten. Im Moment schließe ich die BOM ab, sodass eine Liste aller benötigten Bauelemente zur Verfügung steht. Weiterhin kommt dann noch ein neueres 3D Modell zum Einsatz. Auch hier sind einige Design Änderungen eingeflossen, die in der ersten Version noch nicht beachtet wurden. Dazu aber später mehr.

Schmartwatch [10]: Energieverbrauch Ergebnis

Posted on by Platinenmacher Leave a comment

Hier ist das Ergebnis des Batterie Tests. Wie anhand der Oszilloskop-Bilder zu sehn war, ist die Batterie kontinuierlich beansprucht worden. Das hat sie nicht lange mit sich machen lassen und so stand heute, als ich aus dem Urlaub zurück gekommen bind, folgendes Ergebnis fest:

Die Uhr lief genau bis zum 29.09. 02:29 Uhr. Das ist nicht besonders lange. Gerade einmal 6,5 Stunden.

Das Ergebnis zeigt, dass es noch zu viele aktive Stromverbraucher gibt. Der nächste Schritt wird sein, diese zu finden und zu beseitigen.

Schmartwatch [09]: Energieverbrauch

Posted on by Platinenmacher Leave a comment

Ich habe jetzt Urlaub und was bietet sich da besser an, als ein Laufzeit Experiment. Die Uhr ist mit der aktuellen Software ausgestattet, das Softdevice ist initialisiert, aber nicht aktiv. Ich habe eine neue Batterie eingelegt und lasse die Uhr jetzt einfach liegen. Dank des E-Ink Displays kann man genau sehen, wie lange die Uhr lief, bevor kein Update mehr kam. Das Foto zeigt die Uhr kurz nach dem Start beim Updaten der Minute.

Testbedingungen

Test startete am  28.09.2018 19:56
Git Revision 0c692ed

Hardware:

  • FR4 Prototyp mit Display Adapter Platine
  • J-Link Adapter mit Diode
  • CR2032 Lithium Knopfzelle von EDEKA zuhause MHD: 12-2022

Zum Schluss noch einige Messungen während die Uhr läuft:

Zustand der Spule am Schaltpunkt des DCDC-Konverters während des Ruhe Betriebs.
Dieser Spannungsverlauf hat eine Einschaltdauer von 15%.		Zustand der Spule am Schaltpunkt des DCDC-Konverters während einer Aktualisierung.
Spannung an der Batterie während des Ruhe Betriebs.Spannung an der Batterie während einer Display Aktualisierung.

Schmartwatch [08]: BOM Management in KiCad

Posted on by Platinenmacher Leave a comment

Um eine elektronische Baugruppe herstellen zu können benötigt man neben einer Leiterplatte elektronische Komponenten. Diese haben spezifische Werte, um die gewünschte Funktion zu erzielen. Spezifiziert werden die Werte beim Eingeben des Schaltplans. In KiCad geht das mit dem Programm Eeschema. Anhand der Funktion und angegebenen Parametern kann eine Auswahl getroffen werden, welche Bauteile von welchem Hersteller für eine Komponenten im Schaltplan verwendet werden können. Ähnlich wie bei der Herstellung von Leiterplatten können dann verschiedene Gründe, wie Lieferzeit und Preis, die Auswahl beeinflussen. Betrachtet man diese Schaltung, zeigt sich dass hier folgende Komponenten verwendet werden:

 
 
 
 

Zwei Widerstände, eine Spule , zwei Kondensatoren, drei Schottky Dioden und ein Transistor. Im Schaltplan sind alle wichtigen Informationen eingeblendet um die Schaltung ausreichend zu spezifizieren. Der Transistor ist angegeben als Si1308EDL. Dieser wird von der Firma Vishay hergestellt und ist nur im SOT-323 Package zu bekommen. Für die Schottky Dioden ist eine Typenbezeichnung angegeben: MBR0530. Ebenso eine Gehäuseform: SOD-123. Somit kann als Bauteil eine Diode von ON Semi oder MCC eingesetzt werden. Bei den Kondensatoren, Widerständen und Spule ist die Auswahl noch größer. Die Kondensatoren haben als Werte die Kapazität, Gehäusegröße und maximal Spannung angegeben. Mit diesen Werten bieten sich mehrere Hersteller an. Hier sind zum Beispiel Murata, Yageo oder TDK zu nennen. Jeder der Kondensatoren, der die angegebenen Werte erfüllt ist geeignet in dieser Schaltung verwendet zu werden. Die Spule ist ähnlich wie die Kondensatoren mit drei Charakteristiken spezifiziert. Der Induktivität, dem maximalen Strom und der Bauform. Mit diesen Parametern bieten sich Spulen der Hersteller Taiyo Yuden oder TDK an. Beide Spulen sind geeignet.
Bei den Widerständen sind lediglich die Gehäuseform (0603) und der Ohmsche Widerstandswert angegeben. Daher bieten sich eine Vielzahl an Herstellern an, z.B. Stackpole, Bourns, Vishay, Yageo oder Susumu.

Wie zu sehen ist, stehen für viele Komponenten der Schaltung Alternativen zur Verfügung. Diese sind grundsätzlich alle geeignet um eine funktionierende Baugruppe zu bilden. Beim Herstellen kann also die günstigste oder kurzfristig beschaffbare Variante gewählt werden. Das ganze zu verwalten nennt man BOM-Management (Bill of Material). In größeren Unternehmen sind ganze Abteilungen damit beschäftigt, die Verfügbarkeit von Alternativen für die Bestückung der Leiterplatte zu sichern. Im kleinen Rahmen reicht aber eine solche Tabelle völlig aus.

Im aktuellsten KiCad (5.0.0) ist das Management der BOM nicht ganz ausgereift, aber dennoch brauchbar. Die Tabelle wird dynamisch mit den Komponenten im Schaltplan aktualisiert und kann auch die einzelnen Gruppen als ganzes bearbeiten. So sind zum Beispiel alle Kondensatoren  mit 100nF gruppiert. Wenn in der Gruppe ein Feld geädert wird, ändert sich auch jede Komponente in der Gruppe. So kann nach der Schaltplaneingabe schnell eine Zuordnung der einzelnen Komponenten zu Bestellnummern (MPN) hergestellt werden. Das Feld Price habe ich noch zusätzlich eingefügt, um einen groben Überblick über die Kosten zu behalten. Wenn in der Tabelle die Felder fehlen, kann einem beliebigen Bauteil das Feld im Eigenschaften-Dialog hinzugefügt werden. Danach sthet es allen Komponenten zur Verfügung.

Mit diesen Feldern in den Eigenschaften der einzelnen Komponenten kann eine Stückliste erzeugt werden, die viele Informationen für eine Bestellung beinhaltet. Über den BOM Ausgabedialog kann das Plugin bom_csv_grouped_by_value ausgeführt werden. Wenn das in der Auswahl nicht aufgeführt ist, aknn es über Add Plugin hinzugefügt werden. Im Ordner „C:\Program Files\KiCad\bin\scripting\plugins“ befindet sich das Script.

Weiterhin sollte in der Kommandozeile das %O durch ein %O.csv ersetzt werden, wie in der Abbildung zu sehen. Dadurch wird der erzeugten Datei die Endung .csv gegeben anstatt keiner.

Nachdem die BOM generiert wurde, findet ihr die Ausgabe im Projektordner mit den Namen des Projekts und wenn die Kommandozeile angepasst wurde mit Endung .csv. Hier sind die Werte der Tabelle als Text abgespeichert und können in einer Tabellenkalkulation bearbeitet werden. Diese Liste kann auch dem Hersteller der Baugruppe übergeben werden. Eventuell müssen hier noch Komponenten gelöscht werden um mögliche Verwirrungen zu vermeiden.

Um Signale an der Flachbaugruppe gut messen zu können, werden Testpunkte in der Schaltung verwendet. Diese sind zwar Komponenten im Schaltplan, haben aber kein Bauteil, das bestückt werden muss. Daher kann in der Stückliste die Zeile entfernt werden. gleiches gilt für die Widerstände, die als DNP (Do Not Place) markiert sind. Auch einer der Steckverbinder soll nicht verlötet werden, daher kann er aus der Liste gestrichen werden.

Was jetzt übrig bleibt, ist eine vollständige Stückliste mit alternativen Bauteilen, wenn möglich, aus der jeder Hersteller ein Angebot für die Baugruppe erstellen kann.