Posts mit dem Label Elektronik werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Elektronik werden angezeigt. Alle Posts anzeigen

Mittwoch, 3. Januar 2018

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.


Dienstag, 5. Dezember 2017

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.

Freitag, 30. Juni 2017

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.


Donnerstag, 20. April 2017

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
  • 160x128 OLED Display
  • Audio Codec LM4930
  • Stereo Mikrofon
  • Haptic Feedback Engine
  • A7 GSM/GPRS Mobile Radio Module
  • ESP8266 WiFi Module
  • µSD-Card Interface

Donnerstag, 7. Juli 2016

Some pads are not soldered after wave soldering?


As you can see in the picture some of the test points are not flowed with solder after the board went through wave soldering. The actual points are not the same on every board. I think this is very strange. Did anyone can explain this to me?

Dienstag, 29. September 2015

ESP8266 - 2: Temperatur mit dem ESP8266 und DHT11

Das Hausautomationsteam in meiner Wohnung hat einen neuen Teamkollegen bekommen. Ein Tempertatur und Luftfeuchte Sensor. Der Sensor basiert auf einer kleinen Schaltung mit dem DHT11 Sensormodul und einem ESP-01 Board. Daran angeschlossen befinden sich zwei AA Akkus.
ESP-01 Modul mit DHT11 Sensor und 2 AA-Akkus
Die Software im ESP2866 wurde diesesmal nicht mit LUA und NodeMCU, sondern mit dem von ESP verfügbaren SDK erstellt. Ich habe dafür die Bibliothek für den DHT Sensor und den MQTT Client verwendet. Diese beiden Bibliotheken sind frei verfügbar und könne hier heruntergeladen werden.

Das System basiert immernoch auf einem MQTT Broker als zentraler Kommunikationshub. Die Sensoren besitzen alle eine eindutige Chip Indentifikationsnummer. Diese, kombiniert mit dem Systemnamen, bilden die Topics, auf denen die Sensoren Daten für das System bereit stellen. Eine Konfiguration des Sensors bei Inbetriebnahme ist auch in Arbeit. Dazu lauscht der Hauptknoten (Webserver, MQTT broker, Festplatte, usw.) auf WLAN Accesspoints die mit dem Namen ESP beginnen. Diese werden in einer bestimmten Liste angezeigt und können vom Hauptknoten angesprochen werden. Dabei verbindet sich der Knoten mit dem Sensor und überträgt die Daten, die für das eigentliche Netzwerk verwendet werden. Diese Kommunikation muss verschlüsselt stattfinden, daher wird auf die AES-Bibliothek des ESP2866 zurück gegriffen. Mit den Daten kann der Sensor sich dann am lokalen WLAN anmelden und seine Daten dem MQTT Broker zur Verfügung stellen.

Code für den Sensor gibt es hier. Eingestellt wird das ganze über die user_config.h
Der Code wacht auf, verbindet sich mit dem MQTT Broker (Herbert) und sendet seine Messwerte. Danach begibt er sich wieder in den Tiefschlaf. Es sind sicherlich noch Optimierungen möglich, so ist es mit einem unmodifizierten ESP-01 Modul nicht möglich aus dem Tiefschlaf wieder aufzuwachen.
Werte in Openhab auf Herbert

Freitag, 19. Juni 2015

Ein Blick auf: BLE - Bluetooth Low Energy

BLE, Bluetooth Low Energy, oder Bluetooth Smart ist ein und das selbe und in aller Munde. Jedes modernere Smartphone hat zumindest Bluetooth 4.0 implementiert und könnte somit theoretisch mit einem BLE Gerät kommunizieren. Als Entwickler befinde ich mich gerade in der Situation, dass eine in die Tage gekommene Funkstrecke mit einem moderneren, energiesparenden Verfahren ersetzt wird. Also warum nicht mit BLE?

