Schmartwatch [04]: Firmware Blinky

Der Erste Schritt zur Inbetriebnahme einer Leiterplatte ist die Validierung der Stromversorgung.
Die Leiterplatten sind geliefert worden und ich habe eine teilweise bestückt. Ich habe zuerst den 3,3V Boost Regler installiert. Mit einem Oszilloskop habe ich die Spannung am Ausgang des Reglers bewertet. Mit einer Last, die dem Regler 15mA konstant abverlangte, kam ich auf einen Ripple von 20mV auf der Ausgangsspannung. Dieser Ripple änderte sich nicht, egal ob die Ausgangsspannung mit nur 1mA oder mit 100mA belastet wurde. Daher habe ich als nächstes das Funkmodul bestückt. Mit dem bestückten Funkmodul war ich dann in der Lage eine Verbindung mit dem Debugger herzustellen. Als Debugger verwende ich einen  JLink Pro von der Firma Segger. Nordic Semiconducters hat für diese Serie an Debuggern einen hervorragend Support.

Nachdem auch der Debugger mit dem Funkmodul in Betrieb genommen war, habe ich die restlichen Bauteile für die Ansteuerung des Displays aufgelötet. Das Display hat im Controller einige Reglerfunktionen integriert und kann sich eigene Hilfsspannungen erzeugen, dazu braucht es lediglich ein paar Kondesatoren, einen Transistor und einige SPI Befehle. Das Footprint des Transostors im Layout der Leiterplatte ist fehlerhaft, die Pins Gate und Drain sind vertauscht. Ein einfaches drehen des Transistors hat das aber wieder repariert.

Ohne angeschlossenes und konfiguriertes Display ist also die Schaltung nicht funktionsfähig. Trotzdem kann sie mit einem einfachen Toggle Signal an allen betroffenen IO-Pins auf Funktionalität und Kurzschlüsse getestet werden.
Kurzschlüsse auf Pins des Displays zeichnen sich hauptsächlich durch die Verlust der Signalqualität am Display Stecker aus. Wenn also ein Output Pin des Funkmoduls, der ein High Signal liefern soll, versucht gegen ein kurzgeschlossenes Low-Signal zu treiben, wird sich die Spannung ungefähr in der Hälfte des erwarteten Wertes befinden.
Nach Beseitigung der Kurzschlüsse am Displaysteckverbinder kann die Inbetriebnahme des Displays beginnen. Dazu habe ich eine Testsoftware geschrieben, die das Display startet und Werte anzeigen soll. Mit Hilfe der verfügbaren Ressourcen auf dem Funkmodul wird ein Bild erstellt, dass dem Display Pixel für Pixel übergeben wird. Danach wird gefragt, ob das Display bereit ist und wenn das der Fall ist, wird das nächste Bild übertragen.

Aktuell startet das Display die Hilfsspannungen nicht von alleine und es zeigt nichts an. Dieser Zustand benötigt viel (relativ zum normalen Betrieb) Strom, sodass das Display spürbar wärmer wird.

Wie genau sich die Ansteuerung in dieser Schaltung zu der Ansteuerung auf dem Eval-Board unterscheidet, wird sich zeigen, wenn das Evalboard den langen weg aus China zu mir gefunden hat.
Bis dahin stehen noch weitere Peripherien zur Verfügung die gerne in Betrieb genommen werden möchten. Darunter fallen:

• I2C Bus für Echtzeituhr
• I2C Bus für Bewegungssensor
• Applikationsstruktur der Firmware (nachladbare Code Teile)
• BLE Softdevice 

Im Moment können wir lediglich davon ausgehen, dass alle Pins des Funkmoduls korrekt gelötet und bisher keine Kurzschlüsse auf der Leiterplatte sind. 

Schmartwatch [03]: Firmware - Mockup

