Mikrocontroller.net - Benutzerbeiträge [de]

Platinensammler

2014-02-25T21:35:12Z

Mox-mox: Noch eine Rechtschreibkorrektur

== Einleitung & Generelles ==
Der Traum eines jeden Elektrotechnik-Hobbyisten ist wohl ein selbst entworfenes PCB.

Oft scheitert eine saubere Realisierung jedoch an der Fertigung der Leiterplatte. Hobbymittel wie die Direkttonermethode führen oft nur zu unzureichend sauberen Ergebnissen, Doppelseitige Platinen sind nur schwer sauber zu realisieren.
Eine vernünftige Ausrüstung zum Belichten ist teuer und so mancher Bastler hat auch schlicht und ergreifend nicht die Möglichkeit zum Umgang mit Entwicklern, Ätzmitteln, usw.

Egal ob man nun die Platinen nicht fertigen kann oder möchte besteht immer die Möglichkeit diese bei den Platinenherstellern (professionell) produzieren zu lassen. Das ist allerdings oft mit nicht unerheblichen Kosten und einem Mindestnutzen verbunden, gerade wenn nur einzelne kleine Platinen benötigt werden.

Aus diesem Grunde biete ich, alias "jakobk", hier im Forum mit meinem Platinensammler die Möglichkeit an, Platinen als Teil einer großen Sammelbestellung (Nutzen) mit zu bestellen.

Diese Bestellung geht immer an einen deutschen Hersteller. Dieser schickt mir auch gut getestete überproduzierte Platinen mit, die ich euch ebenfalls kostenlos "dazu lege".