Das Protokoll, dass von der Bluetooth Special Interest Group als Bluetooth 4.0 definiert und später mit 4.1 aktualisiert wurde ist modular aufgebaut. Ein Hersteller eines BLE Peripherie Gerätes kann das Gerät so aufbauen, dass es für den Host (Mobiltelefon oder PC/Laptop) selbsterklärend ist, welche Daten es zur Verfügung stellt. Dazu werden im Protokoll Stack verschiedene Client/Server Strukturen angeboten. Somit ist es möglich ohne spezielle Software auf der Host-Seite ein BLE Peripherie Gerät zu verwenden. Dabei hat man sich auf eineige Profile geeinigt, die von der Bluetoth SIG veröffentlicht und betreut werden.

Da mein aktuelles Projekt nicht in sehr hoher Stückzahl produziert werden wird (< 10000 / a) lohnt es sich nicht die RF-Hardware selbst zu implementieren und zu zertifizieren. Für diesen Zweck eignet sich ein Modul, dass bereits alle Zertifizierungen im RF-Bereich mitbringt. Die Auswahl an marktreifen Modulen von diversen Anbietern ist groß und viele weitere sind angekündigt. Daher habe ich mich auf eine kleine Auswahl beschränkt.

HerstellerChipsatzProzessorCompilerDebugger
RFduinonRF51822Cortex-M0Arduino IDE/ Keil µVisionSegger J-Link
Laird BL600nRF51822Cortex-M0SmartBASICSmartBASIC / Segger J-Link
LSR SaBLE-xCC2640Cortex-M3Code Composer Studio / IAR WorkbenchSegger J-Link / TI XDS100v3
Panasonic PAN1740DA14580Cortex-M0Keil µVisionSegger J-Link
Cypress EZ-BLE PRoC ModulePRoC BLECortey-M0PSoC CreatorPSoC MiniProg3

Jedes dieser Module habe ich auf meinem Tisch liegen, oder mir näher anschauen können. Jedes Modul hat seine Vor- und Nachteile und spezielle Anwendungsgebiete.

Beginnen wir mit dem RFduino. Wie man an dem Namen schon erahnen kann, ist das Modul im Arduino-Universum angesiedelt. Es kommt mit einem Plugin für die Arduino-IDE und ermöglicht mit einer Bibliothek des einfachen Einstieg in die Entwicklung von BLE-Geräten. Die Einfachheit der Umgebung ist gleichzeitig auch das große Manko dieses Moduls. Wenn die Arduino IDE als Entwicklungunsumgebung verwendet wird, ist man auf die in der Bibliothek vorgegebene Funktionalität beschränkt. Vom ordentlichen Debuggen ganz zu schweigen. Mehr als ein printf() kann man dem Chip dann nicht abverlangen. Wenn jedoch der Arduino Bootloader mit einem J-Link überschrieben wird, kann man den Chip auf dem Board in vollem Umfang programmieren. Dann nicht mehr in der Arduino IDE sondern zum Beispiel in µVision und dem SDK von Nordic. Dass der RFduino allerdings in einigen Jahren noch lieferbar ist, ist zweifelhaft.

Das BL600 von Laird kommt mit einem etwas ungewöhnlichen Aufzug daher. Es wird nicht wie üblich cross-compiliert, sondern dem Modul wohnt ein BASIC Interpreter inne, der Skripte entweder zur Laufzeit, oder vorab als Bytecode interpretiert. Die Skripte werden in einem Teil des Flash-Speichers abgelegt und von dort dann auch Aufgerufen. Die Debug-Möglichkeiten halten sich hier auch begrenzt an ein printf(). Das Ausweichen auf eine richtige IDE mit SDK ist von Laird wohl nicht vorgesehen. Dafür ist der Einstieg mit der BASIC Programmiersprache wesentlich einfacher als bei den anderen Modulen. Die werden in C oder C++ programmiert und haben ein teilweise Echtzeit OS. All das bleibt dem BASIC Anwender verborgen.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