Die Entwicklung von Firmware für eine Hardware, die noch nicht im finalen Design vorliegt, oder überhaupt in Realität verfügbar ist, ist schwierig. Ebenso verhält es sich mit der Schmartwatch Firmware. Die Hardware ist in der Prototypenphase bestellt. Das heißt aber nicht, dass mit der Firmwareentwicklung gewartet werden muss. Ich habe vor so wenig Bibliotheken wie möglich einzubinden und viele Funktionen selbst zu schreiben. Das soll mehr zum Üben und Lernen dienen als zeiteffizient zu entwickeln.

Um die Funktionen testen zu können, werden sie in verschiedenen Abstraktionsebenen entwickelt.
Die grundlegende Ebene ist die direkte Hardware-Ebene; die CPU. Dort werden die Register der einzelnen Peripherien angesprochen. Das werde ich über die bereits verfügbare Hersteller SDK Schnittstelle machen. Auch den Bluetooth Stack des Herstellers werde ich übernehmen. Denn die Programmierung der Hardware Funktionen sind von Hersteller zu Hersteller, machmal auch von Chip zu Chip unterschiedlich. Einen Bluetooth-LE Stack selbst zu schreiben finde ich auch keine sinnvolle Beschäftigung. Vor allem, wenn das Ziel ist eine Smartwatch zu programmieren.

Eine der selbst geschriebenen Funktionen wird jedoch die Erstellung von Bildschirm Inhalten sein. Die Uhr besitzt ein 3-Farben e-ink Display. Rot, Schwarz und Weiß. Damit bieten sich verschiedene Möglichkeiten an, um Grafiken anzuzeigen. Ich habe mich für folgende Zeichenfeatures entschieden:

• Einzelne Pixel
• Linien
• Rechtecke
• Rechteckige Flächen
• Rechtecke mit runden Ecken
• Rechteckige Flächen mit runden Ecken
• Kreisringe
• Kreisförmige Flächen

Gezeichnet werden kann in den drei Fraben und transparent. Transparent bedeutet, dass die an dieser Stelle vorhandene Farbe beibehalten werden soll. Um noch weitere Elemente auf das Display zu zeichnen, werden diese Funktionen zur Verfügung stehen:

• Monochrome Bilder
• Texte mit nichtproportionalen Schriftarten (Monospace)

Diese Grundfunktionen zu grafischen Darstellung auf dem Display kann ich testen, ohne eine echte Hardware auf dem Tisch zu haben. Dazu schrieb ich eine Windows Software, die das Display der Uhr in 2-facher Vergrößerung anzeigt und alle die Funktionen meiner Grafik Bibliothek verwendet.

Um ein Bild für das Display zu zeichnen, befindet sich im RAM der Smartwatch ein Framebuffer, das ist ein Speicherbereich, der Informationen zu allen Pixeln des Displays beinhaltet. Mit dem 'render' Befehl, werden alle Daten aus dem RAM in das Display kopiert und angezeigt. So können Bildteile verändert werden, ohne dass von Außen eine Änderung auf dem Display sichtbar ist. Erst wenn der Bildschirm fertig erzeugt ist, wird er an das Display übertragen und in einem Rutsch dargestellt.

Die Übertragung und das Rendern der Bilddaten ist eine Hardware abhängige Funktionalität. Das Schreiben auf den Framebuffer hingegen kann unabhängig der Hardware passieren. Das machen wir uns hier zu nutze. Die Windowsanwendung nutzt die Schmartwatch Funktionen der eigenen Grafik Bibliothek um auf ein Framebuffer zu schreiben. Eine Renderer Funktion der Windows Anwendung kopiert dann den Framebuffer in ein Windows geeignetes Speicherformat und gibt es um den Faktor 2 vergrößert am Monitor aus.

Hier sehen wir einen Screenshot der Anwendung. Die schwarzen und roten Rechtecke gehören zur Displayfläche dazu. Es werden zwei Texte gezeichnet, die einer Uhrzeit entsprechen, zwei unterschiedlich farbige Linien und ein Kreis, sowie eine große schwarze Fläche. Die Grafik rechts inclusive Text ist ein monochromes Bild, das ebenfalls als schwarz / transparent gerendert wird.

