Mikrocontroller.net - Benutzerbeiträge [de]

Strukturierte Programmierung auf Mikrocontrollern

2022-10-06T09:29:46Z

172.26.27.242: /* Grundlegendes */

== Grundlegendes ==

In diesem Artikel sollen die Grundlagen der sauberen Aufteilung eines Programms in Module, Schichten und Strukturen erklärt werden, besonders bezogen auf Mikrocontroller.

Leider fällt im Forum oft auf, dass sehr gerne einfach alles in eine C-Datei "geklatscht" wird, was für kleinere Programme halbwegs funktionieren mag, bei größeren Projekten jedoch versagt, da man schnell die Übersicht verliert und sich auch die Wartbarkeit des Codes sehr verschlechtert.

Für die stukturierte (professionelle) Programmierung sind 3 Faktoren von Bedeutung:

== Planung ==
Zahllose Softwareentwickler starten ihre Programmierkarriere out of the box, d.h. sie haben keine Ausbildung und bringen sich das Programmieren selber bei. Sie starten daher oft direkt mit der Entwicklungsplattform und Beispiel-Codes, die sie modifizieren. Damit wird sozusagen auf der Ebene der Umsetzung gestartet und die Funktion des Programmes quasi nebenbei mit geplant. Dieses für kleine Projekte funktionable Vorgehen, bringt dann bei wachsenden Programmen Probleme, weil der Entwickler niemals ein strukturiertes Entwickeln gelernt hat. Diese Personen haben dann in der Praxis das Problem, dass sie gesteigerten Anforderungen in Sachen Planung und Dokumentation gegenüberstehen und die althergebrachte bottom up Methode nicht mehr gefragt ist. Unglücklicherweise wird selbst an Hochschulen nur sehr selten auf praktische Belange diesbezüglich Rücksicht genommen.

Am Anfang eines Projektes steht daher sinnvollerweise ein Konzept, in dem wichtige Dinge vorab erfasst sind, damit man sich während des Entwickelns nicht "verläuft". As nützlich haben sich erweisen:

- Beschreibung der Funktionen eines Programmes mit Benutzereingriffsmöglichkeiten (use cases), jeweilige Reaktion des Programms (responses, event handling), autonome Aktionen im Hintergrund (interrupts, polling), erlaubte Funktionen, verbotene Zustände

- Erstellung eines Blockdiagramms zur Aufteilung der funktionellen Module und Beschreibung der Untermodule und ihrer Funktion

- Hinweise zur Umsetzung unter Rücksichtnahme auf Randbedingungen der speziellen Hardware (z.B. Timing, Tempo des Controllers, Loop-Anzahl, Verzögerungen infolge polling, maximale Interrupttiefe, und -dichte.

- Beschreibung der mathematischen Funktionen, Niederlegung der Formeln, Beispielrechnungen in Excel mit Test der Auflösungen und Rundungsuntersuchung samt Bereichsgrenzenprüfung etc.

Diese Vordokumentation ergibt einen Leitfaden für die Entwicklung = Umsetzung und hilft, dass mehrere Personen an einem Projekt arbeiten können. Zudem ist es leichter erweiterbar, da sofort ersichtlich ist, was die Software können sollte und was sie nicht kann und worauf Rücksicht genommen wurde.

Diese Dokumentation wird um die finale Doku erweitert und bildet wiederum die Basis für Änderung, die Erzeugung von Abkömmlingen und die Planung neuer Projekte. Hat man einen Stamm an Doku beisammen, ist die Planung und Definition nur noch ein Copy&Paste und man hat direkt einen Leitfaden der Todos im neuen Projekt. Die Chance, etwas zu vergessen oder zu übersehen, wird drastisch verringert.

== Versionsverwaltung ==

Oft kommt es vor, dass man an einem Programm arbeitet und irgendwann nach einer Änderung gar nichts mehr funktioniert und man es, warum auch immer, nicht schafft, den alten Zustand wiederherzustellen. Labile Naturen werfen dann meist das Projekt einfach hin, echte Männer fangen von vorn an ;-). Beides ist keine Lösung. Besonders interessant wird es, wenn man mit mehreren Personen an einer Datei arbeiten möchte und mehrere zur gleichen Zeit auf der selben Datei arbeiten. Wenn jeder einfach speichert, bleiben nur die letzten Änderungen erhalten.