SaBLE-x mit dem CC2640 auf einem kleinen Prototyp-Board

Das PAN1740 war eines der ersten Module, die ich getestet habe. Es hat im Gegensatz zu den anderen hier aufgezeigten Chipsätzen einen Dialog DA14580 an Board. Dieser besitzt kein Flash Speicher, sondern lediglich ein OTP ROM. Das bedeutet, dass jedesmal, wenn ein Update der Firmware gemacht werden soll das ROM weiter beschrieben wird, bis kein Platz mehr drauf ist und der Chip unbrauchbar. Während der Entwicklungsphase wird der Code im RAM getestet. Das Problem dabei ist, dass das Gerät nicht mit Batterie getestet werden kann, da bei einem Batteriewechsel der Code aus dem RAM verschwindet. Es fällt somit leider für meine Zwecke as.

Ein weiterer Favorit ist das PRoc von Cypress. PRoC steht für Programmel Radio on Chip und ist mit der PSoC (Programmable System on Chip) Familie von Cypress verbunden. Die Entwicklungsumgebung von Cypress, das PSoC Creator, ist eine hervorragende kleine IDE mit Code Generator, Compiler, Debugger und Online Hilfe.

BLE Grundlagen


Die obige Abbildung zeigt die Grundstruktur eines BLE Geräts. Jedes Gerät besitzt mindestens ein Profil. Dieses beinhaltet dann mindestens einen Service (GAP) und diese enthalten Charakteristiken, die Daten des Geräts. Schon zu Beginn wird klar, um BLE zu verstehen und zu Verwenden, müssen einige Begriffe geklärt werden. Es gibt bereits eineige umfangreiche Literatur [1] und viele Webseiten [2], die einen Einblick in BLE geben, daher hier nur das nötigste.

GAP, GATT

Das Generic Access Protocol (GAP) koordiniert das Advertising und die Datenübertragung, wenn keine Verbindung (Bonding) zwischen den Geräten besteht. Weiterhin leitet es bei Bedarf die Verbindung ein, kümmert sich um Authentifizierung und Verschlüsselung der Verbindung.

Das Generic Attribution Profile (GATT) ist das Herzstück des Protokolls und kümmert sich um die einzelnen Charakteristiken und wie deren Daten übertragen werden. Es greift, sobald ein Bondig besteht und transferiert aus Charakteristiken und Descriptoren Daten anhand der UUID oder des Handles. 
Um den Kommunikationsfluss zwischen Device (Peripheral) und Basis (Central) zu steuern wird der CCCS eingesetzt. Der Client Configuration Characteristic Server. Dieser ist eine GATT Characteristic, die angibt, welche Daten veränderlich sind, ob und wann geschrieben, oder gelesen werden darf, oder ob eine Notification stattfindet, sobald der Wert sich geändert hat.

All das sieht auf den ersten Blick sehr komplex aus und alles Andere als Energiesparend. Allerdings kommt hier zu Gute, dass die Kommunikation über BLE ein verbindungsloses Verfahren ist, das bedeutet, dass der ganze Aufwand nur einmalig getrieben wird um eine Verbindung mit Verschlüsselung zu erzeugen und das Gerät kennen zu lernen. Wenn auf beiden Seiten dieses Bonding eingeleitet wurde, kann die Verbindung anhand der ausgehandelten Verbindungsparametern weitergeführt werden. Dieser Teil ist dann erstaunlich energiesparend.