Transparent ist die virtuelle vierte Farbe des Displays. Sie bedeutet, dass für dieses Pixel der bereits im Framebuffer liegende Wert beibehalten werden soll. Somit können Bilder übereinander dargestellt werden. Das wird in der Phase der Watchface Programmierung noch häufiger genutzt werden. Die Schriftarten, die standartmäßig in dem Betriebsystem der Uhr verwendet werden, sind natürlich von der Größe her begrenzt. So bietet es ich an, für die Anzeige der Uhrzeit Bitmaps zu verwenden. Auch grafische Effekte können mit mehreren Layern erzeugt werden.

Der Windows Simulator hat den Vorteil, dass im PC nahezu unbegrenzte Rechenkapaität zur Verfügung steht. Im vergleich zu einer Embedded CPU in unserer Smartwatch, versteht sich. Daher kann der Bildschirminhalt so schnell wie möglich immer wieder komplett geschrieben werden. Für eine spätere Implementierung mit e-Paper ist es wichtig die Aktualisierungsrate der Frames gering zu halten. Wenn möglich soll nur ein Teil des Displays aktualisiert werden. Wie genau das funktioniert und wie performant sich das lösen lässt, wird sich zeigen, wenn das Display des ersten Prototyps angesteuert wird.

Die Lieferung mit den FR4 Prototypen ist heute eingegeangen. Jetzt kann die Bestückung beginnen ind die Inbetriebnahme der Hardware, sowie die ersten Funktionen der Firmware.

Schmartwatch [02]: Prototyp Layout

Mit den Anforderungen aus Teil 1 habe ich mich an eine Prototypen Layout gesetzt. Prototyp deshalb, weil es auf normalem FR4 gefertigt ist. Um die Schaltung zu validieren, die später auf Flex material gefertigt werden soll ist das völlig ausreichend. FR4 ist ein Material, dass wesentlich hitzestabieler ist als das Polyamid des Flex PCB. Das heißt, auf dem normalen Board kann man besser löten als auf dem Plastik des Flex Boards. Weiterhin ist ein FR4 Board weitaus günstiger.

Das Design soll von der Form her so sein, wie in Artikel 1 gezeigt. Das Display ist dort bereits eingezeichnet. Wenn später die Leiterplatte aus flexiblem material gefertigt wird, kann sie einfach gebogen werden.

Die Schaltung darf nur auf der Vorderseite des Boards platziert werden. Das heißt die Batterie und alle anderen Bauelemente kämpfen um den Platz unterhalb des Displays. Es sind zwar einige Bauelemente nötig, doch sie passen alle mehr oder weniger unter das Display.

Das Layout der Leitungen darf maximal zwei Lagen nicht überschreiten eine 4 Lagen Flex Leiterplatte ist wesentlich teurer als zwei Lagen. Weiterhin sollen 3,3V und GND als Fläche ausgelegt werden, wo immer das möglich ist.
In Lila ist der Stiffener eingezeichnet, eine Fläche aus stabilem Kunststoff, die auf das Polyamid der Flex-Leiterplatte aufgeklebt wird um an dieser Stelle eine stabile Ebene zu bilden. Als
Schnalle für das Armband habe ich mit eine Steckverbinder für Flex Literplatten ausgesucht, der
505147-0490 und 505148-0408 sollen den Schließmechanismus der Uhr bilden.

Das fertige Layout der Armbanduhr sieht für den Prototypen dann wie folgt aus. Einige Verbindungen haben sich für die Flex Variante allerdings geändert, da ich de Piezo Buzzer erst nachträglich in die Anforderungen aufgenommen habe.

Vorderseite (rot) und Rückseite (grün) des Prototypen Designs