Dies löst ein Versionsverwaltungssystem, auch Source Code Management (SCM) oder Version Control System (VCS) genannt. Bekannte Versionsverwaltungen sind RCS, CVS, SVN, GIT. Ich möchte mich hier auf SVN beschränken. Eine gute Grundlagenerklärung zur Funktion von SVN bietet der Wikipedia-Artikel [http://de.wikipedia.org/wiki/Subversion_(Software) Subversion]. Ich bitte den Leser, sich diesen Artikel gründlich zu Gemüte zu führen. Dort sind vor allem wichtige Grundbegriffe erklärt, die den Rahmen dieses Artikels sprengen würden.

Wer unter Linux, Unix oder BSD-Varianten arbeitet, der hat unter allen bekannten Versionsverwaltungen die größte Auswahl. Selbst ein frühes Festlegen auf ein SCM ist nicht unumkehrbar, denn es gibt sogar Konverter, die später den ganzen Code-Baum samt Geschichte umwandeln in ein anderes SCM.

=== Installation von SVN ===

Unter Windows empfehle ich den Server [http://www.visualsvn.com/ VisualSVN] und den in die Windows-Oberfläche integrierten Client [http://tortoisesvn.net/ TortoiseSVN]. Unter einem Debian-Derivat (z. B. Kubuntu) installiert man einfach das Paket '''subversion'''. Es existieren auch für Linux graphische Clients, auf die ich hier nicht weiter eingehen möchte.

=== Verwendung von SVN ===

Zur Verwendung von SVN gibt es eine sehr gute Anleitung unter: [https://www.bsdwiki.de/Subversion BSDwiki]. Ein Versionsverwaltungssystem mag zunächst lästig erscheinen. Spätestens, nachdem man das erste Mal seine Software zerschossen hat, mag man es nicht mehr missen.

== Dokumentation ==

Wichtig ist eine gute Dokumentation des Codes. Eine Möglichkeit dabei sind aussagekräftige Kommentare im Programmtext, die es gestatten, einen Zusammenhang zwischen der Implementierung und der Funktion herzustellen. "Aussagekräftig" bedeutet damit, dass man nicht schreibt, 'was' die Codezeile macht, sondern 'warum' und was sie funktionell bedeutet:

'''schlecht''': 
<syntaxhighlight lang="c">
maxTests = 5; # Setze maxTests auf 5 <--- redundant und daher nutzlos
</syntaxhighlight>

'''gut''': 
<syntaxhighlight lang="c">
maxTests = 5; # Maximal 5 Abfragedurchläufe <--- Bindung zur gewünschten Funktion.
</syntaxhighlight>

Weiterhin wird vor allem für größere Sachen empfohlen, ein integriertes Dokumentationssystems zu verwenden. Hier wurden gute Erfahrungen mit [http://de.wikipedia.org/wiki/Doxygen Doxygen] gemacht. Dieses Programm wurde unter der GPL veröffentlicht und erzeugt u.A. auch sogannte Callgraphs

Doch nicht nur das Vorhandensein inhaltlicher Erläuterungen ist wichtig - auch die Art der Codegestaltung spielt in der Praxis eine wesentliche Rolle:

== Formatierung des Quelltextes ==

Um ein Programm gut und schnell verstehen zu können, muss auch der Quelltext sauber formatiert sein. Denn ein Programm schreibt man einmal, liest es aber viele Male. Dazu müssen ein paar grundlegende Formatierungsregeln beachtet und einheitlich umgesetzt werden.

* Syntax highlighting: Die meisten Editoren und Entwicklungsumgebungen unterstützen das farbige Hervorheben von Schlüsselwörtern. Das erleichtert die Lesbarkeit deutlich. Vor allem Kommentare sind somit leichter lokalisierbar.
* Einrückung: Bei While oder For -Schleife, If-Abfragen oder switch-Anweisungen sollen die Blöcke stets eingerückt werden, um die logische Struktur darzustellen. Dadurch sieht man auch leichter vergessene Klammern oder falsche logische Zuordung in verketteten if-Anweisungen.
* Begrenzung der Zeilenlänge auf 80-100 Zeichen
* Tabulatoren als Leerzeichen einfügen lassen: Das können die Editoren heute allein. Der Vorteil ist, dass der Quelltext danach immer gleich aussieht, und nicht auf einem anderen Editor mit anderer Tabulatoreinstellung verschoben aussieht.

=== Benennung von Variablen, Makros, Nutzung von Anweisungen ===

* selbsterklärende Funktions- und Variablennamen ersparen einem 100000 Kommentare
* Variablennamen sollen in erster Linie den Inhalt einer Variablen beschreiben, nicht ihren Datentyp.
* Defines komplett in GROSSBUCHSTABEN
* Namen von Variablen und Funktionen bzw. Methoden in Kleinbuchstaben; Worttrennung mit Unterstrich oder CamelCase (jede Wortsilbe beginnt mit einem Großbuchstaben, z.B GetInfo, MaxCount etc.)
* Namen wie i, j, k für Indizes für Zählschleifen
* Variablen wie x, y, z für Positionen
* bei Arrays z.B. einkaufsPreis[i] oder einkaufsPreis[index] verwenden. i bzw. index sind übliche Namen um aus einem Array ein einzelnes Element zu identifizieren.
* Variablen und Makros so lokal wie möglich halten
* mit globalen Variablen sparsam umgehen und diese auch im Namen kennzeichnen, z. B. den Modulnamen voranstellen 'i8_LOG_Position'
* Vermeidung langer Funktionen / Aufspalten in kleinere Funktionen und Bibliotheken: Verwendest du den gleichen Code an verschiedenen Stellen lohnt es sich diesen in eine Funktion auszulagern.
* Eine Funktion löst genau eine Aufgabenstellung
* Funktionen sollen nur das machen, was der Funktionsname erwarten lässt.
* Wiederverwendbarkeit durch Funktionen, keine doppelten Codeteile, für Geschwindigkeit notfalls #inline verwenden
* kurze und knackige Berechnungen, keinen Spaghetticode; Werden in der Berechnung Konstanten verwendet, dann am besten einen Kommentar dazu (z. B. b = a*3.6e6 // 3.6e6 ist Millisekunden pro Stunde)
* statt ?: am besten Verzweigungen verwenden, da dieser oft nicht bekannt ist und auch nur noch selten verwendet wird.
* Leerzeichen und Leerzeilen kosten kein Geld! Aber bitte nicht tonnenweise!
* Kommentare schreibt man für sich selbst, für später
* Kommentare sofort schreiben, hinterher ist man zu faul und nicht mehr zu 100 % im Problem vertieft
* Je genialer die Idee, um so nötiger der Kommentar.
* Zusammenhänge dokumentieren. Die erschliessen sich nicht aus den paar Zeilen Code, auf die man gerade schaut!
* Kommentare sollen die 'Warum'-Frage beantworten und nicht die 'Wie'-Frage! Wie etwas gemacht wird, steht im Code. Aber dort steht nicht warum es gemacht wird.
* Kommentare nach dem Muster "Das ist eine for-Schleife" lösen maximal Schmunzeln aus, es sei denn es handelt sich um ein C-Lehrbuch. Solche Kommentare ("Hier beginnen die Variablen", "Hier beginnen die Funktionen", etc) lässt man besser. Jeder der mehr als 5 Stunden C programmiert erkennt eine for-Schleife auf Anhieb und wenn nicht soll er zuerst ein C-Buch studieren, ehe er sich an Code versucht.
* Die üblichen Regeln der Muttersprache sollten in den Stil einfließen
* einheitlicher Stil bei Formatierung und Namensgebung
* Vermeidung voreiliger Optimierungen

Beispiele

<syntaxhighlight lang="c">

/* Sicherung gegen doppeltes Einfuegen von Headerfiles */
#ifndef HEADER_FILE_NAME
#define HEADER_FILE_NAME

// Das Headerfile

#endif

#define IN_GROSSBUCHSTABEN // Caps mit underline

int funktionsName(int param); // CamelCase

char varName; // CamelCase
</syntaxhighlight>

== Modularisierung ==

Nun zum wichtigsten Punkt: Ein Programm richtig in Module und Schichten zu unterteilen. Das ist aus verschiedenen Gründen notwendig.

* Übersichtlichkeit: Vor allem bei größeren Sachen will und muss man den Überblick behalten. Dazu muss ein Programm sauber formatiert und strukturiert sein.
* Wartungsfreundlichkeit: Sowohl in der Entwicklungsphase als auch später bei der Erweiterung/Wartung ist ein gut modularisiertes Programm sehr wichtig
* Speicherverbrauch: Einen Ablauf, welcher mehrfach im Programm verwendet wird, packt man sinnvollerweise in eine Funktion. Dadurch wird nur einmal Speicherplatz benötigt, egal wie oft sie verwendet wird.
* Kapselung: Das Prinzip des Versteckens von Details steigert die Lesbarkeit deutlich, denn eine Funktion, die vielleicht drei Bildschirmseiten füllt, steht einfach als eine Anweisung in einer Zeile. Das ist vor allem deshalb von Vorteil, weil man sich nur einmal mit den Details einer Funktion beschäftigen muss, nämlich dann, wenn man sie erstellt. Für die Nutzung im Programm will man diese Information gar nicht haben, sie stören hier nur (Informationsüberfluß).
* Leistungsfähigkeit: Ein gut modularisiertes Programm erreicht ein bestimmte Funktionalität einfach und kompakt, weil die einzelnen Funktionen so angelegt sind, dass sie einfach und dennoch vielfältig verwendet werden können. Wichtig ist dabei die richtige Portionierung.
**Welche Funktion sollen immer zusammen sein, welche sollten getrennt werden?
**Wie gestaltet man die Parameter für eine Funktion sinnvoll?
* Testbarkeit: Das leidige Thema der Softwareentwicklung ist der Test. Dieser sollte theoretisch alle Fehler finden, praktisch wird das aber oft nicht erreicht. Da Software meist eine recht komplexe Sache ist, kann man sie nur sehr schwer als Gesamtwerk vollständig prüfen. Darum müssen zuerst die Teile einzeln getestet werden. Ein gut modularisiertes Programm kann man leichter testen.

== Siehe auch ==
*[[Erweiterte LCD-Ansteuerung]]: Artikel mit einem einfachen Beispiel für strukturierte Programmierung
*[http://www.mikrocontroller.net/topic/26550#new Forumsbeitrag]: C++ CodeChecking (Style,...)
*[http://www.mikrocontroller.net/topic/132304#new Forumsbeitrag]: Tutorial für _sauberen_ C-Code
*[https://www.mikrocontroller.net/topic/392060?goto=new#new Forumsbeitrag]: goto verpönnt - was dann nehmen?
*[https://www.mikrocontroller.net/topic/438529#new Forumsbeitrag]: Doku zu AVR Assembler für komplexe Projekte
*[https://www.mikrocontroller.net/topic/1675?goto=new#10504 Forumsbeitrag]: Klingonische Softwareentwickler (Achtung Humor!)
*[https://www.mikrocontroller.net/topic/533978#7002671 Forumsbeitrag]: Suche Literatur für strukturierte Embedded Programmierung

== Weblinks ==

* [http://www.gimpel.com/html/pcl.htm PC-lint, ein Analyseprogramm für C-Code]
* [http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html Recommended C Style and Coding Standards, engl.]
* [http://www.jetcafe.org/jim/c-style.html Standards and Style for Coding in ANSI C, engl.]
* [http://de.wikipedia.org/wiki/Programmierstil Wikipediaartikel über Programmierstil]
* [http://www.campwoodsw.com/sourcemonitor.html Tool zur statischen Codeanalyse u.a. für C/C++]
*[http://en.wikipedia.org/wiki/Program_optimization Program optimization] auf Wikipedia, engl.
* [https://sites.google.com/site/artcfox/demystifying-the-tlc5940 demystifying-the-tlc5940] Umfassende Erklärung zur Ansteuerung eines TLC5940 sowie Hinweisen zum Vorgehen bei der Einarbeitung in neue Hard- und Software, engl.
* [http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code The Exceptional Beauty of Doom 3's Source Code] (engl.)
* [ftp://ftp.idsoftware.com/idstuff/doom3/source/CodeStyleConventions.doc CodeStyleConventions.doc] von iD Software für DOOM 3, (lokale [[:Datei:CodeStyleConventions_ID_Software.pdf | Kopie]])
* [http://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675/ref=sr_1_1?ie=UTF8&qid=1444238128&sr=8-1&keywords=weniger+schlecht+programmieren Weniger schlecht programmieren], ISBN: 3897215675
* [http://c2.com/cgi/wiki?ThreeStarProgrammer ThreeStarProgrammer]: Warum man keinen hochkomplexen Code schreiben soll (engl.)
* [https://de.wikipedia.org/wiki/Therac-25 Therac-25] Beschreibung eines Unfalls in der Medizintechnik, hervorgerufen durch Software- und Konzeptfehler
* [http://www.ccnr.org/fatal_dose.html FATAL DOSE] Radiation Deaths linked to AECL Computer Errors (engl.)
* [https://www.safetty.net/publications/pttes ‘Patterns for Time-Triggered Embedded Systems’] by Michael J. Pont

[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Mikrocontroller]]

Ätzen mit luftregenerierten Kupferchlorid

2022-10-05T11:13:03Z

172.26.27.242: /* Equipment */

von [https://www.mikrocontroller.net/user/show/coldtobi Coldtobi], Ergänzungen zu Kaliumchlorid von [https://www.mikrocontroller.net/usr/show/bastians BastianS]

= Einleitung =

Vor etwa zwei Jahren (2010?) bin ich auf das [http://home.exetel.com.au/adam.seychell/PCB/etching_CuCl/index.html hier] beschriebene Verfahren gestosssen und habe es zum ersten Mal 2012 ausprobiert.

Das Charmante an dieser Lösung ist, das die Ätzbrühe nie verdirbt (nur mehr wird) und das nachdem man die Ätzbrühe zum ersten Mal angesetzt hat keine anderen Chemikalien als Salzsäure* benötigt werden.

Im Prinzip ähnelt diese Methode der Methode [[Platinenherstellung_mit_der_Photo-Positiv-Methode#mit_Salzs.C3.A4ure_und_Wasserstoffperoxid|Salzsäure/Wasserstoffperoxid]], bei welcher vereinfacht gesagt das Wasserstoffperoxid verwendet wird um die Ätzbrühe zu regenerieren, was in der hier vorgestellten Methode durch den in der Luft enthaltenen Sauerstoff ersetzt wird.
Der Mehrwert ergibt sich dadurch, dass das Wasserstoffperoxid nicht mehr benötigt wird, denn dieses ist eine (auch politisch) heikle Chemikalie.
Außerdem entsteht kein giftiges Chlorgas.

(* naja, man braucht auch Wasser wenn die Suppe mal zu dick wird :))

=== Vorteile ===
* '''Einfache Verfügbarkeit der Chemikalien.''' (H2O2, NaPS und Fe(iii)Cl haben inzwischen Handelsbeschränkungen)

* insbesondere: '''kein H2O2''' wird benötigt

* '''Entsorgung''': Es entsteht kaum Abfall bzw. dauert es sehr lange bis man was zu entsorgen hat.

* Sehr gute '''Ätzergebnisse''', kaum Unterätzung (zuminderst meine subjektive Meinung im direkten Vergleich mit Fe(III)Cl)

* '''Prozessparameter''' sehr gut kontrollierbar -- für gute Reproduzierbarkeit.

* '''Haltbarkeit''' der Lösung praktisch unbegrenzt. Sehr Vorteilhaft für Gelegenheitsätzer. (Da es sich der Zeit selber zersetzt kann H2O2 nicht unbegrenzt aufbewahrt werden. Ausserdem sollte H2O2 kühl gelagert werden).

* '''Lagerbar im geschlossenen Gefäß''' -- Im Gegensatz zu H2O2 gast hier kein Sauerstoff aus, die Lösung kann also im gasdichten Behälter aufbewahrt werden, ohne dass man Angst haben muss das es diesen durch den steigenden Druck "zerreist".

=== Nachteile ===
* '''Aufwändiger'''

Erstellung der Ätzlösung braucht etwas Zeit und für schnelles Regenerieren muss man sich Equipment bauen/besorgen. Allerdings auch eine einmalige Sache...
Für den Gelegenheitsätzer, reicht normalerweise ein größeres Gefäß, in das zusätzlich zur Ätzlösung genug Luft passt zur Regeneration.

* '''Salzsäure ist korrosiv''' und dampft immer ein wenig aus. Dieser Nachteil entfällt jedoch, wenn man statt der freien Säure ein Alkalichlorid (z.B. Kaliumchlorid) als Komplexbildner verwendet.

Dieser Punkt ist der am meisten diskutierte Punkt. Er lässt sich jedoch entweder durch die Verwendung von Kaliumchlorid oder Natriumchlorid völlig vermeiden. Außerdem ist er IMHO durch sauberes Arbeiten bzw. gutes Equipment im Griff zu bekommen.

Das Problem wird verstärkt durch das Einblasen von Luft, da hier immer etwas Aerosol entsteht. Das lässt sich verringern wenn das Regenerationsgefäß abgedeckt ist,
so dass sich die Spritzer am Deckel ablagern können und wieder zurücklaufen.

Die durch Verdunstung entstehenden Dämpfe können z.B durch eine Plastikbox gekapselt werden, so dass sie zuverlässig "contained" werden.

Ums deutlich zu machen: Wenn man nicht gewissenhaft arbeitet, wirds irgendwo in der Gegend zu rosten anfangen!
Wenn man gewissenhaft arbeitet, dann nicht. z.B habe ich als "Kontrolle" neben meinem Kontainment (die Plastikbox) ein paar Nägel liegen -- die rosten nicht.
Die Kontrollgruppe in der Plastikbox sofort.

* '''Sauberes & Gewissenhaftes Arbeiten notwendig!'''

Eigentlich selbstverständlich, ich hab's hier nur als Nachteil rein damit es jedem klar ist das das hier kein Kinderspielzeug ist -- wie auch die anderen Ätzmethoden keines sind.

=== Verwendung von Kaliumchlorid statt freier Salzsäure ===

Das Patent DE2942504A1 (abgelaufen) schlägt vor die üblicherweise in der Ätzlösung vorhandene freie Salzsäure durch Kaliumchlorid (oder alternativ Natriumchlorid) zu ersetzen.
Durch den kleinen Mehraufwand für die Beschaffung von KCl ergeben sich einige Vorteile:
* '''höherere Ätzgeschwindigkeit''': 5 Minuten für eine 35 µm Platine bei Raumtemperatur
* '''kein Ausgasen''': die Lösung enthält keine freie Salzsäure mehr, die ausgast
* '''einfachere Prozessführung''': die Titration zur Einstellung der freien Säurekonzentration entfällt, lediglich eine Waage ist nötig um das KCl korrekt nachzudosieren (siehe Methode 3 bei Badführung)

Konkret erwähnt das Patent eine Ätzlösung mit 130 bis 320 g/l, insbesondere 210 g/l Kupfer(II)chlorid und 70 bis 250 g/l, insbesondere 160 g/l Kaliumchlorid.

Details dazu gibt es [https://www.bastianschmidt.de/etching hier (auf englisch)].

=== Disclaimer ===

Die Informationen in diesem Artikel werden ohne Gewähr wiedergegeben -- Verwendung der Informationen ausschliesslich auf eigene Gefahr. Keine Haftung für Schäden, die durch die Informationen in diesen Artikel entstehen
Der Artikel setzt gewissen Menschenverstand / Sachkenntnis vorhanden. Im Zweifel ist der Artikel fehlerhaft. Wenn Sie sich unsicher sind, lassen sie die Sache lieber sein!
Gesetzliche Vorgaben -- zum Beispiel zur Entsorgung -- sind zu beachten. (die hier wiedergebenen Informationen sind sicherlich nicht vollständig.)

= chemischer Ablauf der Kupferchloridätzung und Regeneration =

Die eigentlich stattfinden Reaktion finden mit diversen Komplexen statt. Die hier wiedergegebenen vereinfachten Formeln reichen jedoch fürs Verständnis überwiegend aus.

== Gleichungen ==

Grundsätzlich ist bei dieser Methode der ätzende Bestandteil NICHT die Salzsäure, sondern das Kupfer(II)chlorid. In Verbindung mit dem Kupfer der Leiterplatte entsteht dann eine [http://de.wikipedia.org/wiki/Komproportionierung Komproportionierung]: Das 0-wertige Kupfer und das 2-wertige Kupfer im CuCl2 werden zu 1-wertigem Kupfer (CuCl) oxidziert bzw. reduziert: Es läuft diese Reaktion ab: 

<big>CuCl2 + Cu → 2 CuCl</big>

Das aktive Kupfer(II)chlorid wird also beim Ätzen "verbraucht". Man kann allerdings das enstandende Kuper(I)chlorid wieder oxidieren. Dazu braucht man einen Oxidator, wie zum Beispiel H2O2, man kann aber auch Luftsauerstoff verwenden. Damit dieser wirken kann, muss er gelöst vorkommen. Somit lautet die Regenerationsformel:

<big>2 HCl + 2 CuCl + O {aq} → 2 CuCl2 + H2O</big> 
bzw. 
<big>6 CuCl + 3 O {aq} + 3 H2O → 2 Cu2(OH)3Cl + 2 CuCl2</big> (im alkalischen)

Das Problem dabei ist, dass sich Sauerstoff nur sehr schlecht in Wasser löst und deshalb diese Reaktion nur sehr langsam abläuft. Man kann die Geschwidigkeit erhöhen, indem man die Oberfläche relativ zum Volumen erhöht. z.B. indem man zum Beispiel Luft, fein verteilt, durch die Brühe pustet.

Wenn man nun beide Gleichungen zusammenfasst erhält man folgende Bilanzgleichung:

<big>Cu + 2 HCl + O → CuCl2 + H2O</big>

In der Bilanz wird also Salzsäure, Sauerstoff und Kupfer verbraucht, es entsteht Kupfer(II)chlorid und Wasser, so dass das Spiel von vorne beginnen kann. Die Ätzbrühe nutzt sich sich also nicht ab, wird aber mit der Zeit immer mehr, da man die verbrauchte Salzsäure ersetzen muss.

Falls während der Regeneration nicht genügend Salzsäure zur Verfügung steht, fällt Kupferoxychlorid Cu2(OH)3Cl aus, welches dann mit Salzsäure gelöst werden kann, so dass in Summe das gleiche passiert.

== Eigenschaften von CuCl / CuCl2 ==

Um die beiden Kupfersalze zu unterscheiden (um z.B das Bad zu troubleshooten bzw. als Hintergrundinfo für die Badpflege) hier noch ein paar wichtige Eigenschaften:
* CuCl2 ist in Wasser gut löslich
* CuCl2 ist bei hoher Chloridionenkonzentration grün (sonst bläulich) und absorbiert bei hohen Konzentrationen Licht relativ stark
* CuCl ist unlöslich in Wasser, jedoch wegen Komplexbildung löslich in Säuren, besonders Salzsäure, sowie Alkalichloridlösungen (z.B. KCl, NaCl)
* CuCl ist dunkel, bräunlich, zusammen mit CuCl2 absorbiert es bereits in kleinen Konzentrationen Licht sehr stark. (Durch 15 mm Ätzlösung mit 1 g/l CuCl kann man kaum mehr durchsehen.)

Hier noch zwei Bilder. Im übrigen sind beide Bilder von hinten mit der selben Taschenlampe beleuchtet.
<gallery>
Datei:CuCl.jpeg|Kupfer(I)chlorid
Datei:CuCl2.jpeg|Kupfer(II)chlorid
</gallery>

== Parameter/Einflussfaktoren beim Ätzen ==

Hier soll ein Überblick auf die Parameter gegeben werden, die die Ätzgeschwindigkeit beinflussen.
(Details findet sich auf [http://home.exetel.com.au/adam.seychell/PCB/etching_CuCl/index.html Adams Seychells] Seite, der hier umfangreiche Analysen gefahren hat. Und [https://www.bastianschmidt.de/etching hier] für die Verwendung von Kaliumchlorid.)

=== Temperatur ===

Wie bei jeder chemischen Reaktion ist die Temperatur ein großer Einflussfaktor: Je wärmer, desto schneller läuft eine Reaktion ab.
Laut Adam Seychell beschleunigen 10°C mehr die Reaktion um etwa 50%.
Allerdings geht es auch bei Raumtemperatur angenehm schnell :)

Auf der anderen Seite erhöht eine Erwärmung das Ausgasen der Salzsäure -- auch darum ist Raumtemperatur voll ok...

=== Konzentation der Salzsäure / des Alkalimetallchlorids ===

Die Kozentration der Salzsäure bzw. des Alkalimetallchlorids beinflusst die folgenden Parameter:
* Ätzgeschwindigkeit -- je mehr Säure desto schneller wird geätzt
* Das Unterätzen -- laut [4] wird das Unterätzen schneller beschleunigt als die Ätzgeschwindigkeit, so das ein höherer Säuregehalt mehr unterätzt.
* Das Ausgasen bei der Verwedung von Salzsäure -- je höher die Konzentration, desto mehr gast aus.

Folglich muss jeder seinen eigenen Kompromiss finden.
ChemCut [4] z.B empfiehlt zwischen 2 und 3 Mol/l, während [3] zwischen 1.3 und 1.4 Mol empfiehlt und Seychell alles zwischen 1 und 3,5 Mol/l gut findet.
(Da ich besonders auf geringes Ausgasen Wert lege ätze ich bei ca. 1,5 mol/l.)
Bei der Verwendung von Kaliumchlorid oder Natriumchlorid statt Salzsäure kann die von ChemCut [4] angegebene Konzentration ohne problematisches Ausgasen erreicht werden. [8] erwähnt eine Konzentration von 2,15 mol/l.

=== Wahl des Komplexbildners ===

Als Komplexbildner um das entstehende CuCl zu lösen, eignen sich Salzsäure oder auch verschiedene Alkalimetallchloridlösungen (KCl, NaCl).
Bei gleicher Konzentration ist die Ätzgeschwindigkeit mit Kaliumchlorid ungefähr doppelt so hoch, wie mit Salzsäure oder Natriumchlorid.

=== Konzentration des Kuper(II)chlorids ===

Sowohl zuwenig als auch zuviel Kupfer(II)chlorid wirkt sich negativ auf die Ätzgeschwindigkeit aus.
Da aber ein Zusammenhang zwischen der Konzentration und der Dichte der Ätzflüssigkeit besteht, kann der zu führende Prozessparameter auch die Dichte sein.

Diese ist auch viel leichter zu ermitteln als die Konzentration des Kupfersalzes.

Alle Quellen [2], [3] und [4] geben als ideale Dichte der Ätzlösung einen Wert von 1,2 - 1,38 g/ml an.
In diesem Bereich hat die Ätzrate ein Plateau, d.h dort sind die Ätzraten in etwa optimal und auch einigermaßen konstant. Kleinere und größere Dichten reduzieren die Ätzraten.
Der angegebene Dichtebereich deckt einen sehr großen größeren Konzentrationsbereich ab. Die Konzentration des Kupfer(II)chlorids spielt für die Ätzgeschwindigkeit eher eine untergeordnete Rolle.

Da die Dichte hauptsächlich durch die Menge an gelösten Kupfer beeinflusst wird, muss
erst mal einiges an Kupfer auflösen bevor man überhaupt diesen Bereich kommt. Wird die Suppe zu dick, kann man sie einfach mit Wasser verdünnen (siehe Badpflege).

=== Konzentration des Kupfer(I)chlorids ===

Während dem Ätzen entsteht Kupfer(I)chlorid, das von der Ätzlösung in Lösung gehalten werden muss.
Es ist praktisch unlöslich in Wasser und löst sich hier durch Komplexbildung mit Sälzsäure oder Alkalimetallchloridlösungen.
Eine Konzentration von 0,4 bis 0,5 mol/l reduziert die Ätzgeschwindigkeit bereits auf die Hälfte im Vergleich zu frischer Ätzlösung ohne Kupfer(I)chlorid.
Sie sollte daher so niedrig wie möglich sein. Dies erreicht man durch frühzeitige Regeneration und Verwendung von genug Ätzlösung für das geplante Vorhaben (siehe [[Ätzen mit luftregenerierten Kupferchlorid#Methoden|Ätzen]]).

= Ätzbrühe erstmalig herstellen =

Wie oben beschrieben braucht man CuCl2 zum Ätzen. Wie kann man nun also dieses Henne-Ei Problem lösen?

Natürlich kann man sich einfach etwas Kupferchlorid kaufen, und das ganze einfach in verdünnter Salzsäure auflösen.
Mir ist allerdings keine Bezugsquelle bekannt die an privat liefern.

Ansonsten kann man auch jemanden bitten, der die Methode bereits einsetzt ihm etwas Ätzbrühe abzugeben.
Immerhin -- wie oben erläutert -- hat ein Vielätzer irgendwann das Problem das er "zu viel" davon hat.

Die dritte Möglichkeit ist selber herstellen.

== Herstellung als "Abfallprodukt" der HCl/H2O2 Methode ==

Wenn mann mit der HCl/H2O2-Methode Platinen ätzt, entsteht dabei Kupferchlorid. Praktisch, denn man kann also sich
eine (kleine) Menge H2O2 besorgen und erstmal mit der herkömmlichen Methode ätzen. In einer [http://www.crcind.com/wwwcrc/tds/TKC3%20POSITIV20.PDF Applikationsschrift von Kontakt Chemie für deren Positiv 20 Lack] wird folgendes Rezept angegeben:

* 770 ml Wasser
* 200 ml Salzsäure (33%)
* 30 ml Wasserstoffperoxid (30%)

Statt der 30% Wasserstoffperoxislösung kann man auch eine geringer dosierte nehmen und dementsprechend weniger Wasser. Zu wenig konzentriert sollte es allerdings auch nicht sein, da man ansonsten zu viel Wasser in die Lösung bekommt, wenn man später H2O2 nachdosiert. Das kann dann Probleme bereiten die optimale Kuferchloridkonzentration zu erreichen.

Allerdings sollte man darauf achten das die Zutaten möglichst rein sind, insbesondere organische Verunreinigungnen können problematisch sein. "Technische Reinheit" sollte aber ausreichend sein.

Damit kann man dann erstmal loslegen und nach dem Ätzen die nun grünliche Flüssigkeit in einem geeigneten Behältnis aufbewahren. Da das H2O2 instabil ist und Sauerstoff abspaltet, darf dieses Behältnis nicht komplett gasdicht sein, also entweder nicht ganz zuschrauben oder ein kleines Loch in den Deckel machen.
Für das nächste Ätzen dosiert man entsprechend Salzsäure nach und gibt bei Bedarf etwas H2O2 zu, so dass die Flüssigkeit durchsichtig wird. (alles CuCl zu CuCl2 umgebaut wurde; "durchsichtig" ist hier als "klar" zu verstehen, als Gegenteil von "trüb". Siehe auch oben bei den Eigenschaften von Kupferchlorid. Das Kupferchlorid schluckt so viel Licht das "durchsichtig" nicht heist das man durchsehen kann).

Hierbei kann man sich schon durchaus am Kapitel "Badpflege" orientieren um herauszufinden wieviel HCl benötigt wird.

Die ganze Prozedure macht man dann so lange bis man sein H2O2 aufgebraucht hat oder man denkt dass man jetzt genügend Kupferchlorid hat. Ich selber habe nur etwa 2-3 Platinen so hergestellt, meine Baddichte war noch kleiner als 1,05 kg/l. Das Ätzen dauert halt dann noch länger.

'''ACHTUNG:''' "Gib nie Wasser in die Säure, sonst geschieht das Ungeheure"! Also immer die Säure in das Wasser kippen, nie umgekehrt!

== Kupferchlorid gezielt herstellen ==

Adam Seychell beschreibt auf seiner Seite [2] wie man sich ganz ohne Wasserstoffperoxid selber genügend Kuperchlorid erzeugen kann:

Um 1l Ätzflüssigkeit anzusetzen gibt man
* 120g Kupfer
* 100ml Salzsäure (25%)
in ein Gefäß, so das das Kupfer größtenteils aus der Säure heraussragt, also Kontakt mit der Säure hat aber nicht komplett bedeckt ist.
Das Metal sollte eine möglichst große Oberfläche haben, also am besten Litzen oder Draht. Das Gefäß muss resistent gegen die Säure sein, insbesondere Metailgefäße sind ungeeignet.
Am besten verwendet man gleich seine angedachte Ätzküvette.

'''ACHTUNG: Bei diesem Ansatz ist sehr viel Säure drin, d.h die Lösung gast viel aus. Salzsäuredämpfe sind sehr korrosiv -- am besten also das Gefäß draussen aufstellen. Aber bitte (haus)tier- und kindersicher!) Bitte beachten dass z.B in einer Garage Sachen in der Nachbargarage korrodieren könnten... Notfalls das Gefäß abdecken und 1-2x am Tag neue Luft reinlassen.''' 
Nach ein paar Tagen sollte die Säuredämpfe gemeinsam mit dem Luftsauerstoff das Kupfer angegriffen haben und die Lösung eine braune Farbe haben, ein Zeichen das Kupfer(I)chlorid entstanden ist.

Wenn die Farbe passt mischt man ''(Reihenfolge beachten -- nur Säure ins Wasser, nie umgekehrt!)''
* 300ml Wasser
* 600ml Salzsäure (25%)
und gibt die Mischung vorsichtig zu der braunen Brühe.

Nun muss man anfangen der Brühe Luft zuzuführen, also das ganze mit dem Sprudler zu durchlüften bis das ganze klar und grün wird,
also das und das restliche Kupfer "aufgefressen" wurde und das Kupfer(I)chlorid zu Kupfer(II)chlorid umgesetzt wurde. Da darduch die Säure verbraucht wird, kann es notwendig sein dass noch welche nachdosiert werden muss (wenn die Lösung braun bleibt und/oder noch Kupfer da ist. Auch hier kann man den Säuregehalt messen und dementsprechend Säure nachgeben.
(Man sollte eh nachdem alles Kupfer weg ist und die Farbe schön grün geworden ist den Säuregehalt messen und eventuell nachdosieren.)

Hier noch als Bildergeschichte... (Zur Dokumentation hab ich nur 100ml angesetzt; Die Zeiten sind nur ungefähr anzusehen)
<gallery>
Datei:CuCl_Herst_1.JPG|12g Kupferlitzen mit 10ml HCl in einem Erlenmeyerkolben
Datei:CuCl_Herst_2.JPG|nach ca. 1 Tagen an der Luft
Datei:CuCl_Herst_3.JPG|wurde die braune Lösung mit ca. 30ml Wasser und ca. 60ml HCl aufgefüllt
Datei:CuCl_Herst_4.JPG|und mit dem Sprudler versehen.
Datei:CuCl_Herst_5.JPG|nach einem weiteren Tag blubbern ist das Kupfer aufgelöst und das CuCl zu CuCl2 umgebaut
Datei:CuCl_Herst_6.JPG|und auch klar geworden (Erlenmeyerkolben von unten beleuchtet)
</gallery>

Adam Seychell empfiehlt hier am Schluss noch auf einen Liter (oder die gewünschte Menge) mit Wasser aufzufüllen. Ich würde dies allerdings nur tun falls die Dichte zu hoch ist, was sicherlich noch nicht der Fall ist.

= Regeneration durch Luftsauerstoff =

== Equipment ==

Wie oben erläutert, benötigt die Regenerationsreaktion Sauerstoff, der aber in Lösung sein muss.
Leider löst sich Sauerstoff nur sehr schlecht in Wasser, so dass man kontinuierlich Sauerstoff dazugeben muss, damit die Reaktion nicht wegen Sauerstoffmangels sehr langsam wird.

Da wir den in der Luft enthaltenen Sauerstoff verwenden wollen, heißt das, dass wir Ätzlösung mit Luft "durchblubbern" müssen, wobei die Luftblasen möglichst klein sein sollten.
Durch die große Oberfläche vieler kleiner Bläschen bekommt der Sauerstoff mehr Gelegenheit, in Lösung zu gehen und sofort mit dem CuCl zu reagieren.

Geeignet hat sich für das Durchlüften ein Keramiksprudelstein erwiesen, wie man sie zum Beispiel auch in der Aquaristik verwendet. Allerdings muss man darauf achten, dass man wirklich einen Ausströmerstein aus Keramik erwischt.
Es gibt auch Sprudelsteine, die aus "verpapptem" Quarzsand hergestellt werden: Diese sind nicht geeignet. Mein Testexemplar hat sich innerhalb von ein paar Tagen "aufgelöst", sodass die kleinste mechanische Belastung zu einem Sandhaufen geführt hat. Man kann es bedingt auch am Preis erkennen: Die keramischen sind etwas teurer -- vielleicht 5€ statt 3€.
Ich habe mir 2 Typen gekauft: Einen [http://www.zoo-kellner.de/ hier ] -- (einem Aquaristikgeschäft bei mir um die Ecke), der sehr feinperlige Blasen erzeugt -- Allerdings wird er dort als aus einem "Sortimentskasten" lose verkauft, ich kann also weder Hersteller noch Produktname nennen. Ein 10cm-Stein kostet dort ca. 4€.
Den Anderen habe ich im Netz gekauft: "Hobby Keramik Ausströmer". Den gibt es in maximal 15cm Länge, weshalb ich ihn gekauft habe. Das Ergebnis is OK, jedoch nicht ganz so "feinperlig" wie der andere. Außerdem musste ich die Enden erst einmal mit Heißkleber abdichten, da dort Luft austrat. Ob dies an mangelhafter Verarbeitung oder am Einfluss der Säure lag, kann ich nicht sagen.

Achja, die Dinger sind empfindlich: Aus Unachtsamkeit sind sie mir in Stücke gebrochen (leasson learned: beim Schlauchanstecken möglichst nahe am Ende -- wo der Schlauch ran soll -- anfassen), jedoch kann man die nach dem Trocknen sehr gut wieder mit Heißkleber zusammenkleben...

Antreiben kann man das Ganze mit einer Aquariumluftpumpe, ich verwende eine Luftpumpe vom Pollin (Best. Nr: [http://www.pollin.de/shop/dt/MzY5OTY2OTk-/Bauelemente_Bauteile/Pumpen/Luftpumpe_CONJOIN_CJP37_C12A2.html 330036]), bei der man dann über die Spannung (Labornetzteil) die Blubberstärke regulieren kann.

Zum Verbinden eignet sich ganz normaler Aquarium-Luftschlauch (ich denke die sind aus weich-PVC).

Da Salzsäure einen geringen Dampfdruck aufweist (also immer etwas ausgast) und diese Dämpfe korrosiv sind, empfehle ich, das gesamte Equipment nochmal in eine extra Plastikbox (mit Deckel und möglichst dicht) zu stellen bzw. dort aufzubewahren. Damit nichts in der Umgebung zu Rosten beginnt.... Ich verwende da eine Box von Ikea (Serie Samla). Die Küvette kann während des Ätzens/Regenerierens auch in der Box verbleiben, so hat man auch gleichzeitig einen Basisschutz gegen Verschütten.

Wenn man etwas geduldig ist, und sowieso nur ab und zu zum Ätzen kommt, kann man problemlos auch einfach ein großes Gefäß (z.B. 5 l Kanister für 1 l Ätzlösung) nehmen, das man ab und zu aufmacht. Nach 1 bis 2 Wochen ist auch so die Ätzlösung regeneriert.

== Regeneration ==

Nun, das ganze Zusammenstecken, am besten im Ätzgefäß fest befestigen und durch die Lösung pusten...
Allerdings empfehle ich das Gefäß irgendwie abzudecken, da durch die Belüftung feine Tröpfchen in die Luft mitgeriessen werden -- ähnlich wie bei einem Glas Sprudel.

= Ätzen =

== Methoden ==

Meiner Meinung ist am besten eine Ätzküvette geeignet: Dort bringt man am besten die Belüftungseinrichtung unter und das Bad wird durch die Belüftung auch gleichzeitig bewegt, was sich positiv auf die Ätzgeschwindigkeit auswirkt:
Das inaktive CuCl wird so möglichst bald wieder aktiviert bzw. durch die Badbewegeung von der Kupferoberfläche weggeführt.

Nicht getestet habe ich das Ätzen in einer Schale. Aber auch dies sollte möglich sein, wenn man das CuCl von der Platine z.B durch Bewegen der Schale immer wieder entfernt -- die Fe(III)Cl-Verwender wissen was ich meine.

Hier kann man das benötigte Volumen wie folgt abschätzen: Angenommen man möchte beim Ätzen nicht mehr als 5 g/l (~ 51 mmol/l)CuCl zulassen -- um eine gute Ätzgeschwindigkeit zu erhalten -- so muss man dafür sorgen dass durch das geätze Kupfer weniger CuCl entsteht: Eine doppelseitige Europakarte mit hat etwa 10g Cu -- entspricht 77 mmol Kupfer bzw. CuCl. Also brauchen wir mindestens 1,5l Volumen damit beim Ätzen diese Konzentration nicht überschritten wird.
Umgerechnet brauchen wir pro cm² zu ätzende Platinefläche minimal 10 ml Ätzflüssigkeit -- in der Praxis aber weniger, da wir nicht alles Kupfer wegätzen.

Diese Mengenabschätzung gilt prinzipiell auch für die Ätzküvette -- allerdings regeneriert man hier gleichzeitig durch die Luftbeweggung, so dass hier auch mit weniger auskommt -- aber in der Regel definiert das Gefäß das Volumen was man braucht.

Prinzipiell sollte diese Methode auch mit Sprühätzern gut funktionieren, man kann sogar erwarten dass durch das Sprühen besonders gut regeneriert wird.

== Materialien ==

Allerding sollte man darauf achten das die verwendeten Materialen den Chemikalien standhält. Hier meine Erfahrungen:

* Expoxidharz: Wurde bei mir spröde, kann aber an damals vorhandenen Restmengen von H2O2 liegen
* Heißkleber: Keine Probleme...
* Bausilikon/Bauacryl: (Als Kleber verwendet; aus der Kartusche) Hält nicht, das Acryl hat sich mehr oder weniger aufgelöst.
* PL (3D-Drucker): Keine Probleme ...
* PP (meine Küvette ist daraus): Keine Probleme ...

[http://www.buerkert.de/media/DE_Bestaendigkeit.pdf Kunststoffbeständigkeit]

= Badpflege / Prozessführung =

Damit das Ätzsystem sauber funktioniert müssen ab und zu ein paar Parameter der Ätze kontrolliert werden und korrigiert werden:

* Zum einen der Säuregehalt (die Säure wird ja beim Regenerieren verbraucht) und
* zum Anderen die Dichte

damit der optimale Bereich nicht überschritten wird.

Vor der Badpflege sollte das CuCl zu CuCl2 umgesetzt worden sein, die Lösung darf also nicht mehr bräunlich sein. Sollte die Lösung während der Regeneration trüb werden (blaugrüner Niederschlag) dann entsteht Kupferoxychlorid und es ist keine freie Salzsäure mehr vorhanden.
Die Regenerationsreaktion läuft trotzdem (etwas verlangsamt) weiter. Man kann sich hier die Titration sparen und so viel Salzsäure zugeben, dass die Lösung klar wird.

== Kontrolle des Salzsäuregehaltes ==

Wie oben erwähnt hat der Säuregehalt Auswirkungen auf die Ätzgeschwindigkeit und auch auf das Ätzergebnis. Schon aus dem Grund der [http://de.wikipedia.org/wiki/Reproduzierbarkeit Reproduzierbarkeit]
sollte man versuchen diesen Parameter konstant zu halten. Allzu genau braucht man hier allerdings nicht sein, das Prozessfenster ist riesig.

Falls man zu hohe Säurekonzentrationen hat, wird man dies in der Regel ignorieren, das sich dieses Problem von selber lösen wird. Man wird nur dann mit Wasser verdünnen, wenn man die Dichte korrigieren muss.

Unten stelle ich zwei Methoden vor: [http://de.wikipedia.org/wiki/Steuerungstechnik#Abgrenzung_zwischen_Steuerung_und_Regelung Regeln bzw. steuern] der Säurekonzentration.

Ich verwende beide Methoden kombiniert um die Säure (einigermaßen) konstant zu halten.

=== Methode 1: Regeln -- Messen des Säuregehaltes durch Titration und Nachdosierung ===

Um herauszufinden wie viel freie Säure noch in der Ätze ist, kann man den pH-Wert zu Rate ziehen. Allerdings wäre es ziemlich kompliziert den pH-Wert direkt zu messen, so dass wir hier einen Trick verwenden:

Wir [http://de.wikipedia.org/wiki/S%C3%A4ure-Base-Titration tritieren] die Ätze so lange mit einer Base bis die Lösung neutral ist und merken uns die Menge an Base die hierzu benötigt wird.
Ein Indikator zeigt uns dann diesen Punkt an. Als Indikator können wir praktischerweise gleich unsere Ätzflüssigkeit verwenden, denn CuCl2 ist nur im Sauren gut löslich...

Als Base bietet sich Natronlauge an, "Belichter" haben die eh zu Hause, "Tonertransferrer" müssen sich halt aus der Apotheke ein paar Gramm besorgen...
Wir verwenden hierbei eine Konzentration von 1mol/l, was später die Konzentrationsermitlung der Säure trivial macht: Man braucht einfach die gleiche Stoffmenge, was sofort klar ist, wenn man auf die Neutralisationsgleichung schaut:

<big>NaOH + HCL -> NaCl + H2O</big>

==== Benötigtes Equipment ====

Wir brauchen für die Säurekontrolle an Hardware:

[[Datei:CuCl Equipment.jpg|miniatur|Equipment]]

* eine kleine (gasdicht verschliessbare, Natronlauge-taugliche) Flasche* -- Apotheken haben die recht günstig. Die Flasche sollte nicht zu groß sein, so 100ml ist meiner Meinung nach ideal.
* eine kleines Becherglas,
* ein paar 2ml Spritzen oder Pipetten mit Skalierung (um Volumen abzumessen),
* ein paar Gramm NaOH. (wie schon oben erwähnt) oder gleich bei der Apotheke anmischen lassen, vor allem wenn keine
* Fein-Waage (optional) vorhanden ist, um das NaOH abzuwiegen.
* destilliertes Wasser (Tipp: Kondenswassertrockner-Wasser ist perfekt!)

Die Flasche sollte eine Dichtung haben, denn CO2 aus der Luft würde die Natronlauge kaputt machen. Deswegen sollte diese Flasche auch nicht zu groß sein.

(* lt. Wikipedia sind Glasflaschen nicht geeignet, sie würden angegriffen.. Ich hatte aber noch nie Probleme damit.)

==== Herstellung der Natronlauge ====

Die Herstellung ist einfach: Mann löst einfach NaOH in (destillierten*) Wasser.

Und zwar nimmt man ca. 4g/100ml**, so dass wir eine '''1,0 molarige Natronlauge''' bekommt.
Das Ganze gibt man in seine Flasche und '''[http://www.seilnacht.com/Chemie/ch_naohl.htm beschriftet]''' diese anständig.

(* Wenn man es in normales Wasser gibt, insbesondere in Gegenden mit harten Wasser, wird die Lauge trüb -- ich nehm mal an das das nicht so vorteilhaft ist...)

(** also 4g abwiegen und mit Wasser auf 100ml auffüllen. Die 4g müssen auch nicht absolut genau sein, die Methodik hier ist eh nicht sooo genau)

==== Durchführung der Titration ====

# Fülle das Becherglas mit 20-30ml Wasser auf.
# Messe mit der Spritze 1ml Ätzflüssigkeit ab und gebe sie in das Becherglas
# Ziehe in einer anderen Spritze* eine definierte Menge Deiner 1,0 molaren NaOH-Lauge auf
# Gib das NaOH tropfenweise in das Becherglas und schwenke es nach jedem Tropen (so dass sich die Schlieren wieder auflösen und die Lösung wieder klar wird)
# Sobald die Lösung NICHT mehr klar werden will ist die Lösung neutralisiert und die Titration fertig.

<gallery>
Datei:CuCl AR Titrat.jpeg|Nach Schritt 2: 1ml Ätzflüssigkeit aufgefüllt mit Wasser
Datei:Titrat NAOH Beleuchtet.jpeg|Schritt 3: Flüssigkeit und aufgezogene Spritze mit NaOH
Datei:Titrat_Tropfen.jpeg|Schritt 4: Dieser Tropfen NaOH hat sich noch nicht aufgelöst
Datei:Titrat_Ende.jpeg|Schritt 5: Die Lösung bleibt trüb -- nichts löst sich mehr. Titration ist zuende.
Datei:Titrat Menge NaOH.jpeg|Dafür haben wir 1.5 ml NaOH benötigt.
</gallery>

Da wir die gleichen Stoffmengen zur Neutralisation brauchen, und die Konzentration der Natronlauge 1molar war, kann man kann man aus dem Volumen der zugegebenen Natronlauge direkt die Konzentration ablesen:
Im Bilderbeispiel wurde 1.5ml Lauge gebraucht um die 1ml der Ätze zu neutralisieren. Die Säurekonzentration ist somit 1,5 molar. Hätten wir 2ml NaOH gebraucht, wäre die Säurekonzentration 2mol/l.

(* Anmerkung: Es ist anzuraten die Spritzen immer nur für die selbe Flüssigkeit zu verwenden, um Kontaminationen insbesondere der NaOH-Lösung zu vermeiden...)

Bilder die das ganze Veranschaulichen findet sich auf Adam Seychell's Seite: http://home.exetel.com.au/adam.seychell/PCB/etching_CuCl/titraion_images.html

==== Berechnung der benötigten Säuremenge ====

Nachdem man ermittelt hat wie groß die Säurekonzentration ist, rechnet man aus, wieviel Säure man hinzugeben muss:

V_Säure = V_Ätze * ( c_soll - c_ist ) / ( c_säure - c_soll)

wobei:
* V_Säure das Volumen der hinzuzufügenfen Salzsäure
* V_Ätze das augenblickliche Volumen der Ätze (wieviel Ätzmittel habe ich schon?)
* c_soll die gewünschte Soll-Säurekonzentration in Mol/l
* c_ist die augenblickliche Säurekonzentration in der Ätze in Mol/l
* c_säure die Säurekonzentration in Mol/l (die dazugegeben werden soll) -- siehe [http://de.wikipedia.org/wiki/Salzs%C3%A4ure Wikipedia-Artikel] für eine Umrechnung %-Mol

Das Libreoffice-Dokument https://www.mikrocontroller.net/wikifiles/6/6e/Hcl-rechner-cucl.ods hat diese Formel als "Konzentrationsrechner Säure" implementiert.

Beispiel:
* V_Ätze: 1 l
* C_ist: 1 Mol/l
* C_soll: 1,5 Mol/l
* C_säure: 7,5 Mol/l
* '''Ergebnis:''' V_Säure: 83 ml

=== Methode 2: Steuern -- Berechnung des Säureverbrauches beim Ätzen ===

Aus der Gleichung oben
:<big>Cu + 2 HCl + O -> CuCl2 + H2O</big>
erkennt man, dass man für das Ätzen von 1 Mol Kupfer 2 Mol Salzsäure benötigt.

Man kann sich also auch die Menge an Salzsäure berechnen, die man für eine Platine benötigt.
Dazu muss man die Stoffmengen ausrechnen, was hier an dem Beispiel einer Europakarte geschehen soll:

* 1 Mol Kupfer sind etwas 65g Metall,
* Eine einseitige Europakarte (mit 35µ Kupferauflage) hat etwa 5g Kupfer. (Gewicht= Volumen*Dichte)
* Da wir aber nicht alles Kupfer wegätzen, z.B also nur 50%, ätzen wir also (5g*50%)/(65g/Mol) = 0,038 Mol Kupfer.
* Da wir 2 mal soviel Stoffmenge an Salzsäure brauchen wie an Kupfer, benötigen wir 0,077 Mol Salzsäure.
* "Übliche" Baumarkt-Salzsäure hat etwa 25%, das entspricht in etwa 7,5 Mol/l.
* Umgerechnet mit unserer Konzentration ist das dann 0,077 Mol/(7,5 Mol/l) ~ 10ml von unserer Salzsäure.

Als Hilfe habe ich dieses Libreoffice-Spreadsheet gemacht:
https://www.mikrocontroller.net/wikifiles/6/6e/Hcl-rechner-cucl.ods
(Dabei einfach die gelben Felder ausfüllen und von den grauen Ablesen.)

=== Methode 3: Verwenden eines Alkalimetallchlorids als Komplexbildner statt freier Salzsäure ===

Ersetzt man die üblicherweise verwendete Salzsäure durch Kaliumchlorid (oder Natriumchlorid), benötigt man keine freie Salzsäure mehr in der Lösung.
Dadurch fällt bei der Regeneration Kupferoxychlorid Cu2(OH)3Cl aus.
Jetzt kann man einfach langsam so viel Salzsäure hinzufügen, dass das Kupferoxychlorid sich gerade auflöst.
Misst man die Menge der dafür nötigen Salzsäure (und kennt deren Konzentration) kann man dadurch auch bestimmen, wie viel Kupfer man geätzt hat (siehe Methode 2) und damit auch, wie viel Kupfer(II)chlorid neu entstanden ist.

Das kann man dann dafür verwenden, um die Konzentration des Alkalimetallchlorids anzupassen.
Bei der in [8] vorgeschlagenen Konzentration ergibt sich die Masse an zuzugebendem Kaliumchlorid als 1,4 mal der Masse der Salzsäure mal deren Konzentration.

== Kontrolle der Dichte ==

Für die Dichte schlägt Adam Seychell ein [http://de.wikipedia.org/wiki/Ar%C3%A4ometer Hydrometer] vor. Nachdem die interessanten Dichtebereiche von vielen Batteriesäuetestern (für Blei Batterien in Autos) abgedeckt werden, kann man die auch normalerweise für wenig Geld kaufen.

Die Dichte braucht man nur ab und zu überprüfen. Denn eine zu hohe Dichte ist gar nicht so einfach zu erreichen. (siehe "Prozessparameter" unten)

=== Berechnung der Dichte aus Volumen und Masse ===

Da bekanntlich Dichte = Masse / Volumen ist, kann man mit einer Feinwaage die Masse eines bestimmten Volumen ermitteln und sich daraus die Dichte errechnen.

Also mit der Spritze z.B. 100 ml abmessen und mit der Waage abwiegen.

<gallery>
Datei:cucl_ar_dichte1.jpg|5x 10ml abgewogen
Datei:cucl_ar_dichte2.jpg|ergeben 59.93g -> Dichte ist 1,20 kg/l
</gallery>

=== Prozessparameter ===

Die optimale Dichte liegt im Bereich von 1,20 kg/l bis 1,38 kg/l.

Wenn die Dichte zu '''klein''' ist, hat man diese beiden Optionen:
* ''' ignorieren''' und Weiterätzen bis die richtige Dichte erreicht wird,
* eindampfen / verdunsten lassen -- was aber wegen der entstehenden Säuredämpfe kein Spass ist, also nicht empfohlen. Alternative kann man auch die Säure verbrauchen (z.B Kupferabfälle reinwerfen).

Wenn man diesen Wert überschreitet, verdünnt man seine Ätze entsprechend mit Wasser. (Berechnungstool im [http://www.mikrocontroller.net/wikifiles/6/6e/Hcl-rechner-cucl.ods Libreoffice-Dokument])

Allerdings wird es schon eine Zeit brauchen bis man die obere Grenze erreicht: Hierzu eine
'''Überschlagsrechnung''' für 1 Liter Ätzflüssigkeit:
* Um die maximale Dichte zu erreichen muss man 380g CuCl2 in Lösung bekommen.
* Dies entspricht ca. 2,8 Mol CuCl2 (CuCl2 hat eine molare Masse von 134 g/Mol)
* Diese CuCl2 ist beim Ätzen von 2,8 * 65 g = ~180 g Kupfer entstanden.
* Um 180g Kuper zu Ätzen wurden 5,6 Mol Salzsäure verbraucht.
* Dies sind bei einer 25%-igen Salzsäure ca. 750ml Volumen,
* wobei dieses 625g Wasser enthält.
* Also haben wir allein durch das Verdünnen des enthaltenen Wassers schon das Volumen auf ca. 1,6l erhöht, was
* wiederum ca. 110g Kupfer (230g CuCl2) aufnehmen kann bis die Dichte wieder kritisch wird.

Diese Überschlagsrechnung macht natürlich ein paar Vernachlässigungen / Fehler, zeigt aber deutlich man sich über Dichte kaum Sorgen machen braucht.

Die Vereinfachungen:
* Die Regenerierung erzeugt auch H20, d.h. aus 1 Mol Hcl werden 0,5 Mol H2O (ca. 9g)
* Das CuCl2 wird nicht im Wasser gelöst und HCl hat eine Dichte >1.
* Es wird angenommen das das Volumen der Lösung nicht ändert, wenn man CuCl2 darin auflöst.

(Der Dichterechner im [http://www.mikrocontroller.net/wikifiles/6/6e/Hcl-rechner-cucl.ods Libreoffice-Dokument] berücksichtigt zuminderst die Dichte der Salzsäure)

= Chemikaliensicherheit & Entsorgung =

Beim Umgang mit Chemikalien sollte die Hinweise im Sicherheitsdatenblatt (MSDS) durchgelesen werden. Die Sicherheitsdatenblätter bekommt man in der Regel vom Hersteller der Chemikalie (Privatanwender haben keinen Anspruch drauf, aber in der Regel gibt es sie im Netz).

Es sollten immer geeignete Persönliche Schutzausrüstungen (PSA) getragen werden. Also immer nur "mit" arbeiten: geeignete Handschuhe, geeignete Schutzbrille und geeignete Kleidung (z.B Kittel) etc...

Beim Arbeiten mit Chemikalien nie essen, trinken oder rauchen. Danach Hände waschen.

Nie Behältnisse die für Lebensmittel gedacht sind für die Aufbewahrung von Chemikalien verwenden.

Alle Chemikalien beschriften

== MSDS (Material Saftey Datasheets)==

Die MSDS sollte also bei seinem Hersteller/Lieferanten bekommen.

Hier noch ein paar Links zur [http://de.wikipedia.org/wiki/GESTIS-Stoffdatenbank GESTIS] für die Stoffe:

* Salzsäure [http://gestis.itrust.de/nxt/gateway.dll/gestis_de/520030.xml?f=templates&fn=default.htm HCl]
* Wasserstoffperoxid [http://gestis.itrust.de/nxt/gateway.dll?f=id$t=default.htm$vid=gestisdeu:sdbdeu$id=002430 H2O2]
* Natriumhydroxid [http://gestis.itrust.de/nxt/gateway.dll/gestis_de/001270.xml?f=templates&fn=default.htm NaOH]
* Kupfer(I)chlorid [http://gestis.itrust.de/nxt/gateway.dll/gestis_de/003280.xml?f=templates&fn=default.htm CuCl]
* Kupfer(II)chlorid [http://gestis.itrust.de/nxt/gateway.dll/gestis_de/002470.xml?f=templates&fn=default.htm CuCl2]

== Entsorgung ==

Chemikalien müssen immer fachgerecht entsorgt werden. Für Privatleute und begrenzten Mengen nimmt in der Regel der Wertstoffhof bzw. das Schadstoffmobil entgegen. Einfach mal bei der Gemeinde nachfragen.
Die Gefäße sollten entsprechend beschriftet werden. Siehe auch hier: http://www.tuf-ev.de/workshop/aetzen/EntsorgungAetzen.htm

'''AUF GAR KEINEN FALL''' darf die Ätzlösung über die Kanalisation entsorgt werden.

= Threads =

Diskussionthread: https://www.mikrocontroller.net/topic/306447

Hier ein paar Links wo das Thema schon mal disktutiert wurde, off topic.. )
https://www.mikrocontroller.net/topic/306023

https://www.mikrocontroller.net/topic/304366

= Externe Links =

[1] Patent RP0178347B1 (abgelaufen) http://www.google.com/patents/EP0178347B1

[2] [http://home.exetel.com.au/adam.seychell/PCB/etching_CuCl/index.html Seite von Adam Seychell]

[3] http://www.iasj.net/iasj?func=fulltext&aId=24599

[4] www.chemcut.net/pdf/Cupric-Chloride.pdf‎

[5] Patent http://www.google.com/patents/EP0048381B1

[6] Technisches Datenblatt HCl von Bayer Science [https://tecci.bayer.de/io-tra-pro/emea/de/docId-2857593/Salzs%C3%A4ure.pdf]

[7] Firmenwerbung? mit Bildern:
http://www.prowet.co.kr/download/board06/120177308463302.pdf

[8] Patent DE2942504A1 https://patents.google.com/patent/DE2942504A1

[9] [https://www.bastianschmidt.de/etching Seite von BastianS] zur Verwendung von Kaliumchlorid statt freier Salzsäure

[[Kategorie:Platinen]]

Umstieg von Arduino auf AVR

2022-09-27T09:50:33Z

172.26.27.242: /* Entfernen der delay()-Aufrufen */

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== Voraussetzungen ==
=== C-Kenntnisse ===
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich nur wärmstens empfehlen, ein C-Buch oder wenigstens ein (gutes) C-Tutorial durchzuarbeiten.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

=== Andere Vorkenntnisse ===
* [[Bitmanipulation]]
* [[Harvard-Architektur]]
* Wissen über [[AVR]] und [[Mikrocontroller]] allgemein kann nicht schaden

=== Software ===
* Compiler: Man sollte entweder die Pfade zu den Executables des avr-gccs in der Arduino-Umgebung zur Umgebungsvariable PATH hinzufügen oder, vor allem wenn man die Arduino-IDE später deinstallieren möchte, eine separate Compiler-Installation vornehmen. Siehe dazu [[AVR-GCC]].
* Ein Terminal-Programm wie Putty oder HTerm kann nie schaden.

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annehmen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum Verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Implementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weitere Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschaltet, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen ''(Darf gerne auch von jemand anderem gemacht werden)''.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

'''Anmerkung:''' Der Compiler mag shiften um Variablen nicht, also das (1 << i). Es ist wesentlich besser, wenn man so etwas schreibt:
<syntaxhighlight lang="c">
uint8_t mask = (1 << 0);
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= mask; // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~mask; // sets the LED on pin off
mask = (mask << 1); // shift the bit to the left
}
</syntaxhighlight>
Das ist erstens schneller und verbraucht zweitens weniger Speicher (im Beispiel nur noch 204 Bytes).

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langem Arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm kompiliert zu bekommen.

=== Das Programm übertragen ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Doch wie bringt man nun den Code auf den AVR? Dazu gibt es unter Anderem zwei Möglichkeiten auf die ich hier eingehen möchte:
* mit extra [[AVR_In_System_Programmer|Programmer/Debugger]]
* mittels dem eingebrannten [[Bootloader]]
Was das ist wird hier nicht erklärt, dafür sind die Artikel verlinkt.

==== Programmer/Debugger ====
Wer schon einen Programmer oder gar Debugger für AVRs sein Eigen nennen kann, der sollte diesen verwenden, da damit noch einmal der Speicherplatz für den Bootloader frei wird (Dadurch kann das Programm noch einmal ~2kB größer werden) und auch die Wartezeit nach jedem Reset entfällt.

Wer noch keinen Programmer hat, der muss sich nicht unbedingt einen solchen kaufen, solange er mit den eben genannten Nachteilen leben kann.

Wer aber jetzt in die Tasche greifen will, der kann sich überlegen, ob er vielleicht nicht lieber direkt einen vollwertigen Debugger kauft. Damit kann man, wie auch am PC, ein laufendes Programm anhalten, Werte von Registern anzeigen, etc. So etwas kann sehr hilfreich sein, wenn "unerklärliche" Phänomene auftreten.

Wie man mit dem Programmer dann schließlich den AVR programmiert hängt wieder von der IDE ab. Beim Atmel Studio wird man sicherlich auf den Programming Dialog zurückgreifen, bei anderen IDEs wird wahrscheinlich ein Drittprogram wie [[AVRDUDE|avrdude]] verwendet.

==== Bootloader ====
Die meisten Arduinos kommen mit einem vorinstalliertem Bootloader. Clones werden auch gerne mal ohne verkauft. Mit dem Bootloader lässt sich der Prozessor auch ohne Programmer über USB direkt flashen.

Also PC-Programm bietet sich dazu [[AVRDUDE|avrdude]] an. Dieses ist ein mehr oder weniger "universales" Brennprogramm für fast alle AVR-Typen. Es beherrscht auch die Kommunikation mit dem Arduino-Bootloader. Damit kann man dann ganz einfach sein Programm übertragen. Die Kommandozeile ist leider je nach Arduino- und Bootloader-Version etwas anderes
<syntaxhighlight lang="bash">
# beim Arduino mega ist es
$ avrdude -cwiring -patmega2560 -P<serial port> -b115200 -U flash:w:<file> -D
# andere Konfigurationen könnten sein (von mir ungetestet, gerne zu Vervollständigen)
$ avrdude -carduino -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
$ avrdude -carduino -patmega328p -P<serial port> -b57600 -U flash:w:<file> -D
$ avrdude -cstk500v2 -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
</syntaxhighlight>

== Arduino-Library Ersatz ==
Nachdem das Minimal-Programm von oben nun auf dem AVR-Board getestet wurde, geht es weiter.

Wir haben uns von Arduino verabschiedet, damit aber auch von allen Arduino-Libraries! Das bedeutet, dass selbst so banale Sachen wie Serial.println() nicht mehr existieren. Diese müssen wir nun selber schreiben.

=== Erstellen eigener Libraries ===
Hier soll nun ein Beispiel mit einer Schritt-für-Schritt-Anleitung gegeben werden. Dazu habe ich mir das UART-Modul ausgesucht.

==== Serielle Kommunikation mittels UART-Hardware ====
Das wird zwar dann die X-te UART library, aber zur Demonstration eignet sich das UART-Modul hervorragend.

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C]]
[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:AVR]]
[[Kategorie:AVR-Boards]]
[[Kategorie:avr-gcc]]
[[Kategorie:Baustelle]]