Eine Funkstrecke funktioniert nur dann, wenn auf beiden Seiten das Radio eingeschaltet ist. Der Empfänger kann nur dann die Daten empfangen, wenn der Empfangsverstärker eingeschaltet ist. Ebenso kann der Sender nur senden, wenn der Sendeversteärker eingeschaltet ist. Ein Mitteilen, dass eine Sendung folgt muss über die Funkstrecke geschehen und so ist es schwierig eine energiesparende Konfiguration zu wählen, wenn der stromhungigste Teil der Schaltung immer aktiv ist. Daher hadelt das BLE-Protokoll zu Beginn einer Verbindung eine Wiederaufnahmezeit aus, nach der sich das Central wieder bei dem Peripheral meldet. Zu diesem Zeitpunkt muss das Peripheral dann sein Radio eingeschaltet haben um auf Anfragen des Centrals am GATT Server zu hören. Das ganze klingt relativ komplex, wenn man aber einmal die grundlgende Struktur verstanden hat stellt sich BLE als simples Protokoll heraus, das darauf ausgelegt ist, möglichst wenig Daten in sehr kurzer Zeit über die Funkstrecke zu senden und dann den größten Teil der Existenz im Tiefschlaf zu verbringen.

Zwei Übertragungsarten

BLE besitzt im Grund zwei Arten der Datenübertragung. Eine unidirektionale, verbindungslose Übertragung von kleinen Datenmengen. Diese Werden in einem so genannten Advertisement Paket verschickt. Dieses Paket besitzt eine Länge von maximal 32 byte und überträgt eine festlegbare Payload. Diese beinhaltet zum Beispiel den Namen des Gerätes, die ID, oder um weche Art es sich handelt. Erzeugt und gehandhabt wird das Paket vom GAP Server. Hier wird dem Zuhörer mitgeteilt, welche Möglichkeitem für eine weitergehende Verbindung bestehen. Verbindungslos bedeutet aber auch, dass die 32 Byte ausgesendet werden, wenn gerade niemand zuhört. Somit besteht für das Peripheral keine Möglichkeit zu erkennen, ob die Daten empfangen wurden. Der Rückkanal ist normalerweise für eine gebondete Verbindung vorgesehen. Dennoch wurde im GAP eine Möglichkeit geschaffen, eine Empfangsbestätigung zu simulieren. Das Peripheral sendet ein Advertisement Paket mit Scanable Flag aus und wartet dann für kurze Zeit auf einen Scan Request
Beim aktiven Scanen wird vom Central eine Scan Request abgeschickt, auf den
das Peripheral mit einer Scan Response antwortet.
 
Sobald ein Central ein Advertisement Paket mit diesm Flag empfängt, kann es diesen Scan Request abschicken und dem Peripheral so einerseits mitteilen, dass das Paket empfangen wurde, andererseits auch noch weitere Daten gewünscht sind. Der Scan Request selsbt kann keine Payload übertragen. Für eine echte Bidirektionale Verbindung muss dann auf eine GATT Verbindung mit Bonding zurück gegriffen werden.

Soweit erst einmal zu BLE. Der zweite Teil folgt dann in Kürze und wird den GATT-Server sowie eineige Profile näher betrachten.

[1] Townsend, Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking (2014) http://www.amazon.de/gp/product/B00K1N23LA
[2] Ti.com,TI Bluetooth Smart tutorial - How to get started part 1 (2013) https://training.ti.com/ti-bluetooth-smart-tutorial-how-get-started-part-1

Samstag, 14. März 2015

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.

Mittwoch, 4. März 2015

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.



Sonntag, 22. Februar 2015

Ein Blick auf KiCad [Netzliste und BOM]

Wie im ersten Teil bereits erwähnt, gibt es in KiCad eine Trennung zwischen Schaltsymbol und physikalischem Bauteil. Alle Symbole im Schaltplan werden mit Bezeichnern angelegt, besitzen Pins mit Pinnummern und werden anschließend in einer Netzliste ausgegeben. Die Netzliste enthält die Informationen, welche Pins eines Symbols/Bauteils mit welchen anderen verbunden sind. Diese abstrakte Information wird nun mit real existierenden Bauteilen verbunden. Doch dazu muss KiCad wissen, wie die Bauelemente aussehen, die im Schaltplan lediglich Symbole mit Pinnummern sind. Dazu wird das Programm CvPcb verwendet. Hier erscheint in der mittleren Liste jedes in der Schaltung verwendete Bauteil. Links sind die Bibliotheken der Lötpads zu finden und rechts eine gefilterte Auswahl an Lötpadformen.