Hier kann man im Design gut erkennen, dass die Richtung der Leitungen auf der Vorder- und Rückseite waagerecht, bzw. senkrecht ausgelegt sind. Dadurch verhindert man, dass sich die Netze zu sehr verheddern und man später überhaupt nicht mehr entflechten kann.
Die GND Fläche auf der Rückseite wird von den Leitungen zum Display durchschnitten. Um ein schwanken des Bezugspotentials zu verhindern, werden die beiden Teilflächen auf der Oberseite gebrückt. Gleiches ist bei dem Signal BATT+ zu sehen, das schneidet die 3V3 Fläche in zwei Teile. Auch hier wird über Brücken ein Potentialausgleich geschaffen. Die große violette Fläche ist eine Klebefläche für die Batteriehaltung. Beim Einlegen der Batterie werden ziemlich große Kräfte angewendet, dadurch können die Lötverbindungen kaputt gehen. Um das zu verhindern, werden die Kräfte hier über die Klebeverbindung auf die Leiterplatte gebracht.

Mit den FR4 Prototypen sind die Inbetriebnahme des DC/DC Boost Konverters, der MCU, IMU und des Displays möglich. Ebenso können Batterielaufzeit und allgemeine Performance des BLE Signals validiert werden.

Der nächste Teil wird sich dann mit den Grundfunktionen der Firmware beschäftigen.

Schmartwatch [01]: Smartwatch selbst gebaut

Das ist der erste Artikel in der Schmartwatch (sprich:  [ˈʃmaːɐ̯tˌvɔʧ]) Serie. In dieser Serie werden verschiedene Themen der Erstellung eines elektronischen Projekts angesprochen. Der erste Artikel beschäftigt sich mit der Idee und dem grundsätlichen Konzept

Ich besitze seit vielen Jahren die Pebble Smartwatch. Zuerst die Kickstarter Pebble, dann die Time und zum Schluss die Round. Die hat leider eine Fahrt in der Waschmaschine nicht überlebt.
Die Firma Pebble wurde von Fitbit gekauft und die Produktion der Uhren, sowie der Software-Support bis Juni 2018 eingestellt.

Das Beste Feature der Pebble ist, dass die Uhrzeit auf dem Display bei jedem Licht, zu jeder Zeit lesbar ist. Bei starkem Sonnenlicht kann das Display gelesen werden und bei Dunkelheit hilft die Beleuchtung. Bei vielen anderen Uhren, muss man das Display erst einschalten, um die Uhrzeit abzulesen. Das kann man zum Beispiel mit einem Schnick aus dem Handgelenk tun, oder über einen Touch am Display. Beides finde ich keine Option, um mal kurz auf die Uhr zu schauen. Weiterhin ist es für die Batterielaufzeit tödlich, wenn dauernd das Display an geht. Das passiert zum Beispiel, wenn der Untergrund beim Radfahren etwas holprig ist.

Meine Lösung: Eine Smartwatch mit langer Batterielaufzeit, ePaper-Display, Piepser, und Bluetooth-LE. Und ein besonders technisches Design. Dazu wird die Uhr aus einer Flex-Leiterplatte hergestellt, die gleichzeitig als Armband dienen soll. Wie und ob das funktioniert, wird sich herausstellen.

Hier sind die Features, für die ich mich entschieden habe:

• nRF52832 im ISP1507-AX Modul
• TPS610994 synchroner Boost-Converter
• M41T62 RTC mit integriertem Kristall
• LSM303AGR eKompass (Magnetfeld/Beschleunigung)
• SMT-0940-T-3V-R Piezo Buzzer
• GDEW0154Z17 ePaper Display

Die MCU ist ein Cortex-M4 mit vielen Peripherien auf dem Chip. Dazu auch ein BLE-Radio und NFC. Für die Uhr werden folgende Peripherien benötigt: BLE, I2C, SPI, NFC und einige GPIO Pins. Der Cortex-M4 mit Fließkomma Unterstützung läuft mit 64MHz. Dadurch kann er schnell auf Ereignisse reagieren und dann wieder in den Sleep-Modus wechseln. Je länger der Sleep-Modus ist, desto erheblicher kann Batteriekapazität gespart werden. Das RAM ist 64kb groß und bietet ausreichend Platz für die Display Daten, sowie BLE und Applikationen. Als Flash sind 512kb vorhanden, was ausreichend Platz für die Firmware, sowie Applikationen und Grafiken ist. Die MCU wird das "Gehirn" der Uhr.