Mit Beginn 2014 gibt es alle zwei Wochen eine Bestellung. Die Abgabetermine für die Bestellungen der sowie Infos zu ihrem Fertigungsstand finden sich weiter [[Platinensammler#Bestellungen|unten ]] im Artikel. Zu jedem Termin nehme ich 2- und 4-lagige Layouts an und bestelle diese dann so, dass sie nach ca 15 Arbeitstagen bei euch sind.

Um die einzelnen Layouts leichter zuordnen zu können füge ich an geeigneter Stelle eine kleine Kennziffer im Bestückungsdruck oder Stoplack ein. I.d.R. setze ich diese Markierung unter einen IC oder ein andere Bauteil das Sie dann nach dem Bestücken verdeckt.

Der Preis wird abhängig von der im Nutzen benötigten Fläche, und der Lagenzahl berechnet. Denn um die einzelnen Layouts vereinzeln zu können muss ein umlaufender 3mm Fräsgraben zur eigentlichen Leiterkartenkontur zugerechnet werden.

d.h. wenn eine Platine 3 x 2 cm groß ist, wird eine Fläche 3,6 cm x 2,6 cm also 9,36 cm² berechnet.

Näheres zu den Kosten findet Ihr [[Platinensammler#Kosten|hier]]

Wenn Ihr noch Fragen oder Anmerkungen habt schreibt [http://www.mikrocontroller.net/user/show/JakobK mir]

Viel Spass beim Layouten!

Jakob

== Designregeln ==

===Kontur===
Die Platinenkontur kann beinahe beliebige Formen haben.

Allerdings sollte sie so beschaffen sein, dass sie mit einem 2 mm Fräser herstellbar ist und sollte mit einer Strichstärke von 1 MIL oder 0,0254 mm gezeichnet werden.

Darüber hinaus muss eine Platine mindestens eine Seitenlänge mit 10 mm und darf keine Seitenlänge unter 5 mm haben. In der anderen Richtung sollte sie, aus versandtechnischen Gründen in ein A4-Blatt passen.

===Bohrungen===
Der kleinste verfügbare Bohrdurchmesser beträgt 0,3 mm.

===Fräsungen===
Innerhalb der Leiterplatten können Fräsungen beliebiger Form eingebracht werden. Auch diese müssen mit einem 2 mm-Fräser herstellbar sein. Daher sollte man diese in einer eigenen Lage mit einer Strichstärke von min. 2 mm Zeichnen.

Wer z.B. für DC-Buchsen metallisierte Langlöcher haben möchte darf diese mit einem 1 mm-Fräser zeichnen. Um die Metallisierung zu erhalten, muss innerhalb dieser Fräsung zusätzlich eine durchkontaktierte Bohrung platziert werden.

===Leiterbahnstärke===
Grundsätzlich sind Leiterbahnen ab 0,15 mm machbar. Die Mindestabstände im Kupfer liegen ebenfalls bei 0,15 mm.

===Abstand zwischen Kontur und Kupfer===
Zwischen Kupfer und Fräsungen sollte (außer natürlich den Stellen wo Kupfer angefräst werden soll) 0,2 mm betragen und die Hersteller mögen Kupfer anfräsen wegen der höheren Belastung ihrer Fräser nicht so gerne.

===Bestückungsdruck===
Die Leiterplatten werden immer mit beidseitigem Bestückungsdruck bestellt.

Um hier ein möglichst gutes Ergebnis zu erhalten sollte man darauf achten, dass die minimale Strichstärke nicht unter 0,15mm geht und man sollte den Bestückungsdruck natürlich "aufräumen" ;-)

Normalerweise gehören Bauteilkonturen und -Referenzen sowie Informationstexte wie z.B. Platinenbezeichnung, Pinbelegung usw. (letztere sind auch im Kupfer oder Stoplack nicht unüblich).

Bei der Datenübername entferne ich sicherheitshalber den Bestückungsdruck von etwaigen Pads.

Daher übernehme ich beim Datenexport aus Eagle z.B. nur die Layer tPlace und tNames sowie bPlace und bNames in den Bestückungsdruck. Also müßt ihr bitte darauf achten, dass in diesen Layern nichts ist, was ihr nicht auf der Platine haben wollt. Umgekehrt gilt natürlich, dass alles was ihr auf der Platine haben wollt auch in diesen Layern sein muss.

Bitte denkt bei euren Layouts daran, denn auf Anmerkungen die eine andere Zusammensetzung des Bestückungsdrucks wünschen kann ich nicht eingehen.

== Fertigungsparameter des Nutzen ==

Die im Rahmen der Platinensammlung bestellten Nutzen werden mit 35µm/35µm (2-Lagig) bzw. 18µm/35µm/35µm/18µm Kupfer (4-Lagig), auf FR4, mit E-Test, HAL-Verzinnung (RoHS), Stoplack und Bestückungsdruck auf beiden Seiten bestellt.

Um die einzelnen Layouts später leichter zuordnen zu können, bekommt Jedes an geeigneter Stelle eine kleine 4stellige Referenz. In der Regel so, dass sie nach dem Bestücken nicht mehr sichtbar oder möglichst unauffällig ist.

Es ist nicht mehr nötig einen Platzhalter zu setzen, da die Suche hiernach oft länger dauert als eine geeignete Stelle zu finden.

In den Bestückungsdruck werden Gehäusekonturen und Referenzen übernommen. Also muss alles was später im Bestückungsdruck landen soll in die entsprechenden Layer gelegt werden.

Für den Bestückungsdruck sollten die gleichen Regeln bzgl. der Strichstärke und Abstände eingehalten werden, um ein sauberes Druckbild zu erhalten.

Wer keinen Bestückungsdruck haben möchte, löscht die entsprechenden Inhalte am besten aus dem abgegebenen Datensatz. Normaler Weise reicht auch der Hinweis im Bestellformular, aber was gar nicht erst abgegeben wird kann auch nicht versehentlich auf der Platine landen.

Allerdings beeinflußt der Verzicht auf den Bestückungsdruck den Preis nicht.

== Kosten ==
Der Preis für Platinen im Sammelnutzen hängt natürlich von der im Nutzen verwendeten Fläche (also Platinengröße + Fräsrand) sowie der Lagenzahl ab.

Ab 2014 kostet der cm² im 2-lagigen Nutzen 0,40€/cm² und im 4-lagigen Nutzen 0,70€/cm². Anders als bisher gibt es ab 2014 immer alle Überproduzierten ohne Mehrkosten dazu.

Unabhängig von der Anzahl gleicher Platinen eines Layouts, wird für jedes Layout eine Bearbeitungsgebühr von 5,00€ berechnet.

Für die gesamte Bestellung kommen dann noch Porto und Versandkosten von 2,50€/Sendung für Versand im Luftpolsterumschlag innerhalb Deutschlands bzw. 4,50€/Sendung für Versand in die EU und die Schweiz.

Anmerkung:
Die genaue Kontur der Platine spielt für den Preis keine Rolle. Es wird immer das überdeckende Rechteck berechnet.

=== Beispielrechnung für ein 3 cm x 2 cm großes Layout ===
Benötigte Nutzenfläche pro Platine A = (3,0cm + 0,6cm) * (2,0cm + 0,6cm) = 9,36cm². Damit liegt der Preis pro Platine dieses Layouts bei 
{| class="wikitable"
|-
! Lagenzahl !! Preis
|-
| 2 || 3,74€/Stk
|-
| 4 || 6,55€/Stk
|-
|}

Mit den 5,00€ Bearbeitungsgebühr pro Layout ergeben sich die folgenden Gesamtkosten:

2-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 3,74€ || 7,48€ || 11,22€ || 14,96€ || 18,70€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 8,74€ || 12,48€ || 16,22€ || 19,96€ || 23,70€
|-
| Preis pro Platine gleichen Layouts || 8,74€ || 6,24€ || 5,41€ || 4,99€ || 4,74€
|-
|}
+ Porto und Versand

4-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 6,55€ || 13,10€ || 19,65€ || 26,20€ || 32,75€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 11,55€ || 18,10€ || 24,65€ || 31,20€ || 37,75€
|-
| Preis pro Platine gleichen Layouts || 11,55€ || 9,05€ || 8,22€ || 7,80€ || 7,55€
|-
|}
+ Porto und Versand

== Zahlungsarten ==
Grundsätzlich lege ich den Platinen einfach eine Rechnung bei, die dann bitte zeitnah zu begleichen ist.

Gerade für Bestellungen aus dem Ausland kann es auf Grund von hohen Überweisungskosten auch interessant sein per Paypal zu bezahlen. Das ist auch kein Problem, aber dann müßt ihr das bitte im Bestellformular unter Anmerkungen angeben und die zusätzlichen Gebühren (0,35€/Zahlung + 1,9% des ursprünglichen Rechnungswertes) kommen noch mit auf die Rechnung.

== Bestellablauf ==
Die geprüften Layoutdaten (*.dru File siehe Designregeln oder hier http://www.mikrocontroller.net/attachment/132705/platinensammler_02.dru ) schickt ihr dann bitte zusammen mit dem ausgefüllten Bestellformular ( http://www.mikrocontroller.net/attachment/199133/Bestellformular_v4.txt ) an ''' platinensammler(at)gmail.com '''

Bitte beachtet, dass ich nur vollständige Bestellungspakete
berücksichten kann (auch die Wiederbesteller bitte). Außerdem solltet
ihr mir bitte keine "Schnellschüsse" mit "Schönheitsfehlern schicken,
die ihr dann noch drei mal bis zum Stichtag nachbessert.

Wenn sich jemand nicht sicher ist, ob sein Layout produzierbar ist,
schaue ich gerne vorab unverbindlich drüber. Gerade bei Layoutneulingen kann das
schon mal ganz nützlich sein, um grobe Fehler zu vermeiden und um ggf.
Unsicherheit entgegen zu wirken.

Sobald ich die Daten geprüft und in den Nutzen übernommen habe,
bestätige ich die Bestellung per Mail. In dieser Mail steht dann eure
Adresse sowie Anzahl, Größe und Kosten eurer Platinen. Wenn ich nichts
von euch höre gehe ich davon aus, dass ich eure Bestellung richtig
übernommen habe. (Auch wenn ich mich über eine kurze Bestätigung freue)

Normaler Weise lege ich den Abgabetermin auf den letzten Werktag vor einem Wochenende. Wer bis zum Abgabetermin keine Auftragsbestätigung hat, sollte sich bei mir melden.

Wenn ein produzierter Nutzen bei mir ist, drösel ich den auseinander und gebe die Teilbestellungen zusammen mit den Rechnungen in die Post.

== Dateiformate ==
Ihr könnt mir eure Layoutdaten in den folgenden Formaten mailen.
* Eagle brd-file
* KiCad brd-file (alte .brd und neue .kicad_pcb)
* SPrint
* RS-274-X (Extended Gerber) / Excellon

=== Eagle ===
Wer Eagle hat, kann mit gerne direkt das BRD-File seines Layouts schicken. Wer auch noch einen kurzen 4-Augencheck haben möchte, sollte bitte auch das SCH-File mit schicken.

Allerdings habe ich zu Eagle noch einen besonderen Hinweis:

Wenn man aus Eagle die Gerberdaten exportiert, wird der Schrifttyp IMMER
in Vector umgewandelt.

Leider verändert das nicht nur das "Aussehen" sondern auch die Größe.

Für Schriften im Bestückungsdruck bedeutet dass, das ein ordentlich
aufgräumter Bestückungsdruck halt nicht mehr ganz so aufgeräumt ist.

Wenn man nun aber (wie ja nicht unüblich) Layoutname und Versionsstand
o.ä. im Kupfer hat und dicht an der Schrift mit Leiterbahnen vorbei
geht, kann diese Veränderung zu Kurzschlüssen führen die weder beim
Designcheck, noch beim E-Test auffallen.

Am Besten gebt ihr in der Konsole (bzw. Befehlszeile) von Eagle "set
vector_font on" (ohne die "") ein.

Dann wandelt schon der Brd-Editor alle Texte in Vector um und ihr seht
auch wirklich das, was später hinten raus fällt.

Da mir das schon ein ganzes Stück Arbeit erspart, währe ich euch dankbar
wenn ihr dies in Zukunft "unerinnert" berücksichten würdet.

=== KiCad ===
Ich versuche immer auf dem aktuellsten Stand von KiCad zu sein und kann daher sowohl die alten (*.brd) , als auch die neunen *.kicad_pcb) KiCad-Layouts weiter verarbeiten.

=== Sprint-Layout===
Es ist auch möglich Sprint-Layouts direkt zu bestellen.

=== Gerberfiles===
Bei den Extended Gerber und Excellon Daten müssen eure Daten die folgenden Endungen für die Lagenzuordnung haben:
{| class="wikitable"
|-
! Lagenbezeichnung !! Datentyp !! Datenformat !! Dateiendung
|-
| Kuntur / Fräsungen || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L00
|-
| Bestückungsdruck Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L01
|-
| Lötstoplack Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L02
|-
| Kupfer Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L03
|-
| Kupfer untere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L04
|-
| Kupfer obere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L05
|-
| Kupfer Oberseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L06
|-
| Lötstoplack Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L07
|-
| Bestückungsdruck Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L08
|-
| durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.DK
|-
| nicht durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.NDK
|}

== FAQ ==
* '''Was sind überproduzierte Platinen?''' - Bei der Leiterplattenherstellung werden in der Regel 2-3 mal so viele Platinen, wie eigentlich bestellt, in die Produktion gegeben. So muss der Hersteller den Herstellungsprozess nicht komplett neu beginnen, falls es zu fertigungsfehlern kommt. Treten diese Fehler nicht oder nicht im erwarteten Umfang auf, so werden mehr Platinen gefertigt als eigentlich bestellt. Diesen Überhang bezeichnet man als Überproduktion.
 
* '''Sind auch "buried vias", "blind vias" möglich?''' - Es sind leider keine ''buried vias'' oder ''blind vias'' möglich
 
* '''Ist eine Lieferung in die Schweiz möglich?''' - Kein Problem (Siehe Verpackung und Versand)
 
* '''Gibt es eine Mindestgröße für ein Layout?''' - Ja die gibt es. Die Mindestmaße für Platinen sind mindestens eine Seite 10 mm, keine Seite unter 5 mm und Mindestfläche 1 cm².
 
* '''Gibt es eine Maximalgröße für ein Layout?''' - Die maximale Größe hänt natürlich in erster Linie von der Fertigungsnutzengröße des Herstellers ab. Diese variiert von Hersteller zu hersteller, ist aber wenigstens ca 300x400mm groß. Allerdings muss ich die Platinen ja anschließend noch verschicken können. Also sollten eure Layouts irgendwie in ein A4-Blatt passen.
 
* '''Bekomme ich eine Rechnung?''' - Ja, zusammen mit den Platinen bekommt ihr eine Rechnung, die auch die MwSt. ausweist.
 
* '''Verringert sich der gewählte Bohrdurchmesser bei metallisierten Löchern um die Beschichtungsdicke?''' - Nein, der Bohrdurchmesser wird vom Hersteller auf seinen Prozess hin korregiert, so dass die im Layout gewählten Bohrdurchmesser auch die Enddurchmesser sind.
 
* '''In welchen Schritten kann ich Bohrdurchmesser wählen?''' - Die Bohrer können in 0,1mm-Schritten gewählt werden.
 
* '''Ist eine Auslandslieferung möglich?''' - Ich verschicke die Platinen auch ins Ausland. Da die Portokosten hierfür steigen, wird der Versand entsprechend teurer. Außerdem fällt für Sendungen in die Schweiz oder andere nicht EU Länder keine Mehrwertsteuer an.
 
* '''Wie klein darf/kann der Bestückungsdruck werden?''' - Ich habe mal eine Schablone mit vorstellbaren Kombinationen machen lassen, um diese Frage möglichst gut beantworten zu können.
[[Datei:SilkSchablone.png|rahmenlos|zentriert|Bild von Platine mit Bestückungsdruck mit verschiedenen Parametern]] Wie man sehen kann, kommt es darauf an, ob man nur eine einzelne Linie, komplexere Strukturen oder Texte gedruckt haben möchte. Bei einfachen Linien kann man bis 50µm Strichstärke runter. Aber der Abstand zwischen den Linien sollte wenigstens 100µm betragen. Was die Lesbarkeit kommt es da natürlich auch auf euer Sehvermögen an. Für mich wäre eine Schrifthöhe von 0,6mm mit einer Strichstärke von ca. 50µm (8% von 0,6mm sind ja 48µm) grade eben die Unterkannte.
 
* '''Gibt es Einschränkungen bezüglich der Form einer Platine (rund, eckig, Auschnitte)?''' - Grundsätzlich gilt, dass die Konturen mit einem 2mm Fräser herstellbar sein müssen.
 
* '''Wie berechnet sich der Preis für nicht Rechteckige Platinen oder Platinen mit Ausfräsungen?''' - Es wird immer das überdeckende Rechteck berechnet.
 
* '''Kann ich "Löcher" in der berechneten Fläche mit passenden Layouts füllen?''' - Das ist kein Problem. Du mußt nur darauf achten, dass der "Lückenfüller" mit genügend 1mm Stegen mit der eigentlichen Platine verbunden ist und der Abstand zwischen den Platinen sonst wenigstens 2mm beträgt.
 
* '''Muss ich das verwendete DRC-File bei der Bestellung mit abgeben?''' - Nein, das ist nicht nötig da die zuletzt verwendeten Designregeln im BRD-File enthalten sind.
 
* '''Welche mindestmaße gelten für den Lötstoplack?''' - Für den Lötstoplack gelten die gleichen Vorgaben wie für den Bestückungsdruck.
 
* '''Wie viel Abstand sollte der Löststoplack von Pads haben?''' - Ich würde da zu ca 100µm raten, aber ich habe das nicht getestet.
 
* '''Gibt es eine Möglichkeit sich die Exportierten Gerbedaten anzusehen?''' - In der Regel klappt das mit GerbV (das ja auch im KiCad-Paket enthalten ist). Wenn da mal was "merkwürdiges" zu sehen ist, solltet Ihr aber nicht zu viel Zeit ins "Debugging" schieben. Ich sehe mir eure Plots (genau wie Layouts allgemein) auch gerne im Vorfeld bzw. bei der Bestellung an.
 
* '''Kann ich auch abweichend formatierte Gerber/Excellon-Daten abgeben?''' - Inzwischen habe ich einigermaßen Übung im Dateninterpretieren. Daher könnt Ihr es gerne auf den Versuch ankommen lassen. Bisher hat es noch immer irgendwie geklappt. Die von mir angegebene Formatierung macht mir das Datenhandling nur einfacher ;-)
 
Noch eine neue Frage? Dann schickt sie [http://www.mikrocontroller.net/user/show/JakobK mir.]

== Bestellungen ==
{| class="wikitable"
|-
! Nutzen !! Lagenzahl !! Status !! Liefertermin !! Update
|-
| 2014-0001|| 2/4 || versandt || 2014/02/03 || 2014/01/30
|-
| 2014-0002|| 2/4 || versandt|| 2014/02/17 || 2014/02/09
|-
| 2014-0003|| 2/4 || in Produktion || 2014/03/03 || 2014/02/09
|-
| 2014-0004|| 2/4 || läuft bis 28.2. || 2014/24/03 || 2014/02/09
|-
|}

== Links ==
* http://www.mikrocontroller.net/topic/245590 (30ct)
* http://www.mikrocontroller.net/topic/273018 (60ct)
* http://www.mikrocontroller.net/topic/245595 (Feedback)
* http://www.mikrocontroller.net/topic/245594 (FAQ)
* http://www.mikrocontroller.net/topic/245594#2696432 (FAQ: EAGLE Hohlsteckerbuchsen)
* http://www.mikrocontroller.net/articles/Platinenhersteller
* http://www.platinensammler.de/

[[Kategorie:Platinen]]
[[Kategorie:Lieferanten]]

Platinensammler

2014-02-25T21:32:44Z

Mox-mox: Rechtschreibfehler

== Einleitung & Generelles ==
Der Traum eines jeden Elektrotechnik-Hobbyisten ist wohl ein selbst entworfenes PCB.

Oft scheitert eine saubere Realisierung jedoch an der Fertigung der Leiterplatte. Hobbymittel wie die Direkttonermethode führen oft nur zu unzureichend sauberen Ergebnissen, Doppelseitige Platinen sind nur schwer sauber zu realisieren.
Eine vernünftige Ausrüstung zum Belichten ist teuer und so mancher Bastler hat auch schlicht und ergreifend nicht die Möglichkeit zum Umgang mit Entwicklern, Ätzmitteln, usw.

Egal ob man nun die Platinen nicht fertigen kann oder möchte besteht immer die Möglichkeit diese bei den Platinenherstellern (professionell) produzieren zu lassen. Das ist allerdings oft mit nicht unerheblichen Kosten und einem Mindestnutzen verbunden, gerade wenn nur einzelne kleine Platinen benötigt werden.

Aus diesem Grunde biete ich, alias "jakobk", hier im Forum mit meinem Platinensammler die Möglichkeit an, Platinen als Teil einer großen Sammelbestellung (Nutzen) mit zu bestellen.

Diese Bestellung geht immer an einen deutschen Hersteller. Dieser schickt mir auch gut getestete überproduzierte Platinen mit, die ich euch ebenfalls kostenlos "dazu lege".

Mit Beginn 2014 gibt es alle zwei Wochen eine Bestellung. Die Abgabetermine für die Bestellungen der sowie Infos zu ihrem Fertigungsstand finden sich weiter [[Platinensammler#Bestellungen|unten ]] im Artikel. Zu jedem Termin nehme ich 2- und 4-lagige Layouts an und bestelle diese dann so, dass sie nach ca 15 Arbeitstagen bei euch sind.

Um die einzelnen Layouts leichter zuordnen zu können füge ich an geeigneter Stelle eine kleine Kennziffer im Bestückungsdruck oder Stoplack ein. I.d.R. setze ich diese Markierung unter einen IC oder ein andere Bauteil das Sie dann nach dem Bestücken verdeckt.

Der Preis wird abhängig von der im Nutzen benötigten Fläche, und der Lagenzahl berechnet. Denn um die einzelnen Layouts vereinzeln zu können muss ein umlaufender 3mm Fräsgraben zur eigentlichen Leiterkartenkontur zugerechnet werden.

d.h. wenn eine Platine 3 x 2 cm groß ist, wird eine Fläche 3,6 cm x 2,6 cm also 9,36 cm² berechnet.

Näheres zu den Kosten findet Ihr [[Platinensammler#Kosten|hier]]

Wenn Ihr noch Fragen oder Anmerkungen habt schreibt [http://www.mikrocontroller.net/user/show/JakobK mir]

Viel Spass beim Layouten!

Jakob

== Designregeln ==

===Kontur===
Die Platinenkontur kann beinahe beliebige Formen haben.

Allerdings sollte sie so beschaffen sein, dass sie mit einem 2 mm Fräser herstellbar ist und sollte mit einer Strichstärke von 1 MIL oder 0,0254 mm gezeichnet werden.

Darüber hinaus muss eine Platine mindestens eine Seitenlänge mit 10 mm und darf keine Seitenlänge unter 5 mm haben. In der anderen Richtung sollte sie, aus versandtechnischen Gründen in ein A4-Blatt passen.

===Bohrungen===
Der kleinste verfügbare Bohrdurchmesser beträgt 0,3 mm.

===Fräsungen===
Innerhalb der Leiterplatten können Fräsungen beliebiger Form eingebracht werden. Auch diese müssen mit einem 2 mm-Fräser herstellbar sein. Daher sollte man diese in einer eigenen Lage mit einer Strichstärke von min. 2 mm Zeichnen.

Wer z.B. für DC-Buchsen metallisierte Langlöcher haben möchte darf diese mit einem 1 mm-Fräser zeichnen. Um die Metallisierung zu erhalten, muss innerhalb dieser Fräsung zusätzlich eine durchkontaktierte Bohrung platziert werden.

===Leiterbahnstärke===
Grundsätzlich sind Leiterbahnen ab 0,15 mm machbar. Die Mindestabstände im Kupfer liegen ebenfalls bei 0,15 mm.

===Abstand zwischen Kontur und Kupfer===
Zwischen Kupfer und Fräsungen sollte (außer natürlich den Stellen wo Kupfer angefräst werden soll) 0,2 mm betragen und die Hersteller mögen Kupfer anfräsen wegen der höheren Belastung ihrer Fräser nicht so gerne.

===Bestückungsdruck===
Die Leiterplatten werden immer mit beidseitigem Bestückungsdruck bestellt.

Um hier ein möglichst gutes Ergebnis zu erhalten sollte man darauf achten, dass die minimale Strichstärke nicht unter 0,15mm geht und man sollte den Bestückungsdruck natürlich "aufräumen" ;-)

Normalerweise gehören Bauteilkonturen und -Referenzen sowie Informationstexte wie z.B. Platinenbezeichnung, Pinbelegung usw. (letztere sind auch im Kupfer oder Stoplack nicht unüblich).

Bei der Datenübername entferne ich sicherheitshalber den Bestückungsdruck von etwaigen Pads.

Daher übernehme ich beim Datenexport aus Eagle z.B. nur die Layer tPlace und tNames sowie bPlace und bNames in den Bestückungsdruck. Also müßt ihr bitte darauf achten, dass in diesen Layern nichts ist, was ihr nicht auf der Platine haben wollt. Umgekehrt gilt natürlich, dass alles was ihr auf der Platine haben wollt auch in diesen Layern sein muss.

Bitte denkt bei euren Layouts daran, denn auf Anmerkungen die eine andere Zusammensetzung des Bestückungsdrucks wünschen kann ich nicht eingehen.

== Fertigungsparameter des Nutzen ==

Die im Rahmen der Platinensammlung bestellten Nutzen werden mit 35µm/35µm (2-Lagig) bzw. 18µm/35µm/35µm/18µm Kupfer (4-Lagig), auf FR4, mit E-Test, HAL-Verzinnung (RoHS), Stoplack und Bestückungsdruck auf beiden Seiten bestellt.

Um die einzelnen Layouts später leichter zuordnen zu können, bekommt Jedes an geeigneter Stelle eine kleine 4stellige Referenz. In der Regel so, dass sie nach dem Bestücken nicht mehr sichtbar oder möglichst unauffällig ist.

Es ist nicht mehr nötig einen Platzhalter zu setzen, da die Suche hiernach oft länger dauert als eine geeignete Stelle zu finden.

In den Bestückungsdruck werden Gehäusekonturen und Referenzen übernommen. Also muss alles was später im Bestückungsdruck landen soll in die entsprechenden Layer gelegt werden.

Für den Bestückungsdruck sollten die gleichen Regeln bzgl. der Strichstärke und Abstände eingehalten werden, um ein sauberes Druckbild zu erhalten.

Wer keinen Bestückungsdruck haben möchte, löscht die entsprechenden Inhalte am besten aus dem abgegebenen Datensatz. Normaler Weise reicht auch der Hinweis im Bestellformular, aber was gar nicht erst abgegeben wird kann auch nicht versehentlich auf der Platine landen.

Allerdings beeinflußt der Verzicht auf den Bestückungsdruck den Preis nicht.

== Kosten ==
Der Preis für Platinen im Sammelnutzen hängt natürlich von der im Nutzen verwendeten Fläche (also Platinengröße + Fräsrand) sowie der Lagenzahl ab.

Ab 2014 kostet der cm² im 2-lagigen Nutzen 0,40€/cm² und im 4-lagigen Nutzen 0,70€/cm². Anders als bisher gibt es ab 2014 immer alle Überproduzierten ohne Mehrkosten dazu.

Unabhängig von der Anzahl gleicher Platinen eines Layouts, wird für jedes Layout eine Bearbeitungsgebühr von 5,00€ berechnet.

Für die gesamte Bestellung kommen dann noch Porto und Versandkosten von 2,50€/Sendung für Versand im Luftpolsterumschlag innerhalb Deutschlands bzw. 4,50€/Sendung für Versand in die EU und die Schweiz.

Anmerkung:
Die genaue Kontur der Platine spielt für den Preis keine Rolle. Es wird immer das überdeckende Rechteck berechnet.

=== Beispielrechnung für ein 3 cm x 2 cm großes Layout ===
Benötigte Nutzenfläche pro Platine A = (3,0cm + 0,6cm) * (2,0cm + 0,6cm) = 9,36cm². Damit liegt der Preis pro Platine dieses Layouts bei 
{| class="wikitable"
|-
! Lagenzahl !! Preis
|-
| 2 || 3,74€/Stk
|-
| 4 || 6,55€/Stk
|-
|}

Mit den 5,00€ Bearbeitungsgebühr pro Layout ergeben sich die folgenden Gesamtkosten:

2-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 3,74€ || 7,48€ || 11,22€ || 14,96€ || 18,70€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 8,74€ || 12,48€ || 16,22€ || 19,96€ || 23,70€
|-
| Preis pro Platine gleichen Layouts || 8,74€ || 6,24€ || 5,41€ || 4,99€ || 4,74€
|-
|}
+ Porto und Versand

4-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 6,55€ || 13,10€ || 19,65€ || 26,20€ || 32,75€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 11,55€ || 18,10€ || 24,65€ || 31,20€ || 37,75€
|-
| Preis pro Platine gleichen Layouts || 11,55€ || 9,05€ || 8,22€ || 7,80€ || 7,55€
|-
|}
+ Porto und Versand

== Zahlungsarten ==
Grundsätzlich lege ich den Platinen einfach eine Rechnung bei, die dann bitte zeitnah zu begleichen ist.

Gerade für Bestellungen aus dem Ausland kann es auf Grund von hohen Überweisungskosten auch interessant sein per Paypal zu bezahlen. Das ist auch kein Problem, aber dann müßt ihr das bitte im Bestellformular unter Anmerkungen angeben und die zusätzlichen Gebühren (0,35€/Zahlung + 1,9% des ursprünglichen Rechnungswertes) kommen noch mit auf die Rechnung.

== Bestellablauf ==
Die geprüften Layoutdaten (*.dru File siehe Designregeln oder hier http://www.mikrocontroller.net/attachment/132705/platinensammler_02.dru ) schickt ihr dann bitte zusammen mit dem ausgefüllten Bestellformular ( http://www.mikrocontroller.net/attachment/199133/Bestellformular_v4.txt ) an ''' platinensammler(at)gmail.com '''

Bitte beachtet, dass ich nur vollständige Bestellungspakete
berücksichten kann (auch die Wiederbesteller bitte). Außerdem solltet
ihr mir bitte keine "Schnellschüsse" mit "Schönheitsfehlern schicken,
die ihr dann noch drei mal bis zum Stichtag nachbessert.

Wenn sich jemand nicht sicher ist, ob sein Layout produzierbar ist,
schaue ich gerne vorab unverbindlich drüber. Gerade bei Layoutneulingen kann das
schon mal ganz nützlich sein, um grobe Fehler zu vermeiden und um ggf.
Unsicherheit entgegen zu wirken.

Sobald ich die Daten geprüft und in den Nutzen übernommen habe,
bestätige ich die Bestellung per Mail. In dieser Mail steht dann eure
Adresse sowie Anzahl, Größe und Kosten eurer Platinen. Wenn ich nichts
von euch höre gehe ich davon aus, dass ich eure Bestellung richtig
übernommen habe. (Auch wenn ich mich über eine kurze Bestätigung freue)

Normaler Weise lege ich den Abgabetermin auf den letzten Werktag vor einem Wochenende. Wer bis zum Abgabetermin keine Auftragsbestätigung hat, sollte sich bei mir melden.

Wenn ein produzierter Nutzen bei mir ist, drösel ich den auseinander und gebe die Teilbestellungen zusammen mit den Rechnungen in die Post.

== Dateiformate ==
Ihr könnt mir eure Layoutdaten in den folgenden Formaten mailen.
* Eagle brd-file
* KiCad brd-file (alte .brd und neue .kicad_pcb)
* SPrint
* RS-274-X (Extended Gerber) / Excellon

=== Eagle ===
Wer Eagle hat, kann mit gerne direkt das BRD-File seines Layouts schicken. Wer auch noch einen kurzen 4-Augencheck haben möchte, sollte bitte auch das SCH-File mit schicken.

Allerdings habe ich zu Eagle noch einen besonderen Hinweis:

Wenn man aus Eagle die Gerberdaten exportiert, wird der Schrifttyp IMMER
in Vector umgewandelt.

Leider verändert das nicht nur das "Aussehen" sondern auch die Größe.

Für Schriften im Bestückungsdruck bedeutet dass, das ein ordentlich
aufgräumter Bestückungsdruck halt nicht mehr ganz so aufgeräumt ist.

Wenn man nun aber (wie ja nicht unüblich) Layoutname und Versionsstand
o.ä. im Kupfer hat und dicht an der Schrift mit Leiterbahnen vorbei
geht, kann diese Veränderung zu Kurzschlüssen führen die weder beim
Designcheck, noch beim E-Test auffallen.

Am Besten gebt ihr in der Konsole (bzw. Befehlszeile) von Eagle "set
vector_font on" (ohne die "") ein.

Dann wandelt schon der Brd-Editor alle Texte in Vector um und ihr seht
auch wirklich das, was später hinten raus fällt.

Da mir das schon ein ganzes Stück Arbeit erspart, währe ich euch Dankbar
wenn ihr dies in Zukunft "unerinnert" berücksichten würdet.

=== KiCad ===
Ich versuche immer auf dem aktuellsten Stand von KiCad zu sein und kann daher sowohl die alten (*.brd) , als auch die neunen *.kicad_pcb) KiCad-Layouts weiter verarbeiten.

=== Sprint-Layout===
Es ist auch möglich Sprint-Layouts direkt zu bestellen.

=== Gerberfiles===
Bei den Extended Gerber und Excellon Daten müssen eure Daten die folgenden Endungen für die Lagenzuordnung haben:
{| class="wikitable"
|-
! Lagenbezeichnung !! Datentyp !! Datenformat !! Dateiendung
|-
| Kuntur / Fräsungen || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L00
|-
| Bestückungsdruck Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L01
|-
| Lötstoplack Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L02
|-
| Kupfer Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L03
|-
| Kupfer untere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L04
|-
| Kupfer obere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L05
|-
| Kupfer Oberseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L06
|-
| Lötstoplack Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L07
|-
| Bestückungsdruck Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L08
|-
| durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.DK
|-
| nicht durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.NDK
|}

== FAQ ==
* '''Was sind überproduzierte Platinen?''' - Bei der Leiterplattenherstellung werden in der Regel 2-3 mal so viele Platinen, wie eigentlich bestellt, in die Produktion gegeben. So muss der Hersteller den Herstellungsprozess nicht komplett neu beginnen, falls es zu fertigungsfehlern kommt. Treten diese Fehler nicht oder nicht im erwarteten Umfang auf, so werden mehr Platinen gefertigt als eigentlich bestellt. Diesen Überhang bezeichnet man als Überproduktion.
 
* '''Sind auch "buried vias", "blind vias" möglich?''' - Es sind leider keine ''buried vias'' oder ''blind vias'' möglich
 
* '''Ist eine Lieferung in die Schweiz möglich?''' - Kein Problem (Siehe Verpackung und Versand)
 
* '''Gibt es eine Mindestgröße für ein Layout?''' - Ja die gibt es. Die Mindestmaße für Platinen sind mindestens eine Seite 10 mm, keine Seite unter 5 mm und Mindestfläche 1 cm².
 
* '''Gibt es eine Maximalgröße für ein Layout?''' - Die maximale Größe hänt natürlich in erster Linie von der Fertigungsnutzengröße des Herstellers ab. Diese variiert von Hersteller zu hersteller, ist aber wenigstens ca 300x400mm groß. Allerdings muss ich die Platinen ja anschließend noch verschicken können. Also sollten eure Layouts irgendwie in ein A4-Blatt passen.
 
* '''Bekomme ich eine Rechnung?''' - Ja, zusammen mit den Platinen bekommt ihr eine Rechnung, die auch die MwSt. ausweist.
 
* '''Verringert sich der gewählte Bohrdurchmesser bei metallisierten Löchern um die Beschichtungsdicke?''' - Nein, der Bohrdurchmesser wird vom Hersteller auf seinen Prozess hin korregiert, so dass die im Layout gewählten Bohrdurchmesser auch die Enddurchmesser sind.
 
* '''In welchen Schritten kann ich Bohrdurchmesser wählen?''' - Die Bohrer können in 0,1mm-Schritten gewählt werden.
 
* '''Ist eine Auslandslieferung möglich?''' - Ich verschicke die Platinen auch ins Ausland. Da die Portokosten hierfür steigen, wird der Versand entsprechend teurer. Außerdem fällt für Sendungen in die Schweiz oder andere nicht EU Länder keine Mehrwertsteuer an.
 
* '''Wie klein darf/kann der Bestückungsdruck werden?''' - Ich habe mal eine Schablone mit vorstellbaren Kombinationen machen lassen, um diese Frage möglichst gut beantworten zu können.
[[Datei:SilkSchablone.png|rahmenlos|zentriert|Bild von Platine mit Bestückungsdruck mit verschiedenen Parametern]] Wie man sehen kann, kommt es darauf an, ob man nur eine einzelne Linie, komplexere Strukturen oder Texte gedruckt haben möchte. Bei einfachen Linien kann man bis 50µm Strichstärke runter. Aber der Abstand zwischen den Linien sollte wenigstens 100µm betragen. Was die Lesbarkeit kommt es da natürlich auch auf euer Sehvermögen an. Für mich wäre eine Schrifthöhe von 0,6mm mit einer Strichstärke von ca. 50µm (8% von 0,6mm sind ja 48µm) grade eben die Unterkannte.
 
* '''Gibt es Einschränkungen bezüglich der Form einer Platine (rund, eckig, Auschnitte)?''' - Grundsätzlich gilt, dass die Konturen mit einem 2mm Fräser herstellbar sein müssen.
 
* '''Wie berechnet sich der Preis für nicht Rechteckige Platinen oder Platinen mit Ausfräsungen?''' - Es wird immer das überdeckende Rechteck berechnet.
 
* '''Kann ich "Löcher" in der berechneten Fläche mit passenden Layouts füllen?''' - Das ist kein Problem. Du mußt nur darauf achten, dass der "Lückenfüller" mit genügend 1mm Stegen mit der eigentlichen Platine verbunden ist und der Abstand zwischen den Platinen sonst wenigstens 2mm beträgt.
 
* '''Muss ich das verwendete DRC-File bei der Bestellung mit abgeben?''' - Nein, das ist nicht nötig da die zuletzt verwendeten Designregeln im BRD-File enthalten sind.
 
* '''Welche mindestmaße gelten für den Lötstoplack?''' - Für den Lötstoplack gelten die gleichen Vorgaben wie für den Bestückungsdruck.
 
* '''Wie viel Abstand sollte der Löststoplack von Pads haben?''' - Ich würde da zu ca 100µm raten, aber ich habe das nicht getestet.
 
* '''Gibt es eine Möglichkeit sich die Exportierten Gerbedaten anzusehen?''' - In der Regel klappt das mit GerbV (das ja auch im KiCad-Paket enthalten ist). Wenn da mal was "merkwürdiges" zu sehen ist, solltet Ihr aber nicht zu viel Zeit ins "Debugging" schieben. Ich sehe mir eure Plots (genau wie Layouts allgemein) auch gerne im Vorfeld bzw. bei der Bestellung an.
 
* '''Kann ich auch abweichend formatierte Gerber/Excellon-Daten abgeben?''' - Inzwischen habe ich einigermaßen Übung im Dateninterpretieren. Daher könnt Ihr es gerne auf den Versuch ankommen lassen. Bisher hat es noch immer irgendwie geklappt. Die von mir angegebene Formatierung macht mir das Datenhandling nur einfacher ;-)
 
Noch eine neue Frage? Dann schickt sie [http://www.mikrocontroller.net/user/show/JakobK mir.]

== Bestellungen ==
{| class="wikitable"
|-
! Nutzen !! Lagenzahl !! Status !! Liefertermin !! Update
|-
| 2014-0001|| 2/4 || versandt || 2014/02/03 || 2014/01/30
|-
| 2014-0002|| 2/4 || versandt|| 2014/02/17 || 2014/02/09
|-
| 2014-0003|| 2/4 || in Produktion || 2014/03/03 || 2014/02/09
|-
| 2014-0004|| 2/4 || läuft bis 28.2. || 2014/24/03 || 2014/02/09
|-
|}

== Links ==
* http://www.mikrocontroller.net/topic/245590 (30ct)
* http://www.mikrocontroller.net/topic/273018 (60ct)
* http://www.mikrocontroller.net/topic/245595 (Feedback)
* http://www.mikrocontroller.net/topic/245594 (FAQ)
* http://www.mikrocontroller.net/topic/245594#2696432 (FAQ: EAGLE Hohlsteckerbuchsen)
* http://www.mikrocontroller.net/articles/Platinenhersteller
* http://www.platinensammler.de/

[[Kategorie:Platinen]]
[[Kategorie:Lieferanten]]

Platinensammler

2014-02-25T21:07:31Z

Mox-mox: Rechtschreibfehler korrigiert

== Einleitung & Generelles ==
Der Traum eines jeden Elektrotechnik-Hobbyisten ist wohl ein selbst entworfenes PCB.

Oft scheitert eine saubere Realisierung jedoch an der Fertigung der Leiterplatte. Hobbymittel wie die Direkttonermethode führen oft nur zu unzureichend sauberen Ergebnissen, Doppelseitige Platinen sind nur schwer sauber zu realisieren.
Eine vernünftige Ausrüstung zum Belichten ist teuer und so mancher Bastler hat auch schlicht und ergreifend nicht die Möglichkeit zum Umgang mit Entwicklern, Ätzmitteln, usw.

Egal ob man nun die Platinen nicht fertigen kann oder möchte besteht immer die Möglichkeit diese bei den Platinenherstellern (professionell) produzieren zu lassen. Das ist allerdings oft mit nicht unerheblichen Kosten und einem Mindestnutzen verbunden, gerade wenn nur einzelne kleine Platinen benötigt werden.

Aus diesem Grunde biete ich, alias "jakobk", hier im Forum mit meinem Platinensammler die Möglichkeit an, Platinen als Teil einer großen Sammelbestellung (Nutzen) mit zu bestellen.

Diese Bestellung geht immer an einen deutschen Hersteller. Dieser schickt mir auch gut getestete überproduzierte Platinen mit, die ich euch ebenfalls kostenlos "dazu lege".

Mit Beginn 2014 gibt es alle zwei Wochen eine Bestellung. Die Abgabetermine für die Bestellungen der sowie Infos zu ihrem Fertigungsstand finden sich weiter [[Platinensammler#Bestellungen|unten ]] im Artikel. Zu jedem Termin nehme ich 2- und 4-lagige Layouts an und bestelle diese dann so, dass sie nach ca 15 Arbeitstagen bei euch sind.

Um die einzelnen Layouts leichter zuordnen zu können füge ich an geeigneter Stelle eine kleine Kennziffer im Bestückungsdruck oder Stoplack ein. I.d.R. setze ich diese Markierung unter einen IC oder ein andere Bauteil das Sie dann nach dem Bestücken verdeckt.

Der Preis wird abhängig von der im Nutzen benötigten Fläche, und der Lagenzahl berechnet. Denn um die einzelnen Layouts vereinzeln zu können muss ein umlaufender 3mm Fräsgraben zur eigentlichen Leiterkartenkontur zugerechnet werden.

d.h. wenn eine Platine 3 x 2 cm groß ist, wird eine Fläche 3,6 cm x 2,6 cm also 9,36 cm² berechnet.

Näheres zu den Kosten findet Ihr [[Platinensammler#Kosten|hier]]

Wenn Ihr noch Fragen oder Anmerkungen habt schreibt [http://www.mikrocontroller.net/user/show/JakobK mir]

Viel Spass beim Layouten!

Jakob

== Designregeln ==

===Kontur===
Die Platinenkontur kann beinahe beliebige Formen haben.

Allerdings sollte sie so beschaffen sein, dass sie mit einem 2 mm Fräser herstellbar ist und sollte mit einer Strichstärke von 1 MIL oder 0,0254 mm gezeichnet werden.

Darüber hinaus muss eine Platine mindestens eine Seitenlänge mit 10 mm und darf keine Seitenlänge unter 5 mm haben. In der anderen Richtung sollte sie, aus versandtechnischen Gründen in ein A4-Blatt passen.

===Bohrungen===
Der kleinste verfügbare Bohrdurchmesser beträgt 0,3 mm.

===Fräsungen===
Innerhalb der Leiterplatten können Fräsungen beliebiger Form eingebracht werden. Auch diese müssen mit einem 2 mm-Fräser herstellbar sein. Daher sollte man diese in einer eigenen Lage mit einer Strichstärke von min. 2 mm Zeichnen.

Wer z.B. für DC-Buchsen metallisierte Langlöcher haben möchte darf diese mit einem 1 mm-Fräser zeichnen. Um die Metallisierung zu erhalten, muss innerhalb dieser Fräsung zusätzlich eine durchkontaktierte Bohrung platziert werden.

===Leiterbahnstärke===
Grundsätzlich sind Leiterbahnen ab 0,15 mm machbar. Die Mindestabstände im Kupfer liegen ebenfalls bei 0,15 mm.

===Abstand zwischen Kontur und Kupfer===
Zwischen Kupfer und Fräsungen sollte (außer natürlich den Stellen wo Kupfer angefräst werden soll) 0,2 mm betragen und die Hersteller mögen Kupfer anfräsen wegen der höheren Belastung ihrer Fräser nicht so gerne.

===Bestückungsdruck===
Die Leiterplatten werden immer mit beidseitigem Bestückungsdruck bestellt.

Um hier ein möglichst gutes Ergebnis zu erhalten sollte man darauf achten, dass die minimale Strichstärke nicht unter 0,15mm geht und man sollte den Bestückungsdruck natürlich "aufräumen" ;-)

Normalerweise gehören Bauteilkonturen und -Referenzen sowie Informationstexte wie z.B. Platinenbezeichnung, Pinbelegung usw. (letztere sind auch im Kupfer oder Stoplack nicht unüblich).

Bei der Datenübername entferne ich sicherheitshalber den Bestückungsdruck von etwaigen Pads.

Daher übernehme ich beim Datenexport aus Eagle z.B. nur die Layer tPlace und tNames sowie bPlace und bNames in den Bestückungsdruck. Also müßt ihr bitte darauf achten, dass in diesen Layern nichts ist, was ihr nicht auf der Platine haben wollt. Umgekehrt gilt natürlich, dass alles was ihr auf der Platine haben wollt auch in diesen Layern sein muss.

Bitte denkt bei euren Layouts daran, denn auf Anmerkungen die eine andere Zusammensetzung des Bestückungsdrucks wünschen kann ich nicht eingehen.

== Fertigungsparameter des Nutzen ==

Die im Rahmen der Platinensammlung bestellten Nutzen werden mit 35µm/35µm (2-Lagig) bzw. 18µm/35µm/35µm/18µm Kupfer (4-Lagig), auf FR4, mit E-Test, HAL-Verzinnung (RoHS), Stoplack und Bestückungsdruck auf beiden Seiten bestellt.

Um die einzelnen Layouts später leichter zuordnen zu können, bekommt Jedes an geeigneter Stelle eine kleine 4stellige Referenz. In der Regel so, dass sie nach dem Bestücken nicht mehr sichtbar oder möglichst unauffällig ist.

Es ist nicht mehr nötig einen Platzhalter zu setzen, da die suche hiernach oft länger dauert als eine geeignete Stelle zu finden.

In den Bestückungsdruck werden Gehäusekonturen und Referenzen übernommen. Also muss alles was später im Bestückungsdruck landen soll in die entsprechenden Layer gelegt werden.

Für den Bestückungsdruck sollten die gleichen Regeln bzgl. der Strichstärke und Abstände eingehalten werden, um ein sauberes Druckbild zu erhalten.

Wer keinen Bestückungsdruck haben möchte, löscht die entsprechenden Inhalte am besten aus dem abgegebenen Datensatz. Normaler Weise reicht auch der Hinweis im Bestellformular, aber was gar nicht erst abgegeben wird kann auch nicht versehentlich auf der Platine landen.

Allerdings beeinflußt der Verzicht auf den Bestückungsdruck den Preis nicht.

== Kosten ==
Der Preis für Platinen im Sammelnutzen hängt natürlich von der im Nutzen verwendeten Fläche (also Platinengröße + Fräsrand) sowie der Lagenzahl ab.

Ab 2014 kostet der cm² im 2-lagigen Nutzen 0,40€/cm² und im 4-lagigen Nutzen 0,70€/cm². Anders als bisher gibt es ab 2014 immer alle Überproduzierten ohne Mehrkosten dazu.

Unabhängig von der Anzahl gleicher Platinen eines Layouts, wird für jedes Layout eine Bearbeitungsgebühr von 5,00€ berechnet.

Für die gesamte Bestellung kommen dann noch Porto und Versandkosten von 2,50€/Sendung für Versand im Luftpolsterumschlag innerhalb Deutschlands bzw. 4,50€/Sendung für Versand in die EU und die Schweiz.

Anmerkung:
Die genaue Kontur der Platine spielt für den Preis keine Rolle. Es wird immer das überdeckende Rechteck berechnet.

=== Beispielrechnung für ein 3 cm x 2 cm großes Layout ===
Benötigte Nutzenfläche pro Platine A = (3,0cm + 0,6cm) * (2,0cm + 0,6cm) = 9,36cm². Damit liegt der Preis pro Platine dieses Layouts bei 
{| class="wikitable"
|-
! Lagenzahl !! Preis
|-
| 2 || 3,74€/Stk
|-
| 4 || 6,55€/Stk
|-
|}

Mit den 5,00€ Bearbeitungsgebühr pro Layout ergeben sich die folgenden Gesamtkosten:

2-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 3,74€ || 7,48€ || 11,22€ || 14,96€ || 18,70€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 8,74€ || 12,48€ || 16,22€ || 19,96€ || 23,70€
|-
| Preis pro Platine gleichen Layouts || 8,74€ || 6,24€ || 5,41€ || 4,99€ || 4,74€
|-
|}
+ Porto und Versand

4-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 6,55€ || 13,10€ || 19,65€ || 26,20€ || 32,75€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 11,55€ || 18,10€ || 24,65€ || 31,20€ || 37,75€
|-
| Preis pro Platine gleichen Layouts || 11,55€ || 9,05€ || 8,22€ || 7,80€ || 7,55€
|-
|}
+ Porto und Versand

== Zahlungsarten ==
Grundsätzlich lege ich den Platinen einfach eine Rechnung bei, die dann bitte zeitnah zu begleichen ist.

Gerade für Bestellungen aus dem Ausland kann es auf Grund von hohen Überweisungskosten auch interessant sein per Paypal zu bezahlen. Das ist auch kein Problem, aber dann müßt ihr das bitte im Bestellformular unter Anmerkungen angeben und die zusätzlichen Gebühren (0,35€/Zahlung + 1,9% des ursprünglichen Rechnungswertes) kommen noch mit auf die Rechnung.

== Bestellablauf ==
Die geprüften Layoutdaten (*.dru File siehe Designregeln oder hier http://www.mikrocontroller.net/attachment/132705/platinensammler_02.dru ) schickt ihr dann bitte zusammen mit dem ausgefüllten Bestellformular ( http://www.mikrocontroller.net/attachment/199133/Bestellformular_v4.txt ) an ''' platinensammler(at)gmail.com '''

Bitte beachtet, dass ich nur vollständige Bestellungspakete
berücksichten kann (auch die Wiederbesteller bitte). Außerdem solltet
ihr mir bitte keine "Schnellschüsse" mit "Schönheitsfehlern schicken,
die ihr dann noch drei mal bis zum Stichtag nachbessert.

Wenn sich jemand nicht sicher ist, ob sein Layout produzierbar ist,
schaue ich gerne vorab unverbindlich drüber. Gerade bei Layoutneulingen kann das
schon mal ganz nützlich sein, um grobe Fehler zu vermeiden und um ggf.
Unsicherheit entgegen zu wirken.

Sobald ich die Daten geprüft und in den Nutzen übernommen habe,
bestätige ich die Bestellung per Mail. In dieser Mail steht dann eure
Adresse sowie Anzahl, Größe und Kosten eurer Platinen. Wenn ich nichts
von euch höre gehe ich davon aus, dass ich eure Bestellung richtig
übernommen habe. (Auch wenn ich mich über eine kurze Bestätigung freue)

Normaler Weise lege ich den Abgabetermin auf den letzten Werktag vor einem Wochenende. Wer bis zum Abgabetermin keine Auftragsbestätigung hat, sollte sich bei mir melden.

Wenn ein produzierter Nutzen bei mir ist, drösel ich den auseinander und gebe die Teilbestellungen zusammen mit den Rechnungen in die Post.

== Dateiformate ==
Ihr könnt mir eure Layoutdaten in den folgenden Formaten mailen.
* Eagle brd-file
* KiCad brd-file (alte .brd und neue .kicad_pcb)
* SPrint
* RS-274-X (Extended Gerber) / Excellon

=== Eagle ===
Wer Eagle hat, kann mit gerne direkt das BRD-File seines Layouts schicken. Wer auch noch einen kurzen 4-Augencheck haben möchte, sollte bitte auch das SCH-File mit schicken.

Allerdings habe ich zu Eagle noch einen besonderen Hinweis:

Wenn man aus Eagle die Gerberdaten exportiert, wird der Schrifttyp IMMER
in Vector umgewandelt.

Leider verändert das nicht nur das "Aussehen" sondern auch die Größe.

Für Schriften im Bestückungsdruck bedeutet dass, das ein ordentlich
aufgräumter Bestückungsdruck halt nicht mehr ganz so aufgeräumt ist.

Wenn man nun aber (wie ja nicht unüblich) Layoutname und Versionsstand
o.ä. im Kupfer hat und dicht an der Schrift mit Leiterbahnen vorbei
geht, kann diese Veränderung zu Kurzschlüssen führen die weder beim
Designcheck, noch beim E-Test auffallen.

Am Besten gebt ihr in der Konsole (bzw. Befehlszeile) von Eagle "set
vector_font on" (ohne die "") ein.

Dann wandelt schon der Brd-Editor alle Texte in Vector um und ihr seht
auch wirklich das, was später hinten raus fällt.

Da mir das schon ein ganzes Stück Arbeit erspart, währe ich euch Dankbar
wenn ihr dies in Zukunft "unerinnert" berücksichten würdet.

=== KiCad ===
Ich versuche immer auf dem aktuellsten Stand von KiCad zu sein und kann daher sowohl die alten (*.brd) , als auch die neunen *.kicad_pcb) KiCad-Layouts weiter verarbeiten.

=== Sprint-Layout===
Es ist auch möglich Sprint-Layouts direkt zu bestellen.

=== Gerberfiles===
Bei den Extended Gerber und Excellon Daten müssen eure Daten die folgenden Endungen für die Lagenzuordnung haben:
{| class="wikitable"
|-
! Lagenbezeichnung !! Datentyp !! Datenformat !! Dateiendung
|-
| Kuntur / Fräsungen || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L00
|-
| Bestückungsdruck Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L01
|-
| Lötstoplack Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L02
|-
| Kupfer Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L03
|-
| Kupfer untere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L04
|-
| Kupfer obere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L05
|-
| Kupfer Oberseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L06
|-
| Lötstoplack Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L07
|-
| Bestückungsdruck Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L08
|-
| durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.DK
|-
| nicht durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.NDK
|}

== FAQ ==
* '''Was sind überproduzierte Platinen?''' - Bei der Leiterplattenherstellung werden in der Regel 2-3 mal so viele Platinen, wie eigentlich bestellt, in die Produktion gegeben. So muss der Hersteller den Herstellungsprozess nicht komplett neu beginnen, falls es zu fertigungsfehlern kommt. Treten diese Fehler nicht oder nicht im erwarteten Umfang auf, so werden mehr Platinen gefertigt als eigentlich bestellt. Diesen Überhang bezeichnet man als Überproduktion.
 
* '''Sind auch "buried vias", "blind vias" möglich?''' - Es sind leider keine ''buried vias'' oder ''blind vias'' möglich
 
* '''Ist eine Lieferung in die Schweiz möglich?''' - Kein Problem (Siehe Verpackung und Versand)
 
* '''Gibt es eine Mindestgröße für ein Layout?''' - Ja die gibt es. Die Mindestmaße für Platinen sind mindestens eine Seite 10 mm, keine Seite unter 5 mm und Mindestfläche 1 cm².
 
* '''Gibt es eine Maximalgröße für ein Layout?''' - Die maximale Größe hänt natürlich in erster Linie von der Fertigungsnutzengröße des Herstellers ab. Diese variiert von Hersteller zu hersteller, ist aber wenigstens ca 300x400mm groß. Allerdings muss ich die Platinen ja anschließend noch verschicken können. Also sollten eure Layouts irgendwie in ein A4-Blatt passen.
 
* '''Bekomme ich eine Rechnung?''' - Ja, zusammen mit den Platinen bekommt ihr eine Rechnung, die auch die MwSt. ausweist.
 
* '''Verringert sich der gewählte Bohrdurchmesser bei metallisierten Löchern um die Beschichtungsdicke?''' - Nein, der Bohrdurchmesser wird vom Hersteller auf seinen Prozess hin korregiert, so dass die im Layout gewählten Bohrdurchmesser auch die Enddurchmesser sind.
 
* '''In welchen Schritten kann ich Bohrdurchmesser wählen?''' - Die Bohrer können in 0,1mm-Schritten gewählt werden.
 
* '''Ist eine Auslandslieferung möglich?''' - Ich verschicke die Platinen auch ins Ausland. Da die Portokosten hierfür steigen, wird der Versand entsprechend teurer. Außerdem fällt für Sendungen in die Schweiz oder andere nicht EU Länder keine Mehrwertsteuer an.
 
* '''Wie klein darf/kann der Bestückungsdruck werden?''' - Ich habe mal eine Schablone mit vorstellbaren Kombinationen machen lassen, um diese Frage möglichst gut beantworten zu können.
[[Datei:SilkSchablone.png|rahmenlos|zentriert|Bild von Platine mit Bestückungsdruck mit verschiedenen Parametern]] Wie man sehen kann, kommt es darauf an, ob man nur eine einzelne Linie, komplexere Strukturen oder Texte gedruckt haben möchte. Bei einfachen Linien kann man bis 50µm Strichstärke runter. Aber der Abstand zwischen den Linien sollte wenigstens 100µm betragen. Was die Lesbarkeit kommt es da natürlich auch auf euer Sehvermögen an. Für mich wäre eine Schrifthöhe von 0,6mm mit einer Strichstärke von ca. 50µm (8% von 0,6mm sind ja 48µm) grade eben die Unterkannte.
 
* '''Gibt es Einschränkungen bezüglich der Form einer Platine (rund, eckig, Auschnitte)?''' - Grundsätzlich gilt, dass die Konturen mit einem 2mm Fräser herstellbar sein müssen.
 
* '''Wie berechnet sich der Preis für nicht Rechteckige Platinen oder Platinen mit Ausfräsungen?''' - Es wird immer das überdeckende Rechteck berechnet.
 
* '''Kann ich "Löcher" in der berechneten Fläche mit passenden Layouts füllen?''' - Das ist kein Problem. Du mußt nur darauf achten, dass der "Lückenfüller" mit genügend 1mm Stegen mit der eigentlichen Platine verbunden ist und der Abstand zwischen den Platinen sonst wenigstens 2mm beträgt.
 
* '''Muss ich das verwendete DRC-File bei der Bestellung mit abgeben?''' - Nein, das ist nicht nötig da die zuletzt verwendeten Designregeln im BRD-File enthalten sind.
 
* '''Welche mindestmaße gelten für den Lötstoplack?''' - Für den Lötstoplack gelten die gleichen Vorgaben wie für den Bestückungsdruck.
 
* '''Wie viel Abstand sollte der Löststoplack von Pads haben?''' - Ich würde da zu ca 100µm raten, aber ich habe das nicht getestet.
 
* '''Gibt es eine Möglichkeit sich die Exportierten Gerbedaten anzusehen?''' - In der Regel klappt das mit GerbV (das ja auch im KiCad-Paket enthalten ist). Wenn da mal was "merkwürdiges" zu sehen ist, solltet Ihr aber nicht zu viel Zeit ins "Debugging" schieben. Ich sehe mir eure Plots (genau wie Layouts allgemein) auch gerne im Vorfeld bzw. bei der Bestellung an.
 
* '''Kann ich auch abweichend formatierte Gerber/Excellon-Daten abgeben?''' - Inzwischen habe ich einigermaßen Übung im Dateninterpretieren. Daher könnt Ihr es gerne auf den Versuch ankommen lassen. Bisher hat es noch immer irgendwie geklappt. Die von mir angegebene Formatierung macht mir das Datenhandling nur einfacher ;-)
 
Noch eine neue Frage? Dann schickt sie [http://www.mikrocontroller.net/user/show/JakobK mir.]

== Bestellungen ==
{| class="wikitable"
|-
! Nutzen !! Lagenzahl !! Status !! Liefertermin !! Update
|-
| 2014-0001|| 2/4 || versandt || 2014/02/03 || 2014/01/30
|-
| 2014-0002|| 2/4 || versandt|| 2014/02/17 || 2014/02/09
|-
| 2014-0003|| 2/4 || in Produktion || 2014/03/03 || 2014/02/09
|-
| 2014-0004|| 2/4 || läuft bis 28.2. || 2014/24/03 || 2014/02/09
|-
|}

== Links ==
* http://www.mikrocontroller.net/topic/245590 (30ct)
* http://www.mikrocontroller.net/topic/273018 (60ct)
* http://www.mikrocontroller.net/topic/245595 (Feedback)
* http://www.mikrocontroller.net/topic/245594 (FAQ)
* http://www.mikrocontroller.net/topic/245594#2696432 (FAQ: EAGLE Hohlsteckerbuchsen)
* http://www.mikrocontroller.net/articles/Platinenhersteller
* http://www.platinensammler.de/

[[Kategorie:Platinen]]
[[Kategorie:Lieferanten]]

Platinensammler

2014-02-23T02:07:40Z

Mox-mox: Leerzeile eingefügt um Formatierung einheitlich zu halten

== Einleitung & Generelles ==
Der Traum eines jeden Elektrotechnik-Hobbyisten ist wohl ein selbst entworfenes PCB.

Oft scheitert eine saubere Realisierung jedoch an der Fertigung der Leiterplatte. Hobbymittel wie die Direkttonermethode führen oft nur zu unzureichend sauberen Ergebnissen, Doppelseitige Platinen sind nur schwer sauber zu realisieren.
Eine vernünftige Ausrüstung zum Belichten ist teuer und so mancher Bastler hat auch schlicht und ergreifend nicht die Möglichkeit zum Umgang mit Entwicklern, Ätzmitteln, usw.

Egal ob man nun die Platinen nicht fertigen kann oder möchte besteht immer die Möglichkeit diese bei den Platinenherstellern (professionell) produzieren zu lassen. Das ist allerdings oft mit nicht unerheblichen Kosten und einem Mindestnutzen verbunden, gerade wenn nur einzelne kleine Platinen benötigt werden.

Aus diesem Grunde biete ich, alias "jakobk", hier im Forum mit meinem Platinensammler die Möglichkeit an, Platinen als Teil einer großen Sammelbestellung (Nutzen) mit zu bestellen.

Diese Bestellung geht immer an einen deutschen Hersteller. Dieser schickt mir auch gut getestete überproduzierte Platinen mit, die ich euch ebenfalls kostenlos "dazu lege".

Mit Beginn 2014 gibt es alle zwei Wochen eine Bestellung. Die Abgabetermine für die Bestellungen der sowie Infos zu ihrem Fertigungsstand finden sich weiter [[Platinensammler#Bestellungen|unten ]] im Artikel. Zu jedem Termin nehme ich 2- und 4-lagige Layouts an und bestelle diese dann so, dass sie nach ca 15 Arbeitstagen bei euch sind.

Um die einzelnen Layouts leichter zuordnen zu können füge ich an geeigneter Stelle eine kleine Kennziffer im Bestückungsdruck oder Stoplack ein. I.d.R. setze ich diese Markierung unter einen IC oder ein andere Bauteil das Sie dann nach dem Bestücken verdeckt.

Der Preis wird abhängig von der im Nutzen benötigten Fläche, und der Lagenzahl berechnet. Denn um die einzelnen Layouts vereinzeln zu können muss ein umlaufender 3mm Fräsgraben zur eigentlichen Leiterkartenkontur zugerechnet werden.

d.h. wenn eine Platine 3 x 2 cm groß ist, wird eine Fläche 3,6 cm x 2,6 cm also 9,36 cm² berechnet.

Näheres zu den Kosten findet Ihr [[Platinensammler#Kosten|hier]]

Wenn Ihr noch Fragen oder Anmerkungen habt schreibt [http://www.mikrocontroller.net/user/show/JakobK mir]

Viel Spass beim Layouten!

Jakob

== Designregeln ==

===Kontur===
Die Platinenkontur kann beinahe beliebige Formen haben.

Allerdings sollte sie so beschaffen sein, dass sie mit einem 2 mm Fräser herstellbar ist und sollte mit einer Strichstärke von 1 MIL oder 0,0254 mm gezeichnet werden.

Darüber hinaus muss eine Platine mindestens eine Seitenlänge mit 10 mm und darf keine Seitenlänge unter 5 mm haben. In der anderen Richtung sollte sie, aus versandtechnischen Gründen in ein A4-Blatt passen.

===Bohrungen===
Der kleinste verfügbare Bohrdurchmesser beträgt 0,3 mm.

===Fräsungen===
Innerhalb der Leiterplatten können Fräsungen beliebiger Form eingebracht werden. Auch diese müssen mit einem 2 mm-Fräser herstellbar sein. Daher sollte man diese in einer eigenen Lage mit einer Strichstärke von min. 2 mm Zeichnen.

Wer z.B. für DC-Buchsen metallisierte Langlöcher haben möchte darf diese mit einem 1 mm-Fräser zeichnen. Um die Metallisierung zu erhalten, muss innerhalb dieser Fräsung zusätzlich eine durchkontaktierte Bohrung platziert werden.

===Leiterbahnstärke===
Grundsätzlich sind Leiterbahnen ab 0,15 mm machbar. Die Mindestabstände im Kupfer liegen ebenfalls bei 0,15 mm.

===Abstand zwischen Kontur und Kupfer===
Zwischen Kupfer und Fräsungen sollte (außer natürlich den Stellen wo Kupfer angefräst werden soll) 0,2 mm betragen und die Hersteller mögen Kupfer anfräsen wegen der höheren Belastung ihrer Fräser nicht so gerne.

===Bestückungsdruck===
Die Leiterplatten werden immer mit beidseitigem Bestückungsdruck bestellt.

Um hier ein möglichst gutes Ergebnis zu erhalten sollte man darauf achten, dass die minimale Strichstärke nicht unter 0,15mm geht und man sollte den Bestückungsdruck natürlich "aufräumen" ;-)

Normalerweise gehören Bauteilkonturen und -Referenzen sowie Informationstexte wie z.B. Platinenbezeichnung, Pinbelegung usw. (letztere sind auch im Kupfer oder Stoplack nicht unüblich).

Bei der Datenübername entferne ich sicherheitshalber den Bestückungsdruck von etwaigen Pads.

Daher übernehme ich beim Datenexport aus Eagle z.B. nur die Layer tPlace und tNames sowie bPlace und bNames in den Bestückungsdruck. Also müßt ihr bitte darauf achten, dass in diesen Layern nichts ist, was ihr nicht auf der Platine haben wollt. Umgekehrt gilt natürlich, dass alles was ihr auf der Platine haben wollt auch in diesen Layern sein muss.

Bitte denkt bei euren Layouts daran, denn auf Anmerkungen die eine andere Zusammensetzung des Bestückungsdrucks wünschen kann ich nicht eingehen.

== Fertigungsparameter des Nutzen ==

Die im Rahmen der Platinensammlung bestellten Nutzen werden mit 35µm/35µm (2-Lagig) bzw. 18µm/35µm/35µm/18µm Kupfer (4-Lagig), auf FR4, mit E-Test, HAL-Verzinnung (RoHS), Stoplack und Bestückungsdruck auf beiden Seiten bestellt.

Um die einzelnen Layouts später leichter zuordnen zu können, bekommt Jedes an geeigneter Stelle eine kleine 4stellige Referenz. In der Regel so, dass sie nach dem Bestücken nicht mehr sichtbar oder möglichst unauffällig ist.

Es ist nicht mehr nötig einen Platzhalter zu setzen, da die suche hiernach oft länger dauert als eine geeignete Stelle zu finden.

In den Bestückungsdruck werden Gehäusekonturen und Referenzen übernommen. Also muss alles was später im Bestückungsdruck landen soll in die entsprechenden Layer gelegt werden.

Für den Bestückungsdruck sollten die gleichen Regeln bzgl. der Strichstärke und Abstände eingehalten werden, um ein sauberes Druckbild zu erhalten.

Wer keinen Bestückungsdruck haben möchte, löscht die entsprechenden Inhalte am besten aus dem abgegebenen Datensatz. Normaler Weise reicht auch der Hinweis im Bestellformular, aber was gar nicht erst abgegeben wird kann auch nicht versehentlich auf der Platine landen.

Allerdings beeinflußt der Verzicht auf den Bestückungsdruck den Preis nicht.

== Kosten ==
Der Preis für Platinen im Sammelnutzen hängt natürlich von der im Nutzen verwendeten Fläche (also Platinengröße + Fräsrand) sowie der Lagenzahl ab.

Ab 2014 kostet der cm² im 2-lagigen Nutzen 0,40€/cm² und im 4-lagigen Nutzen 0,70€/cm². Anders als bisher gibt es ab 2014 immer alle Überproduzierten ohne Mehrkosten dazu.

Unabhängig von der Anzahl gleicher Platinen eines Layouts, wird für jedes Layout eine Bearbeitungsgebühr von 5,00€ berechnet.

Für die gesamte Bestellung kommen dann noch Porto und Versandkosten von 2,50€/Sendung für Versand im Luftpolsterumschlag innerhalb Deutschlands bzw. 4,50€/Sendung für Versand in die EU und die Schweiz.

Anmerkung:
Die genaue Kontur der Platine spielt für den Preis keine Rolle. Es wird immer das überdeckende Rechteck berechnet.

=== Beispielrechnung für ein 3 cm x 2 cm großes Layout ===
Benötigte Nutzenfläche pro Platine A = (3,0cm + 0,6cm) * (2,0cm + 0,6cm) = 9,36cm². Damit liegt der Preis pro Platine dieses Layouts bei 
{| class="wikitable"
|-
! Lagenzahl !! Preis
|-
| 2 || 3,74€/Stk
|-
| 4 || 6,55€/Stk
|-
|}

Mit den 5,00€ Bearbeitungsgebühr pro Layout ergeben sich die folgenden Gesamtkosten:

2-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 3,74€ || 7,48€ || 11,22€ || 14,96€ || 18,70€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 8,74€ || 12,48€ || 16,22€ || 19,96€ || 23,70€
|-
| Preis pro Platine gleichen Layouts || 8,74€ || 6,24€ || 5,41€ || 4,99€ || 4,74€
|-
|}
+ Porto und Versand

4-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 6,55€ || 13,10€ || 19,65€ || 26,20€ || 32,75€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 11,55€ || 18,10€ || 24,65€ || 31,20€ || 37,75€
|-
| Preis pro Platine gleichen Layouts || 11,55€ || 9,05€ || 8,22€ || 7,80€ || 7,55€
|-
|}
+ Porto und Versand

== Zahlungsarten ==
Grundsätzlich lege ich den Platinen einfach eine Rechnung bei, die dann bitte zeitnah zu begleichen ist.

Gerade für Bestellungen aus dem Ausland kann es auf Grund von hohen Überweisungskosten auch interessant sein per Paypal zu bezahlen. Das ist auch kein Problem, aber dann müßt ihr das bitte im Bestellformular unter Anmerkungen angeben und die zusätzlichen Gebühren (0,35€/Zahlung + 1,9% des ursprünglichen Rechnungswertes) kommen noch mit auf die Rechnung.

== Bestellablauf ==
Die geprüften Layoutdaten (*.dru File siehe Designregeln oder hier http://www.mikrocontroller.net/attachment/132705/platinensammler_02.dru ) schickt ihr dann bitte zusammen mit dem ausgefüllten Bestellformular ( http://www.mikrocontroller.net/attachment/199133/Bestellformular_v4.txt ) an ''' platinensammler(at)gmail.com '''

Bitte beachtet, dass ich nur vollständige Bestellungspakete
berücksichten kann (auch die Wiederbesteller bitte). Außerdem solltet
ihr mir bitte keine "Schnellschüsse" mit "Schönheitsfehlern schicken,
die ihr dann noch drei mal bis zum Stichtag nachbessert.

Wenn sich jemand nicht sicher ist, ob sein Layout produzierbar ist,
schaue ich gerne vorab unverbindlich drüber. Gerade bei Layoutneulingen kann das
schon mal ganz nützlich sein, um grobe Fehler zu vermeiden und um ggf.
Unsicherheit entgegen zu wirken.

Sobald ich die Daten geprüft und in den Nutzen übernommen habe,
bestätige ich die Bestellung per Mail. In dieser Mail steht dann eure
Adresse sowie Anzahl, Größe und Kosten eurer Platinen. Wenn ich nichts
von euch höre gehe ich davon aus, dass ich eure Bestellung richtig
übernommen habe. (Auch wenn ich mich über eine kurze Bestätigung freue)

Normaler Weise lege ich den Abgabetermin auf den letzten Werktag vor einem Wochenende. Wer bis zum Abgabetermin keine Auftragsbestätigung hat, sollte sich bei mir melden.

Wenn ein produzierter Nutzen bei mir ist, drösel ich den auseinander und gebe die Teilbestellungen zusammen mit den Rechnungen in die Post.

== Dateiformate ==
Ihr könnt mir eure Layoutdaten in den folgenden Formaten mailen.
* Eagle brd-file
* KiCad brd-file (alte .brd und neue .kicad_pcb)
* SPrint
* RS-274-X (Extended Gerber) / Excellon

=== Eagle ===
Wer Eagle hat, kann mit gerne direkt das BRD-File seines Layouts schicken. Wer auch noch einen kurzen 4-Augencheck haben möchte, sollte bitte auch das SCH-File mit schicken.

Allerdings habe ich zu Eagle noch einen besonderen Hinweis:

Wenn man aus Eagle die Gerberdaten exportiert, wird der Schrifttyp IMMER
in Vector umgewandelt.

Leider verändert das nicht nur das "Aussehen" sondern auch die Größe.

Für Schriften im Bestückungsdruck bedeutet dass, das ein ordentlich
aufgräumter Bestückungsdruck halt nicht mehr ganz so aufgeräumt ist.

Wenn man nun aber (wie ja nicht unüblich) Layoutname und Versionsstand
o.ä. im Kupfer hat und dicht an der Schrift mit Leiterbahnen vorbei
geht, kann diese Veränderung zu Kurzschlüssen führen die weder beim
Designcheck, noch beim E-Test auffallen.

Am Besten gebt ihr in der Konsole (bzw. Befehlszeile) von Eagle "set
vector_font on" (ohne die "") ein.

Dann wandelt schon der Brd-Editor alle Texte in Vector um und ihr seht
auch wirklich das, was später hinten raus fällt.

Da mir das schon ein ganzes Stück Arbeit erspart, währe ich euch Dankbar
wenn ihr dies in Zukunft "unerinnert" berücksichten würdet.

=== KiCad ===
Ich versuche immer auf dem aktuellsten Stand von KiCad zu sein und kann daher sowohl die alten (*.brd) , als auch die neunen *.kicad_pcb) KiCad-Layouts weiter verarbeiten.

=== Sprint-Layout===
Es ist auch möglich Sprint-Layouts direkt zu bestellen.

=== Gerberfiles===
Bei den Extended Gerber und Excellon Daten müssen eure Daten die folgenden Endungen für die Lagenzuordnung haben:
{| class="wikitable"
|-
! Lagenbezeichnung !! Datentyp !! Datenformat !! Dateiendung
|-
| Kuntur / Fräsungen || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L00
|-
| Bestückungsdruck Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L01
|-
| Lötstoplack Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L02
|-
| Kupfer Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L03
|-
| Kupfer untere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L04
|-
| Kupfer obere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L05
|-
| Kupfer Oberseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L06
|-
| Lötstoplack Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L07
|-
| Bestückungsdruck Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L08
|-
| durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.DK
|-
| nicht durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.NDK
|}

== FAQ ==
* '''Was sind überproduzierte Platinen?''' - Bei der Leiterplattenherstellung werden in der Regel 2-3 mal so viele Platinen, wie eigentlich bestellt, in die Produktion gegeben. So muss der Hersteller den Herstellungsprozess nicht komplett neu beginnen, falls es zu fertigungsfehlern kommt. Treten diese Fehler nicht oder nicht im erwarteten Umfang auf, so werden mehr Platinen gefertigt als eigentlich bestellt. Diesen Überhang bezeichnet man als Überproduktion.
 
* '''Sind auch "buried vias", "blind vias" möglich?''' - Es sind leider keine ''buried vias'' oder ''blind vias'' möglich
 
* '''Ist eine Lieferung in die Schweiz möglich?''' - Kein Problem (Siehe Verpackung und Versand)
 
* '''Gibt es eine Mindestgröße für ein Layout?''' - Ja die gibt es. Die Mindestmaße für Platinen sind mindestens eine Seite 10 mm, keine Seite unter 5 mm und Mindestfläche 1 cm².
 
* '''Gibt es eine Maximalgröße für ein Layout?''' - Die maximale Größe hänt natürlich in erster Linie von der Fertigungsnutzengröße des Herstellers ab. Diese variiert von Hersteller zu hersteller, ist aber wenigstens ca 300x400mm groß. Allerdings muss ich die Platinen ja anschließend noch verschicken können. Also sollten eure Layouts irgendwie in ein A4-Blatt passen.
 
* '''Bekomme ich eine Rechnung?''' - Ja, zusammen mit den Platinen bekommt ihr eine Rechnung, die auch die MwSt. ausweist.
 
* '''Verringert sich der gewählte Bohrdurchmesser bei metallisierten Löchern um die Beschichtungsdicke?''' - Nein, der Bohrdurchmesser wird vom Hersteller auf seinen Prozess hin korregiert, so dass die im Layout gewählten Bohrdurchmesser auch die Enddurchmesser sind.
 
* '''In welchen Schritten kann ich Bohrdurchmesser wählen?''' - Die Bohrer können in 0,1mm-Schritten gewählt werden.
 
* '''Ist eine Auslandslieferung möglich?''' - Ich verschicke die Platinen auch ins Ausland. Da die Portokosten hierfür steigen, wird der Versand entsprechend teurer. Außerdem fällt für Sendungen in die Schweiz oder andere nicht EU Länder keine Mehrwertsteuer an.
 
* '''Wie klein darf/kann der Bestückungsdruck werden?''' - Ich habe mal eine Schablone mit vorstellbaren Kombinationen machen lassen, um diese Frage möglichst gut beantworten zu können.
[[Datei:SilkSchablone.png|rahmenlos|zentriert|Bild von Platine mit Bestückungsdruck mit verschiedenen Parametern]] Wie man sehen kann, kommt es darauf an, ob man nur eine einzelne Linie, komplexere Strukturen oder Texte gedruckt haben möchte. Bei einfachen Linien kann man bis 50µm Strichstärke runter. Aber der Abstand zwischen den Linien sollte wenigstens 100µm betragen. Was die Lesbarkeit kommt es da natürlich auch auf euer Sehvermögen an. Für mich wäre eine Schrifthöhe von 0,6mm mit einer Strichstärke von ca. 50µm (8% von 0,6mm sind ja 48µm) grade eben die Unterkannte.
 
* '''Gibt es Einschränkungen bezüglich der Form einer Platine (rund, eckig, Auschnitte)?''' - Grundsätzlich gilt, dass die Konturen mit einem 2mm Fräser herstellbar sein müssen.
 
* '''Wie berechnet sich der Preis für nicht Rechteckige Platinen oder Platinen mit Ausfräsungen?''' - Es wird immer das überdeckende Rechteck berechnet.
 
* '''Kann ich "Löcher" in der berechneten Fläche mit passenden Layouts füllen?''' - Das ist kein Problem. Du mußt nur darauf achten, dass der "Lückenfüller" mit genügend 1mm Stegen mit der eigentlichen Platine verbunden ist und der Abstand zwischen den Platinen sonst wenigstens 2mm beträgt.
 
* '''Muss ich das verwendete DRC-File bei der Bestellung mit abgeben?''' - Nein, das ist nicht nötig da die zuletzt verwendeten Designregeln im BRD-File enthalten sind.
 
* '''Welche mindestmaße gelten für den Lötstoplack?''' - Für den Lötstoplack gelten die gleichen Vorgaben wie für den Bestükungsdruck.
 
* '''Wie viel Abstand sollte der Löststoplack von Pads haben?''' - Ich würde da zu ca 100µm raten, aber ich habe das nicht getestet.
 
* '''Gibt es eine Möglichkeit sich die Exportierten Gerbedaten anzusehen?''' - In der Regel klappt das mit GerbV (das ja auch im KiCad-Paket enthalten ist). Wenn da mal was "merkwürdiges" zu sehen ist, solltet Ihr aber nicht zu viel Zeit ins "Debugging" schieben. Ich sehe mir eure Plots (genau wie Layouts allgemein) auch gerne im Vorfeld bzw. bei der Bestellung an.
 
* '''Kann ich auch abweichend formatierte Gerber/Excellon-Daten abgeben?''' - Inzwischen habe ich einigermaßen Übung im Dateninterpretieren. Daher könnt Ihr es gerne auf den Versuch ankommen lassen. Bisher hat es noch immer irgendwie geklappt. Die von mir angegebene Formatierung macht mir das Datenhandling nur einfacher ;-)
 
Noch eine neue Frage? Dann schickt sie [http://www.mikrocontroller.net/user/show/JakobK mir.]

== Bestellungen ==
{| class="wikitable"
|-
! Nutzen !! Lagenzahl !! Status !! Liefertermin !! Update
|-
| 2014-0001|| 2/4 || versandt || 2014/02/03 || 2014/01/30
|-
| 2014-0002|| 2/4 || versandt|| 2014/02/17 || 2014/02/09
|-
| 2014-0003|| 2/4 || in Produktion || 2014/03/03 || 2014/02/09
|-
| 2014-0004|| 2/4 || läuft bis 28.2. || 2014/24/03 || 2014/02/09
|-
|}

== Links ==
* http://www.mikrocontroller.net/topic/245590 (30ct)
* http://www.mikrocontroller.net/topic/273018 (60ct)
* http://www.mikrocontroller.net/topic/245595 (Feedback)
* http://www.mikrocontroller.net/topic/245594 (FAQ)
* http://www.mikrocontroller.net/topic/245594#2696432 (FAQ: EAGLE Hohlsteckerbuchsen)
* http://www.mikrocontroller.net/articles/Platinenhersteller
* http://www.platinensammler.de/

[[Kategorie:Platinen]]
[[Kategorie:Lieferanten]]

Platinensammler

2014-02-23T02:06:42Z

Mox-mox: Rechtschreibfehlerkorrektur

== Einleitung & Generelles ==
Der Traum eines jeden Elektrotechnik-Hobbyisten ist wohl ein selbst entworfenes PCB.

Oft scheitert eine saubere Realisierung jedoch an der Fertigung der Leiterplatte. Hobbymittel wie die Direkttonermethode führen oft nur zu unzureichend sauberen Ergebnissen, Doppelseitige Platinen sind nur schwer sauber zu realisieren.
Eine vernünftige Ausrüstung zum Belichten ist teuer und so mancher Bastler hat auch schlicht und ergreifend nicht die Möglichkeit zum Umgang mit Entwicklern, Ätzmitteln, usw.

Egal ob man nun die Platinen nicht fertigen kann oder möchte besteht immer die Möglichkeit diese bei den Platinenherstellern (professionell) produzieren zu lassen. Das ist allerdings oft mit nicht unerheblichen Kosten und einem Mindestnutzen verbunden, gerade wenn nur einzelne kleine Platinen benötigt werden.

Aus diesem Grunde biete ich, alias "jakobk", hier im Forum mit meinem Platinensammler die Möglichkeit an, Platinen als Teil einer großen Sammelbestellung (Nutzen) mit zu bestellen.

Diese Bestellung geht immer an einen deutschen Hersteller. Dieser schickt mir auch gut getestete überproduzierte Platinen mit, die ich euch ebenfalls kostenlos "dazu lege".

Mit Beginn 2014 gibt es alle zwei Wochen eine Bestellung. Die Abgabetermine für die Bestellungen der sowie Infos zu ihrem Fertigungsstand finden sich weiter [[Platinensammler#Bestellungen|unten ]] im Artikel. Zu jedem Termin nehme ich 2- und 4-lagige Layouts an und bestelle diese dann so, dass sie nach ca 15 Arbeitstagen bei euch sind.

Um die einzelnen Layouts leichter zuordnen zu können füge ich an geeigneter Stelle eine kleine Kennziffer im Bestückungsdruck oder Stoplack ein. I.d.R. setze ich diese Markierung unter einen IC oder ein andere Bauteil das Sie dann nach dem Bestücken verdeckt.

Der Preis wird abhängig von der im Nutzen benötigten Fläche, und der Lagenzahl berechnet. Denn um die einzelnen Layouts vereinzeln zu können muss ein umlaufender 3mm Fräsgraben zur eigentlichen Leiterkartenkontur zugerechnet werden.

d.h. wenn eine Platine 3 x 2 cm groß ist, wird eine Fläche 3,6 cm x 2,6 cm also 9,36 cm² berechnet.

Näheres zu den Kosten findet Ihr [[Platinensammler#Kosten|hier]]

Wenn Ihr noch Fragen oder Anmerkungen habt schreibt [http://www.mikrocontroller.net/user/show/JakobK mir]

Viel Spass beim Layouten!

Jakob

== Designregeln ==

===Kontur===
Die Platinenkontur kann beinahe beliebige Formen haben.

Allerdings sollte sie so beschaffen sein, dass sie mit einem 2 mm Fräser herstellbar ist und sollte mit einer Strichstärke von 1 MIL oder 0,0254 mm gezeichnet werden.

Darüber hinaus muss eine Platine mindestens eine Seitenlänge mit 10 mm und darf keine Seitenlänge unter 5 mm haben. In der anderen Richtung sollte sie, aus versandtechnischen Gründen in ein A4-Blatt passen.

===Bohrungen===
Der kleinste verfügbare Bohrdurchmesser beträgt 0,3 mm.

===Fräsungen===
Innerhalb der Leiterplatten können Fräsungen beliebiger Form eingebracht werden. Auch diese müssen mit einem 2 mm-Fräser herstellbar sein. Daher sollte man diese in einer eigenen Lage mit einer Strichstärke von min. 2 mm Zeichnen.

Wer z.B. für DC-Buchsen metallisierte Langlöcher haben möchte darf diese mit einem 1 mm-Fräser zeichnen. Um die Metallisierung zu erhalten, muss innerhalb dieser Fräsung zusätzlich eine durchkontaktierte Bohrung platziert werden.

===Leiterbahnstärke===
Grundsätzlich sind Leiterbahnen ab 0,15 mm machbar. Die Mindestabstände im Kupfer liegen ebenfalls bei 0,15 mm.

===Abstand zwischen Kontur und Kupfer===
Zwischen Kupfer und Fräsungen sollte (außer natürlich den Stellen wo Kupfer angefräst werden soll) 0,2 mm betragen und die Hersteller mögen Kupfer anfräsen wegen der höheren Belastung ihrer Fräser nicht so gerne.

===Bestückungsdruck===
Die Leiterplatten werden immer mit beidseitigem Bestückungsdruck bestellt.

Um hier ein möglichst gutes Ergebnis zu erhalten sollte man darauf achten, dass die minimale Strichstärke nicht unter 0,15mm geht und man sollte den Bestückungsdruck natürlich "aufräumen" ;-)

Normalerweise gehören Bauteilkonturen und -Referenzen sowie Informationstexte wie z.B. Platinenbezeichnung, Pinbelegung usw. (letztere sind auch im Kupfer oder Stoplack nicht unüblich).

Bei der Datenübername entferne ich sicherheitshalber den Bestückungsdruck von etwaigen Pads.

Daher übernehme ich beim Datenexport aus Eagle z.B. nur die Layer tPlace und tNames sowie bPlace und bNames in den Bestückungsdruck. Also müßt ihr bitte darauf achten, dass in diesen Layern nichts ist, was ihr nicht auf der Platine haben wollt. Umgekehrt gilt natürlich, dass alles was ihr auf der Platine haben wollt auch in diesen Layern sein muss.

Bitte denkt bei euren Layouts daran, denn auf Anmerkungen die eine andere Zusammensetzung des Bestückungsdrucks wünschen kann ich nicht eingehen.

== Fertigungsparameter des Nutzen ==

Die im Rahmen der Platinensammlung bestellten Nutzen werden mit 35µm/35µm (2-Lagig) bzw. 18µm/35µm/35µm/18µm Kupfer (4-Lagig), auf FR4, mit E-Test, HAL-Verzinnung (RoHS), Stoplack und Bestückungsdruck auf beiden Seiten bestellt.

Um die einzelnen Layouts später leichter zuordnen zu können, bekommt Jedes an geeigneter Stelle eine kleine 4stellige Referenz. In der Regel so, dass sie nach dem Bestücken nicht mehr sichtbar oder möglichst unauffällig ist.

Es ist nicht mehr nötig einen Platzhalter zu setzen, da die suche hiernach oft länger dauert als eine geeignete Stelle zu finden.

In den Bestückungsdruck werden Gehäusekonturen und Referenzen übernommen. Also muss alles was später im Bestückungsdruck landen soll in die entsprechenden Layer gelegt werden.

Für den Bestückungsdruck sollten die gleichen Regeln bzgl. der Strichstärke und Abstände eingehalten werden, um ein sauberes Druckbild zu erhalten.

Wer keinen Bestückungsdruck haben möchte, löscht die entsprechenden Inhalte am besten aus dem abgegebenen Datensatz. Normaler Weise reicht auch der Hinweis im Bestellformular, aber was gar nicht erst abgegeben wird kann auch nicht versehentlich auf der Platine landen.

Allerdings beeinflußt der Verzicht auf den Bestückungsdruck den Preis nicht.

== Kosten ==
Der Preis für Platinen im Sammelnutzen hängt natürlich von der im Nutzen verwendeten Fläche (also Platinengröße + Fräsrand) sowie der Lagenzahl ab.

Ab 2014 kostet der cm² im 2-lagigen Nutzen 0,40€/cm² und im 4-lagigen Nutzen 0,70€/cm². Anders als bisher gibt es ab 2014 immer alle Überproduzierten ohne Mehrkosten dazu.

Unabhängig von der Anzahl gleicher Platinen eines Layouts, wird für jedes Layout eine Bearbeitungsgebühr von 5,00€ berechnet.

Für die gesamte Bestellung kommen dann noch Porto und Versandkosten von 2,50€/Sendung für Versand im Luftpolsterumschlag innerhalb Deutschlands bzw. 4,50€/Sendung für Versand in die EU und die Schweiz.

Anmerkung:
Die genaue Kontur der Platine spielt für den Preis keine Rolle. Es wird immer das überdeckende Rechteck berechnet.

=== Beispielrechnung für ein 3 cm x 2 cm großes Layout ===
Benötigte Nutzenfläche pro Platine A = (3,0cm + 0,6cm) * (2,0cm + 0,6cm) = 9,36cm². Damit liegt der Preis pro Platine dieses Layouts bei 
{| class="wikitable"
|-
! Lagenzahl !! Preis
|-
| 2 || 3,74€/Stk
|-
| 4 || 6,55€/Stk
|-
|}

Mit den 5,00€ Bearbeitungsgebühr pro Layout ergeben sich die folgenden Gesamtkosten:

2-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 3,74€ || 7,48€ || 11,22€ || 14,96€ || 18,70€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 8,74€ || 12,48€ || 16,22€ || 19,96€ || 23,70€
|-
| Preis pro Platine gleichen Layouts || 8,74€ || 6,24€ || 5,41€ || 4,99€ || 4,74€
|-
|}
+ Porto und Versand

4-Lagig
{| class="wikitable"
|-
! Anzahl !! 1 !! 2 !! 3 !! 4 !! 5
|-
| Nutzenkosten || 6,55€ || 13,10€ || 19,65€ || 26,20€ || 32,75€
|-
| Bearbeitungsgebühr || 5,00€ || 5,00€ || 5,00€ || 5,00€ || 5,00€
|-
| Gesamtkosten pro Layout || 11,55€ || 18,10€ || 24,65€ || 31,20€ || 37,75€
|-
| Preis pro Platine gleichen Layouts || 11,55€ || 9,05€ || 8,22€ || 7,80€ || 7,55€
|-
|}
+ Porto und Versand

== Zahlungsarten ==
Grundsätzlich lege ich den Platinen einfach eine Rechnung bei, die dann bitte zeitnah zu begleichen ist.

Gerade für Bestellungen aus dem Ausland kann es auf Grund von hohen Überweisungskosten auch interessant sein per Paypal zu bezahlen. Das ist auch kein Problem, aber dann müßt ihr das bitte im Bestellformular unter Anmerkungen angeben und die zusätzlichen Gebühren (0,35€/Zahlung + 1,9% des ursprünglichen Rechnungswertes) kommen noch mit auf die Rechnung.

== Bestellablauf ==
Die geprüften Layoutdaten (*.dru File siehe Designregeln oder hier http://www.mikrocontroller.net/attachment/132705/platinensammler_02.dru ) schickt ihr dann bitte zusammen mit dem ausgefüllten Bestellformular ( http://www.mikrocontroller.net/attachment/199133/Bestellformular_v4.txt ) an ''' platinensammler(at)gmail.com '''

Bitte beachtet, dass ich nur vollständige Bestellungspakete
berücksichten kann (auch die Wiederbesteller bitte). Außerdem solltet
ihr mir bitte keine "Schnellschüsse" mit "Schönheitsfehlern schicken,
die ihr dann noch drei mal bis zum Stichtag nachbessert.

Wenn sich jemand nicht sicher ist, ob sein Layout produzierbar ist,
schaue ich gerne vorab unverbindlich drüber. Gerade bei Layoutneulingen kann das
schon mal ganz nützlich sein, um grobe Fehler zu vermeiden und um ggf.
Unsicherheit entgegen zu wirken.

Sobald ich die Daten geprüft und in den Nutzen übernommen habe,
bestätige ich die Bestellung per Mail. In dieser Mail steht dann eure
Adresse sowie Anzahl, Größe und Kosten eurer Platinen. Wenn ich nichts
von euch höre gehe ich davon aus, dass ich eure Bestellung richtig
übernommen habe. (Auch wenn ich mich über eine kurze Bestätigung freue)

Normaler Weise lege ich den Abgabetermin auf den letzten Werktag vor einem Wochenende. Wer bis zum Abgabetermin keine Auftragsbestätigung hat, sollte sich bei mir melden.

Wenn ein produzierter Nutzen bei mir ist, drösel ich den auseinander und gebe die Teilbestellungen zusammen mit den Rechnungen in die Post.

== Dateiformate ==
Ihr könnt mir eure Layoutdaten in den folgenden Formaten mailen.
* Eagle brd-file
* KiCad brd-file (alte .brd und neue .kicad_pcb)
* SPrint
* RS-274-X (Extended Gerber) / Excellon

=== Eagle ===
Wer Eagle hat, kann mit gerne direkt das BRD-File seines Layouts schicken. Wer auch noch einen kurzen 4-Augencheck haben möchte, sollte bitte auch das SCH-File mit schicken.

Allerdings habe ich zu Eagle noch einen besonderen Hinweis:

Wenn man aus Eagle die Gerberdaten exportiert, wird der Schrifttyp IMMER
in Vector umgewandelt.

Leider verändert das nicht nur das "Aussehen" sondern auch die Größe.

Für Schriften im Bestückungsdruck bedeutet dass, das ein ordentlich
aufgräumter Bestückungsdruck halt nicht mehr ganz so aufgeräumt ist.

Wenn man nun aber (wie ja nicht unüblich) Layoutname und Versionsstand
o.ä. im Kupfer hat und dicht an der Schrift mit Leiterbahnen vorbei
geht, kann diese Veränderung zu Kurzschlüssen führen die weder beim
Designcheck, noch beim E-Test auffallen.

Am Besten gebt ihr in der Konsole (bzw. Befehlszeile) von Eagle "set
vector_font on" (ohne die "") ein.

Dann wandelt schon der Brd-Editor alle Texte in Vector um und ihr seht
auch wirklich das, was später hinten raus fällt.

Da mir das schon ein ganzes Stück Arbeit erspart, währe ich euch Dankbar
wenn ihr dies in Zukunft "unerinnert" berücksichten würdet.

=== KiCad ===
Ich versuche immer auf dem aktuellsten Stand von KiCad zu sein und kann daher sowohl die alten (*.brd) , als auch die neunen *.kicad_pcb) KiCad-Layouts weiter verarbeiten.

=== Sprint-Layout===
Es ist auch möglich Sprint-Layouts direkt zu bestellen.

=== Gerberfiles===
Bei den Extended Gerber und Excellon Daten müssen eure Daten die folgenden Endungen für die Lagenzuordnung haben:
{| class="wikitable"
|-
! Lagenbezeichnung !! Datentyp !! Datenformat !! Dateiendung
|-
| Kuntur / Fräsungen || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L00
|-
| Bestückungsdruck Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L01
|-
| Lötstoplack Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L02
|-
| Kupfer Unterseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L03
|-
| Kupfer untere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L04
|-
| Kupfer obere Innenlage || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L05
|-
| Kupfer Oberseite || Extended Gerber|| metric / 2:4 / absolute / leading zero supression || *.L06
|-
| Lötstoplack Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L07
|-
| Bestückungsdruck Oberseite || Extended Gerber || metric / 2:4 / absolute / leading zero supression || *.L08
|-
| durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.DK
|-
| nicht durchkontaktierte Bohrungen || Excellon || metric / 2:4 / absolute / leading zero supression || *.NDK
|}

== FAQ ==
* '''Was sind überproduzierte Platinen?''' - Bei der Leiterplattenherstellung werden in der Regel 2-3 mal so viele Platinen, wie eigentlich bestellt, in die Produktion gegeben. So muss der Hersteller den Herstellungsprozess nicht komplett neu beginnen, falls es zu fertigungsfehlern kommt. Treten diese Fehler nicht oder nicht im erwarteten Umfang auf, so werden mehr Platinen gefertigt als eigentlich bestellt. Diesen Überhang bezeichnet man als Überproduktion.
 
* '''Sind auch "buried vias", "blind vias" möglich?''' - Es sind leider keine ''buried vias'' oder ''blind vias'' möglich
 
* '''Ist eine Lieferung in die Schweiz möglich?''' - Kein Problem (Siehe Verpackung und Versand)
 
* '''Gibt es eine Mindestgröße für ein Layout?''' - Ja die gibt es. Die Mindestmaße für Platinen sind mindestens eine Seite 10 mm, keine Seite unter 5 mm und Mindestfläche 1 cm².
 
* '''Gibt es eine Maximalgröße für ein Layout?''' - Die maximale Größe hänt natürlich in erster Linie von der Fertigungsnutzengröße des Herstellers ab. Diese variiert von Hersteller zu hersteller, ist aber wenigstens ca 300x400mm groß. Allerdings muss ich die Platinen ja anschließend noch verschicken können. Also sollten eure Layouts irgendwie in ein A4-Blatt passen.
 
* '''Bekomme ich eine Rechnung?''' - Ja, zusammen mit den Platinen bekommt ihr eine Rechnung, die auch die MwSt. ausweist.
 
* '''Verringert sich der gewählte Bohrdurchmesser bei metallisierten Löchern um die Beschichtungsdicke?''' - Nein, der Bohrdurchmesser wird vom Hersteller auf seinen Prozess hin korregiert, so dass die im Layout gewählten Bohrdurchmesser auch die Enddurchmesser sind.
 
* '''In welchen Schritten kann ich Bohrdurchmesser wählen?''' - Die Bohrer können in 0,1mm-Schritten gewählt werden.
 
* '''Ist eine Auslandslieferung möglich?''' - Ich verschicke die Platinen auch ins Ausland. Da die Portokosten hierfür steigen, wird der Versand entsprechend teurer. Außerdem fällt für Sendungen in die Schweiz oder andere nicht EU Länder keine Mehrwertsteuer an.
 
* '''Wie klein darf/kann der Bestückungsdruck werden?''' - Ich habe mal eine Schablone mit vorstellbaren Kombinationen machen lassen, um diese Frage möglichst gut beantworten zu können.
[[Datei:SilkSchablone.png|rahmenlos|zentriert|Bild von Platine mit Bestückungsdruck mit verschiedenen Parametern]] Wie man sehen kann, kommt es darauf an, ob man nur eine einzelne Linie, komplexere Strukturen oder Texte gedruckt haben möchte. Bei einfachen Linien kann man bis 50µm Strichstärke runter. Aber der Abstand zwischen den Linien sollte wenigstens 100µm betragen. Was die Lesbarkeit kommt es da natürlich auch auf euer Sehvermögen an. Für mich wäre eine Schrifthöhe von 0,6mm mit einer Strichstärke von ca. 50µm (8% von 0,6mm sind ja 48µm) grade eben die Unterkannte.
 
* '''Gibt es Einschränkungen bezüglich der Form einer Platine (rund, eckig, Auschnitte)?''' - Grundsätzlich gilt, dass die Konturen mit einem 2mm Fräser herstellbar sein müssen.
 
* '''Wie berechnet sich der Preis für nicht Rechteckige Platinen oder Platinen mit Ausfräsungen?''' - Es wird immer das überdeckende Rechteck berechnet.

* '''Kann ich "Löcher" in der berechneten Fläche mit passenden Layouts füllen?''' - Das ist kein Problem. Du mußt nur darauf achten, dass der "Lückenfüller" mit genügend 1mm Stegen mit der eigentlichen Platine verbunden ist und der Abstand zwischen den Platinen sonst wenigstens 2mm beträgt.
 
* '''Muss ich das verwendete DRC-File bei der Bestellung mit abgeben?''' - Nein, das ist nicht nötig da die zuletzt verwendeten Designregeln im BRD-File enthalten sind.
 
* '''Welche mindestmaße gelten für den Lötstoplack?''' - Für den Lötstoplack gelten die gleichen Vorgaben wie für den Bestükungsdruck.
 
* '''Wie viel Abstand sollte der Löststoplack von Pads haben?''' - Ich würde da zu ca 100µm raten, aber ich habe das nicht getestet.
 
* '''Gibt es eine Möglichkeit sich die Exportierten Gerbedaten anzusehen?''' - In der Regel klappt das mit GerbV (das ja auch im KiCad-Paket enthalten ist). Wenn da mal was "merkwürdiges" zu sehen ist, solltet Ihr aber nicht zu viel Zeit ins "Debugging" schieben. Ich sehe mir eure Plots (genau wie Layouts allgemein) auch gerne im Vorfeld bzw. bei der Bestellung an.
 
* '''Kann ich auch abweichend formatierte Gerber/Excellon-Daten abgeben?''' - Inzwischen habe ich einigermaßen Übung im Dateninterpretieren. Daher könnt Ihr es gerne auf den Versuch ankommen lassen. Bisher hat es noch immer irgendwie geklappt. Die von mir angegebene Formatierung macht mir das Datenhandling nur einfacher ;-)
 
Noch eine neue Frage? Dann schickt sie [http://www.mikrocontroller.net/user/show/JakobK mir.]

== Bestellungen ==
{| class="wikitable"
|-
! Nutzen !! Lagenzahl !! Status !! Liefertermin !! Update
|-
| 2014-0001|| 2/4 || versandt || 2014/02/03 || 2014/01/30
|-
| 2014-0002|| 2/4 || versandt|| 2014/02/17 || 2014/02/09
|-
| 2014-0003|| 2/4 || in Produktion || 2014/03/03 || 2014/02/09
|-
| 2014-0004|| 2/4 || läuft bis 28.2. || 2014/24/03 || 2014/02/09
|-
|}

== Links ==
* http://www.mikrocontroller.net/topic/245590 (30ct)
* http://www.mikrocontroller.net/topic/273018 (60ct)
* http://www.mikrocontroller.net/topic/245595 (Feedback)
* http://www.mikrocontroller.net/topic/245594 (FAQ)
* http://www.mikrocontroller.net/topic/245594#2696432 (FAQ: EAGLE Hohlsteckerbuchsen)
* http://www.mikrocontroller.net/articles/Platinenhersteller
* http://www.platinensammler.de/

[[Kategorie:Platinen]]
[[Kategorie:Lieferanten]]

AVR-GCC-Codeoptimierung

2014-02-19T14:21:50Z

Mox-mox: /* Feinabstimmung der Optimizer */

Entstanden aus diesem [http://www.mikrocontroller.net/topic/66690 Thread] sollen hier ein paar Hinweise/Erfahrungen gegeben werden, um den Quellcode in Punkto Größe und Geschwindigkeit zu optimieren. ''En detail'' ist das Thema komplex, da es stark von der Codeoptimierung des Compilers abhängt. Es ist im Einzelfall ratsam zu prüfen, ob die eigenen Maßnahmen auch erfolgreich waren. Die Diskussionen [http://www.mikrocontroller.net/topic/132624] bzw. [http://www.mikrocontroller.net/topic/180800#new] können als Anhaltspunkte dienen, wie eine solche Prüfung ablaufen kann.

== Prinzipien der Optimierung ==

Wie so oft sollte man nicht einfach wild drauf los optimieren und sich zunächst ein paar Dinge klar machen.

* Warum will ich optimieren?
* Was kann man sinnvoll optimieren?
* Wieviel Rechenzeit oder Speicher soll dabei gespart werden?
* Wie kann optimiert werden?
* "Verfrühte Optimierung ist die Wurzel allen Übels"

Viele Optimierungen sind "Angst-Optimierungen", die nicht wirklich nötig sind. Die Gefahr mit Optimierungen ist, den Code tot zu optimieren, sprich Lesbarkeit, Portierbarkeit und ggf. Fehlerfreiheit sinken massgeblich. Kurz und knapp in diesem [http://blogs.msdn.com/b/audiofool/archive/2007/06/14/the-rules-of-code-optimization.aspx BLOG] formuliert.

=== Warum ===

Optimieren sollte man nur, wenn
* der Speicher nicht mehr ausreicht (RAM, Flash)
* Die Laufzeit für bestimmte Programmteile zu groß wird und somit bestimmte (Echtzeit-)Ausgaben nicht im erforderlichen Zeitrahmen erledigt werden

Weiter sollte man folgende Punkte gegeneinander abwägen:

* Codeverbrauch
* Datenverbrauch. Statisch/Stack/Heap
* Mittlere Laufzeit/maximale Laufzeit
* Entwicklungszeit
* Portabilität (Compiler, Hardware, ...)
* Verständlichkeit der Quelle, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]
* ABI-Konformität

=== Was ===

Die goldene Regle lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren. Der Rest muss nur sauber und lesbar geschrieben sein. Was jedoch nichts bringt, ist eine Funktion, die von 1 Minute Programmlaufzeit lediglich 1 Sekunde verbraucht, um den Faktor 10 schneller zu machen. Die Programmlaufzeit sinkt dann von 60 Sekunden auf 59.1 Sekunden. Der Aufwand, die Funktion um einen Faktor 10 schneller zu machen ist aber meistens beträchtlich! Kann ich aber den Code, der für die 59 Sekunden verantwortlich ist um einen Faktor 10 schneller machen, dann sinkt die Gesamtlaufzeit von 60 Sekunden auf 6.9 Sekunden. Dort bringt Optimieren augenscheinlich viel mehr!

Um die optimierungswürdigen Stellen zu finden, muss man sein Programm analysieren. Dazu gibt es verschiedene Möglichkeiten.

====Speicherverbrauch nach Funktionen aufschlüsseln====

;map-File:
:dort sind alle globalen und statischen Variablen enthalten. Eine Map-Datei kann mit den GNU-Tools während des Linkens angelegt werden:
::<pre>> avr-gcc ... -Wl,-Map,foo.map</pre>
: Die Option -Wl bewirkt, daß avr-gcc die angehängen Optionen unverändert an den Linker weiterreicht. Dieser erzeugt dann das Mapfile "foo.map", eine Textdatei.
;avr-size: Mit Tools wie avr-size kann die Platzbelegung einzelner Module ermittelt werden:
::<pre>> avr-size -x foo1.o foo2.o ...</pre>
:bzw. die Platzbelegung der elf-Datei:
::<pre>> avr-size foo.elf</pre>
;avr-nm:
::<pre>> avr-nm --size-sort -S foo.elf</pre>
:ergibt eine Liste mit der Größe aller Objekte: der erste Spalte enthälte die Adresse, die zweite Spalte die Größe, die dritte den Typ und die vierte Spalte den zugehörigen Symbolnamen. Der Typ ergibt sich aus der folgenden Zuordnung, wobei Großbuchstaben globale Symbole kennzeichnen und Kleinbuchstaben Symbole, die Modul-lokal sind:
:;T/t: Objekte in der text-Section: Funktionen, Daten im Flash
:;D/d: Objekte im data-Segment (initialisierte Daten)
:;B/b: Objekte im bss-Segment (Null-initialisierte Daten)

;avr-gcc: Der Compiler hat bereits Informationen über die übersetzten Funktionen, die man direkt zur Analyse verwenden kann. Dazu lässt man avr-gcc die Assembler-Ausgabe, die ohne weiteres Zutun nur als temporäre Datei angelegt wird, abspeichern. Etwa für die Quelldatei foo.c:
::<pre>> avr-gcc -save-temps foo.c -c ...</pre>
:Die Assembler-Datei wird damit als foo.s angelegt und nicht gelöscht. (Das ebenfalls angelegte Präcompilat foo.i wird nicht benötigt). Für jede Funktion gibt avr-gcc 3.4.x im Prolog einen Kommentar der Form<ref>Für avr-gcc 4.x sehen die Kommentare anders aus oder fehlen je nach Compilerversion ganz</ref>
::<pre>/* prologue: frame size=0 */</pre>
:aus, was die Größe des aktuellen Frames angibt. Dies ist der Platz auf dem Stack, der für lokale Variablen benötigt wird. Am besten ist es, wenn die Frame-Size wie im Beispiel gleich 0 ist. Ansonsten sollte man versuchen, diese Größe auf Null zu bringen. Für Variablen, die nicht in Registern gehalten werden können, müssen Speicherzugriffe in den Stack erzeugt werden. Diese machen das Programm sowohl größer aus auch langsamer. Zudem reserviert avr-gcc bei solche Funktionen das Y-Register als Frame-Pointer; das Y-Register steht damit nicht mehr für lokale Variablen zur Verfügung was sich ebenfalls ungünstig auf die Codegüte auswirkt. Ein Grund für das Anlegen eines Frames können zu viele lokale Variablen sein (zB lokale Puffer/Arrays) oder lokale Variablen/Strukturen/Parameter mit ungünstigen Größen, etwa eine 3-Byte große Struktur.

: Neben dieser Information gibt avr-gcc Kommentare der Gestalt
::<pre>/* prologue end (size=2) */</pre>
:aus die darüber informieren, wie viele Register auf dem Stack gesichert wurden.

: Zusammen mit Werkzeugen wie grep, die in jedem Linux und jeder WinAVR-Distribution enthalten sind, findet man schnell Übeltäter wie Funktionen mit Frame.

;Assembler-Code sichten: Ein kurzer Blick auf den erzeugten Assembler-Code zeigt oft, wie gut der Compiler den Code umgesetzt hat. Den erzeugten Assembler-Code zu überfliegen ist wesentlich zeitsparender als selbst in Assembler zu programmieren. Je nach Gusto verwendet man zur Einsicht den Assembler-Code, den avr-gcc ausgibt (s.o.), Assembler-Dumps des Assemblers, List-Files oder HEX-Dumps. Siehe auch<ref>[http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc roboternetz.de: Assembler-Dump erstellen mit avr-gcc]</ref>

;Hilfsmittel: einkaufen oder selber bauen. Es gilt herauszufinden, welche Funktion massig Stack durch lokale Variablen verbraucht. Stacktracer können das. Wenn man keinen hat, dann muss man sich eben selber einen bauen, indem man den Stackpointer mitloggt. Zur Not einen Code-Review machen: Alle Funktionen optisch durchgehen und die identifizieren, die viele Variablen anlegen. Dann die Aufrufhierarchie der Funktion feststellen: Wirken sich die vielen Variablen überhaupt aus oder entsteht mein Problem durch eine tiefe Funktionsaufrufhierarchie, bei der zwar wenige Variablen pro Funktion im Spiel sind, aber die Menge der ineinandergeschachtelten Aufrufe 'das Kraut fett macht'
;Profitools: können das alles fast auf Knopfdruck, kosten aber viel Geld

====Laufzeit messen====

*Simulator
*In Echtzeit mittels Testpin, welche an Anfang einer Funktion/Blocks gesetzt wird und am Ende wieder gelöscht wird. Mit einem [[Oszilloskop]] kann man so sehr einfach die Laufzeit messen.

; Anmerkung: Solche Messverfahren liefern immer nur eine ''untere'' Schranke für die Laufzeit, niemals eine obere Schranke. Eine obere Schranke, wie man sie etwa in sicherheitsktitischen Systemen benötigt, liefert eine statische Codeanalyse.

=== Wieviel ===

Der Aufwand von Optimierungen wächst exponentiell. Die letzten paar Prozent brauchen überproportional viel Aufwand.

=== Wie ===

Meist muss man die Wahl treffen ob man Speicher oder Rechenzeit sparen will, beides gleichzeitg geht meist nicht. Das Konzept heißt 'Space for Time' und kann in beide Richtungen verwendet werden. Als Beispiel soll eine komplizierte Berechnung dienen. Diese kann man relativ kompakt in eine Funktion packen, welche dann aber eher langsam ist. Oder man benutzt eine sehr große Tabelle, in welcher die Ergebnisse schon für jeden Eingangswert vorausberechnet wurden. Diese Lösung ist sehr schnell, verbraucht aber sehr viel Speicher.

* Inlining von Funktionen erhöht den Speicherverbrauch, senkt aber die Laufzeit. Beispiel: Funktion A ist 50 Byte groß und wird 10 mal im Programm aufgerufen. Ein Aufruf kostet 10 Byte:
** Ohne Inline: 10 * 10Byte + 50 Byte = 150 Byte Platzverbrauch
** Mit Inline: 10 * 50 Byte = 500 Byte
* Optimierer einschalten
* möglichst keine Floating Point Operationen, besser ist meist [[Festkommaarithmetik]]
* Formeln umstellen und zusammenfassen
* Variablen so klein wie möglich, uint8_t wo's nur geht.
* Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei

== GCC-Optionen ==

=== Optimierungs-Level ===

avr-gcc kennt mehrere Optimierungsstufen:
;<tt>-O0</tt>: Keine Optimierung des erzeugten Codes. Diese Optimierungsstufe optimiert den Resourcenverbrauch des ''Hostrechners'' und die Nachvollziehbarkeit der erzeugten Codes anhand von Debug-Information. Alle lokalen Variablen werden auf dem Stack angelegt und nicht in Registern gehalten. Es werden keine komplexen Optimierungsalgorithmen angewandt; lediglich Konstanten wie 1+2 werden zu 3 gefaltet.

;<tt>-O1</tt>: Je höher die Optimierungsstufe, desto schwieriger ist der erzeugte Code nachvollziehbar — auch mit Debugger. Diese O-Stufe ist ein Kompromiss zwischen aggressiver Optimierung und Nachvollziehbarkeit des erzeugten Codes. Ein ehernes Gesetz in GCC ist, dass er den gleichen Code erzeugen muss unabhängig davon, ob Debug-Information erzeugt wird oder nicht. Im Umkehrschluss erlaubt volle Debug-Unterstützung nicht alle Optimierungen, wozu diese Optimierungsstufe dient.

;<tt>-O2</tt>: Optimierung auf Geschwindigkeit. Für AVR nur mässig sinnvoll, da sich der Codezuwachs nicht in einen entsprechenden Geschwindigkeitszuwachs transformiert. Dies liegt vor allem daran, daß Sprünge und Funktionsaufrufe auf AVR im Vergleich zu anderen Architekturen sehr billig sind. Es bringt also kaum einen Geschwindigkeitszuwachs, einen Block zu kopieren um einen Sprung zu sparen. Hingegen vergrößert dies den Code deutlich.

;<tt>-O3</tt>: Dito. Auf Teufel-komm-raus Funktionen zu inlinen, Schleifen aufzurollen oder gar Funktionen mehrfach für unterschiedliche Aufruf-Szenarien zu implementieren, ist auf einem kleinen µC wie AVR der Overkill.

;<tt>-Os</tt>: Optimierung auf Codegröße. Die bevorzugte Optimierungsstufe für AVR und viele andere µC.

Jede O-Option ist ein Sammlung von verschiedenen Schaltern, welche bestimmte Optimierungsstrategien aktivieren. Um zu sehen, welche Schalter dies genau sind, erzeugt man wie oben beschrieben mit den Schalten
-save-temps -fverbose-asm
die Assembler-Ausgabe von gcc und schaut die Optionen im s-File nach. Einzelne Optionen lassen sich gezielt aktivieren bzw. deaktivieren und damit zum Beispiel zum <tt>-Os</tt>-Paket hinzufügen.

Eine Ausnahme bildet <tt>-O0</tt>: Hier ist Code-Optimierung generell deaktiviert, und Optimierungsschalter bleiben ohne Wirkung.

=== Feinabstimmung der Optimizer ===

Kandidaten für Optimierungsoptionen sind folgende Schalter. <tt>-m</tt> kennzeichnet maschinenspezifische Schalter, die nur für AVR gültig sind. <tt>-f</tt> bzw. <tt>-fno-</tt> sind maschinenunabhängige Schalter, die auch für andere Architekturen verfügbar sind.

;<tt>-fno-split-wide-types</tt>: Je nach Quelle kann die Deaktivierung von <tt>-fsplit-wide-types</tt> besseren Code ergeben.

;<tt>-fno-inline-small-functions</tt>: Relativ kleine Funktionen /immer/ zu inlinen kann den Code unnötig vergrößern, dieser Schalter unterbindet das automatische Inlinen kleiner Funktionen.

;<tt>-finline-limit=</tt>''wert'': Maximalwert für automatisch geinlinte Funktionen. In einschlägigen Foren werden kleine Werte für ''wert'' vorgeschlagen, z.B. 1…3

;<tt>-mcall-prologues</tt>: Die für aufwändige Funktionen mitunter recht langen push/pop-Sequenzen werden durch Hilfsfunktionen ersetzt. Das kann vor allem bei grossen Programmen Platz sparen. Die Ausführungszeit steigt an.

;<tt>-fno-jump-tables</tt>: Switch-Statements werden hierdurch mitunter deutlich kürzer.

;<tt>-fno-move-loop-invariants -fno-tree-loop-optimize</tt>: Einige Schleifenoptimierungen, welche die Registerlast erhöhen und für AVR kaum zu einem Geschwindigkeitszuwachs führen, werden deaktiviert.

;<tt>-fno-tree-switch-conversion</tt>: Neue GCC-Versionen können switch/case Anweisungen u.U. in Lookup-Tabellen umwandeln, die im RAM abgelegt werden, siehe auch [http://gcc.gnu.org/PR49857 PR49857]. Dieser Optimierung ist bei RAM-Knappheit in Betracht zu ziehen, bring aber natürlich nur dann etwas, wenn diese Optimierung auch ausgeführt wurde.

;<tt>-fno-optimize-sibling-calls</tt>: Ab 4.7 wirksam: Tailcall-Optimierung kann den Code vergrößern, wenn Epiloge mehrfach erzeugt werden. In diesem Fall deaktiviert man die Tailcall-Optimierung.

;<tt>-maccumulate-args</tt>: Ab 4.7: Funktionen, die mehrere printf-artige Aufrufe enthalten und viele Artumente per Stack an diese übergeben, werden u.U kleiner.

;<tt>-mstrict-X</tt>: Ab 4.7: Beeinflusst die Art und Weise, wie das X-Register zur Adressierung verwendet wird.

;<tt>-mbranch-cost=</tt>''wert'': Ab 4.7: Setzt die Kosten, mit der der Compiler einen bedingten Sprunge veranschlagt. Default-Wert ist ''wert''<tt>=0</tt>.

;<tt>-fno-caller-saves</tt>: Kann zu effizienteren Pro-/Epilogen beitragen.

;<tt>-fno-tree-ter</tt>: Es gibt Fälle, in denen der Compiler die Berechnung temporärer Variablen über volatile-Zugriffe und Memory-Barriers zieht, siehe [http://gcc.gnu.org/PR53033 PR53033]. Von der C-Spezifikation her ist dies zulässig, kann aber zu unerwünschter Umsortierung der volatile-Operation führe, z.B. wenn es sich dabei um eine <tt>SEI</tt>-Instruktion handelt. Ohne diese Optimierung wird der Code evtl. etwas größer, aber Probleme wie im PR beschrieben können vermieden werden.

;<tt>--param case-values-threshold=</tt>''wert'': Ab 4.7: Schwellwert an Einträgen in einem switch/case, ab dem anstatt eines binären if/else-Entscheidungsbaums eine Sprungtabelle zu den case-Labels erzeugt wird. Voreinstellung ab 4.7 ist ''wert''<tt>=7</tt>. Ältere Compilerversionen verwenden andere Werte. Siehe auch <tt>-f[no-]jump-tables</tt>.

Generell gilt für all diese Optionen, daß sie abhängig vom Projekt zu einer Codeverbesserung oder -verschlechterung führen können — dies ist i.d.R. vom Projektcode abhängig.

=== Linker-Optionen ===

;<tt>-ffunction-sections -Wl,--gc-sections</tt>: Der Linker wirft nicht referenzierte Sections weg, was die Codegröße günstig beeinflussen kann. Diese Optimierung verkleinert den Code nur dann, wenn nicht verwendete Funktionen in der Anwendung rumgammeln. Weil der Linker nur auf Section-Ebene optimieren kann, muss zusätzlich der Compiler mit <tt>-ffunction-sections</tt> aufgerufen werden, um die Anwendung auf möglichst viele Sections zu verteilen.

;<tt>-Wl,--relax -mrelax</tt>: Der Linker fasst Tail-Calls wie
::<tt>CALL some_function RET</tt>
: zusammen als
::<tt>JMP some_function</tt>
: Siehe auch die Compiler-Option <tt>-f[no-]optimize-sibling-calls</tt> von oben. Zudem wird <tt>CALL</tt> umgewandelt zur kürzeren <tt>RCALL</tt>-Instruktion falls das Sprungziel im ±4 KiB-Zielbereich von <tt>RCALL</tt> liegt. Analog für <tt>JMP</tt> zu <tt>RJMP</tt>.

: Die beiden Optionen sind gleichwertig; die erste Variante veranlasst den Compiler, den Linker mit <tt>--relax</tt> aufzurufen. Die zweite Variante verwendet den allgemeinen <tt>-Wl</tt>-Mechanismus, um eine Option von der Compiler-Kommandozeile an den Linker durchzureichen.

=== Weitere Optionen ===

;<tt>-mtiny-stack</tt>: Der Compiler ändert nur das Low-Byte des Stackpointers (SP), was auf Controllern mit 16-Bit SP zu kleinerem Code führen kann. Benötigt der Code Platz auf dem Stack, so erzeugt der Compiler u.U. Code, der den SP liest, einen Offset aufaddiert/abzieht und den SP dann zurückschreibt. Dies ist aufwändig. Für den Fall, daß sich dabei das High-Byte SP nicht ändert, kann Code eingespart werden.

:Beispiel: ATtiny44 hat RAM von <tt>0x60</tt> bis <tt>0x15f</tt>. Braucht die Anwendung nicht mehr als <tt>0x60</tt> = 96 Bytes an Stack, dann kann mit <tt>-mtiny-stack</tt> compiliert werden.

=== Änderung des Binärinterfaces per Option ===

{{Warnung|
;Warnung: Im Gegensatz zu den Optionen der vorherigen Abschnitte, bei denen es sich um reine Optimierungsoptionen handelt, ändern die folgenden Optionen das Binärinterface (ABI) des vom Compiler erzeugten Codes und sind daher nur nach eingehender Prüfung anzuwenden! Wird eine Anwendung mit diesen Schaltern übersetzt, dann ist sicher zu stellen, daß ''alle'' Module inclusive Libraries damit derzeugt werden oder die ABI-Änderung sich nicht auf Code in Bibliotheken auswirkt!
}}

Vorsicht in auch deshalb geboten, weil manche Entwicklungsumgebungen wie "Atmel Studio" das ABI ''per Default'' verändern und ohne daß der Anwender es extra anfordert.

;<tt>-funsigned-char</tt>: Anders als im avr-gcc ABI ist der Typ <tt>char</tt> unsigned anstatt signed.
:Besser: Verwende die C99-Typen wie <tt>uint8_t</tt> aus dem C99-Header <tt>stdint.h</tt>.

;<tt>-funsigned-bitfields</tt>: Bitfelder mit Basetype <tt>char</tt>, <tt>short</tt>, <tt>int</tt> <tt>long</tt> und <tt>long long</tt> werden als unsigned implementiert anstatt als signed wie in der avr-gcc ABI.
:Besser: Wenn ein Bitfeld unsigned sein soll, dann mach es unsigned!

;<tt>-fpack-struct</tt>: Im Gegensatz zur avr-gcc ABI werden Strukturen und Unions per default gepackt.
:Besser: Wenn ein zusammengesetzter Typ gepackt werden soll, mache ein Typedef mit explizitem <tt>__attribute__((packed))</tt>!

;<tt>-fshort-enums</tt>: Enum-Typen werden so kurz wie möglich implementiert anstatt als <tt>int</tt> gemäß avr-gcc ABI.

;<tt>-mint8</tt>: Ein <tt>int</tt> ist nur nocht 8 Bits breit. Dies entspricht nicht mehr dem C-Standard und wird nicht durch die C-Bibliotheken wie AVR-Libc oder newlib unterstützt! Die Codegröße von 8-Bit Operationen kann sich verkleinern, weil andere Integer-Promotion Regeln angewandt werden. Literals müssen ggf. angepasst bzw gecastet werden, siehe auch C99-Makros wie <tt>UINT16_C</tt> aus <tt>stdint.h</tt>.

== Anpassungen der Quelle ==

=== Attribute noreturn, OS_main und OS_task ===

Mikrocontroller-Programme laufen normalerweise in einer Endlosschleife, so dass die main-Routine nie verlassen wird.
Teilt man dies dem Compiler mit, kann er bestimmte Optimierungen durchführen.
So ist es zum Beispiel unnötig, Code zum Sichern und Zurücklesen von Registern zu erzeugen.

Das Mitteilen funktioniert beim gcc über Attribute, die man der Deklaration oder bei der Implementierung einer Funktion anhängt:
<syntaxhighlight lang="c">static void main_loop (void) __attribute__((noreturn));
void main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>
oder
<syntaxhighlight lang="c">static void __attribute__((noreturn))
main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>

Die Funktion <tt>main_loop</tt> kann dann in <tt>main</tt> aufgerufen werden:

<syntaxhighlight lang="c">int main (void)
{
main_loop();

return 0;
}</syntaxhighlight>
Das abschließende <tt>return</tt> wird vom Compiler wegoptimiert und belegt keinen Speicher.

<tt>avr-gcc</tt> kennt weiterhin die Attribute <tt>OS_main</tt> und <tt>OS_task</tt>.
Die Verwendung von <tt>OS_main</tt> kann etwa aussehen wie folgt. Natürlich kann auch wie oben die Hauptschleife in einer eigenen Funktion implementiert werden, und das <tt>return</tt> verursacht keinen zusätzlichen Code:
<syntaxhighlight lang="c">int __attribute__((OS_main))
main (void)
{
while (1)
{
// Hauptschleife
}

return 0;
}</syntaxhighlight>

=== Statische Variablen in einer Struktur sammeln ===

Gibt es in einem Programm mehrere inhaltlich zusammengehörende Variablen, dann ist es sinnvoll diese in einer Struktur zu vereinigen. Neben einer klareren Programm- bzw. Datenstruktur kann dies auch zu kleinerem Code führen.

Beispiel ist die folgende kleine Routine, welche die Zeit in der globalen <tt>time</tt>-Strukture um eine Sekunde erhöht:

<syntaxhighlight lang="c">
#include <stdint.h>

typedef struct
{
uint8_t second;
uint8_t minute;
uint8_t hour;
} time_t;

// Globale time-Struktur enthält die Zeit
time_t time;

void next_second (void)
{
// Zeiger auf die globale time-Struktur
time_t *ptime = &time;

// time um 1 Sekunde erhöhen

if (++ptime->second == 60)
{
ptime->second = 0;

if (++ptime->minute == 60)
{
ptime->minute = 0;

if (++ptime->hour == 24)
ptime->hour = 0;
}
}
}
</syntaxhighlight>

Die Funktion enthält mehrere indirekte Zugriffe auf die <tt>time</tt>-Struktur, und es wäre günstig, wenn <tt>avr-gcc</tt> indirekte Adressierung für die Zugriffe verwendet: Alle Zugriffe geschehen über den Struktur-Zeiger <tt>ptime</tt>, und ein indirekter Zugriff per <tt>LD</tt>, <tt>LDD</tt>, <tt>ST</tt> oder <tt>STT</tt> kostet 2 Bytes, während die direkten Spreicherzugriffe <tt>LDS</tt> und <tt>STS</tt> jeweils 4 Bytes verbrauchen.

<tt>avr-gcc</tt> erzeugt mit Optimierung auf Größe jedoch folgenden Code:

<syntaxhighlight lang="c">
next_second:
// if (++ptime->second == 60)
lds r24, time
subi r24, -1
sts time, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
sts time, __zero_reg__
// if (++ptime->minute == 60)
lds r24, time+1
subi r24, -1
sts time+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
sts time+1, __zero_reg__
// if (++ptime->hour == 24)
lds r24,time+2
subi r24, -1
sts time+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
sts time+2, __zero_reg__
.L1:
ret
</syntaxhighlight>
D.h. obwohl der C-Code indirekt zugreift, enthält das Compilat direkte Zugriffe und der Code belegt 56 Bytes an Flash. Grund ist, daß der Compiler den Inhalt der Variablen <tt>ptime</tt> kennt und daher die indirekten Struktur-Zugriffe in direkte umwandelt.

Um indirekte Adressierung im erzeugten Code zu erzwingen, kann man die Struktur-Adresse als Parameter übergeben:
<syntaxhighlight lang="c">
void next_second (time_t *ptime)
</syntaxhighlight>
oder – als hässliche Lösung – dem Compiler des Wissen um den Inhalt von <tt>ptime</tt> per Inline-Assembler nehmen:
<syntaxhighlight lang="c">
asm ("" : "+r" (ptime));
</syntaxhighlight>

Dies führt denn zu folgendem Code, der um 25% kleiner ist und nur noch 42 Bytes Flash belegt:
<syntaxhighlight lang="c">
next_second:
// time_t *ptime = &time;
// asm ("" : "+r" (ptime));
ldi r30, lo8(time)
ldi r31, hi8(time)
// if (++ptime->second == 60)
ld r24, Z
subi r24, -1
st Z, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
st Z, __zero_reg__
// if (++ptime->minute == 60)
ldd r24, Z+1
subi r24, -1
std Z+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
std Z+1, __zero_reg__
// if (++ptime->hour == 24)
ldd r24, Z+2
subi r24, -1
std Z+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
std Z+2, __zero_reg__
.L1:
ret
</syntaxhighlight>

Weil AVRs nur zwei Zeiger-Register haben, die über diese Addressierungsart verfügen (Y und Z), ist diese Optimierung nur eingeschränkt anwendbar.

Werden etwa Z oder Y für andere Zwecke benötigt – etwa für Flash-Adressierung per <tt>LPM</tt> oder Y als Frame-Pointer gebraucht – verkleinert sich das Anwendungsfeld noch weiter. Zudem müssen genügend Struktur-Zugriffe nacheinander erfolgen, damit ein positiven Effekt auf die Codegröße zustande kommt. Immerhin muss die Adresse geladen werden, das Zeiger-Register wird belegt und steht nicht für andere Variablen zur Verfügung, und im Falle von Y kommen <tt>PUSH</tt>/<tt>POP</tt> im Prolog/Epilog hinzu. Werden viele unterschiedliche Struktur-Pointer verwendet ("viele" relativ zur Anzahl der verfügbaren Pointer-Registern), kann die Codegröße auch ansteigen.

Direkte Zugriffe sind in jedem Falle schneller, denn direkte und indirekte Zugriffe kosten die gleiche Zeit. Die Indirekten Zugriffe erfordern jedoch die Initialisierung des Zeiger-Registers und evl <tt>PUSH</tt>/<tt>POP</tt>.

=== Multiplikationen mit Konstanten ===

Der Compiler instanziiert sofort eine teure allgemeine Bibliotheksfunktion, auch wenn es anders ginge. Ich hatte eine einzige 32-bit Multiplikation mit 10 drin, die mir ein mulsi3 beschert hat. Mit a = (b<<3) + (b<<1) geht es in dem Fall kürzer. Wie gesagt, map-File beobachten.

;Anmerkung: Variablen als unsigned definieren, dann sollte der Compiler das selbst machen.

;Anmerkung: Auch Schieben ist teuer auf AVR. Schauen wir uns also mal an, was aus folgendem Code wird:

<syntaxhighlight lang="c">
uint32_t foo (uint32_t i)
{
return i*10;
}

uint32_t bar (uint32_t i)
{
return (i << 1) + (i << 3);
}
</syntaxhighlight>

{{Scrollbox|15ex;|
<pre>
00000032 <foo>:
32: 2a e0 ldi r18, 0x0A ; 10
34: 30 e0 ldi r19, 0x00 ; 0
36: 40 e0 ldi r20, 0x00 ; 0
38: 50 e0 ldi r21, 0x00 ; 0
3a: 19 d0 rcall .+50 ; 0x6e <__mulsi3>
3c: 08 95 ret

0000003e <bar>:
3e: 26 2f mov r18, r22
40: 37 2f mov r19, r23
42: 48 2f mov r20, r24
44: 59 2f mov r21, r25
46: 22 0f add r18, r18
48: 33 1f adc r19, r19
4a: 44 1f adc r20, r20
4c: 55 1f adc r21, r21
4e: e3 e0 ldi r30, 0x03 ; 3
50: 66 0f add r22, r22
52: 77 1f adc r23, r23
54: 88 1f adc r24, r24
56: 99 1f adc r25, r25
58: ea 95 dec r30
5a: d1 f7 brne .-12 ; 0x50 <__SREG__+0x11>
5c: 26 0f add r18, r22
5e: 37 1f adc r19, r23
60: 48 1f adc r20, r24
62: 59 1f adc r21, r25
64: 95 2f mov r25, r21
66: 84 2f mov r24, r20
68: 73 2f mov r23, r19
6a: 62 2f mov r22, r18
6c: 08 95 ret

0000006e <__mulsi3>:
6e: ff 27 eor r31, r31
70: ee 27 eor r30, r30
72: bb 27 eor r27, r27
74: aa 27 eor r26, r26

00000076 <__mulsi3_loop>:
76: 60 ff sbrs r22, 0
78: 04 c0 rjmp .+8 ; 0x82 <__mulsi3_skip1>
7a: a2 0f add r26, r18
7c: b3 1f adc r27, r19
7e: e4 1f adc r30, r20
80: f5 1f adc r31, r21

00000082 <__mulsi3_skip1>:
82: 22 0f add r18, r18
84: 33 1f adc r19, r19
86: 44 1f adc r20, r20
88: 55 1f adc r21, r21
8a: 96 95 lsr r25
8c: 87 95 ror r24
8e: 77 95 ror r23
90: 67 95 ror r22
92: 89 f7 brne .-30 ; 0x76 <__mulsi3_loop>
94: 00 97 sbiw r24, 0x00 ; 0
96: 76 07 cpc r23, r22
98: 71 f7 brne .-36 ; 0x76 <__mulsi3_loop>

0000009a <__mulsi3_exit>:
9a: 9f 2f mov r25, r31
9c: 8e 2f mov r24, r30
9e: 7b 2f mov r23, r27
a0: 6a 2f mov r22, r26
a2: 08 95 ret

</pre>
}}

: Der Funktionsaufruf samt Lib-Funktion ist garnicht sooo teuer. Bereits mit zwei Multiplikationen im Programm — auch einer Multiplikation mit einer anderen Konstanten oder einer Variablen — gewinnt die lib-Version, da der Code wiederverwendet wird. Übrigens sind diese Multiplikationsroutinen und auch die in die libgcc enthaltenen Divisionen keine "normalen" Funktionen wie sie von C erzeugt werden. avr-gcc weiß genau, welche Register diese Routinen belegen und welche nicht. Damit ist der Aufruf einer solchen Funktion billiger als ein herkömmlicher Funktionsaufruf, bei dem die Funktion als Blackbox behandelt werden muss, die alle call-clobbered Register zerstört.

=== Alle Variablen nur so breit wie nötig ===

Hatte ich eigentlich schon, nur an einigen wenigen Stellen war ich da etwas nachlässig. Mitunter reicht ein kleinerer Typ doch, wenn man z. B. vorher geeignet skaliert. Am besten nur die skalaren Typen aus <stdint.h> verwenden, das erleichtert auch das Folgende. Bei RAM Knappheit: kann ich Strings sinnvollerweise aus dem RAM ins Flash verbannen? Kann ich es mir leisten mehrere Flag-Variablen in ein Byte zusammenzufassen, auch wenn dann die Zugriffe möglicherweise etwas langsamer werden.

=== Logische Operatoren werden auf int-Größe erweitert ===

Obwohl der AVR ein 8-Bit Controller ist, verlangt der C-Standard, daß ein <tt>int</tt> mindestens 16 Bits groß ist. Wegen den Promotion-Regeln von C werden 8-Bit Operanden in Operationen auf 16 Bits aufgeweitet. Beispiel:

<syntaxhighlight lang="c">
#include <stdint.h>

uint8_t c;

void foo (uint8_t a, uint8_t b)
{
if (a == ~b)
c = 0;
}
</syntaxhighlight>
Den zweiten Operanden mit dem Komplement weitet der Compiler auf 16 Bit auf, wodurch alle high-Bits von <tt>~b</tt> gesetzt werden. Der Compiler erkennt, daß der Vergleich niemals wahr ist und optimiert ihn weg:
<syntaxhighlight lang="c">
foo:
ret
</syntaxhighlight>

Ein Cast verhindert dieses:
<syntaxhighlight lang="c">
void foo (uint8_t a, uint8_t b)
{
if (a == (uint8_t) ~b)
c = 0;
}
</syntaxhighlight>
was übersetzt wird zu:
<syntaxhighlight lang="c">
foo:
// if (a == (uint8_t) ~b)
com r22
cpse r24, r22
rjmp .L1
// c = 0
sts c, __zero_reg__
.L1:
ret

</syntaxhighlight>

;Achtung: Tatsächlich handelt es sich dabei nicht um ein Optimierungsproblem, sondern einen typischen Programmierfehler. Die beiden Varianten sind keineswegs identisch! Bei Variablen vom Typ <tt>uint8_t</tt> ist der Ausdruck <tt>(a == ~b)</tt> immer falsch! Dies unterstreicht mehr als eindringlich, daß eine gute Kenntnis der Programmiersprache das A und O jedes erfolgreichen Programmierers ist. Kenne zuallerst mal deine Programmiersprache - und zwar auch in den intimen Details!

=== Speichern von globalen Flags ===

Oft werden in den Programmen Flags verwendet um beispielsweise eingetroffene Interrupts in der main-Routine auszuwerten. Hierzu wird üblicherweise eine globale Variable verwendet.

Um den Wert dieser Variable abzufragen, muss sie jedoch erst aus dem SRAM in ein Register geladen werden, und kann dann erst auf ihren Status hin überprüft werden. Eine Möglichkeit ist, der globalen Variablen ein einziges Register fest zuzuordnen:
<syntaxhighlight lang="c">
register uint8_t counter8_1 asm("r2");
register uint8_t counter8_2 asm("r3");
register uint16_t counter16_1 asm("r4"); // r4:r5
register uint16_t counter16_2 asm("r6"); // r6:r7
</syntaxhighlight>
siehe auch: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind

Als Alternative kann man ein nicht verwendetes Register des I/O-Bereichs verwenden. Dabei würde sich z. B. das Register eines zweiten UARTs, oder das EEPROM-Register anbieten, falls diese nicht benötigt werden.

Neuere AVR-Modelle besitzen für diesen Zweck 3 frei verwendbare Bytes im bitadressierbaren I/O-Bereich: GPIOR0-2.

{{Warnung|
;Warnung: Dieses Vorgehen verändert das ABI! Um dieses Feature fehlerfrei anzuwenden, ist einiges an Wissen über die Interna von GCC notwendig. Auch ein korrekt funktionierendes Programm ist keine Garantie dafür, daß die globalen Register fehlerfrei implementiert wurden. Unter Umständen bringen erst spätere Codeänderungen/-erweiterung den Fehler zum Vorschein, und weil der Fehler vorher nicht akut war, sucht man sich den Wolf an der falschen Stelle im Code anstatt bei der globalen Registern. Siehe auch [[Globale Register]].}}

=== Puffern von volatile-Variablen ===

Der Compiler behandelt volatile-Variablen bei mehreren Manipulationen wie heiße Kartoffeln. Für jeden einzelnen Vorgang wiederholt sich das Spiel:

* aus dem Speicher holen
* bearbeiten
* zurückspeichern

Unter Umständen ist dieses Verhalten unsinnig. Ein Minimalbeispiel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
var++;

if (var > 100)
var = 0;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird '''var''' pro [[ISR]]-Ausführung zwei mal aus dem RAM geholt und zurückgeschrieben. Das ist überflüssig, weil die Interruptrountine nicht unterbrochen werden kann. Aus Sicht der ISR bräuchte man eigentlich kein volatile, kann es aber wegen des Zugriffs aus main heraus nicht weglassen. Eine Lösung findet sich im folgenden Schnipsel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
char temp = var;

if (++temp > 100)
temp=0;

var = temp;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird die globale Variable '''var''' in der lokalen Variable '''temp''' gepuffert. Ein Nachteil durch das Anlegen von '''temp''' ergibt sich nicht, da das dafür verwendete Register für die Manipulation sowieso benötigt wird.

Wie alle Optimierungen kann dieses Vorgehen auch nach hinten losgehen: Wenn Laden und Zurückspeichern von '''var''' weit auseinanderliegen (extrem lange ISR), müllt man sich die Register zu. Im schlimmsten Fall wird '''temp''' sogar zwischenzeitlich auf dem Stack ausgelagert.

=== Schleifen ===

Bei Schleifen, die eine bestimmte Anzahl an Durchläufen ausgeführt werden sollen, ist es besser den Schleifenzähler vorher auf einen Wert zu setzen, und am Ende einer Do-While Schleife diesen zu dekrementieren.
So beschränkt sich die Sprungbedingung auf ein brne (branch if not equal).

Beispiel:
<syntaxhighlight lang="c">
uint8_t counter;
counter = 100;
do
{
// mach irgendetwas
} while (--counter);
</syntaxhighlight>

Achtung: Derartige Optimierungen sind meistens zweifelhaft und sehr Compilerabhängig. Compiler betreiben aufwendige Code- und Datenflussanalysen, in denen sie viele Dinge ins Kalkül ziehen, die ein menschlicher Programmierer im Regelfall nicht mehr überblicken kann. Von einem ordentlichen Compiler kann erwartet werden, dass er derartige Umstellungen (sofern sie möglich sind) in Eigenregie erledigt. Auch wenn es einzelne Compiler bzw. Compilerversionen gibt, in denen ein manueller Umbau einer derartigen Schleife tatsächlich eine Verbesserung bringt, sollte man immer im Hinterkopf behalten, dass sich in der nächsten Compilerversion alles umdrehen kann. Im Zweifelsfall lieber die Schleifenvariante benutzen, die der Situation angemessen ist und die den gewünschten Vorgang am klarsten beschreibt. Wenn dieser Vorgang im weitesten Sinne einen Countdown darstellt, dann ist natürlich nichts gegen eine derartige Schleifenkonstruktion einzuwenden.

=== Schiebeoperationen ===

Oft benötigt man Schiebeoperationen, um Daten Bit für Bit zu [[Bitmanipulation | verarbeiten]], z.B. für [http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister Soft]-[[SPI]]. Hier empfiehlt es sich DRINGEND, möglichst nur Schiebeoperationen mit konstanten Verschiebungszähler durchzuführen, diese sind auf dem AVR deutlich schneller als Schiebeoperationen mit Variablen, welche meist durch mehrfache Funktionsaufrufe mit Scheifen etc. gelöst werden. Dabei verwendet man oft konstante Bitmasken, um die einzelnen Bits nacheinander zu maskieren.

Noch schneller geht das Schieben von Konstanten um einen konstanten Wert, denn das macht der Compiler bei eingeschalteter Optimierung noch während des Compilierens. Gerade für schnelle IO-Operationen kommt dann meist nur ein einziger ASM-Befehl heraus (sbi, cbi).

Ebenso ist es wenig empfehlenswert, 32 oder gar 64 Bit Datentypen zu schieben, das dauert sehr lange. Besser ist es, die Daten als Array von 8 Bit Werten zu handhaben und diese zu schieben, das ist meist deutlich schneller. Gute Beispiele findet man [http://www.mikrocontroller.net/topic/179566#1729219 hier] und [http://www.mikrocontroller.net/topic/169509#1631439 hier].

<syntaxhighlight lang="c">
#define DATAPORT PORTD
#define IO-BIT PD4

uint8_t a, b, i;

i=5
a = b << i; // variabler Verschiebewert, langsam
a = b << 5; // konstanter Verschiebewert, schnell

DATAPORT |= (1<<IO-BIT); // alles Konstanten, sehr schnell
</syntaxhighlight>

==Optimierung der Ausführungsgeschwindigkeit==

Hierzu gibt es schon eine Application-Note von Atmel. Diese AppNote bezieht sich auf den IAR-Compiler. Die darin genannten "Optimierungen" sind für avr-gcc größtenteils obsolet oder bleiben bestenfalls ohne Effekt.

Weblinks:
* [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035]: Efficient C Coding for AVR
* [http://en.wikipedia.org/wiki/Program_optimization Program optimization] auf Wikipedia, engl.
* [http://bleaklow.com/2012/06/20/sensor_smoothing_and_optimised_maths_on_the_arduino.html Sensor smoothing and optimised maths on the Arduino] - Multiplikation vs. Division

== Fußnoten ==
<references/>

== Links ==
[http://www.atmel.com/Images/doc8453.pdf Atmel AVR4027]: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers ([http://www.atmel.com/Images/AVR4027.zip Beispiel-Code])

[[Category:avr-gcc]]

AVR Checkliste

2014-02-16T19:56:00Z

Mox-mox: Bindestrich eingefügt

[[Category:AVR]]
Diese Seite soll als erste Anlaufstelle dienen, wenn der [[AVR]]-Mikrocontroller mal wieder nicht so will wie er soll. Es wird versucht, die Standardfehler und Probleme aufzulisten und zu erklären, was man dagegen tun kann.

== Hardware ==

=== Anderen Controller benutzt als den im Schaltplan: Pinkompatibilität sichergestellt? ===

Nur wenige AVR-Controller sind pinkompatibel und damit untereinander austauschbar. Manchmal liegen gar die am dringensten benötigten Funktionen (ISP-Programmierung) bei anderen Controllern auf anderen Pins. Unbedingt vorher die Belegungen anhand der Datenblätter vergleichen!

=== Fuses richtig gesetzt? ===

Die AVR-Controller haben 'Fuses' (deutsch: 'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene bestimmen. Ein häufiger Fehler ist beispielsweise, dass die falsche Taktquelle gewählt wurde (Fuse "CKSEL" etc.): einige AVRs können mit dem internen Oszillator (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), fehlt dem Controller unter Umständen der Systemtakt und er läuft nicht an, oder man bekommt auf der seriellen Schnittstelle Nonsens, oder die Timer bzw. Zeitschleifen im Programm laufen zu langsam oder zu schnell.

Eine andere Fuse (JTAGEN) schaltet auf einem Port (z. B. PORTC auf ATMega32) die JTAG-Unterstützung ein bzw. aus. Wenn sie eingeschaltet ist, funktionieren vier Bits dieses Ports nicht wie gewohnt, da sie für die JTAG-Schnittstelle reserviert werden.

In dem zum STK500 gehörenden Entwicklungstool 'AVR Studio' gibt es in der Programmer-Dialogbox einen Tab 'Fuses', der controllerabhängig den Status der Fusebits anzeigt und Änderungen ermöglicht.
Siehe auch: [[AVR Fuses]].

=== ISP-Adapter ===

Bei ISP-Programmieradaptern für den Parallelport kann es zu Inkompatibilitäten mit manchen Ports kommen. Tritt das Problem auch auf, wenn der ISP-Adapter an einem anderen Rechner angeschlossen ist? Funktioniert es vielleicht mit einer anderen Software? Siehe auch: [[AVR In System Programmer]]).

Bei seriellem Programmer mit Controller (STK500, Atmel AVRISP etc.): Programmieren dauert sehr lange, es gibt Fehler. Abhilfe: ISP Taktrate richtig einstellen (<1/4 F_CPU).

Beim Programmieren mit dem usbasp Programmieradapter muss die Geschwindigkeit richtig eingestellt werden. Bei einem AVR der auf den eingebauten 1 Mhz läuft muss mit langsamer Geschwindigkeit (Jumper zu) programmiert werden.

=== Programmieren via SPI und angeschlossene SPI-Hardware ===
Wenn Peripherie über SPI angebunden ist, muss sich diese zum Programmierzeitpunkt auf dem Bus neutral verhalten. Normalerweise bedeutet dies, dass die Slave-Select/Chip-Select-Leitungen der Peripherie auf high gezogen werden müssen, wenn die Chips keinen internen Pull-Up haben. Werte von 10 kΩ bis 100 kΩ für normale Anwendungen haben sich bewährt.

=== Spannungsversorgung richtig angeschlossen? ===

Der AVCC-Pin ist der Versorgungsanschluss für den AD-Wandler und den zugehörigen Port. Er ist nicht an allen AVRs vorhanden; wenn er aber vorhanden ist, so muss er auf jeden Fall angeschlossen sein, auch wenn der AD-Wandler nicht benutzt wird. Wird der AD-Wandler verwendet, sollte zur Verbesserung der Genauigkeit der AVCC-Pin über einen Lowpass-Filter angeschlossen werden (siehe Datenblatt).
Oft funktioniert die Programmierung des Controllers auch, wenn Vcc oder GND nicht richtig angeschlossen ist. Zur Sicherheit kann man mit einem Messgerät direkt an den Anschlüssen des AVRs kontrollieren (VCC-GND, AVCC-GND) prüfen, ob die Verbindungen korrekt sind. Es empfiehlt sich, vor dem Einsetzen bzw. Einlöten des Controllers die Versorgungsanschlüsse nochmals zu prüfen, um sicherzustellen, dass man den IC nicht durch eine zu hohe Spannung aufgrund eines Fehlers in der Versorgung zerstört.

=== Reset-Pin korrekt beschaltet? ===

Der Reset-Anschluss am AVR ist 'active-low', d. h. wenn man den Pin mit GND (Masse) verbindet, wird der Controller zurückgesetzt gehalten. Zwar haben die meisten(!) AVRs einen internen Pullup-Widerstand, der den Reset-Pin gegen VCC "zieht", dieser ist jedoch relativ hochohmig (ca. 50 kΩ, vgl. Datenblatt) und reicht in extrem stark gestörter Umgebung nicht aus, um den Reset-Pin sicher "hochzuhalten". Als Mindestbeschaltung empfiehlt sich dringend, einen externen Pullup-Widerstand vorzusehen (typisch 10 kΩ), der den Reset-Pin mit VCC verbindet. Er sollte nicht kleiner als 4,7 kΩ sein, da der Programmieradapter sonst eventuell den Reset-Pin während des Programmiervorgangs nicht sicher auf "low" ziehen kann. Mit einem Oszilloskop kann man gut überprüfen, ob der Pegel am Reset-Pin sauber zwischen high und low wechselt. Zusätzlich sollte man auch noch einen Kondensator 47 nF oder 100 nF zwischen Reset-Pin und GND anordnen. Dieses RC-Glied sorgt dafür, dass der Controller beim Einschalten der Versorgungsspannung für eine definierte Zeitspanne im Reset gehalten wird. Im laufenden Betrieb sorgt der Kondensator dafür, dass der Reseteingang unempfindlich gegenüber Spikes und Glitches wird. Er sollte deshalb unmittelbar in Pin-Nähe beim Prozessor untergebracht werden. Dieser Kondensator darf jedoch nicht verwendet werden, wenn [[debugWIRE]] möglich sein soll.

Atmel empfiehlt zusätzlich noch zum Schutz vor Überspannungen eine externe Diode nach VCC ("Clamp-Diode"), da für den Reset-Pin keine interne vorhanden ist. Diese Diode bereitet jedoch bei manchen Programmieradaptern Schwierigkeiten. Allerdings schützt die Diode den Controller davor, in den High-Voltage Programming Mode zu schalten, zum Beispiel als Folge von Störspannung wegen EMV, und dadurch den Programmspeicher zu überschreiben.

=== Flashen / Lesen / Fuse nur einmal möglich ===

Es kann vorkommen, dass ein AVR nur einmal programmiert werden kann, danach geht es nicht mehr (z.B. Typ wird nicht mehr erkannt). Erst nachdem die Versorgungsspannung getrennt / wieder verbunden ist, geht es erneut.

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR einmal programmieren.

Der Reset PIN müsste bei korrekter Beschaltung eine Spannung nahe VCC (z.B. 4.9V) aufweisen, ist die Spannung bei GND, ist der Pin kurzgeschlossen und verursacht dieses Problem.

=== Abblockkondensator(en) ordnungsgemäß installiert? ===

Abblockkondensatoren dienen dazu, hochfrequente Störungen, die durch Schaltvorgänge verursacht werden können, nach GND abzuleiten, so das sie den Integrierten Schaltkreis, also das IC nicht erreichen. Dort würden sie Funktionsstörungen verursachen. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen
* eine niederimpedante Anbindung sollte gegeben sein - also keine Stegleitungen. Dies bedeutet, das die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen MUSS und dann weiter zm IC gereicht wird.

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, jeder Abblokkondesnator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leiten) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind (der Widerstand=Impedanz ist bei hochfrequenzen Spannungen zu groß - ein schneller (hochfrequenter) Spannungsimpuls kann so nicht abgeleitet werden)!

=== Quarz oder Quarzoszillator angeschlossen? ===

Die neueren AVRs haben einen internen [[Oszillator]], der im Auslieferungszustand über die entsprechenden Fuses eingeschaltet ist. In diesem Fall muss kein externer [[Quarze und AVR|Quarz]] mehr angeschlossen werden. Man kann in den [[AVR Fuses|Fuse-Bits]] aber einstellen, dass man einen externen Taktgenerator (''external clock'', z. B. Quarzoszillator) oder externen Quarz (''external crystal'') verwenden möchte.

Dann, oder wenn der AVR keinen internen Takt hat, wird an die entsprechenden Pins des Controllers ein Quarz (''external crystal'', Bauelement mit zwei "Beinchen") oder Quarzoszillator (''external clock'', Bauelement mit vier "Beinchen") angeschlossen. Im Falle eines Quarzes werden die XTAL-Pins mit den beiden Anschlüssen des Quarzes und jeweils mit einem Kondensator (ca. 12 bis 22 pF) (vgl. Datenblatt ATMega 8) gegen Masse angeschlossen. Im Falle eines Quarzoszillators reicht es aus, den Taktausgang mit dem XTAL1-Pin zu verbinden, und den XTAL2-Pin unbeschaltet zu lassen. Die Fuses sind entsprechend einzustellen.

=== Alle Ground-Anschlüsse beschaltet? ===

Bei IC's mit mehreren Ground-Anschlüssen müssen immer alle Anschlüsse beschaltet werden. Siehe http://www.mikrocontroller.net/forum/read-1-107259.html

=== Alle Lötstellen in Ordnung? ===

"Kalte", d.h. schlechte Lötstellen erkennt man an ihrer matten Oberfläche (bei bleihaltigem Lot). Bei beschädigten Lötstellen erkennt man oft einen Riss, der sich kreisförmig um die Mitte des Lötpunktes herum gebildet hat. Solche Stellen verursachen oft erst bei mechanischer Beanspruchung Probleme.

Bei kleinen Abständen (SMD-Bauteile) müssen besonders Verbindungen zwischen benachbarten Lötungen kontrolliert werden.

Bei Lochrasterplatinen kann man mit einem spitzen Messer (Bastelmesser) die Zwischenräume von möglichen leitenden Verbindungen befreien.

=== Eingänge ===

Taster müssen:

* entprellt werden ([[Entprellung]])

* einen [[AVR-GCC-Tutorial#Tasten_und_Schalter|Pullup-Widerstand]] besitzen, so sie ''active-low'' betrieben werden, d.h. wenn beim Tastendruck der Pin mit GND (Masse) verbunden wird (dies ist die übliche Anschaltung). Man kann einen externen Pull-Up Widerstand (typ. 10 kOhm) benutzen oder den internen aktivieren (DDR als Eingang also "0", PORT auf "1").

Will man einen Taster ''active-high'' betreiben, soll also bei Tastendruck eine "1" in PIN gelesen werden, ist ein externer Pull-Down-Widerstand (typ. 10 kOhm) gegen GND anzuschließen, denn interne Pull-Downs sind nicht verfügbar.

Symptome: Aufgrund des Prellens bekommt man bei einem Tastendruck statt eines Signals mehrere, und beim fehlenden Pullup fängt man sich Störungen (z. B. das 50 Hz-Netzbrummen) ein, da der Pin nicht auf einem "definierten Pegel" liegt, wenn der Taster nicht geschlossen ist. Soll z. B. bei einem Tastendruck eine LED angehen, dann leuchtet die LED durch das Netzbrummen plötzlich mit 50 Hz anstatt aus zu sein.

* active low: ein Anschluss des Tasters an den Port-Pin, den anderen Taster-Anschluss an GND; internen Pull-Up-Widerstand aktivieren oder externen Widerstand zwischen Port-Pin und VCC.

* active high: Taster zwischen Port-Pin und VCC; externen Widerstand zwischen Port-Pin und GND.

=== Ausgänge ===

Man sollte darauf achten, das "kritische" Ausgänge, d.h. Ausgänge, über die nicht "nur" eine LED geschaltet wird, einen definierten Zustand haben, wenn der Portpin auf "Eingang" und damit hochohmig geschaltet ist. Dadurch wird sichergestellt, dass beim Einschalten nicht kurz ein Verbraucher geschaltet wird (z. B. "Zucken" eines Motors). Dies kann man bewerkstelligen, indem man extern Widerstände (auch hier Pull-Up bzw. Pull-Down genannt, typ. 10 kOhm) an den Ausgangs-Pins vorsieht, die den Ausgang auf den gewünschten Zustand ziehen.

=== Besonderheiten bei ATmega128 und seinen Derivaten im 64-Pin-Gehäuse===

[[Bild:isp.png|thumb|300px|right|ISP-Adapter]]
Der ATmega64 und der ATmega128 sowie alle vom ATMega128 abgeleiteten AVRs im 64-Pin-Gehäuse (ATMega641/1281/2561, AT90PWM2/3/2B/3B sowie AT90CAN32/64/128, Ausnahmen sind nur AT90USB64/128, die eine ganz andere Pinbelegung haben) haben besondere Fallstricke, über die man bei nicht ausreichendem Datenblattstudium leicht stolpert.

* Der erste betrifft den Anschluss der ISP-Signale (MISO, MOSI, SCK, RESET). Dieser erfolgt nicht wie bei den meisten anderen AVR-Controllern an den gleichnamigen Pins, sondern an PDI, PDO, SCK und RESET. Die Pinzuordnung ist:
:* MOSI → PE0 (Pin 2)
:* MISO → PE1 (Pin 3)
:* SCK → PB1 (Pin 11)
:* RESET → RESET (Pin 20)
: PEN (Pin 1) hat für normale ISP-Adapter keine Bedeutung und kann offen gelassen oder direkt mit Vcc verbunden werden. Die Benutzung der Pins PDI und PDO anstelle von MOSI und MISO gilt für praktisch alle ATmega128-Derivate im 64-Pin-TQFP-Gehäuse, darunter AT90CAN32/64/128 und ATmega641/1281/2561. Im Zweifelsfall im Datenblatt (Pin Configuration) nachsehen, ob PE0 und PE1 mit "PDI" bzw. "PDO" beschriftet sind.

* Die zweite kleine Gemeinheit betrifft die M103C-Fuse (ATmega103 Compatibility Mode, nur bei den ATmega-Typen, nicht beim AT90CAN32/64/128). Diese ist bei fabrikneuen Atmega64/128 gesetzt und sorgt dafür, dass sich diese wie ein Atmega103 verhalten.
** Dies hat zur Folge, dass ein für den ATmega64 oder ATmega128 geschriebenes Programm beim ersten RET abstürzt, da der SRAM an einer anderen Stelle endet als erwartet und somit der Prozessor keine gültige Rücksprungadresse vom Stack holen kann.
** Außerdem funktionieren einige IO-Pins an PORTC, PORTF und PORTG anders.
** Für weitere Infos bzgl. [[TWI]], [[UART]], [[Timer]], [[Bootloader]] und Kalibrierung des internen RC-Oszillators unbedingt das Datenblatt lesen.

== Software ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das fuehrt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

=== Alle Interruptvektoren definiert? ===

Wenn man irgendwelche [[Interrupt]]vektoren verwendet, sollte man alle definieren, auch die nicht benutzten. Passiert es dann aufgrund eines Fehlers, dass ein Interrupt unbeabsichtigt ausgeführt wird, so führt der Controller dann eine definierte Aktion aus. Benutzt man eine Hochsprache wie C oder Basic, nimmt einem der Compiler diese Arbeit ab.

Ausserdem sollte man immer im Datenblatt des Controllers nachsehen, wie die Interrupttabelle aufgebaut ist. Die kleinen AVRs verwenden ein RCALL zum Anspringen der Interrupts, welches 1 Wort lang ist. Die grossen AVRs mit mehr als 8 KiBi FLASH verwenden ein CALL, welches 2 Worte lang ist. Verwendet man nun den falschen Befehl, verschieben sich die Einsprungadressen und das Chaos ist perfekt.

In einem komplett interruptlosen Programm kann man auf die Interrupttabelle selbstverständlich verzichten (erkennbar daran, dass nirgendwo im Code Interrupts mittels Assembler-Befehl SEI eingeschaltet werden).

Oft hilft es einen Catch All Interruptvektor zu definieren um herauszufinden ob ein Fehler (z.B. ein Neubeginn des Programms) vorliegt.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

ISR (BADISR_vect)
{
// Hier eine Fehlerausgabe definieren.
// Z.B. UART-Ausgabe oder ein PIN toggeln
}</syntaxhighlight>

Dann findet man solche Fehler recht schnell.

=== Alle Konfigurationsregister korrekt initialisiert? ===

Alle benötigten Konfigurationsregister (auch "I/O-Register" genannt) eines Mikrocontrollers müssen korrekt initialisiert werden. Bei Fehlfunktionen sollten diese Konfigurationen noch einmal mit dem Datenblatt abgeglichen werden.
Manchmal ist es auch sinnvoll, bestimmte Funktionen explizit abzuwählen. Ein Beispiel hierfür ist der [[Analog-Komparator]] des AVR: Schaltet man diesen ab, wenn man ihn nicht benötigt, kann man dadurch ein wenig Strom sparen.
Wenn man besonders "sauber" programmieren möchte, initialisiert man Konfigurationsregister immer, d.h. auch wenn sie nicht im Programm verwendet werden. Dies verhindert mögliche zufällige Fehlkonfigurationen.

=== Stackpointer initialisiert? (Nur in Assembler relevant) ===

Fehlerbeschreibung: ''Das Programm lief, bis ein "rcall" oder ein Interrupt eingefügt wurde. Danach ging plötzlich gar nichts mehr.''

Wahrscheinliche Ursache: Der Stack ist ein spezieller Bereich im RAM, der von Sprungbefehlen und Interruptaufrufen dazu verwendet wird, die Rücksprungadresse ins Hauptprogramm zu speichern. Da der Stack bei den AVRs nach "unten" wächst, d.h. in Richtung Anfang des RAMs, wird er üblicherweise ans Ende des RAMs gelegt. Der Stack muss vor der ersten Benutzung, am besten direkt am Anfang des Programms, initialisiert werden (sonst ist nach einem Sprung in ein Unterprogramm die Rücksprungadresse undefiniert und das Programm wird an einer unvorhersehbaren Stelle weiter ausgeführt, was in der Regel einen Absturz zur Folge hat). "Den Stack initialisieren" bedeutet, den Stackpointer auf den gewünschten "Startwert" zu setzen. Meistens wird dafür die letzte RAM-Adresse gewählt.

Die Initialisierung unterscheidet sich geringfügig je nach verwendetem AVR. Bei den alten AT90xxxx und den ATtinys ist sie mit zwei Zeilen erledigt:

<syntaxhighlight lang="avrasm">
ldi r16, RAMEND ;Die Adresse der letzten Stelle im RAM in r16 laden
out SPL, r16 ;Die Adresse in das Register SPL ausgeben
</syntaxhighlight>

Da die ATmegas mehr RAM haben, reicht das 8 bit-Register SPL nicht mehr, und es ist ein zweites (SPH) dazugekommen. Die Initialisierung des Stacks erfordert hier vier Zeilen:

<syntaxhighlight lang="avrasm">
ldi r16, LOW(RAMEND) ;Untere 8 bit des 16 bit-Wertes RAMEND laden
out SPL, r16
ldi r16, HIGH(RAMEND) ;Obere 8 bit laden
out SPH, r16
</syntaxhighlight>

=== 16bit-Register in richtiger Reihenfolge geladen/gelesen? (Nur in Assembler relevant) ===

Bei den 16-bit Registern (z. B. Timer1) genau die Hinweise im Kapitel "Accessing 16-bit Registers" beachten!

So muss z. B. das High-Byte VOR dem Low-Byte geschrieben werden, weil mit dem Schreiben des Low Byte das gesamte Register "übernommen" wird.
Beim Lesen muss zuerst das Low-Byte gelesen werden, dann das High-Byte.
Es wird dadurch garantiert, dass sich zwischen den beiden einzelnen Befehlen nicht noch das Register weiter verändert, z. B. beim 16bit Counter.
Möglich wird das durch ein "temporary Register", von dem es aber nur eines gibt - was beachtet werden muss, da zwischen diesen beiden einzelnen Lese-/Schreib-Befehlen kein Interrupt auftreten darf, der selber das temporary Rgegister benutzt.

In C oder Basic kümmert sich der Compiler um das Problem - man liest oder beschreibt dann einfach z. B. TCNT1 anstatt TCNT1H und TCNT1L einzeln.

=== Flag richtig gelöscht? ===

Ein beliebter Fehler ist, dass man überliest, dass gesetzte Flags (z. B. die Interrupt-Flags) durch beschreiben mit einer '1' und nicht mit einer '0' gelöscht werden!

Beispiel:
* das Flag ist zuerst '0'
* das Ereignis (z. B. Zählerüberlauf, also Bit TOV0 in TIFR) tritt auf und setzt das jeweilige Bit im Register auf '1'
* wir haben auf die '1' gewartet und wollen das Bit nun wieder löschen und müssen dafür eine '1' (eins!) in das Register schreiben, '''keine''' '0'. Trotzdem wird das Bit dadurch '0' z. B.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

Das ganze ist kein Fehler, sondern hat seine guten Gründe.

Wenn Interrupts zugelassen sind (z. B. in TIMSK) und die Interruptroutine aufgerufen wird, werden diese Flags zumeist automatisch gelöscht.

Der UART-Empfangs-Interrupt (RXC in UCSRA) jedoch nicht! Der wird gelöscht durch Auslesen des Empfangsregisters (UDR). Hier liegt wiederum ein beliebter Stolperstein: Man prüft oft zuerst in der Interruptroutine die Fehlerflags (z. B. Parity) und macht dann manchmal den Fehler das empfangene Zeichen im Fehlerfall nicht auszulesen. Das führt dann zum Absturz (der IRQ wird immer wieder aufgerufen) - man muss also immer das UDR lesen auch wenn etwas Fehlerhaftes drinsteht.

Zusätzlich ist zu beachten, dass in C die Interrupt-Flags '''nicht''' mit einer Veroderung des Registers (z. B. TIFR |= (1 << TOV0)) gelöscht werden sollten, da bei dieser Operation alle anderen evtl. gesetzten Flags im betreffenden Register ebenfalls gelöscht werden. Es ist die Schreibweise von oben zu benutzen (also TIFR = (1 << TOV0))!

=== Alle Interrupt-Variablen als volatile bezeichnet? ===

Das Schlüsselwort volatile kann als Attribut an Variablen gehängt werden. Der Ausdruck „volatile int i“ versieht die Integervariable i mit dem Attribut volatile. Das Attribut weist den Compiler an, diese Variable nicht zu optimieren, sondern im Speicher abzulegen und zu beachten, dass diese Variable von anderen Prozessen geändert werden kann. Normale Variablen können durch den Compiler auf Register reduziert werden, oder die Daten werden einmalig aus dem Speicher geladen und erst am Ende des Programmes wieder zurückgeschrieben. Das kann Probleme bereiten, wenn beispielsweise in einer [[Interrupt]]routine die Variable verändert wird. Darum müssen alle globalen Variablen, die in einer Interruptroutine geändert werden, mit diesem Schlüsselwort versehen werden.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen >8 Bit welche in der ISR und in der Hauptfunktion genutzt werden muss [[atomar]] erfolgen. Das Vergessen dieser Regel führt selten zu Problemen, aber wenn dann zu schwer Nachvollziehbaren...

=== Die Programmierfrequenz passend? ===

Sollte ein Programmieren nicht möglich sein erst einmal die Programmiergeschwindigkeit bei AVR dude mit der Option
-B bitclock anpassen
wobei bitclock die Perioden dauer in Milisekunden (floating-point Zahl) ist. Normalerweise -B 1 für Controller mit >=4MHz daher ist bei der Erstprogrammierung ein höherer Wert zu versuchen.

== Serielle Verbindungen ==

=== [[I²C]]/[[TWI]] ===

Sind die Leitungen SCL und SDA mit einem Pullup-Widerstand ausgestattet? Die I²C-Bus-Leitungen SCL und SDA müssen über einen Pullup-Widerstand mit einem Wert von 4,7 kΩ bis 10 kΩ mit der Versorgungsspannung (+5 V) verbunden sein.

=== UART/USART ===

==== Übertragungsprobleme durch falschen oder ungenauen Takt ====

* Der interne [[Oszillator]] ist recht ungenau und nicht temperaturstabil. Daher kann die Umgebungstemperatur auch den [[UART|USART]]-Takt verändern. Für serielle, asynchrone Kommunikation per UART sollte man deshalb immer einen Quarz oder einen Oszillator verwenden, egal bei welcher Baudrate: 3% Fehler sind immer 3% Fehler, egal ob bei 1200 oder 9600 [[Baud]]. Falls doch der interne Oszillator verwendet wird: Wurde er für die richtige Frequenz und Betriebsspannung kalibriert?

* Nicht mit allen Quarzen kann man alle Baudraten genau genug erzeugen. Deswegen gibt es [[Baudratenquarz]]e wie z. B. 3,6864 MHz. Näheres steht im Datenblatt.

* Geschieht die Konfiguration des U(S)ART automatisch durch die Programmiersprache (z. B. in [[Bascom AVR|BASCOM]], [[C]]), dann muss dort der Takt ''genau'' angegeben werden. Setzt man z. B. einen 3,6864 MHz-Quarz ein, darf man dort nicht einfach "4 MHz" angeben, weil dann die Abweichung mit ca. 8% zu hoch wäre. Damit funktioniert die Übertragung nicht mehr.

* Im AVR-Studio kann man die Taktfrequenz sowohl über ein <code>#define F_CPU</code> im Quelltext als auch über das Optionsmenu oder das selbsterstellte Makefile einstellen. Es darf nur ''eine'' Variante verwendet werden!

* Wenn ein externer Oszillator oder Quarz angeschlossen ist: Sind die [[AVR Fuses | Fuses]] des Controllers so gesetzt, dass er auch verwendet wird?

* Ist die Fuse CLKDIV ''nicht'' programmiert?

* Es taucht auch des öfteren das Missverständnis auf, dass man nur F_CPU verändern muss, um den µC mit einem anderen Takt laufen zu lassen. Dem ist nicht so. Der µC-Takt wird durch die Fuses bzw. den eventuell angeschlossenen Quarz oder Quarzoszillator bestimmt. F_CPU dient nur dazu, die dadurch festgelegte Frequenz im C-Programm zur Verfügung zu haben. F_CPU ist nur eine Information, mit der man bei der Programmierung arbeiten kann. Aber ein anderer F_CPU-Wert führt nicht dazu, dass der µC dann magisch auf diese Frequenz umgestellt wird.

* Um zu prüfen, ob der externe Quarz auch wirklich verwendet wird, kann man mittels _delay_ms() testweise eine LED im Sekundentakt blinken lassen. Den Unterschied zwischen Quarz und internem RC-Oszillator kann man bei grösseren Frequenzunterschieden leicht sehen. Ebenso sieht man, ob versehentlich die CLKDIV Fuse gesetzt ist: die Blinkfrequenz ist dann achtmal langsamer. Allerdings muss man auch hier aufpassen. Siehe [[AVR-GCC-Tutorial#Warteschleifen (delay.h)|AVR-GCC-Tutorial: Warteschleifen]].

Im folgenden Programm muss angepasst werden:
*Die vermeintliche Taktfrequenz F_CPU
*der Port und der Pin, an dem eine LED angeschlossen ist.

Wird das Programm laufen gelassen, muss die LED 1 Sekunde ein/1 Sekunde aus sein. Stimmen die Zeiten nicht, ist das ein deutlicher Hinweis darauf, dass die tatsächlich vom µC verwendete Taktfrequenz nicht mit der in F_CPU angegebenen übereinstimmt. Das Programm muss mit aktivierter Optimierung <code>-Os</code> compiliert werden.
<syntaxhighlight lang="c">
// Testprogramm für CPU Takt
// Hier die vermeintliche Taktrate des µC eintragen
// Im Beispiel hier: 1Mhz

#define F_CPU 1000000

#include <avr/io.h>
#include <util/delay.h>

// Hier die tatsächlich verwendeten Parameter angeben

#define LED_PORT PORTB
#define LED_DDR DDRB
#define LED_PIN PB0

int main()
{
LED_DDR |= 1 << LED_PIN;

while (1)
{
LED_PORT ^= 1 << LED_PIN;
_delay_ms(1000);
}

return 0;
}
</syntaxhighlight>

* Erscheinen im Terminalprogramm kryptische Zeichen anstatt ordentlichen Buchstaben (z. B. ü statt A), liegt das zu 99,9% an einer falsch eingestellten/erzeugten Baudrate im Mikrocontroller. Meistens wiederum liegt dies daran, dass der µC nicht mit der vermeintlichen Taktrate läuft und daher die Baudratenparameter falsch berechnet werden.

* URSEL-Bit in UCSRC: Bei der Initialisierung der UART beachtet, wenn das für den verwendeten AVR notwendig ist, siehe [[AVR-GCC-Tutorial/Der_UART#Die_UART-Register|AVR-GCC-Tutorial/Der UART: Die UART-Register]].

* In den Tutorials für [[AVR-Tutorial: UART |Assembler]] und [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_UART GCC] wird die Nutzung recht gut erklärt und mit Beispielen erläutert.

==== Sonstige Fehlerquellen bei UART/USART ====

* Funktioniert die Datenübertragung zum PC nur solange der Programmieradapter eingesteckt ist, deutet dies auf ein Problem mit der Masse hin (z. B. GND-Anschluss am RS232-Stecker nicht belegt oder dergleichen).

* Der Pegelwandler/Inverter (z. B. MAX232) muss mit Kondensatoren für die internen Ladungspumpen beschaltet werden. Beim MAX232 sind dies mindestens vier Kondensatoren ≥ 1 µF (Polung beachten!), beim MAX202, MAX232A und MAX3232 vier Kondensatoren ≥ 100 nF. Hinzu kommt der obligatorische Abblockkondensator von 100 nF keramisch zwischen VCC und GND des ICs. Das jeweilige Datenblatt gibt Auskunft über die Beschaltung bei "typischer Anwendung".

* TX/RX vertauscht? Modem- oder Nullmodemkabel?

* Bei Kommunikation mit PC: ist die serielle Schnittstelle richtig konfiguriert? Nicht nur Baudrate, Stopp- und Parity-Bits, sondern auch Handshakeverhalten muss stimmen (kein Hardwarehandshake bei ausschließlicher Verwendung der Pins RX/TX).

* Wird das Signal eventuell durch zusätzliche Chips invertiert? (EEPROM von FT232 falsch Programmiert)

* Die Hardware und Verkabelung kann man schnell prüfen, indem man den Pin R1OUT bzw. R2OUT mit T1IN bzw. T2IN am MAX232 miteinander verbindet (je nachdem welches Pinpaar verwendet wird). Dann sollte man auf dem PC ein Terminalprogramm wie Hyperterminal starten und nach dem Eingeben von Zeichen diese sofort angezeigt bekommen, egal mit welcher Baudrate. Lediglich die Flusssteuerung muss auf "Kein" eingestellt werden.

: Man muss aber beachten, dass T1IN bzw. T2IN für diesen Test ''nicht'' mit dem Mikrocontroller verbunden sein darf, weil sonst zwei Ausgänge miteinander verbunden sind, siehe [[Ausgangsstufen Logik-ICs]]. Wenn der µC gesockelt ist, kann man ihn dafür einfach aus dem Sockel nehmen und die RX/TX Pins direkt im µC-Sockel mit einem Stück Draht verbinden.

* UART Ausgabe-Pin als Output-Pin deklariert?

* Spannung an Pin 15 und 16 liegt an? (Falsche Zeichen kommen an, aber in der richtigen Reihenfolge. Beim Test durch Kurzschluss von T1IN und R1OUT kommt nichts an)

=== SPI (Hardware) ===
* Master Mode: SS Pin als Ausgang oder auf High gelegt? (siehe hier: [http://www.holger-klabunde.de/avr/avrhelp.htm] )
* SPI zu schnell
* Hängen andere SPI-Devices am Bus, die undefiniertes CS haben?
* Sind die DDR-Register der SPI-Ports richtig gesetzt?

== Analog-Digital-Wandler ==

* Sind die Pullup-Widerstände deaktiviert? (im allgemeinen)
* (im speziellen) Bei einige Controllern liegt der JTAG mit auf den ADC-Pins. Die betroffenen ADC-Kanäle werden erst richtig funktionieren, wenn der JTAG deaktiviert ist. Das geht per Fuse oder - wenn man an die Fuses nicht mehr herrankommen sollte, weil man mit einem Bootloader arbeitet - auch per Software.

== Weblinks ==
* [http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

C ohne Makefile

2014-02-16T19:20:56Z

Mox-mox: Befehl zum ausführbar-Machen in der Konsole zugefügt

Während es unbedingt zu empfehlen ist, zum Übersetzen von mittelgroßen und großen Projekten Makefiles zu verwenden, kann es bei sehr kleinen Programmen oder für kurze Tests einfacher sein, das Übersetzen und Übertragen direkt per Kommandozeilenbefehl zu erledigen. Hier wird eine Methode vorgestellt, die es erlaubt, mit einer einzigen Datei auszukommen, die gleichzeitig als Batch-Datei fürs Übersetzen und Übertragen sowie als Quellcode-Datei verwendet wird.

Dieser Trick gelingt sehr gut unter Linux (hier: Ubuntu). Wahrscheinlich ist es ohne größere Probleme möglich, eine Windows-Variante zu erstellen (bitte im Artikel ergänzen).

Am besten kann die Funktionsweise an einer Beispiel-Quellcodedatei gezeigt werden (hier für AVR-Mikrocontroller):

<div class="code"><pre>
# /*
M=atmega328p; F=${0:0:-2}; rm -f "$F".hex; avr-gcc -mmcu=$M -Os \
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums \
-Wall -Wstrict-prototypes -std=gnu99 -g "$F".c -o "$F".elf && \
avr-objcopy -O ihex -R .eeprom "$F".elf "$F".hex && \
avrdude -c usbasp -p $M -B 12 -U flash:w:"$F".hex:i; exit; */

#include <avr/io.h>

int main(void) {
DDRB= 0xFF;
while(1) {
PORTB= 0x03;
// ...
}
return 0;
}

</pre></div>

== Voraussetzungen ==

Neben avr-gcc wird im Beispiel das weit verbreitete Programm [[avrdude]] verwendet. Natürlich kann auch jedes andere Programm zur Übertragung der am Ende erzeugten .hex-Datei verwendet werden. Die Kommandozeilen sind dann entsprechend anzupassen.

== Vorbereitung ==

Die oben im Beispiel gezeigten Kopfzeilen (alles oberhalb von "#include") müssen in die eigene Quellcodedatei kopiert werden. Dort müssen sie ebenfalls ganz am Anfang stehen.

In der zweiten Zeile der Quellcodedatei muss der Name des verwendeten Mikrocontrollers auf den tatsächlich verwendeten Typ geändert werden. Der Compiler akzeptiert den Namen nur in Kleinbuchstaben, also zum Beispiel: <tt>attiny13a</tt>

Damit die Quelldatei als Programm startbar ist, muss einmalig das Ausführungsflag gesetzt werden. Unter Ubuntu kann das am einfachsten so erledigt werden: Rechtsklick auf das Symbol der Quelldatei, Menüpunkt "Eigenschaften", Reiter "Zugriffsrechte", Häkchen bei "Datei als Programm ausführen" setzen. In der Konsole geht das bei eigentlich allen Linuxen mit "sudo chown +x dateiname".

== Arbeitsweise ==

Die Quelldatei mit den oben gezeigten speziellen Kopfzeilen kann ganz wie gewohnt editiert werden. Zum Übersetzen des Programms bewegt man sich per Kommandozeilenbefehl <tt>cd</tt> in dessen Verzeichnis und ruft es auf, als wäre es ein ganz normales Batch-Kommando. Unter Linux so:

<tt>./meinprogramm.c</tt>

Das Programm wird nun übersetzt, in eine .hex-Datei konvertiert und auf den Mikrocontroller übertragen. 

Geht bei der Übersetzung etwas schief, weil das Programm nicht fehlerfrei übersetzt werden konnte, unterbleibt das Übertragen auf den Mikrocontroller, und die Terminal-Ausgabe zeigt die betreffenden Fehlermeldungen.

== Disassemblieren ==

Mit diesem Befehlszeilenkommando kann man sich anzeigen lassen, welche Assembler-Befehle der C-Compiler erzeugt hat:

<tt>avr-objdump -D -m avr -S -j .text -j .data hier_der_quelldateiname.elf</tt>

C-Programmierer mit guten Assemblerkenntnissen werden hier so manche Überraschung finden. Teilweise lernt man neue Kniffe, die man danach selbst in der Assemblerprogrammierung einsetzen kann. In vielen Fällen wird man sich aber auch wundern, wie umständlich manche Programmabschnitte vom Compiler umgesetzt werden. Man kann sich selbst ein Bild davon machen, in welchen Fällen die Programmiersprache C Vorteile hat und in welchen Fällen man mit Assembler eher zum Ziel kommt.

== Warum funktioniert es, Kommandozeilenbefehle ''und'' Quellcode in derselben Datei zu verwenden? ==

Für das Programmieren von Mikrocontrollern ist die Antwort darauf nicht wichtig, man kann auch einfach hinnehmen, dass es so ist. Für jeden, der sich intensiver mit den Hintergründen beschäftigen will, hier ein paar Sätze zur Erklärung.

Für die Parser von Compiler und Shell ist der jeweils andere Code "unsichtbar":
* Der C-Compiler interpretiert alles, was zwischen /* und */ steht, als Kommentar und ignoriert den betreffenden Abschnitt. Das #-Zeichen zu Beginn der Datei wird in C als Einleitung für eine Präprozessor-Direktive verstanden. Da dem #-Zeichen aber in der gleichen Zeile keine solche Direktive folgt, wird es vom Compiler als "leere Direktive" angesehen und deshalb ignoriert.
* Der Kommandozeileninterpreter betrachtet das #-Zeichen als Einleitung eines Kommentars und ignoriert daher den Rest der ersten Zeile; er macht gleich mit der zweiten Zeile weiter und arbeitet sich bis zum Kommando "exit" durch. Dort beendet er seine Arbeit und ignoriert deshalb den danach folgenden C-Quellcode.

[[Kategorie:avr-gcc Tutorial]]

AVR Checkliste

2014-02-16T13:17:06Z

Mox-mox: AT90PWM zur Liste der Mikrocontroller mit mit anderer ISP-Pinbelegung zugefügt

[[Category:AVR]]
Diese Seite soll als erste Anlaufstelle dienen, wenn der [[AVR]]-Mikrocontroller mal wieder nicht so will wie er soll. Es wird versucht, die Standardfehler und Probleme aufzulisten und zu erklären, was man dagegen tun kann.

== Hardware ==

=== Anderen Controller benutzt als den im Schaltplan: Pinkompatibilität sichergestellt? ===

Nur wenige AVR-Controller sind pinkompatibel und damit untereinander austauschbar. Manchmal liegen gar die am dringensten benötigten Funktionen (ISP-Programmierung) bei anderen Controllern auf anderen Pins. Unbedingt vorher die Belegungen anhand der Datenblätter vergleichen!

=== Fuses richtig gesetzt? ===

Die AVR-Controller haben 'Fuses' (deutsch: 'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene bestimmen. Ein häufiger Fehler ist beispielsweise, dass die falsche Taktquelle gewählt wurde (Fuse "CKSEL" etc.): einige AVRs können mit dem internen Oszillator (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), fehlt dem Controller unter Umständen der Systemtakt und er läuft nicht an, oder man bekommt auf der seriellen Schnittstelle Nonsens, oder die Timer bzw. Zeitschleifen im Programm laufen zu langsam oder zu schnell.

Eine andere Fuse (JTAGEN) schaltet auf einem Port (z. B. PORTC auf ATMega32) die JTAG-Unterstützung ein bzw. aus. Wenn sie eingeschaltet ist, funktionieren vier Bits dieses Ports nicht wie gewohnt, da sie für die JTAG-Schnittstelle reserviert werden.

In dem zum STK500 gehörenden Entwicklungstool 'AVR Studio' gibt es in der Programmer-Dialogbox einen Tab 'Fuses', der controllerabhängig den Status der Fusebits anzeigt und Änderungen ermöglicht.
Siehe auch: [[AVR Fuses]].

=== ISP-Adapter ===

Bei ISP-Programmieradaptern für den Parallelport kann es zu Inkompatibilitäten mit manchen Ports kommen. Tritt das Problem auch auf, wenn der ISP-Adapter an einem anderen Rechner angeschlossen ist? Funktioniert es vielleicht mit einer anderen Software? Siehe auch: [[AVR In System Programmer]]).

Bei seriellem Programmer mit Controller (STK500, Atmel AVRISP etc.): Programmieren dauert sehr lange, es gibt Fehler. Abhilfe: ISP Taktrate richtig einstellen (<1/4 F_CPU).

Beim Programmieren mit dem usbasp Programmieradapter muss die Geschwindigkeit richtig eingestellt werden. Bei einem AVR der auf den eingebauten 1 Mhz läuft muss mit langsamer Geschwindigkeit (Jumper zu) programmiert werden.

=== Programmieren via SPI und angeschlossene SPI-Hardware ===
Wenn Peripherie über SPI angebunden ist, muss sich diese zum Programmierzeitpunkt auf dem Bus neutral verhalten. Normalerweise bedeutet dies, dass die Slave-Select/Chip-Select-Leitungen der Peripherie auf high gezogen werden müssen, wenn die Chips keinen internen Pull-Up haben. Werte von 10 kΩ bis 100 kΩ für normale Anwendungen haben sich bewährt.

=== Spannungsversorgung richtig angeschlossen? ===

Der AVCC-Pin ist der Versorgungsanschluss für den AD-Wandler und den zugehörigen Port. Er ist nicht an allen AVRs vorhanden; wenn er aber vorhanden ist, so muss er auf jeden Fall angeschlossen sein, auch wenn der AD-Wandler nicht benutzt wird. Wird der AD-Wandler verwendet, sollte zur Verbesserung der Genauigkeit der AVCC-Pin über einen Lowpass-Filter angeschlossen werden (siehe Datenblatt).
Oft funktioniert die Programmierung des Controllers auch, wenn Vcc oder GND nicht richtig angeschlossen ist. Zur Sicherheit kann man mit einem Messgerät direkt an den Anschlüssen des AVRs kontrollieren (VCC-GND, AVCC-GND) prüfen, ob die Verbindungen korrekt sind. Es empfiehlt sich, vor dem Einsetzen bzw. Einlöten des Controllers die Versorgungsanschlüsse nochmals zu prüfen, um sicherzustellen, dass man den IC nicht durch eine zu hohe Spannung aufgrund eines Fehlers in der Versorgung zerstört.

=== Reset-Pin korrekt beschaltet? ===

Der Reset-Anschluss am AVR ist 'active-low', d. h. wenn man den Pin mit GND (Masse) verbindet, wird der Controller zurückgesetzt gehalten. Zwar haben die meisten(!) AVRs einen internen Pullup-Widerstand, der den Reset-Pin gegen VCC "zieht", dieser ist jedoch relativ hochohmig (ca. 50 kΩ, vgl. Datenblatt) und reicht in extrem stark gestörter Umgebung nicht aus, um den Reset-Pin sicher "hochzuhalten". Als Mindestbeschaltung empfiehlt sich dringend, einen externen Pullup-Widerstand vorzusehen (typisch 10 kΩ), der den Reset-Pin mit VCC verbindet. Er sollte nicht kleiner als 4,7 kΩ sein, da der Programmieradapter sonst eventuell den Reset-Pin während des Programmiervorgangs nicht sicher auf "low" ziehen kann. Mit einem Oszilloskop kann man gut überprüfen, ob der Pegel am Reset-Pin sauber zwischen high und low wechselt. Zusätzlich sollte man auch noch einen Kondensator 47 nF oder 100 nF zwischen Reset-Pin und GND anordnen. Dieses RC-Glied sorgt dafür, dass der Controller beim Einschalten der Versorgungsspannung für eine definierte Zeitspanne im Reset gehalten wird. Im laufenden Betrieb sorgt der Kondensator dafür, dass der Reseteingang unempfindlich gegenüber Spikes und Glitches wird. Er sollte deshalb unmittelbar in Pin-Nähe beim Prozessor untergebracht werden. Dieser Kondensator darf jedoch nicht verwendet werden, wenn [[debugWIRE]] möglich sein soll.

Atmel empfiehlt zusätzlich noch zum Schutz vor Überspannungen eine externe Diode nach VCC ("Clamp-Diode"), da für den Reset-Pin keine interne vorhanden ist. Diese Diode bereitet jedoch bei manchen Programmieradaptern Schwierigkeiten. Allerdings schützt die Diode den Controller davor, in den High-Voltage Programming Mode zu schalten, zum Beispiel als Folge von Störspannung wegen EMV, und dadurch den Programmspeicher zu überschreiben.

=== Flashen / Lesen / Fuse nur einmal möglich ===

Es kann vorkommen, dass ein AVR nur einmal programmiert werden kann, danach geht es nicht mehr (z.B. Typ wird nicht mehr erkannt). Erst nachdem die Versorgungsspannung getrennt / wieder verbunden ist, geht es erneut.

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR einmal programmieren.

Der Reset PIN müsste bei korrekter Beschaltung eine Spannung nahe VCC (z.B. 4.9V) aufweisen, ist die Spannung bei GND, ist der Pin kurzgeschlossen und verursacht dieses Problem.

=== Abblockkondensator(en) ordnungsgemäß installiert? ===

Abblockkondensatoren dienen dazu, hochfrequente Störungen, die durch Schaltvorgänge verursacht werden können, nach GND abzuleiten, so das sie den Integrierten Schaltkreis, also das IC nicht erreichen. Dort würden sie Funktionsstörungen verursachen. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen
* eine niederimpedante Anbindung sollte gegeben sein - also keine Stegleitungen. Dies bedeutet, das die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen MUSS und dann weiter zm IC gereicht wird.

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, jeder Abblokkondesnator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leiten) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind (der Widerstand=Impedanz ist bei hochfrequenzen Spannungen zu groß - ein schneller (hochfrequenter) Spannungsimpuls kann so nicht abgeleitet werden)!

=== Quarz oder Quarzoszillator angeschlossen? ===

Die neueren AVRs haben einen internen [[Oszillator]], der im Auslieferungszustand über die entsprechenden Fuses eingeschaltet ist. In diesem Fall muss kein externer [[Quarze und AVR|Quarz]] mehr angeschlossen werden. Man kann in den [[AVR Fuses|Fuse-Bits]] aber einstellen, dass man einen externen Taktgenerator (''external clock'', z. B. Quarzoszillator) oder externen Quarz (''external crystal'') verwenden möchte.

Dann, oder wenn der AVR keinen internen Takt hat, wird an die entsprechenden Pins des Controllers ein Quarz (''external crystal'', Bauelement mit zwei "Beinchen") oder Quarzoszillator (''external clock'', Bauelement mit vier "Beinchen") angeschlossen. Im Falle eines Quarzes werden die XTAL-Pins mit den beiden Anschlüssen des Quarzes und jeweils mit einem Kondensator (ca. 12 bis 22 pF) (vgl. Datenblatt ATMega 8) gegen Masse angeschlossen. Im Falle eines Quarzoszillators reicht es aus, den Taktausgang mit dem XTAL1-Pin zu verbinden, und den XTAL2-Pin unbeschaltet zu lassen. Die Fuses sind entsprechend einzustellen.

=== Alle Ground-Anschlüsse beschaltet? ===

Bei IC's mit mehreren Ground-Anschlüssen müssen immer alle Anschlüsse beschaltet werden. Siehe http://www.mikrocontroller.net/forum/read-1-107259.html

=== Alle Lötstellen in Ordnung? ===

"Kalte", d.h. schlechte Lötstellen erkennt man an ihrer matten Oberfläche (bei bleihaltigem Lot). Bei beschädigten Lötstellen erkennt man oft einen Riss, der sich kreisförmig um die Mitte des Lötpunktes herum gebildet hat. Solche Stellen verursachen oft erst bei mechanischer Beanspruchung Probleme.

Bei kleinen Abständen (SMD-Bauteile) müssen besonders Verbindungen zwischen benachbarten Lötungen kontrolliert werden.

Bei Lochrasterplatinen kann man mit einem spitzen Messer (Bastelmesser) die Zwischenräume von möglichen leitenden Verbindungen befreien.

=== Eingänge ===

Taster müssen:

* entprellt werden ([[Entprellung]])

* einen [[AVR-GCC-Tutorial#Tasten_und_Schalter|Pullup-Widerstand]] besitzen, so sie ''active-low'' betrieben werden, d.h. wenn beim Tastendruck der Pin mit GND (Masse) verbunden wird (dies ist die übliche Anschaltung). Man kann einen externen Pull-Up Widerstand (typ. 10 kOhm) benutzen oder den internen aktivieren (DDR als Eingang also "0", PORT auf "1").

Will man einen Taster ''active-high'' betreiben, soll also bei Tastendruck eine "1" in PIN gelesen werden, ist ein externer Pull-Down-Widerstand (typ. 10 kOhm) gegen GND anzuschließen, denn interne Pull-Downs sind nicht verfügbar.

Symptome: Aufgrund des Prellens bekommt man bei einem Tastendruck statt eines Signals mehrere, und beim fehlenden Pullup fängt man sich Störungen (z. B. das 50 Hz-Netzbrummen) ein, da der Pin nicht auf einem "definierten Pegel" liegt, wenn der Taster nicht geschlossen ist. Soll z. B. bei einem Tastendruck eine LED angehen, dann leuchtet die LED durch das Netzbrummen plötzlich mit 50 Hz anstatt aus zu sein.

* active low: ein Anschluss des Tasters an den Port-Pin, den anderen Taster-Anschluss an GND; internen Pull-Up-Widerstand aktivieren oder externen Widerstand zwischen Port-Pin und VCC.

* active high: Taster zwischen Port-Pin und VCC; externen Widerstand zwischen Port-Pin und GND.

=== Ausgänge ===

Man sollte darauf achten, das "kritische" Ausgänge, d.h. Ausgänge, über die nicht "nur" eine LED geschaltet wird, einen definierten Zustand haben, wenn der Portpin auf "Eingang" und damit hochohmig geschaltet ist. Dadurch wird sichergestellt, dass beim Einschalten nicht kurz ein Verbraucher geschaltet wird (z. B. "Zucken" eines Motors). Dies kann man bewerkstelligen, indem man extern Widerstände (auch hier Pull-Up bzw. Pull-Down genannt, typ. 10 kOhm) an den Ausgangs-Pins vorsieht, die den Ausgang auf den gewünschten Zustand ziehen.

=== Besonderheiten bei ATmega128 und seinen Derivaten im 64-Pin-Gehäuse===

[[Bild:isp.png|thumb|300px|right|ISP-Adapter]]
Der ATmega64 und der ATmega128 sowie alle vom ATMega128 abgeleiteten AVRs im 64-Pin-Gehäuse (ATMega641/1281/2561, AT90PWM2/3/2B/3B sowie AT90CAN32/64/128, Ausnahmen sind nur AT90USB64/128, die eine ganz andere Pinbelegung haben) haben besondere Fallstricke, über die man bei nicht ausreichendem Datenblattstudium leicht stolpert.

* Der erste betrifft den Anschluss der ISP-Signale (MISO, MOSI, SCK, RESET). Dieser erfolgt nicht wie bei den meisten anderen AVR-Controllern an den gleichnamigen Pins, sondern an PDI, PDO, SCK und RESET. Die Pinzuordnung ist:
:* MOSI → PE0 (Pin 2)
:* MISO → PE1 (Pin 3)
:* SCK → PB1 (Pin 11)
:* RESET → RESET (Pin 20)
: PEN (Pin 1) hat für normale ISP-Adapter keine Bedeutung und kann offen gelassen oder direkt mit Vcc verbunden werden. Die Benutzung der Pins PDI und PDO anstelle von MOSI und MISO gilt für praktisch alle ATmega128-Derivate im 64-Pin-TQFP-Gehäuse, darunter AT90CAN32/64/128 und ATmega641/1281/2561. Im Zweifelsfall im Datenblatt (Pin Configuration) nachsehen, ob PE0 und PE1 mit "PDI" bzw. "PDO" beschriftet sind.

* Die zweite kleine Gemeinheit betrifft die M103C-Fuse (ATmega103 Compatibility Mode, nur bei den ATmega-Typen, nicht beim AT90CAN32/64/128). Diese ist bei fabrikneuen Atmega64/128 gesetzt und sorgt dafür, dass sich diese wie ein Atmega103 verhalten.
** Dies hat zur Folge, dass ein für den ATmega64 oder ATmega128 geschriebenes Programm beim ersten RET abstürzt, da der SRAM an einer anderen Stelle endet als erwartet und somit der Prozessor keine gültige Rücksprungadresse vom Stack holen kann.
** Außerdem funktionieren einige IO-Pins an PORTC, PORTF und PORTG anders.
** Für weitere Infos bzgl. [[TWI]], [[UART]], [[Timer]], [[Bootloader]] und Kalibrierung des internen RC-Oszillators unbedingt das Datenblatt lesen.

== Software ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das fuehrt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

=== Alle Interruptvektoren definiert? ===

Wenn man irgendwelche [[Interrupt]]vektoren verwendet, sollte man alle definieren, auch die nicht benutzten. Passiert es dann aufgrund eines Fehlers, dass ein Interrupt unbeabsichtigt ausgeführt wird, so führt der Controller dann eine definierte Aktion aus. Benutzt man eine Hochsprache wie C oder Basic, nimmt einem der Compiler diese Arbeit ab.

Ausserdem sollte man immer im Datenblatt des Controllers nachsehen, wie die Interrupttabelle aufgebaut ist. Die kleinen AVRs verwenden ein RCALL zum Anspringen der Interrupts, welches 1 Wort lang ist. Die grossen AVRs mit mehr als 8 KiBi FLASH verwenden ein CALL, welches 2 Worte lang ist. Verwendet man nun den falschen Befehl, verschieben sich die Einsprungadressen und das Chaos ist perfekt.

In einem komplett interruptlosen Programm kann man auf die Interrupttabelle selbstverständlich verzichten (erkennbar daran, dass nirgendwo im Code Interrupts mittels Assembler-Befehl SEI eingeschaltet werden).

Oft hilft es einen Catch All Interruptvektor zu definieren um herauszufinden ob ein Fehler (z.B. ein Neubeginn des Programms) vorliegt.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

ISR (BADISR_vect)
{
// Hier eine Fehlerausgabe definieren.
// Z.B. UART-Ausgabe oder ein PIN toggeln
}</syntaxhighlight>

Dann findet man solche Fehler recht schnell.

=== Alle Konfigurationsregister korrekt initialisiert? ===

Alle benötigten Konfigurationsregister (auch "I/O-Register" genannt) eines Mikrocontrollers müssen korrekt initialisiert werden. Bei Fehlfunktionen sollten diese Konfigurationen noch einmal mit dem Datenblatt abgeglichen werden.
Manchmal ist es auch sinnvoll, bestimmte Funktionen explizit abzuwählen. Ein Beispiel hierfür ist der [[Analog-Komparator]] des AVR: Schaltet man diesen ab, wenn man ihn nicht benötigt, kann man dadurch ein wenig Strom sparen.
Wenn man besonders "sauber" programmieren möchte, initialisiert man Konfigurationsregister immer, d.h. auch wenn sie nicht im Programm verwendet werden. Dies verhindert mögliche zufällige Fehlkonfigurationen.

=== Stackpointer initialisiert? (Nur in Assembler relevant) ===

Fehlerbeschreibung: ''Das Programm lief, bis ein "rcall" oder ein Interrupt eingefügt wurde. Danach ging plötzlich gar nichts mehr.''

Wahrscheinliche Ursache: Der Stack ist ein spezieller Bereich im RAM, der von Sprungbefehlen und Interruptaufrufen dazu verwendet wird, die Rücksprungadresse ins Hauptprogramm zu speichern. Da der Stack bei den AVRs nach "unten" wächst, d.h. in Richtung Anfang des RAMs, wird er üblicherweise ans Ende des RAMs gelegt. Der Stack muss vor der ersten Benutzung, am besten direkt am Anfang des Programms, initialisiert werden (sonst ist nach einem Sprung in ein Unterprogramm die Rücksprungadresse undefiniert und das Programm wird an einer unvorhersehbaren Stelle weiter ausgeführt, was in der Regel einen Absturz zur Folge hat). "Den Stack initialisieren" bedeutet, den Stackpointer auf den gewünschten "Startwert" zu setzen. Meistens wird dafür die letzte RAM-Adresse gewählt.

Die Initialisierung unterscheidet sich geringfügig je nach verwendetem AVR. Bei den alten AT90xxxx und den ATtinys ist sie mit zwei Zeilen erledigt:

<syntaxhighlight lang="avrasm">
ldi r16, RAMEND ;Die Adresse der letzten Stelle im RAM in r16 laden
out SPL, r16 ;Die Adresse in das Register SPL ausgeben
</syntaxhighlight>

Da die ATmegas mehr RAM haben, reicht das 8 bit-Register SPL nicht mehr, und es ist ein zweites (SPH) dazugekommen. Die Initialisierung des Stacks erfordert hier vier Zeilen:

<syntaxhighlight lang="avrasm">
ldi r16, LOW(RAMEND) ;Untere 8 bit des 16 bit-Wertes RAMEND laden
out SPL, r16
ldi r16, HIGH(RAMEND) ;Obere 8 bit laden
out SPH, r16
</syntaxhighlight>

=== 16bit-Register in richtiger Reihenfolge geladen/gelesen? (Nur in Assembler relevant) ===

Bei den 16-bit Registern (z. B. Timer1) genau die Hinweise im Kapitel "Accessing 16-bit Registers" beachten!

So muss z. B. das High-Byte VOR dem Low-Byte geschrieben werden, weil mit dem Schreiben des Low Byte das gesamte Register "übernommen" wird.
Beim Lesen muss zuerst das Low-Byte gelesen werden, dann das High-Byte.
Es wird dadurch garantiert, dass sich zwischen den beiden einzelnen Befehlen nicht noch das Register weiter verändert, z. B. beim 16bit Counter.
Möglich wird das durch ein "temporary Register", von dem es aber nur eines gibt - was beachtet werden muss, da zwischen diesen beiden einzelnen Lese-/Schreib-Befehlen kein Interrupt auftreten darf, der selber das temporary Rgegister benutzt.

In C oder Basic kümmert sich der Compiler um das Problem - man liest oder beschreibt dann einfach z. B. TCNT1 anstatt TCNT1H und TCNT1L einzeln.

=== Flag richtig gelöscht? ===

Ein beliebter Fehler ist, dass man überliest, dass gesetzte Flags (z. B. die Interrupt-Flags) durch beschreiben mit einer '1' und nicht mit einer '0' gelöscht werden!

Beispiel:
* das Flag ist zuerst '0'
* das Ereignis (z. B. Zählerüberlauf, also Bit TOV0 in TIFR) tritt auf und setzt das jeweilige Bit im Register auf '1'
* wir haben auf die '1' gewartet und wollen das Bit nun wieder löschen und müssen dafür eine '1' (eins!) in das Register schreiben, '''keine''' '0'. Trotzdem wird das Bit dadurch '0' z. B.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

Das ganze ist kein Fehler, sondern hat seine guten Gründe.

Wenn Interrupts zugelassen sind (z. B. in TIMSK) und die Interruptroutine aufgerufen wird, werden diese Flags zumeist automatisch gelöscht.

Der UART-Empfangs-Interrupt (RXC in UCSRA) jedoch nicht! Der wird gelöscht durch Auslesen des Empfangsregisters (UDR). Hier liegt wiederum ein beliebter Stolperstein: Man prüft oft zuerst in der Interruptroutine die Fehlerflags (z. B. Parity) und macht dann manchmal den Fehler das empfangene Zeichen im Fehlerfall nicht auszulesen. Das führt dann zum Absturz (der IRQ wird immer wieder aufgerufen) - man muss also immer das UDR lesen auch wenn etwas Fehlerhaftes drinsteht.

Zusätzlich ist zu beachten, dass in C die Interrupt-Flags '''nicht''' mit einer Veroderung des Registers (z. B. TIFR |= (1 << TOV0)) gelöscht werden sollten, da bei dieser Operation alle anderen evtl. gesetzten Flags im betreffenden Register ebenfalls gelöscht werden. Es ist die Schreibweise von oben zu benutzen (also TIFR = (1 << TOV0))!

=== Alle Interrupt Variablen als volatile bezeichnet? ===

Das Schlüsselwort volatile kann als Attribut an Variablen gehängt werden. Der Ausdruck „volatile int i“ versieht die Integervariable i mit dem Attribut volatile. Das Attribut weist den Compiler an, diese Variable nicht zu optimieren, sondern im Speicher abzulegen und zu beachten, dass diese Variable von anderen Prozessen geändert werden kann. Normale Variablen können durch den Compiler auf Register reduziert werden, oder die Daten werden einmalig aus dem Speicher geladen und erst am Ende des Programmes wieder zurückgeschrieben. Das kann Probleme bereiten, wenn beispielsweise in einer [[Interrupt]]routine die Variable verändert wird. Darum müssen alle globalen Variablen, die in einer Interruptroutine geändert werden, mit diesem Schlüsselwort versehen werden.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen >8 Bit welche in der ISR und in der Hauptfunktion genutzt werden muss [[atomar]] erfolgen. Das Vergessen dieser Regel führt selten zu Problemen, aber wenn dann zu schwer Nachvollziehbaren...

=== Die Programmierfrequenz passend? ===

Sollte ein Programmieren nicht möglich sein erst einmal die Programmiergeschwindigkeit bei AVR dude mit der Option
-B bitclock anpassen
wobei bitclock die Perioden dauer in Milisekunden (floating-point Zahl) ist. Normalerweise -B 1 für Controller mit >=4MHz daher ist bei der Erstprogrammierung ein höherer Wert zu versuchen.

== Serielle Verbindungen ==

=== [[I²C]]/[[TWI]] ===

Sind die Leitungen SCL und SDA mit einem Pullup-Widerstand ausgestattet? Die I²C-Bus-Leitungen SCL und SDA müssen über einen Pullup-Widerstand mit einem Wert von 4,7 kΩ bis 10 kΩ mit der Versorgungsspannung (+5 V) verbunden sein.

=== UART/USART ===

==== Übertragungsprobleme durch falschen oder ungenauen Takt ====

* Der interne [[Oszillator]] ist recht ungenau und nicht temperaturstabil. Daher kann die Umgebungstemperatur auch den [[UART|USART]]-Takt verändern. Für serielle, asynchrone Kommunikation per UART sollte man deshalb immer einen Quarz oder einen Oszillator verwenden, egal bei welcher Baudrate: 3% Fehler sind immer 3% Fehler, egal ob bei 1200 oder 9600 [[Baud]]. Falls doch der interne Oszillator verwendet wird: Wurde er für die richtige Frequenz und Betriebsspannung kalibriert?

* Nicht mit allen Quarzen kann man alle Baudraten genau genug erzeugen. Deswegen gibt es [[Baudratenquarz]]e wie z. B. 3,6864 MHz. Näheres steht im Datenblatt.

* Geschieht die Konfiguration des U(S)ART automatisch durch die Programmiersprache (z. B. in [[Bascom AVR|BASCOM]], [[C]]), dann muss dort der Takt ''genau'' angegeben werden. Setzt man z. B. einen 3,6864 MHz-Quarz ein, darf man dort nicht einfach "4 MHz" angeben, weil dann die Abweichung mit ca. 8% zu hoch wäre. Damit funktioniert die Übertragung nicht mehr.

* Im AVR-Studio kann man die Taktfrequenz sowohl über ein <code>#define F_CPU</code> im Quelltext als auch über das Optionsmenu oder das selbsterstellte Makefile einstellen. Es darf nur ''eine'' Variante verwendet werden!

* Wenn ein externer Oszillator oder Quarz angeschlossen ist: Sind die [[AVR Fuses | Fuses]] des Controllers so gesetzt, dass er auch verwendet wird?

* Ist die Fuse CLKDIV ''nicht'' programmiert?

* Es taucht auch des öfteren das Missverständnis auf, dass man nur F_CPU verändern muss, um den µC mit einem anderen Takt laufen zu lassen. Dem ist nicht so. Der µC-Takt wird durch die Fuses bzw. den eventuell angeschlossenen Quarz oder Quarzoszillator bestimmt. F_CPU dient nur dazu, die dadurch festgelegte Frequenz im C-Programm zur Verfügung zu haben. F_CPU ist nur eine Information, mit der man bei der Programmierung arbeiten kann. Aber ein anderer F_CPU-Wert führt nicht dazu, dass der µC dann magisch auf diese Frequenz umgestellt wird.

* Um zu prüfen, ob der externe Quarz auch wirklich verwendet wird, kann man mittels _delay_ms() testweise eine LED im Sekundentakt blinken lassen. Den Unterschied zwischen Quarz und internem RC-Oszillator kann man bei grösseren Frequenzunterschieden leicht sehen. Ebenso sieht man, ob versehentlich die CLKDIV Fuse gesetzt ist: die Blinkfrequenz ist dann achtmal langsamer. Allerdings muss man auch hier aufpassen. Siehe [[AVR-GCC-Tutorial#Warteschleifen (delay.h)|AVR-GCC-Tutorial: Warteschleifen]].

Im folgenden Programm muss angepasst werden:
*Die vermeintliche Taktfrequenz F_CPU
*der Port und der Pin, an dem eine LED angeschlossen ist.

Wird das Programm laufen gelassen, muss die LED 1 Sekunde ein/1 Sekunde aus sein. Stimmen die Zeiten nicht, ist das ein deutlicher Hinweis darauf, dass die tatsächlich vom µC verwendete Taktfrequenz nicht mit der in F_CPU angegebenen übereinstimmt. Das Programm muss mit aktivierter Optimierung <code>-Os</code> compiliert werden.
<syntaxhighlight lang="c">
// Testprogramm für CPU Takt
// Hier die vermeintliche Taktrate des µC eintragen
// Im Beispiel hier: 1Mhz

#define F_CPU 1000000

#include <avr/io.h>
#include <util/delay.h>

// Hier die tatsächlich verwendeten Parameter angeben

#define LED_PORT PORTB
#define LED_DDR DDRB
#define LED_PIN PB0

int main()
{
LED_DDR |= 1 << LED_PIN;

while (1)
{
LED_PORT ^= 1 << LED_PIN;
_delay_ms(1000);
}

return 0;
}
</syntaxhighlight>

* Erscheinen im Terminalprogramm kryptische Zeichen anstatt ordentlichen Buchstaben (z. B. ü statt A), liegt das zu 99,9% an einer falsch eingestellten/erzeugten Baudrate im Mikrocontroller. Meistens wiederum liegt dies daran, dass der µC nicht mit der vermeintlichen Taktrate läuft und daher die Baudratenparameter falsch berechnet werden.

* URSEL-Bit in UCSRC: Bei der Initialisierung der UART beachtet, wenn das für den verwendeten AVR notwendig ist, siehe [[AVR-GCC-Tutorial/Der_UART#Die_UART-Register|AVR-GCC-Tutorial/Der UART: Die UART-Register]].

* In den Tutorials für [[AVR-Tutorial: UART |Assembler]] und [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_UART GCC] wird die Nutzung recht gut erklärt und mit Beispielen erläutert.

==== Sonstige Fehlerquellen bei UART/USART ====

* Funktioniert die Datenübertragung zum PC nur solange der Programmieradapter eingesteckt ist, deutet dies auf ein Problem mit der Masse hin (z. B. GND-Anschluss am RS232-Stecker nicht belegt oder dergleichen).

* Der Pegelwandler/Inverter (z. B. MAX232) muss mit Kondensatoren für die internen Ladungspumpen beschaltet werden. Beim MAX232 sind dies mindestens vier Kondensatoren ≥ 1 µF (Polung beachten!), beim MAX202, MAX232A und MAX3232 vier Kondensatoren ≥ 100 nF. Hinzu kommt der obligatorische Abblockkondensator von 100 nF keramisch zwischen VCC und GND des ICs. Das jeweilige Datenblatt gibt Auskunft über die Beschaltung bei "typischer Anwendung".

* TX/RX vertauscht? Modem- oder Nullmodemkabel?

* Bei Kommunikation mit PC: ist die serielle Schnittstelle richtig konfiguriert? Nicht nur Baudrate, Stopp- und Parity-Bits, sondern auch Handshakeverhalten muss stimmen (kein Hardwarehandshake bei ausschließlicher Verwendung der Pins RX/TX).

* Wird das Signal eventuell durch zusätzliche Chips invertiert? (EEPROM von FT232 falsch Programmiert)

* Die Hardware und Verkabelung kann man schnell prüfen, indem man den Pin R1OUT bzw. R2OUT mit T1IN bzw. T2IN am MAX232 miteinander verbindet (je nachdem welches Pinpaar verwendet wird). Dann sollte man auf dem PC ein Terminalprogramm wie Hyperterminal starten und nach dem Eingeben von Zeichen diese sofort angezeigt bekommen, egal mit welcher Baudrate. Lediglich die Flusssteuerung muss auf "Kein" eingestellt werden.

: Man muss aber beachten, dass T1IN bzw. T2IN für diesen Test ''nicht'' mit dem Mikrocontroller verbunden sein darf, weil sonst zwei Ausgänge miteinander verbunden sind, siehe [[Ausgangsstufen Logik-ICs]]. Wenn der µC gesockelt ist, kann man ihn dafür einfach aus dem Sockel nehmen und die RX/TX Pins direkt im µC-Sockel mit einem Stück Draht verbinden.

* UART Ausgabe-Pin als Output-Pin deklariert?

* Spannung an Pin 15 und 16 liegt an? (Falsche Zeichen kommen an, aber in der richtigen Reihenfolge. Beim Test durch Kurzschluss von T1IN und R1OUT kommt nichts an)

=== SPI (Hardware) ===
* Master Mode: SS Pin als Ausgang oder auf High gelegt? (siehe hier: [http://www.holger-klabunde.de/avr/avrhelp.htm] )
* SPI zu schnell
* Hängen andere SPI-Devices am Bus, die undefiniertes CS haben?
* Sind die DDR-Register der SPI-Ports richtig gesetzt?

== Analog-Digital-Wandler ==

* Sind die Pullup-Widerstände deaktiviert? (im allgemeinen)
* (im speziellen) Bei einige Controllern liegt der JTAG mit auf den ADC-Pins. Die betroffenen ADC-Kanäle werden erst richtig funktionieren, wenn der JTAG deaktiviert ist. Das geht per Fuse oder - wenn man an die Fuses nicht mehr herrankommen sollte, weil man mit einem Bootloader arbeitet - auch per Software.

== Weblinks ==
* [http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

Bidirektionale Analogübertragung

2010-04-11T19:06:21Z

Mox-mox:

Übertragung von zwei Analogwerten durch eine Leitung in zwei Richtungen

Das Prinzip der Übertragung von Analogwerten in beide Richtungen über eine einzelne Leitung wurde schon vor langer Zeit in der Fernmeldetechnik verwendet. Damals war ein Übertrager zwischen Mikrophon, Leitung und Hörer. Das nannte sich "Mithördämpfung".

Hier ein Schaltung, die die gleichzeitige Übertragung von Analogsignalen über eine einzige Leitung erlaubt:

[[Bild:Bidirektionale_Analogübertragung.png]]

Auf der Leitung G bildet sich der Mittelwert der beiden Ausgangsspannungen A und B, weil jeder der Ausgangsspannungen über 10k in die Leitunng einspeist.

G = A/2 + B/2

Die Spannung am Eingang der Differenzverstärkers D ist:

D = G - A/2 = A/2 + B/2 - A/2 = B/2

Das heißt: An der Station A wird am Messpunkt D die Hälfe der Ausgangsspannung der Station B gesehen, obwohl Station A selbst durch die gleiche Leitung Spannungssignale an B sendet.

Das ist zunächst unabhängig davon, ob die Signale analog oder digital sind.
Bei hochfrequenten Signalen kann der Einfluß der Leitungskapazität dadurch kompensiert werden, dass Kondensatoren an den Spannungsteilern eingesetzt werden, die der Leitungskapazität entsprechen.

Das Ausgangssignal kann durch einen Trennverstärker wieder auf volle Amplitude verstärkt werden, Dabei ist zu beachten, dass jeder der beiden Anschlüsse D schon 5 kOhm Innenwiderstand hat.

[[Category:Datenübertragung]]