Erst wenn jedes Element im Schaltplan ein Footprint zugewiesen bekommen hat, kann das Layout der Leiterplatte beginnen.

Eng mit dem Zuweisen der Footprints zu den einzelnen Schaltsymbolen verbunden ist das Führen einer Stückliste; Die BOM (bill of materials). Die aktuelle Version von KiCad ist momentan im Umbau, was das Erstellen der BOM betrifft. Normalerweise wird eine BOM abhängig der verschiedenen Bauelemente sortiert. Sodass nicht alle 10k 0603 SMD Widerstände einzeln aufgeführt werden, sondern der Widerstand einmal mit Stückzahl und eine Liste alle Bezeichner.

Die aktuelle KiCad Version ermöglicht das Anlegen von Plugins zur Erstellung von Stücklisten. Die zur Zeit einfachste Lösung ist das Erzeugen der Stückliste über ein Python-Script, das mit KiCad ausgeliefert wird. Allerdings sind in dem Windows Release von kicad.nosoftware.cz die Skripte nicht mitgeliefert. Zu finden sind sie im GitHub von KiCad, oder hier zum einfach herunterladen.

Durch einfügen der Kommandozeile "C:\KiCad\bin\python.exe" "c:\kicad\share\bom-in-python\bom_csv_grouped_by_value_with_fp.py" "%I" "%O" wird das Plugin aufgerufen und erstelle eine Datei mit der Endung .bom. Die Datei ist eine Textdatei, die zum Beispiel in LibreOffice oder Excel geöffnet werden kann. Sie enthält die Bauteilbezeichner, Anzahl der Bauteile, deren Wert, Das Symbol und die Pad Geometrie für die Platine. Weiterhin gibt es noch eine Beschreibung zum Bauteil und das Verkäufer Feld.

 

Die Übersicht über alle verschiedenen Bauteile eines Projektes ist die Grundlage zur Erzeugung der BOM. Mit diesem Dokument kann jetzt das Auswählen der Bauelemente beginnen. Dazu füge ich die Spalte "Partnumber" neben dem Feld "Value" hinzu. Dort werden die Herstellernamen Bauteile eingetragen. Um Bauteile zu finden verwende ich zum Beispiel RS oder Farnell. Die Herstellerbezeichnung ist der gesuchte Wert für die Stückliste. Dieser wird für jedes Bauteil eingetragen. Nachdem alle Komponenten der BOM eine Herstellerbezeichnung haben geht es nun an das Bestellen der Bauelemente. Um eine Übersicht der Kosten für das Projekt zu erhalten kann man zum Beispiel Teilesuchmaschinen, wie Octopart verwenden.


Bei dieser Strückliste teilt mir Octopart mit, dass zwei Teile nicht verfügbar sind und dass ein Teil nur bei einem Hersteller verfügbar ist. Daher werden diese Teile in der BOM durch kompatible Bauelemente ersetzt, sodass die BOM vollständig von einem der Distributoren zu beziehen ist.

Nächste Woche schauen wir uns dann das Layouten und der Leiterplatte und erstellen der produktionsrelevanten Daten an.

Sonntag, 15. Februar 2015

Ein Blick auf KiCAD [Schaltplan]

KiCad ist ein FOSS Softwarepaket, dass zur Entwicklung von elektronischen Schaltungen und das Design der Leiterplatte verwendet werden kann. Es ist seit 2007 in Entwicklung und mittlerweile so weit, dass es zum professionellen Einsatz angewendet werden kann. Das Projekt wird vom CERN unterstützt, die einige neue Funktionen für den Schaltplaneditor, das Backend und den Layouter zur Verfügung gestellt hat.