Betrieben werden soll die Uhr mit einer CR2032 Batterie. Die liefert eine Spannung von 3V ... 1,8V. Um auf die Betriebsspannung von 3,3V zu kommen, muss ein Baustein her, der mit Hilfe einer Induktivität die Spannung hochsetzt. Dazu habe ich den Energiesparenden TPS61099 von Texas Instrument gewählt. Dieser Boost-Converter hat einen sehr kleinen Energiebedarf. Dadurch verbraucht der Regler kaum Energie für sich selbst und kann der nachfolgenden Schaltung die Energie zur Verfügung stellen. Eingeschaltet werden soll der Booster, wenn das Uhrband geschlossen wird. Das bedeutet, dass die Uhr keine Zeit anzeigt, wenn sie geöffnet ist. Ob das eine sinnvolle Funktion ist, wird sich im Alltag herausstellen.

Die M41T62 Echtzeituhr besitzt einen 32kHz Kristall und bringt alles mit, um die Uhrzeit auf +-5 Sekunden pro Monat genau zu halten. Angeschlossen wir die RTC über I2C und kann da bis zu 400kHz leisten. Das hilft, die Dauer der Kommunikation zwischen MCU und RTC kurz zu halten, denn auch hier ist die Zeit, die die CPU nicht schlafen kann und mehr Strom von der Batterie braucht unerwünscht.

Um die Schlafdauer zu maximieren, kann in der RTC ein Alarm programmiert werden, der die CPU dann aufweckt, wenn etwas abzuarbeiten ist. Somit muss die CPU nicht immer aufwachen und selbst nachschauen, ob etwas zu berechnen ist. Diese Funktion muss allerdings in der Software vorgesehen werden.

Um zu erkennen, ob die Uhr bewegt wird, wird ein elektronischer Kompass LSM303AGR verbaut. Dieser bietet Messwerte zur Beschleunigung und Magnetfelder in alle 3 Achsen. Dadurch können zum Beispiel ein Schrittzähler oder ein 'draufschau' Modus implementiert werden. Auch kann die Uhr erkennen, wie der Arm gehalten wird, dadurch können verschiedene Applikationen implementiert werden. Ein Beispiel ist eine Maussteuerung für den PC, oder ein umschalten des Dialogfelds, wenn der Arm auf 'wegschauen' gedreht wird.

Wie jede gute Uhr, soll auch meine Smartwatch piepen können. Der gewählte Piezo Buzzer ist mit 9 x 9mm sehr klein und passt unter das Display. Die Eigenfrequenz von 4kHz ist ein heller Pfeifton, aber er wird nur kurz zum Piepen verwendet. DerTon ist daher nicht so schmerzhaft, wie ein durchgehender Ton mit dieser Frequenz.

Zu guter Letzt das Display, mit dem eigentlich alles angefangen hat. Ich habe auf der Webseite AliExpress ein Display gefunden, dass die ideale Abmaße für eine Uhr hat und mich dann dazu entschlossen das Projekt Schmartwatch zu starten. Es hat eine Auflösung von 152x152 Pixel bei einer Größe von 1,54Zoll (39,11mm). Das ergibt eine Auflösung von ca. 5,5 Pixel pro mm. Ebenso hat das e-Paper zwei mögliche Farben, rot und schwarz, neben dem weißen Hintergrund.

Auf dem Display befindet sich ein zweiter Controller, der die Ansteuerung des Displays übernimmt. Dieser Controller ist auf dem Glas des Displays aufgeklebt und dann dort mit sehr feinen Golddrähten verbunden. Verbunden ist der Controller des Displays über den SPI Bus der MCU.

Der nächste wird sich mit der Erstellung der Prototypen Leiterplatte beschäftigen. Weitere Artikel werden dann die Software, Flex-Leiterplatte und Bestückung, sowie BOM-Management beinhalten.

Regenbogen LED Tower