Für meine kleineren Projekte, habe ich bis jetzt immer nur den Schaltplaneditor verwendet. Bei einem aktuellen Projekt, möchte ich allerdings auch die Leiterplatte herstellen lassen. Dabei soll die Platte im KiCad Layouter entwickelt werden. Diese Artikelserie wird sich mit den Abläufen und Tücken von der Erstellung einer Schaltung, bis hin zur fertigen Leiterplatte befassen. Die Aufteilung der Artikel wird sich an dem Workflow orientieren, den man bei der Erstellung einer Leiterplatte durchläuft. Es wird sich dabei nicht um eine Anleitung zum erstellen von Schaltungen handeln, sondern vielmehr ein Überblick darüber, wie die Arbeit mit KiCad abläuft.
Begonnen wird beim Erstellen des Schaltplans, danach wird die Netzliste erstellt. Diese enthält alle Informationen über die verwendeten Bauteile und deren Eigenschaften (Namen, Pinbelegung und Landepads) sowie Verbindungen. Nebenbei wird die Liste der Bauteile erstellt, die daraufhin zu beschaffen sind. Mit der Netzliste kann dann im dritten Teil die Leiterplatte entworfen werden. Neben der Platzierung der Bauteile werden wir auch die fertigungstechnischen Feinheiten betrachten und den Prozess der Bestellung durchführen. Wenn die Platte dann eingetroffen ist, wird der letzte Artikel, die Bestückung der Platte und das Löten im Reflow-Prozess beschrieben.

KiCad Installieren

Ähnlich wie bei anderen FOSS Projekten, wird KiCad ständig weiterentwickelt und man kann sich die aktuellste Version als Quellcode aus dem Internet herunterladen. Für viele Betriebssysteme gibt es bereits fertige Binärpakete, die installiert werden können. Zur Zeit sind neue Builds auf http://kicad.nosoftware.cz/ zu finden. Wer sich die Mühe machen möchte, das Programm selbst zu kompilieren, kann dafür den Winbuilder verwenden.

Ich beziehe mich in dieser Artikelserie auf die Version 2015-01-17 BZR 5376 aus dem nosoftware.cz Fundus. 

KiCad Manager

Nach dem Start von KiCad wird der Projektmanager gestartet. Dieser zeigt die verwendeten Dateien, des aktuellen Projekts an und bietet eine Schnellstartleiste für die benötigten Programme, wie Schaltplan- und Symboleditor, oder Layouter. Weiterhin sind noch einige kleine Tools, wie Bitmap zu Komponenten-Konvertierung, Berechnungs-Tools und Schaltplan-Layouteditor. 
Von diesem Fenster aus wird ein Projekt verwaltet. 

Der Schaltplaneditor

Der Schaltplan wird über den Editor Eeschema erstellt. Die Abbildung zeigt den fertigen Schaltplan eines Projekts. Die Übersichtsseite des Schaltplans, also die erste Seite ist hier wie ein Blockschaltbild zu betrachten. Verschiedene Funktionen sind in einzelne Blätter (Subsheets) aufgeteilt. Das muss man nicht unbedingt machen, es macht die Schaltung ab einer gewissen Größe allerdings übersichtlicher. Ich habe meine Schaltungen eigentlich immer auf A3-Größe festgelegt und gehe von dort aus in Subsheets um die Komplexität der einzelnen Komponenten geringer zu halten. Um Signale zwischen den einzelnen Blättern austauschen zu können, werden hierarchische Labels verwendet. Zwei unterschiedliche Netze, die mit einem gleichnamigen Label verbunden werden, sind danach das gleiche Netz. Auf dem Hauptblatt sieht man dann die Verbindungen der einzelnen Untergruppen. Somit wird die Logik abstrahiert und einfacher auf den ersten Blick zu verstehen.