Im Letzten Urlaub habe ich meinen LED Turm mit einem AVR ATMega32U2 gebaut. Mit dem Ergebnis bin ich allerdings nicht ganz zufrieden gewesen. Mechanisch war alles wie ich es wollte, allerdings hat der ATMega32U2 nicht so funktioniert, wie ich mir das gewünscht habe. Außerdem war einer der Footprints falsch und der USB Stecker ist nach dem zweiten mal Stecken abgerissen.

Regenbogen Modus

Ebenso habe ich lange auf die Plexiglas Platten warten müssen. In den Bildern sind nur die Untere und die Obere verbaut.

Ich habe wieder einmal Urlaub und habe mir das Projekt nochmal vorgenommen. Versuch 2 ist fertig und bestellt. Diesmal habe ich einen ESP8266 als Controller verwendet. Jetzt hat Die LED Regenbogen Lampe WLAN und kann über MQTT gesteuert werden. Wenn alles glatt geht. Die Hardware habe ich jetzt mal wieder bei PCBWay bestellt. Fertig bestückt mit allem außer ESP8266 Modul und RGB LEDs. Die müssen nachträglich noch eingelötet werden.

Wenn die Leiterplatte geliefert wird, alles funktioniert und die Daten nochmal aufgehübscht sind, werde ich sie online stellen, für jeden, der interessiert ist das nachzubauen.

Nokia 3210 Retro Fit Board Teil 9

Ich habe leider immer noch Probleme mit der Power Versorgung. Der LiPo Chip, der die Ladespannung für den Akku aus die 5V USB zur Verfügung stellt, funktioniert einwandfrei. Der dahintergelegene Teil, der zwei mal 3,3V aus den 4,2 V der Batterie machen soll, hat teilweise Probleme die Spannung stabil zu halten, was dazu führt dass der Microconroller abstürzt.

Die Lösung wird sein, den kompletten Spannungsregler zu ersetzen. Dazu werde ich eine kleine Schaltung aufbauen, die das mit möglichst wenig Komponenten schafft. Dann hoffe ich, dass ich eine stabile Verbindung zum Controller bekomme um die anderen Komponenten in Betrieb zu nehmen.

Für den 3,3V Regler werde ich auf ein integriertes Schaltregler Modul zurück greifen. Das kann dann hoffentlich die Spannung zuverlässig zur Verfügung stellen.

Ein Redesign des PCB werde ich wahrscheinlich nicht durchführen, dafür ist das 6-Lagen Board zu teuer.

Nokia 3210 Retro Fit Board Teil 8

Ich bin mitten in der Inbetriebnahme des Retro Fit Boards für das Nokia 3210. Dabei sind mir einige Probleme aufgefallen.

Das Board hat einen Fehler im Kupfer der Rückseite. Glücklicherweise ist das Kupfer eine große Struktur und kann relativ einfach aufgekratzt werden um den Fehler zu entfernen.

Die Kupferfläche zum Anbinden der Speicherdrossel der 3V3 Versorgung ist mit der GND Plane kollidiert. Beide Planes besitzen die Priorität 0 und werden daher übereinander liegend generiert. Das ganze ist sehr ärgerlich, wird aber im DRC gezeigt... Den hätte ich besser mal komplett durchgeschaut.

Jetzt bleibt nur die manuelle Nachbearbeitung der Leiterplatte. Wenn die beiden Kupferflächen aufgetrennt sind, funktioniert auch der Buck Regler für das 3V3 Netz. Allerdings nur auf instabilen 2,6V.  Die Instabilität der Versorgungsspannung führt dazu, dass die CPU nicht zuverlässig läuft. Die Kommunikation mit JTAG funktioniert nur sporadisch und es kommt oft zu Abbrüchen der Verbindung. Hier helfen 10µF am Ausgang der Spule L202, aber in manchen Situationen bricht auch so die Spannung zusammen.