Ein Schaltplan besteht aber nicht nur aus Subsheets, sondern auch aus Komponenten, die die eigentliche Schaltung darstellen. Diese werden über das 'Bauteil hinzufügen' Menü ausgewählt und in den Schaltplan eingefügt. Das Menü erscheint, wenn man das Bauteil-Werkzeug ausgewählt hat und in den Schaltplan klickt. Hier sind alle Bauteile, die in der Bibliothek abgelegt sind zu finden. Über die Filter Eingabe kann nach eine bestimmten Teil gesucht werden, über das Auswahlmenü können die einzelnen Bibliotheken durchsucht werden. Der untere Bereich dient als Vorschau für die Komponente und gibt zusätzliche Informationen zu dem Bauteil, sofern diese bei der Erstellung hinterlegt wurden. Das gewählte Bauteil kann nach dem Drücken des OK-Buttons in den Schaltplan eingefügt werden. 

Sollte ein Bauteil nicht in der Bibliothek zu finden sein, muss es neu angelegt werden. Es sind zwar mittlerweile eine Vielzahl von Bauteilbibliotheken im Internet zu finden, doch es kann vorkommen, dass es dieses eine Bauteil mit diesem Gehäuse und diesem Pinout eben noch nicht gibt. Der Bauteil-Editor von KiCad ist allerdings einfach zu benutzen, wenn man das System hinter den Bibliotheken einmal verstanden hat. Eine Bibliothek ist eine Datei. In dieser Datei befinden sich Beschreibungen für eine oder mehrere Bauteile. Die Bibliotheksdatei muss in einem KiCad bekannten Verzeichnis liegen und zusätzlich noch als aktive Bibliothek ausgewählt werden. Erst dann ist sie in der Bauteil-Auswahl verfügbar. Die erzeugten Biblioteks-Dateien sind im Textformat gespeichert. Diese Eigenschaft machen wir uns später zu Nutze, wenn es darum geht verschiedene Versionen zu verwalten.

Das neue Bauteil bekommt einen Namen. Es wird festgelegt, welche Bezeichner für das Bauteil verwendet werden soll (R für Widerstände, L für Induktivitäten, C für Kondensatoren, V für Dioden, usw.) und die Anzahl der Komponenten pro Bauteil (bspw. für Dual-FETs oder Widerstandsarrays).
Daraufhin kann das Bauteil gezeichnet werden und die Pins eingefügt, benamt und benummert werden. Wichtig ist festzulegen, wie der Energiefluss der Pins ist. Hier sollte Jeder Versorgungspin (VCC, GND, ...) als Eingang, jeder Ausgangspin als Ausgang (Vout, ...) und jeder Controller-Pin als Bidirektional festgelegt werden. Man kann hier noch weiter ins Detail gehen, wenn man das möchte. Die grobe Festlegung des Energieflusses ist aber wichtig um spätere Fehler im Design Rule Check (DRC) zu vermeiden.


In den Eigenschaften des Bauteils, können für später wichtige Informationen hinterlegt werden. Einmal grundsätzliche Eigenschaften zur Darstellung des Symbols, ähnlich der Einstellungen beim Erstellen des neuen Symbols. Eine Beschreibung das Bauteils und das Datenblatt sollten nicht fehlen, so kann während der Schaltplaneingabe schnell auf das Datenblatt zugegriffen werden. Für viele Bauteile gibt es unterschiedliche Beschreibungen, die mit der eigentlichen Funktion des Bauteils nicht viel zu tun haben (Gehäuseform, Verpackungseinheiten, ...). Außerdem gibt es Bauteile, die von verschiedenen Herstellern geliefert werden, aber die gleiche Beschaltung und Funktion aufweisen. So können dem Bauteil Aliase vergeben werden, um es unter diesen Namen in der Liste der Komponenten zu finden. Obwohl im Schaltplaneditor keine fixe Verbindung von Schaltplakomponente und physikalischem Bauteil besteht, kann dem Bauteil eine Reihe von Landungspads (Footprints) für die Leiterplatte mitgegeben werden. Das erleichtert später die Zuweisung von Bauteilform zu Bauteil. 

Bauteile-Bezeichner

Nachdem der Schaltplan in den Editor eingegeben wurde, oder schon währenddessen kann der Komponente ein Bezeichner zugewiesen werden. Beim Erstellen des Symbols haben wir gesehen, dass jedes Symbol einen Prefix besitzt, der die Art des Bausteins beschreibt (R, L, C, V, ...). Dazu kommt dann meistens noch eine Nummer, die das Bauteil eindeutig kennzeichnet. So entsteht dann der Widerstand R100 oder der Kondensator C371. Die Bezeichnung kann manuell beim Hinzufügen des Symbols erfolgen, oder automatisch mit dem Annotation-Tool. Dieses Tool erlaubt es uns entweder alle, oder alle noch nicht benannten Bauteile mit den nächsten freien Nummern zu benennen. Dabei kann der aktuelle Schaltplan, oder alle Schaltpläne des Projekts beachtet werden. Die nächstmögliche freie Zahl ist aber auf das ganze Projekt bezogen, denn jeder Bezeichner darf nur einmal vorkommen.
Das Annotationstool besitzt die Möglichkeit, die zu benennenden Bauteile entweder waagerecht, oder senkrecht zu ermitteln und zu bezeichnen. Ich habe eigentlich immer die senkrechte Reihenfolge gewählt. Der nächste Punkt, die Annotationsauswahl, lässt es zu, dass wir Blatt abhängig die Bezeichnung der Bauteile erhöhen. So wird der erste Widerstand auf Blatt 3 mit 300 bezeichnet, der zweite mir R301 usw. Später hilft das den Widerstand von der Leiterplatte wieder in den Subsheets zu finden. Das ist vor allem im Fehlerfall praktisch.

DRC

Der Design Rules Check ist ein sehr hilfreiches Tool beim verifizieren der Schaltung. Er schaut sich den kompletten Schaltplan an und bestimmt anhand von gegebenen Bedingungen, ob der Schaltplan so regelkonform ist. Diese Regeln werden in den Optionen festgelegt. Das Bild zeigt einen typischen Fehler; Ein Pin eines Bauteils ist nicht angeschlossen und der Pin wurde nicht explizit, als nicht verbunden gekennzeichnet. Im Schaltplan wurde die Stelle markiert und wird beim Klick auf den Fehler in der Fehlerliste hervorgehoben. Allerdings ist das nur ein Warnhinweis und kann ignoriert werden. In den Optionen des DRC kann festgelegt werden, wie mit verschiedenen Bedingungen umgegangen werden soll. Beispielsweise ist es OK zwei Eingangspins oder Tri-State-Pins miteinander zu verbinden, aber wenn zwei Ausgangspins verbunden werden, wird ein Fehler erzeugt. Diese Regeln sind nicht verpflichtend, können aber helfen, dass beim eingeben des Schaltplans keine Fehler gemacht wurden.

Zusammenfassung

Der Schaltplan wird in EEschema eingegeben. Dabei werden Symbole aus einer Bibliothek verwendet. Diese Symbole sind nicht zwangsweise an ein Physikalisches Bauteil gebunden. Die Bibliothek ist eine Textdatei in der alle zu dieser Bibliothek gehörenden Symbole hinterlegt sind.
Komplexe Schaltungen können auf Subsheets ausgelagert werden. Diese können Signale mit hierarchischen Labels austauschen. Das Bezeichnen von Komponenten kann manuell oder mit dem Annotationstool gemacht werden. Am Ende kann mit dem DRC ermittelt werden, ob noch grobe Fehler im Schaltplan zu finden sind.

Wie die virtuellen Komponenten im Schaltplan zu ihren physikalischen Gegenstücken umgewandelt werden, warum ein Widerstand auch ein wichtiges Bauteil ist, warum es sinnvoll ist Schaltplansymbol und physikalisches Bauteil zu trennen und was die Netzliste macht, betrachten wir dann im nächsten Beitrag.