Der Boostconverter, der Die Batteriespannung auf 4V hochsetzen soll, passt nicht auf das Footprint, das vorgesehen ist. Hier habe ich vorerst eine Brücke zwischen Dem Eingangs Kondensator und der Spule L202 gelötet. Ich habe ein "Texas_S-PVSON-N8_NoThermalVias" aus der KiCad Bibliothek verwendet. Der Chip der da drauf soll ist allerdings ein WSON Chip mit 2x2mm Kantenlänge der PVSON ist 3x3mm. Da hilft nur manuelles Nacharbeiten.

Für den 3V3 Buck-Konverter habe ich einige Experimente mit dem Layout gemacht. Die stabilste Spannung habe ich bei zwei Spulen je 4,7µH und verteilter Ausgangkapazität > 22µF erhalten.

Zwei Spulen und verteilte Ausgangskapazität

Diese Schaltung werde ich nun auf dem komplett bestückten Board ausprobieren und dann sehen wir weiter.

NRF3210 soldering part 3

Nokia 3210 Retro Fit Board Teil 7

Die Prototypen Boards sind da. 10 Leiterplatten des 6-lagigen Designs sind letze Woche angekommen und ich habe mit der Bestückung einer Leiterplatte begonnen. Wie in den Videos 1 und 2 gezeigt, ist das manuelle Löten ein zeitaufwändiges Unterfangen.


Die über 150 Komponenten müssen zuerst einmal sortiert und bereitgelegt werden. Dann kann die eigentliche Bestückarbeit beginnen. Für dieses Projekt habe ich mich entschieden alles per Hand zu löten, also keine Schablone mit Lötpaste zu verwenden. Das hätte den Bestückungsprozess zwar beschleunigt, aber macht es für die Inbetriebnahme schwerer. Die kann nämlich jetzt Stück für Stück erfolgen, da nicht alle Komponenten bestückt sind. Für einen zweiten Produktionslauf, würde ich die Lötpasten-Schablone bevorzugen.

Mit etwas Übung und einem professionellen Lötkolben* kann man 0402 Bauteile problemlos löten. Für die ICs habe ich Lötpaste, Flussmittel* und ein Heißluftfön*.

Beim Zusammensetzen sind mir ein paar kleine Fehler aufgefallen. Einige Löcher, die für Befestigungsschrauben oder Kuststoffbolzen im Gehäuse vorgesehen sind, passen nicht genau. Hier muss das Gehäuse angepasst, oder das Loch aufgefeilt werden. Es ist aber nichts dramatisches.

Ebenso passt die Metall-Rückseite nicht mehr drauf, wenn der JTAG Stecker und die Kopfhörerbuchse bestückt sind. Auch hier muss das Gehäuse angepasst werden.

Die Nächten Tage wird es mit der Software weiter gehen.

* Links gehen auf Amazon.de

NRF3210 soldering part 2

NRF3210 soldering part 1

Nokia 3210 Retro Fit Board Teil 5

Es ging weiter mit dem 3210 Board. Das Layout ist in der ersten Version fertig! Genauere Infos dazu gibt's auf dem Hackaday Post zum heutigen Fortschritt.

Hackaday Post

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.

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 3

Android im Simulator

Ok, zugegeben. Das ganze Projekt ist ziemlich lächerlich, aber trotzdem ein interessanter Ansatz. Nicht umsonst gibt es für Android eine Hardware Mindestvoraussetzung, die unter Anderem auch die Displaygröße vorgibt. Das sind für gewöhnliche Android Hardwaren mindestens 426 x 320 pixel. Anders sieht es aber bei Android Wear aus, der Version für smart watches. Ich werde also weiter in Richtung Android Wear schauen, dort ist der Android App Starter besser aufgebaut und mit den Eingabe-Buttons des Nokias kann man sicherlich alle wichtigen Funktionen abbilden. Es sind immerhin mehr als an einer Armbanduhr.

Zum Schluss noch ein kleines Video, dass euch die Hardware ein wenig näher bringen soll.

Ormerod Erweitungungsboard für Diamond Hotend

Im Sommer habe ich meinen Ormerod für das Diamond-Hotend umgerüstet. Dazu habe ich an den Extension-Stecker drei Pololu-kompatible Schrittmotortreiber angelötet. Damit ihr das nachzubauen könnt, gibt es jetzt das Adapterboard mit Aufnahmestellen für vier Pololu Module.

3D Rendering der Baugruppe in KiCad

Das Board wird einfach nur an den Erweiterungssteckplatz gesteckt. Die Konfigurationsdatei auf der SD-Karte kann angepasst werden um die neuen Schrittmotoren zu unterstützen.

Fertig bestücktes Duex X Board mit vier Pololu Stepper Treibern

Die Änderungen in der Konfigurationsdatei müssen auf der SD-Karte des Duet Boards durchgeführt werden. Jede Farbe, die mit dem Diamond Hotend gedruckt werden soll erhält eine eigenes Werkzeug. Dazu müsst ihr die Befehle G10 und M563 verwenden.
Mit M563 wird das "Werkzeug" angelegt. Werkzeug deshalb in Anführungszeichen, weil ein Werkzeug eine bestimmt Farbe im Hotend ist. M563 legt die Parameter fest, mit denen die Farbe erzeugt wird.

M563 P0 D0 H1

Diese Zeile erzeugt das erste Werkzeug T0 und teilt mit, welche Motoren und welche Heizer zum Werkzeug T0 gehören. D0 ist der Extrudermotor 0 und H1 ist der Heizer Nummer 1. Heizer Nummer 0 ist das Druckbett. Motor 0 ist der erste Extruder auf dem Duet Board. Um Motoren des Extension Board zu verwenden müsst ihr die Nummer an der jeweiligen Pinleiste nehmen. Das gilt jedoch nur für ein Duet Board der Version 0.6! Mit der neuen 0.8.5 Version wurde auch ein weiterer Motortrieber auf das Basisboard gebracht. Somit muss die Nummer um eins erhöht werden.

Als nächstes müssen wir einstellen, mit welcher Arbeitstemperatur (220°C) und welcher Standby-Temperatur (120°C) das Werkzeug arbeitet:

G10 P0 S220 R120

Auch hier muss die Werkzeugnummer 0 angegeben werden.

Duex Board mit zwei zusätzlichen Schrittmotoren angeschlossen

Mit den beiden Zeilen die wir oben sehen können wir jetzt eine ganze Liste an neuen Werkzeugen definieren. Der Drucker ist jetzt in der Lage 5 (oder 6) Motoren zu steuern. Für das Diamond Hotend benötigen wir nur 3. Wenn alle drei Motoren an das Extension Board E1, E2 und E3 angeschlossen sind, steht in der config.g also:

G10 P0 S220 R120
G10 P1 S220 R120
G10 P2 S220 R120
M563 P0 D1 H1
M563 P1 D2 H1
M563 P2 D3 H1

Damit können wir schon drei Farbige Drucke erzeugen. Das Schöne kommt allerdings, wenn wir die Eigenschaften eines Werkzeugs so definieren, dass mehr als nur ein Motor verwendet wird. 
Zu diesem Zweck gibt es in der Firmware für das Duet Board den Befehl M567. Dieser legt ein Mischverhältnis für ein bestimmtes Werkzeug fest.

M567 P0 E0:0.1:0.2:0.7

Dieser Befehl legt fest, dass das Werkzeug T0 ab sofort die zu extrudierende Länge gleichzeitig auf folgenden Motoren ausgibt:

• Motor 0 : 0%
• Motor 1: 10%
• Motor 2: 20%
• Motor 3: 70%

Wie wir oben sehen sind an Motoren 1 bis 3 die Motoren für das Diamond Hotend angeschlossen. Somit erhalten wir eine heterogen gemischte Masse am Ausgang der Düse. Mit transparenten Filamenten sollte das allerdings brauchbare Ergebnisse liefern. Ob das funktioniert wird sich in der Zukunft zeigen. Im Moment warte ich noch auf Teile um drei funktionierende Extruder zusammen zu bauen.

In der Zwischenzeit kann man die Extensionboards auch nachbauen, oder käuflich erwerben. Die Daten sowie eine Anleitung werden in den nächsten Tagen online gestellt.