Mikrocontroller.net - Benutzerbeiträge [de]

Wanderkiste (Widlar)

2017-09-16T16:35:38Z

Df2au: /* Idee */ Typos

=Idee=
Die Idee, die hinter einer Wanderkiste steckt, ist, dass die Teilnehmer elektronische Bauteile und Module tauschen und
sich ein Netzwerk von Gleichgesinnten bildet.

=Name=
Der Name geht auf den Elektronikpionier [https://en.wikipedia.org/wiki/Bob_Widlar Bob Widlar] zurück.

=Regeln:=

;Inhalt

* Neu Ware THT, SMD + Neue/Funktionierende Gebrauchte PCBs sowie Arduino Zubehör und Co
* Kein Elektroschrott, keine Schlachtplatinen, kein vergammelter Müll der Jahre lang im Keller lag. ,keine Batterien / Akkus, keine Transformatoren & schwere Spulen, kein Gefahrengut
* In/Out-Liste in Form eines aus sagekräftigen Fotos im Thread (je ein Bild)
* Wer die Regln nicht akzeptieren kann oder will macht nicht mit!

;Versand

* nur DHL Paket (versichert!)
* Sendungs Nummer sowie Sendungs Eingang/Ausgang (Datum) trägt jeder in die Liste unten ein
* Kein Ausland, keine Inseln und keine Packstation und keine Postämter
=Teilnehmer=

Die Teilnehmer tragen sich selbst ein, der Weg der Kiste ergibt sich automatisch.

Wer einen anderen Teilnehmer austrägt oder sich vor jemanden setzt (also eine Zeile einfügt), an eine Stelle die vergeben ist, der fliegt raus.

{| border="1" class="wikitable"
|+ Teilnehmer
|-
! style="width:60px" | Nr. !! Name !! style="width:80px" | IN !! style="width:80px" | OUT !! DHL Code
|-
| 1 || [https://www.mikrocontroller.net/user/show/sven_rvbg sven_rvbg] || - || ||
|-
| 2 || [https://www.mikrocontroller.net/user/show/dl3yc dl3yc]|| - || ||
|-
| 3 || [https://www.mikrocontroller.net/user/show/NormalZeit NormalZeit] || - || ||
|-
| 4 || [https://www.mikrocontroller.net/user/show/chfreund chfreund] || - || ||
|-
| 5 || [https://www.mikrocontroller.net/user/show/bastler-david bastler-david] ||folgt noch|| ||
|-
| 6 || [https://www.mikrocontroller.net/user/show/JoergL JoergL]|| - || ||
|-
| 7 || [https://www.mikrocontroller.net/user/show/Erlang Erlang] || || ||
|-
| 8 || [https://www.mikrocontroller.net/user/show/da_miez da_miez] || || ||
|-
| 9 || || || ||
|-
| 10 || || || ||
|}

Platinenhersteller

2016-05-17T14:12:15Z

Df2au: /* smart prototyping */

== Einleitung ==
Die Vor- und Nachteile von Platinenherstellern/-lieferanten werden relativ häufig im [http://www.mikrocontroller.net/forum/platinen Forum] diskutiert (und führen ab und zu zu Flamewars :-). Damit man schnell einen Überblick über die verschiedenen Möglichkeiten erhält, soll hier eine Liste zusammengetragen werden.

Jeder kann/soll seinen Beitrag leisten, d.h. wenn man einen Platinenlieferanten kennt, der noch nicht erwähnt ist, einfach hinzufügen. Falls man den Hersteller nicht so gut kennt, einfach mal den Namen und die URL hinzufügen, es gibt sicherlich andere, die den Hersteller so gut kennen, dass sie sich zutrauen, ein Urteil über die Leistung zu fällen.

'''Eigentümer oder Mitarbeiter von Firmen dürfen diese gerne eintragen, falls sie in der Liste noch nicht vorhanden sind. Beim Eintrag oder Änderungen bitte in der Zusammenfassung unbedingt darauf hinweisen, dass Sie über Ihre eigene Firma schreiben.''' Und bitte der Versuchung widerstehen, die Einträge mit werbeähnlichen Texten oder Werbung zu ergänzen. Zufriedene Kunden mögen bitte darauf achten, ihre Zufriedenheit so zu formulieren, dass nicht der Eindruck entsteht, der Eintrag sei von einem Hersteller zur "Verschönerung" gemacht worden.

'''Diese Seite kann nur von angemeldeten Benutzern bearbeitet werden!''' Bei neuen Einträgen bitte die Sortierung beachten.

Einige Hinweise, Hilfestellungen zur Platinenfertigung und Auftragsvergabe gibt es auch in der [http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.6 de.sci.electronics-FAQ].

Verschiedene Threads deuten an, dass "normaler" grüner Stopplack meistens die besseren Ergebnisse erzielt (http://www.mikrocontroller.net/topic/329356, http://www.mikrocontroller.net/topic/321295). Das kann je nach Hersteller schwanken.

=== Preise ===
Zur besseren Vergleichbarkeit bei jedem Hersteller dazu schreiben, was '''eine doppelseitige durchkontaktierte Eurokarte (160mm x 100mm) mit deutscher MwSt.''' ohne Versand kostet.
Dazu noch die Lieferzeit und ob Lötstopplack und Bestückungsdruck dabei ist.
''Zusätzlich'' kann man noch die Preise für andere Formate, Stückzahlen etc. dazu schreiben.

{| class="wikitable sortable" style="text-align:center"
|+ Schnellübersicht von Anbietern mit Online-Calculator (Lötstopplack, kein Bestückungsdruck, inkl. MwSt & Porto)
|-
! Anbieter !! Lagenanzahl !! Breite / mm !! Höhe / mm !! Dicke / mm !! Arbeitstage !! Preis / Euro !! ermittelt am
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 2 || 148.73 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 3 || 133.85 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 4 || 113.03 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 5 || 95.18 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 6 || 83.29 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 2 || 160 || 100 || 1.6 || 7 || 59.49 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 4 || 160 || 100 || 1.6 || 3 || 294.50 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 4 || 160 || 100 || 1.6 || 4 || 248.69 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 4 || 160 || 100 || 1.6 || 5 || 209.42 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 4 || 160 || 100 || 1.6 || 6 || 183.25 || 2014-09-16
|-
| [[#Ätzwerk_GmbH|Ätzwerk]] || 4 || 160 || 100 || 1.6 || 7 || 130.89 || 2014-09-16

|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 1 || 261.61 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 2 || 233.75 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 3 || 205.92 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 4 || 178.09 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 5 || 150.26 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 7 || 127.98 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 8|| 94.57 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 10 || 91.23 || 2014-09-16
|-
| [[#Basista_Leiterplatten|Basista]] || 2 || 160 || 100 || 1.6 || 12 || 89.02 || 2014-09-16

|-
| [[#Becker_und_Müller|Becker und Müller]] || 2 || 160 || 100 || 1.6 || 4 || 195.26 || 2015-07-06
|-
| [[#Becker_und_Müller|Becker und Müller]] || 2 || 160 || 100 || 1.6 || 5 || 132.95 || 2015-07-06
|-
| [[#Becker_und_Müller|Becker und Müller]] || 2 || 160 || 100 || 1.6 || 7 || 120.49 || 2015-07-06
|-
| [[#Becker_und_Müller|Becker und Müller]] || 2 || 160 || 100 || 1.6 || 10 || 108.02 || 2015-07-06
|-
| [[#Becker_und_Müller|Becker und Müller]] || 2 || 160 || 100 || 1.6 || 12 || 101.79 || 2015-07-06

|-
| [[#Eurocircuits_GmbH|Eurocircuits]] || 2 || 160 || 100 || 1.6 || 8 || 68.87 || 2014-09-16

|-
| [[#LEITON|LeitOn]] || 2 || 160 || 100 || 1.6 || 3 || 192.93 || 2014-09-16
|-
| [[#LEITON|LeitOn]] || 2 || 160 || 100 || 1.6 || 5 || 91.86 || 2014-09-16
|-
| [[#LEITON|LeitOn]] || 2 || 160 || 100 || 1.6 || 8 || 61.24 || 2014-09-16
|-
| [[#LEITON|LeitOn]] || 2 || 160 || 100 || 1.6 || 12 || 48.99 || 2014-09-16

|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 1 || 160 || 100 || 1.6 || 5 || 55.22 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 2 || 160 || 100 || 1.6 || 2 || 165.65 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 2 || 160 || 100 || 1.6 || 5 || 55.22 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 4 || 160 || 100 || 1.6 || 2 || 290.54 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 4 || 160 || 100 || 1.6 || 5 || 110.98 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 6 || 160 || 100 || 1.6 || 2 || 336.89 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 6 || 160 || 100 || 1.6 || 6 || 177.31 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 8 || 160 || 100 || 1.6 || 2 || 486.57 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 8 || 160 || 100 || 1.6 || 6 || 256.09 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 10 || 160 || 100 || 1.6 || 3 || 1058.03 || 2016-02-16
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 10 || 160 || 100 || 1.6 || 7 || 622.37 || 2016-02-16

|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 1 || 320.48 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 2 || 268.96 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 3 || 243.19 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 4 || 217.43 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 5 || 165.90 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 7 || 145.29 || 2014-09-21
|-
| [[#PCB Pool|PCB Pool]] || 2 || 160 || 100 || 1.6 || 8 || 114.37 || 2014-09-21

|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 2 || 270.67 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 3 || 215.21 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 4 || 178.25 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 5 || 131.44 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 6 || 120.87 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 7 || 89.19 || 2014-09-21
|-
| [[#Onlineshop WEdirekt|WEdirekt]] || 2 || 160 || 100 || 1.6 || 8 || 89.19 || 2014-09-21
|-
|}

== Liste der Hersteller ==

=== Deutschland ===
==== Übersicht ====
{| class="wikitable sortable" style="text-align:center"
|+ Übersicht von Anbietern aus Deutschland
|-
! Anbieter !! PLZ !! Ort !! privat !! gewerblich !! Online-Calculator !! produziert in Deutschland !! ermittelt am
|-
| [[#Accent PCB GmbH|Accent PCB GmbH]] || 40212 || Düsseldorf || ? || ja || nein || [http://www.accentpcb.com/about-us.html teilweise] || 2014-09-21
|-
| [[#Ätzwerk GmbH|Ätzwerk GmbH]] || 81925 || München || ? || ja || ja || ? || 2014-09-21
|-
| [[#am2s|am2s]] || 88376 || Königseggwald || ja || ja || nein || [http://www.am2s.de/pcb.html teilweise] || 2014-09-21
|-
| [[#andus electronic|Andus Electronic]] || 10997 || Berlin || ? || ja || nein || ja? || 2014-09-21
|-
| [[#ANTtronic|ANTtronic]] || 53844 || Troisdorf || ? || ja || nein || ? || 2014-09-21
|-
| [[#Basista Leiterplatten|Basista Leiterplatten]] || 46236 || Bottrop || ja || ja || ja || ja? || 2014-09-21
|-
| [[#Bauer-Elektronik|Bauer-Elektronik]] || 66557 || Illingen || ja? || ja || nein || ja? || 2014-09-21
|-
| [[#Britze|Britze]] || 12099? || Berlin || ? || ja || ja || [http://www.britze.de/unternehmen-produktion.html ja] || 2014-09-21
|-
| [[#B&B Gruppe|B&B Gruppe]] || 09648 || Mittweida || ? || ja || nein || [http://www.bb-gruppe.de/handel/ teilweise] || 2014-09-21
|-
| [[#Becker und Müller|Becker und Müller]] || 77790 || Steinach i.K. || ja || ja || ja || ja || 2014-09-21
|-
| [[#Contag|Contag]] || 13581 || Berlin || ? || ja || nein || ja? || 2014-09-21
|-
| [[#Christian Enzmann Gmbh|Christian Enzmann Gmbh]] || 82538 || Geretsried || ? || ja || nein || teilweise || 2014-09-21
|-
| [[#Deutschlaender Electronic GmbH|Deutschlaender Electronic GmbH]] || 74924 || Neckarbischofsheim || ? || ja || ja || ja? || 2014-09-21
|-
| [[#EPN Electroprint GmbH|EPN Electroprint GmbH]] || 07806 || Neustadt an der Orla || ja? || ja || ja || [http://www.epn.de/de/home/geschichte.html ja] || 2014-09-21
|-
| [[#Elischer Leiterplatten|Elischer Leiterplatten]] || 72574 || Bad Urach || ? || ? || nein || ? || 2014-09-21
|-
| [[#Fischer Leiterplatten GmbH|Fischer Leiterplatten GmbH]] || 58454 || Witten || nein || ja || ja || [http://www.fischer-leiterplatten.de/ueber-uns.htm ja] || 2014-09-21
|-
| [[#GLS Leiterplatten-Service GmbH|GLS Leiterplatten-Service GmbH]] || 09221 || Neukirchen || ja? || ja || nein || ja || 2014-09-21
|-
| [[#HAKA Elektronik-Leiterplatten GmbH|HAKA Elektronik-Leiterplatten GmbH]] || 66583 || Spiesen-Elversberg || ja? || ja || ja || ja? || 2014-09-21
|-
| [[#IBR Leiterplatten GmbH & Co. KG|IBR Leiterplatten GmbH & Co. KG]] || 74906 || Bad Rappenau || nein || ja || ja || ja? || 2014-09-21
|-
| [[#ILFA Feinstleitertechnik GmbH|ILFA Feinstleitertechnik GmbH]] || 30559 || Hannover || ? || ja || nein || teilweise || 2014-09-21
|-
| [[#Eurocircuits GmbH|Eurocircuits GmbH]] || 57612 || Kettenhausen || ? || ja || ja || teilweise || 2014-09-21
|-
| [[#Entwicklung & CNC|Entwicklung & CNC]] || 72805 || Lichtenstein || ? || ja || nein || ja || 2014-09-21
|-
| [[#kessler systems GmbH|kessler systems GmbH]] || 88376 || Königseggwald || ? || ja || nein || teilweise || 2014-09-21
|-
| [[#LEITON|LEITON]] || 12099 || Berlin || ja || ja || ja || teilweise || 2014-09-21
|-
| [[#Leiterplatten-Express-Service GmbH|Leiterplatten-Express-Service GmbH]] || 63329 || Egelsbach || ? || ja || nein || ja || 2014-09-21
|-
| [[#Microcirtec|Microcirtec]] || 47805 || Krefeld || nein || ja || ja || ja || 2014-09-21
|-
| [[#MME-Leiterplatten|MME-Leiterplatten]] || 53604 || Bad Honnef || ? || ja || ja || ja? || 2014-09-21
|-
| [[#M & V Leiterplatten - Vertriebs GmbH|M & V Leiterplatten - Vertriebs GmbH]] || 56355 || Bettendorf || ? || ja || ja || ja || 2014-09-20
|-
| [[#Multi_Printed_Circuit_Boards_Ltd.|Multi-CB]] || 85649 || Brunnthal || nein || ja || ja || ? || 2015-02-16
|-
| [[#PCB Joker|PCB Joker GmbH]] || 12099 || Berlin || ? || ja || ja || ja || 2014-09-20
|-
| [[#PCB Pool|PCB Pool]] || 65326 || Aarbergen || ja || ja || ja || teilweise || 2014-09-20
|-
| [[#Precoplat|Precoplat]] || 47805 || Krefeld || ? || ja || ja || ja || 2014-09-20
|-
| [[#Q-print/Q-PCB|Q-print/Q-PCB]] || 68542 || Heddesheim || ? || ja || ja || nein? || 2014-09-20
|-
| [[#Rinde PCB GmbH|Rinde PCB GmbH]] || 42899 || Remscheid || ? || ja || ja || ja || 2015-01-23
|-
| [[#Ruwel|Ruwel]] || 47608 || Geldern || nein? || ja || nein || teilweise || 2014-09-20
|-
| [[#Steimer Leiterplatten GmbH|Steimer Leiterplatten GmbH]] || 42327 || Wuppertal || ja || ja || ja || ja || 2014-09-20
|-
| [[#Onlineshop WEdirekt|Onlineshop WEdirekt]] || 74585 || Rot am See || ja || ja || ja || [http://www.wedirekt.de/index.php/web/live/de/wedirekt/ueberuns/die_produktion/die_produktion_1.php ja] || 2014-09-20
|-
|}

==== 2PrintBeta ====
Homepage: http://www.2printbeta.de/Dienstleistungen/PCB-Stencil-Service::337.html
* SMD-Schablonen aus Mylar gelasert, preiswert und schnell. Masken bis zu 0.5mm Pitch problemlos möglich.
* Super günstig, super flott!
* Keine Begrenzung der Padanzahl.
* Als Student erhalten Sie 25% Rabatt! (Nur gegen Nachweis des Studentenausweises!)

==== Accent PCB GmbH ====
Homepage: http://www.accentpcb.com/duitsland-home.html

Eigendarstellung (vgl. auch [http://www.mikrocontroller.net/topic/316646 Forenthread]):
* Leiterplatten "ab 75€ - €99€"
* erfahrene Techniker
* Beratung gratis
* Produktion in Asien und Europa
* auch flexible und "starr-flexible" Platinen
* Standort: Niederlande

==== Ätzwerk GmbH ====
Homepage: http://www.aetzwerk.de

Eigendarstellung:
* 100x160mm, Lötstopp doppelseitig, Bestückungsdruck einseitig, Stuktur>0,15mm, Bohrungen>0,3mm, 7AT, 59€
* scheint auch an privat zu liefern
* SMD-Schablonen
* Expressfertigung

Erfahrungen:
* verschicken unaufgeforderte Newsletter
* [https://www.mikrocontroller.net/topic/246385 Diskussionsfaden "Ätzwerk GmbH"]

==== am2s ====
Homepage: http://www.am2s.de
* Leiterplatten (Prototypen und Kleinserien, bis hin zur Großserie)
* Eildienst möglich
* Ein- und doppelseitige Leiterplatten, Multilayer.
* Layoutservice
* günstige Preise
* sehr gute Qualität
* Lieferzeit ab 3 AT

==== andus electronic ====
Homepage: http://www.andus.de
* Prototypen Fertigung
* Top Qualität
* Top Service
* Vergleichsweise Teuer

==== ANTtronic ====
Homepage: http://www.anttronic.de/pcb/ früher: http://www.gsel.de
* gute Preise, aber Lieferzeit beachten!
* 1 Europlatine einseitig kein Lötstoplack 17€ inkl. MwSt +7€ Versand
* 1 Europlatine doppelseitig ''nicht durchkontaktiert'' kein Lötstoplack 23€ inkl. MwSt +7€ Versand; 2Stück 37€

==== Basista Leiterplatten ====
Homepage: http://www.basista.de
* Eurokarte doppelseitig für 52€ inkl. MwSt / mit Stopplack + Best.Druck 94€ inkl. MwSt
* Prototypen standardmäßig chemisch zinnbehandelt
* Preise OK
* Früher geliefert ohne Aufpreis (7 statt 10 AT)
* Qualität OK
* Onlinekalkulator
* 100x160mm, zweiseitig, durchkontaktiert, mit Lötstop, 8AT, 82€

==== Bauer-Elektronik ====
Homepage: http://www.bauer-leiterplatten.de
* Eurokarte doppelseitig für 61€ inkl. MwSt 8AT Lieferzeit / Stopplack +10% / Best.Druck +10%
* Prototypen aktivzinnbehandelt, dieses lässt sich laut Firmenangaben noch nach Jahren löten
* Eildienst 2h: Versand am selben Tag bei Einsendung bis 13:00 400€ für 2dm²

==== Britze ====
Homepage: http://www.britze.de
* Leiterplatten in kleinen und mittlere Serien
* Musterleiterplatten / Prototypen
* 1- und 2-lagige Leiterplatten
* Multilayer bis 10 Lagen
* Aluminiumträgerleiterplatten
* ''Online-Kalkulator'' für Multinutzen und Leiterplatten
* Beratung/Layout/Entflechtung von Leiterplatten
* 100x160mm, zweiseitig, durchkontaktiert, mit Lötstop, 10AT, 73€
* scheint auch an privat zu liefern
"Seit dem 17.9.2012 werden alle Leiterplatten von Britze durch die Firma LeitOn GmbH vertrieben, mit der schon eine langjährige Zusammenarbeit besteht." Bestellungen direkt bei britze.de offenbar nur noch für Bestandskunden möglich.

==== B&B Sachsenelektronik GmbH ====
Homepage: http://www.bb-gruppe.de
* Klein- und Musterserien, Spezialist Sondertechniken
* Zusätzliche Partner für Großserien in Asien mit eigenen Mitarbeitern
* Ein- und Doppelseitige Leiterplatten
* Multilayer
* Schleifringe
* Starrflex
* Hochstromleiterplatte
* Dickkupfer
* Flexlam
* Dünnstleiterplatte
* IMS
* HDI Leiterplatte
* E-Test inklusive
* Datenformate: Gerber, Eagle, Excellon, Sieb & Meier
* Eildienst möglich
* Abrufeinteilung und Konsignationslager möglich
* Standort: 09648 Mittweida/Sachsen

==== Becker und Müller ====
Homepage: https://www.becker-mueller.de
* Online Kalkulator (2Lagen, 4 Lagen, 6 Lagen)
* Sonderbauformen (Alu, etc.) möglich
* Qualität gut
* Hochfrequenzschaltungen
* Eildienst möglich

==== Contag====
Homepage: http://www.contag.de
* SAUSCHNELL- ab 4 STUNDEN(!)
* Aber auch sehr teuer
* Qualität sehr gut

==== Christian Enzmann Gmbh ====
Hompage: http://www.enzmann.de

Prototypen
* Schnelle Reaktion auf individuelle Kundenwünsche
* Liefertermine werden eingehalten
Serienfertigung
* gefertigten Prototypen sollen später in Produktion von Großserien gehen
* Kunden können mit großen Stückzahlen versorgt werden

==== Deutschlaender Electronic GmbH ====
Homepage: http://www.deutschlaender.net
* Leiterbahnbreite und -abstand ab 100 µm
* Bohrdurchmesser (Endmaß) ab 0,2 mm
* Sacklöcher, Halblöcher, Tiefenfräsung
* Materialstärke ab 0,5 mm bis 2,4mm
* Kupferauflagen: 35 µm, 70 µm, 105 µm,145 µm und 235 µm
* Hoch-Tg oder Aluminiummaterial
* Fotosensitiver Lötstoplack (grün,schwarz,rot und weiß)
* Bestückungsdruck (weiß,gelb,schwarz und rot)
* Carbondruck (Kontaktflächen)
* Abziehlack
* Viadruck
* Konturfräsen
* Schlitze fräsen - auch durchkontaktiert
* Kerb Ritzen für Kontur, Sollbruchstellen, Sprungritzen
* Kontur anfasen, z.B. für Steckerkamm
* Oberflächenveredelung:
** HAL bleifrei / PbSn
** Chemisch Nickel/Gold(Ni/Au)
** Chemisch Zinn (Sn)
** Galvanisch Nickel/Gold (Ni/Au, Hartgold)
* Datenformate: Gerber, Eagle, Target, Autocad, Excellon, Sieb & Meier
* Eildienst möglich (3AT/5AT/7AT)

==== EPN Electroprint GmbH ====
Homepage: http://www.epn.de
* 8 Tage Lieferzeit, Eilservice 24h auch möglich
* Single-Layer, Multi-Layer (bis 22 Lagen als Spezialanfertigung!), Dickkupfer
* Verzinnung: Hot-Air-Leveling oder chemisch Zinn
* Lötstopplack verschiedene Farben nach Absprache möglich
* Stencil-Fertigung
* Thüringer Staatspreis für Qualität
* Standort: Neustadt an der Orla/Thüringen

==== Elischer Leiterplatten ====
mailto:aurel-elischer@t-online.de
* Firmensitz / Post-Adresse: Dipl.-Ing. Aurel Elischer, Leiterplatten, Am Forst 7, 72574 Bad Urach, Tel. 07125/4498, Ust.Id.-Nr.: DE 223 09 4959
* Layoutentwurf, LP Entwicklung, herstellen, bestücken, löten, prüfen
* 3 KW Lieferzeit (nach Vereinbarung auch kürzer)
* sehr gute Preise, Qual.1A
* einen Preis zu nennen, wäre Unfair. Es ist abhängig davon ob:
** 1 oder 2-seitig
** Leiterbahnenabstand und Lötflächenanstände größer als 0,3 mm
** Cu 30, 70, 110 µm
** Stärke der LP 1,0; 1,6; 2,0; ... mm
** mit (1- oder 2-seitig, grün, blau, weiß, schwarz,...)oder ohne Beschriftung
** mit oder ohne Stoplack
** gefräst oder nur geritzt
** einzeln oder X-Fach-Montage
* unbedingt Gerber 274X und Exellon für die Anfrage (Angebot kostenlos) beifügen; keine Angst: Gerber 274X und Exellon kann man aus jedem Programm generieren

==== Elk Tronic ====
Homepage http://www.elk-tronic.de
* Entwicklung und Fertigung von Kleingeräten und Kleinserien
* Verkauf von IC-Adaptern und Bauteilen

==== Eurocircuits GmbH ====
Hompage: http://www.eurocircuits.de
* ideal für kleine Stückzahlen ab 1 Stück
* Lieferzeit ab 2 AT
* gute Preise bei Prototypen aber auch bei mittleren Stückzahlen
* Online Datenvisualisierung und DRC Check
* SMD - Schablonen
* Preisberechnung eindeutig ohne versteckte Kosten
* Europakarte, 2-lagig, 68.87€ (2014-09-16)

==== Entwicklung & CNC (gewerblich) ====
Hompage: http://www.entwicklung-cnc.de 
mailto:julian.huesing85@googlemail.com
* Europlatine 100x160 1 bis 2 Seitig ca. 20-40€ (Berechnung Maschinenzeit)
* Auch große Platinen möglich.
* Isolationsbreiten abhängig vom Stichel: minimale Isolationsbreite ca. 0,15 mm
* Bohr und Fräsarbeiten, auch aufwändige Konturen realisierbar
* Lieferzeit 8AT, ansonsten Aufpreis bei schnellerer Lieferung
* CNC Fräsarbeiten in PCB, Alu, Holz, Kunststoff, GFK, etc. max. Verfahrwege: 1150x720mm (Fräsmaschine: BZT PFE1000)
* Fertigung erfolgt auf Rechnung mit ausgewiesener Mehrwertsteuer
* USt-IdNr.: DE293952582

==== Fischer Leiterplatten GmbH ====
Homepage: http://www.fischer-leiterplatten.de
* 1 Europlatine inkl. Lack, E-Test, ohne Bestückungsdruck für 46,41€ inkl. MwSt in 10 Tagen + Versand
* 1 Europlatine inkl. Lack, E-Test, Best.-Druck top oder bottom für 58,31€ inkl. MwSt in 10 Tagen + Versand
* 1 Europlatine inkl. Lack, E-Test, Best.-Druck doppelseitig für 117,81€ inkl. MwSt in 10 Tagen + Versand
* max. 4 lagig
* Bestückungsdruck doppelseitig
* Bohrungen no limit
* min Clearance 0,15mm (Standard)
* min Bohrdurchmesser 0,3mm (Standard)
* Gerber/Eagle/Protel/Target
* mehrere Leiterplatten können auf einer Europakarte, zum Preis einer Europakarte, zusammengefasst werden und werden automatisch vereinzelt.
* Überlieferung wird kostenlos beigelegt. (Sprich: in der Regel werden mehr Leiterplatten geliefert als bestellt.)
* Verkauf nur an Gewerbetreibende (aber es wird kein Gewerbenachweis verlangt ;) )
* Erfahrungen: [http://www.mikrocontroller.net/topic/209947#2078731]

==== GLS Leiterplatten-Service GmbH ====
Homepage: <strike>http://www.leiterplattenprototypen.de</strike> 
(URL defekt am 16.3.2015, Redirect zur DeNIC).

* Top Qualität (mittleres Preisniveau)
* Top Service
* Prüfung der Layoutdaten in der CAM
* Standardlieferzeit: 10 Arbeitstage
* Eilservice bis 3 Arbeitstage (mit Aufpreis)
* Oberfläche Standard: HAL bleifrei; aber auch z. B. chem. Gold, chem. Zinn und HAL bleihaltig
* einseitige, nichtdurchkontaktierte Leiterplatten
* durchkontaktierte Leiterplatten
* Multilayer: bis 8-Lagen
* bietet zusätzlichen Service rund um die Leiterplatte: Erstellung von Leiterplattenlayouts und Digitalisierung/Scannen von alten Fertigungsfilmen, Papierausdrucken oder vorhandenen Musterleiterplatten
* SMD Schablonen
* Prototypenfertigung bei Chemnitz

==== HAKA Elektronik-Leiterplatten GmbH ====
Homepage: http://www.haka-lp.de
* Zwillingsangebot: 2 identische Europakarten für 50€ (durchkontaktiert, Lötstop, kein Bestückungsdruck, nur Eagle- oder Target-Dateien), auch hierbei kostenlose Duplizierung kleinerer Layouts
* Zwillingsangebot: 2 identische Doppel-Eurokarten (200x160) für 90€, gleiche Bedingungen wie oben
* Prototypenangebot (min. Abstand 0,15 mm, min. Leiterbahnbreite 0,15 mm, kleinste Bohrung 0,3 mm, durchkontaktiert, Lötstop), 160x100mm in 2AT = 260EUR .. 8AT = 72 EUR .. 15AT = 63 EUR
* bei Platinen kleiner 1 qdm gibt es entsprechend mehr ohne Aufpreis
* Lieferzeit ab 3 Werktage; Achtung: Lieferzeit sind nur Circa-Werte und nicht verbindlich. Auch bei Aufpreis (AGB)!
* sehr gute Qualität

==== LED-Hobby ====
Homepage: http://www.led-hobby.de (ebay-Shop)
* keine Platinen
* SMD Bestückung, Reflowlöten, Lohnbestückung
* Laserschneiden in Plexiglas, Acryl, Sperrholz

==== IBR Leiterplatten GmbH & Co. KG ====
Homepage: http://www.ringler.de
* sehr freundlicher und kompetenter Service
* reagiert sehr schnell
* Qualität TOP
* Preise TOP - günstige Einmalkosten/Setup
* kann auch Dinge wie Alu, Starrflex, fine pitch oder 0,1 er vias
* Lieferzeit ab 2 Tage
* 2 Lagen in 10 Tagen - 10 Lagen Multilayer ohne besondere Nachfrage binnen 18 Tagen geliefert
* liefert generell schneller als bestätigt / macht auch Rahmenaufträge
* Mehrmengen bei Prototypen werden kostenlos geliefert
* SMD-Schablonen

==== ILFA Feinstleitertechnik GmbH ====
Homepage: http://www.ilfa.de

==== kessler systems GmbH ====
Homepage: http://www.kesslersystems.de
* Leiterplatten und Bestückung (Prototypen und Kleinserien, bis hin zur Großserie)
* Sehr schnell
* Ein- und doppelseitige Leiterplatten, Multilayer.
* Layoutservice
* SMD- und THT Bestückung
* Gerätebau
* günstige Preise
* sehr gute Qualität
* Lieferzeit an 3 AT
* Bauelementebeschaffung auch schon bei 1 Stück (super funktioniert)

==== LEITON ====
Homepage: http://www.leiton.de 
http://www.leiterplatten-online.de
* Flexible Leiterplatten online kalkulieren
* Alle Layouts werden in der CAM eingehend geprüft
* Schnellste Bearbeitung von Anfragen
* Diverse Spezialfertigungen (Aluminiumkern, HF, hoch-Tg etc.)
* Fließender Übergang vom Prototyp in die Serie möglich
* Niederlassungen in Hongkong & China für Großserien (LeitOn HK Ltd.)
* Relativ günstig
* bei mehreren kleinen Leiterplatten wird nach Gesamtfläche berechnet, nicht nach Mindestfläche x Mindestpreis x Stückzahl
* Gute Qualität
* Bis 8-lagig und ab 12 Std.

==== Leiterplatten-Express-Service GmbH ====
Homepage: http://www.les-gmbh.com

==== Microcirtec ====
Homepage: http://www.microcirtec.de
* Direct - Online - Shop — zum Kalkulieren-Bestellen und Kaufen
* Mit Auftragsverfolgung per Online
* Vom Rapid Prototyping bis zur Rapid Mass-Production
* Qualität betrachten wir als selbstverständlich
* Allerdings ist die Anmelde-Prozedur ein Drama
* Preiswert

==== MME-Leiterplatten ====
Homepage: http://mme-pcb.de
* [http://www.mikrocontroller.net/topic/73790 Thread 'MME-PCB, Erfahrungen'](bereits 4 Jahre alt)
* Verkauft über seine Homepage (Onlinekalkulator)
* Europakarte: ES: 20,60 EUR, DSDK: 41,50 EUR
* Durchkontaktierung bei zweiseitigen Leiterplatten ist im Preis inbegriffen
* Trennen und Bohren inklusive
* Stopplack inklusive
* Bestückungsdruck (16€) kosten extra
* min. Abstand 0,20 mm, min. Leiterbahnbreite 0,20 mm, kleinste Bohrung 0,4 mm
* Lieferzeit 8-12 Arbeitstage (bei mir waren es nur 5 Werktage)
* Überlieferung kostet nichts (häufig wird eine Leiterplatte mehr geliefert, bei mir waren es bei vier bestellten Platinen zwei mehr)
* Mit einer bestellten einseitigen Platine (DIL Bauteile) bin ich sehr zufrieden
* Die auf der Seite beworbene Lierferzeit wird meist eingehalten.
* Bis zu zehn unterschiedliche Karten können in einem Auftrag gepoolt werden -> preiswerter weil dm² kosten über alle gerechnet werden.
* Antwortet bei mir nicht auf emails, telefonisch kaum zu erreichen.
*Kommunikation hat sich erheblich verbesssert.
* Kommunikation wieder schleppend ( stand: August 2013 )

==== M & V Leiterplatten - Vertriebs GmbH ====
Homepage: http://pcb-center.de früher: http://www.mvpcb.de/
* Bin sehr zufrieden, gute Preise, 10 - 14 Tage
* Top Qualität, nichts auszusetzen
* Qualität sehr gut, hohe Auflösung, auch SMD fine pitch möglich
* Eurokarte doppelseitig 2xStopplack FR4 bleifrei konturgefräst 63€ inkl. MwSt zzgl. Versand
* Eurokarte einseitig 1xStopplack FR4 bleifrei konturgefräst 44€ inkl. MwSt zzgl. Versand

* Freundlicher Kontakt, Leiterplatten sehen gut aus, lieferten 6 Tage zu frueh!
* Bis zu fünf unterschiedliche Karten können in einem Auftrag gepoolt werden -> preiswerter weil dm² kosten über alle gerechnet werden.

==== Multi Printed Circuit Boards Ltd. ====
Homepage: http://www.multi-cb.de

Eigendarstellung:
* Online Kalkulator
* nur für Gewerbetreibende
* 1-48 Lagen Leiterplatten und SMD-Schablonen ab 48h
* Standard 2L & 4L: 5AT Produktionszeit, 6L & 8L: 6AT Produktionszeit
* Standard: 125µm Leiter, 0.2mm Bohren
* Inklusive: Kompletter Design-Rule-Check, Tooling, Lötstopp 2x grün, Posidruck 1x weiß
* Möglich: 75µm Leiter, Blind- & Buried Vias, 0.1mm Bohren, Dickkupfer, ...
* Diverse Spezialfertigungen wie Flex, Starrflex, Metallkern, HF, Hoch-Tg, etc.
* Impedanzkontrolle inkl. Testcoupon
* UL-Zertifizierung

==== PCB Joker ====
Homepage: http://www.pcb-joker.com
* Poolkonzept extrem!
* 1- bis 4 Lagen Multilayer
* Allgemein schnell und geringe Terminzuschläge
* Leiterplatten werden bei verschiedenen deutschen Herstellern platziert
* Sehr günstig , sehr übersichtliche Onlinekalkulation
* Bezahlung per PayPal oder Vorkasse
* Farbe, Dicke, Kupferauflage und Oberfläche können nicht festgelegt werden, sondern sind "Joker"

==== PCB Pool ====
Homepage: http://www.pcb-pool.de
Alternativname: BETA Layout
* Standort: Im Aartal 14, 65326 Aarbergen, [http://www.openstreetmap.de/karte.html?zoom=17&lat=50.23705&lon=8.06361&layers=B000TT Link zur Openstreetmap Karte]
* ideal für einzelne Boards und Klein(st)serien
* Preise im üblichen Rahmen
* Günstigere Preise für 10er oder 20er Auflage
* sehr gute Qualität
* Lieferzeit ab 2 AT
* SMD-Schablonen
* Aktzeptieren von den gängigsten Layoutprogrammen die Boarddaten direkt. AUCH von KiCAD. Siehe http://www.pcb-pool.com/ppde/info_dataformat.html
* Bietet als Service das (Platz optimierte) Zusammensetzten verschiedener Platinen/Projekte. (Stichwort: Ausnutzen von konkaven Polygonen oder Platinen mit "Loch" durch andere Kleinstplatinen) Es können auch Projektdateien verschiedener Programme kombiniert werden (Dafür unbedingt manuelles Angebot per Mail einholen und als Kommentar anmerken. ACHTUNG: Der Online-Kalkulator erstellt hier pro Upload einen Auftrag! Daher für eine solche Kombination NICHT verwenden)

==== Precoplat ====
Homepage: http://www.precoplat.de

* Standort: [http://www.openstreetmap.de/karte.html?zoom=17&lat=51.32818&lon=6.58062&layers=B000TT Oberdiessemer Str. 15, 47805 Krefeld]
* Prototypen, Großserien und alles dazwischen.
* Extrem flexibel im Angebot (Fläche/Lieferzeit, Blitz-Prototyping, Rapid-Mass-Produktion)
* Online Bestellung
* sehr gute Qualität
* bis 24 Lagen
* Mikro-Vias 100-200u
* Carbonlack
* Elektrischer Test (Flying probe + Nadelbett)

==== Q-print/Q-PCB ====
Homepage: http://www.Q-PCB.de
* ideal für einzelne Boards und Klein(st)serien
* supergünstige Preise
* gute Qualität (u.U. Lötstop etwas unsauber)
* keine Zusatzpreise für 2x Lötstoplack o.ä.
* 150 µm kleinste Strukturbreite
* ohne Aufpreis bekommt man entweder HAL oder Ni/Au, gegen Aufpreis kann man aus einem von beiden wählen
* SMD-Schablonen
* Lieferzeit ab 4 AT
* Platine 50mm x 60mm, doppelseitig: ~45€ incl. Versand und ~5€ Nachnahme
* Platine 85mm x 58mm, doppelseitig: 33€ zzgl 6,80 Versand
* Platine 100mm x 160mm, doppelseitig: 49€ +7€ für Lötstopp +6,80€ Versand

==== Rinde PCB GmbH ====
Homepage: http://www.rinde.de
* Mitglied der chinesischen Sunshine PCB Group

==== Ruwel ====
Homepage: http://www.ruwel.com
* Standort: Am Holländer See 70, 47608 Geldern, [http://www.openstreetmap.de/karte.html?zoom=17&lat=51.50451&lon=6.32046&layers=B000TT Link zur Openstreetmap Karte]
* Werke in Deutschland und China
* Überwiegend Großserien.
* Hochtemperatur, Dickkupfer, Kupferinlays, Semiflex, Sacklochbohren.

==== SMTstencil (Großbritannien) ====
Homepage: http://smtstencil.co.uk
* SMD-Schablonen aus Polyester gelasert
* preiswert
* kleinste Strukturen 0,25 x 0,25 mm²
* kleinster Abstand 0,3 mm

==== Steimer Leiterplatten GmbH ====
Homepage: http://www.steimer.de

==== The PCB-Shop / Europrint Deutschland GmbH ====
Homepage: http://www.thepcbshop.com
* Punktabzug, da der Preisrechner nur mit Internet Explorer funktioniert
* gute Qualität
* guter Preis (inkl. gratis Überlieferungen - 30 kleine Platinen bestellt, 35 bekommen)
* wenig Statusinformationen (Link zur Statusseite kommt per Mail, dort ändert sich der Status und der Empfänger eigentlich täglich - ist aber trotzdem fristgerecht angekommen)

==== Würth Elektronik GmbH & Co. KG ====
Homepage: http://www.we-online.de
* gehört sicherlich nicht zu den preisgünstigsten
* kann Bauteile in der Leiterplatte fertigen (R, C, Potis u.a.)
* beherrscht Microvias in allen erdenklichen Varianten
* sehr kompetentes Ansprechpersonal

==== Onlineshop WEdirekt ====

Homepage: http://www.wedirekt.de
* PCB's in Basistechnologie, 2-8 Lagen
* SMD Schablonen in allen Ausführungen
* Europlatine doppelseitig mit Lötstopplack 67€ inkl. MwSt
* Design- und Applikationsfachbücher rund um EMV


=== Deutschland sehr günstige===
Diese Hersteller zeichnen sich durch einen sehr günstigen Preis von '''unter 30€ pro doppelseitiger Eurokarte''' aus und können (bis auf pcb-devboards) '''keine Durchkontaktierungen''' herstellen.

==== EBC Utz Kohl ====
Homepage: [http://www.e-b-c-elektronik.de http://www.e-b-c-elektronik.de]
* recht einfach gehalten, daher wirklich günstig
* Ideal für den Bastler, denen es auf den Preis ankommt
* Geätzt einseitig Euroformat 160 x 100mm 16,- EUR (zzgl 1,- EUR Entsorgungspauschale pro Platine)
* Geätzt doppelseitig Euroformat 160 x 100mm 26,20 (zzgl 2,- EUR Entsorgungspauschale pro Platine)
* Geometrie: Leiterbahnabstand/-breite >0.3/0.3mm; Bohrdurchmesser >0.8mm?; Bohrrestring >? = D-d; Leiterplattengröße <160x100mm?; ein- und doppelseitig
* doppelseitige Platinen sind nicht durchkontaktiert !
* eigentlich ein Ladengeschäft, versendet jedoch auch

==== Platinenbelichter ====
Homepage: http://www.platinenbelichter.de
* eine doppelseitige Europlatine kostet 14,90 EUR Grundpreis + Bohrungen (Preis je Bohrung 0,026cent)
* Geometrie: Leiterbahnabstand/-breite >0.18/0.18mm; Bohrdurchmesser >0.4mm; Bohrrestring >0.25mm = D-d; Leiterplattengröße <300x200mm; ein- und doppelseitig
* Lötstopplack grün auf anfrage möglich
* Scannservice
* Layoutherstellung vom Schaltplan bis zur fertigen Platine

==== Platinendesign ====
Homepage: http://www.platinendesign.de
* Geometrie: Leiterbahnabstand/-breite > 0.25/0.25mm; Bohrdurchmesser >?; Bohrrestring > 0.3mm = D-d; Leiterplattengröße < 300×200mm; ein- und doppelseitig
* eine doppelseitige Europlatine kostet 14 EUR Grundpreis + Bohrung 2cent + Optionen
* keine Durchkontaktierungen möglich
* Lötstopplack grün
* Lieferzeit von bis zu 8 Arbeitstagen nach Geldeingang
* Zeitweise geschlossen, Neueröffnung am 31.3.2013

==== Ertürk Electronic ====
Website: http://www.erturk.de

[mailto:info@erturk.de info@erturk.de]
* Wir rechnen nach dm², Platinenbestellung nur per E-Mail oder telefon möglich. E-Mails werden sehr schnell beantwortet!
* Platine 1seitig FR4, 10,00€/dm²
* Platine 2seitig FR4, 14,00€/dm²
* Kupfer-Endstärke 35µm oder 70µm oder 105µm
* Chemische Verzinnung optional erhältlich
* Geometrie: Leiterbahnabstand/-breite > 0,16/0,16mm; Bohrdurchmesser > 0,4mm; Bohrrestring >0,3mm, Leiterplattengröße < 220×330mm; ein- und doppelseitig
* Sehr hohe Qualität
* Bohrung möglich (ab 20 dm² CNC gesteuert), 0,03 Euro pro Bohrung
* Lieferzeit meistens nach Geldeingang oder bis 3 Arbeitstage
* Ab 15 Platinen sind Durchkontaktierungen, Lötstoplack, Bohrungen und Positionsdruck möglich (Lieferzeit bis zu 2 Wochen). Anfrage und Auftragsannahme nur mit Gerberdaten oder Eagle Daten möglich.
* Für ein Prototyp-Angebot reicht eine Eagle, Sprintlayout- Target3001 oder PDF-Datei schon aus. PDF muss im Maßstab 1:1 und schwarz/weiß sein
* Bestückung möglich (THT / SMD oder gemischt) SMD-Bestückung mit Reflow Verfahren!
* SMD Schablonenherstellung
* Verpackung und Versand von 0,00 bis 5,90 Euro innerhalb Deutschland egal wieviel Sie bestellen
* Mindestauftragsannahme ab 15,00 Euro Inklusiver Verpackung/Versand.
* Stand: Juli 2014

==== Cadgrafik Bauriedl (nur Filme) ====
Homepage: [http://cadgrafik-bauriedl.de/leiterplattenfilme.htm]
* Überträgt Layouts auf hochwertige Folie/Film zum Selberätzen
* 1,15 € / 100 cm² Film, 2,50 € Mindestbestellwert (Stand März 2009)
* 2 € Porto (Stand März 2009)

==== pcb-devboards.de ====
Shop ab 30.10.2015 auf unbestimmte Zeit geschlossen.
Homepage: http://www.pcb-devboards.de/catalog/index.php?cPath=38_55_157
* Einseitige oder doppelseitige durchkontaktierte Leiterplatten mit 0,5-3,20mm Dicke
* Fertigung nur alle 10-15 Arbeitstage
* Eagle, Target (freeware) oder extended Gerberdaten
* Basismaterial FR4 (standard oder schwarz) oder RO4003C (weiß)
* bestimmte Stückzahl von Einzelplatinen ist inklusive, bei sehr vielen Platinen wird eine Fräspauschale erhoben
* Leiterbahnabstand/-breite Standard: 0,2mm Optional: 0,15mm
* Kleinster Restring umlaufend Standard: 0,2mm Optional: 0,15mm
* Kleinster Bohrdurchmesser: 0,4mm
* Optional 35µm Lötstopplaminat
* Bestückungsdruck nicht verfügbar
* Oberfläche: chemisch Zinn oder Silber
* Kupfer-Endstärke 35µm oder 70µm
* Maximale Größe 290x195mm = 5,65dm²
* Versand nach Deutschland ab 6 € (für Stammkunden ab 3,40 €), EU ab 8 €, weltweit ab 8 €

Preisbeispiele:
* FR4 1,60mm 44x44mm doppelseitig 5 €
* FR4 1,60mm 160x100mm einseitig 16,50 €, doppelseitig 23,50 €
* FR4 0,5mm 0,8mm 1,0mm 1,6mm 290x195mm doppelseitig 50 €, Dicke: 3,2mm 60 €

Erfahrungsbericht von [http://www.mikrocontroller.net/articles/Spezial:Beitr%C3%A4ge/Voga2073 Voga2073]: sehr gute Qualität auch bei feinen Strukturen. Der Lötstoplack ist auflaminiert, aber sehr gut positioniert. Leider ist kein Bestückungsdruck möglich. Besonders hervorzuheben ist die Erstellungsdauer: montags bis 12 bestellt, am folgenden Samstag war der Brief in meinem Briefkasten (dies jetzt schon nach drei Bestellungen wiederholt so gelaufen). Preislich ist dieser Anbieter recht attraktiv, ich bin hierhin gewechselt, seit Jakob seine Preisstrategie verschlechtert hat und ich werde wohl bei diesem Anbieter bleiben. Noch positiv zu erwähnen ist das Shopsystem, für jeden wesentlichen Schritt im Herstellungsprozess wird man benachrichtigt. Alles in allem ein sehr guter Anbieter.

=== EU ===
Einfacher, parametrisierbarer Preisvergleich für aktuell 21 weltweite Platinenhersteller (inkl. Abschätzung der Versandkosten): http://pcbshopper.com

==== BILEX-LP (Bulgarien) ====
Homepage http://www.bilex-lp.com
* deutschsprechender Ansprechpartner
* liefern bleifreie Platinen(RoHs konform)
* 26€ für eine doppelseitige Eurokarte ohne Lack und Druck
* ca. 19 euro fuer eine 80x100mm 2-lagige Platine inkl. dukos
* Stencils ab 15.00€
* SMD- und THT Bestückung, Beschaffung der Bauteile
* Layoutservice
* Lieferzeit ab 3-4 AT
* insgesamt von 5 bis 7 AT Anlieferung bei Airmail (Porto ab 4,-Euro)
* FedEx wollte von Bulgarien aus ab 27,-Euro, 1-2AT), DHL ab 20,-Euro, besser DHL nehmen
* Löcher größer 6 mm wurden nicht gebohrt, sondern gefräst(gegen Anfrage)
* Berichtete Qualitätsmängel (in Einzelfällen): ausgefranste Platinenfräsung, Lötstoplack hebt ab(nur bei Sn-Pb beschichtung, nicht bei Ni-Au).
* Fräsungen müssen extra bestellt werden! Aber trotzdem günstig

==== CUBE CZ s.r.o. (Tschechische Republik) ====
Homepage http://www.cube.cz

* kein Termineinhaltung bei Eilservice - Lieferung hat sich durch wiederholte DRC Checks (dauern jeweils einen Tag) und Vorauskassa statt Zahlungsziel 20 Tage wie auf der Rechnung angegeben von 4AT auf 10AT verzögert
* Keine Design Rules auf der Homepage verfügbar
* UL Zertifikat aus 2001 für nur 6 Mil Traces
* für Deutsche Verhältnisse günstig

==== LNAFIN (Finnland) ====
Homepage: http://electronics-pcb.com 
Produkte: http://electronics-pcb.com/shop 
mailto:pcb@lnafin.com
* PCB Vertrieb mit Mikrowellenbereich und Multilagig HDI Kompetenz
* Leiterplatten fuer Industrie und auch als Kleinserien (kein MOQ)
* Elektronik und Layout Design Hilfe (bitte siehe Produkte)
* Auch ASIC design und PCBA (14 ASIC Erfahrung)
* Sicher Service auf Deutsch

==== PIU-Printex (Österreich) ====
Homepage http://www.piu-printex.at
* Bei größeren Mengen (> 20 Stück, einseitig, viele Bohrungen) günstig
* Bearbeitung innerhalb 6 AT
* Telefonische Kontaktaufnahme bei Rückfragen
* Ich war sehr positiv überrascht.

==== PRIONIK (Österreich) ====
Homepage: noch in Arbeit 
mailto:office@prionik.at
* Erstellung von hochwertigen Folien/Filmen zum selberätzen
* 1,25 € / 1dm² Film, 2,50 € Mindestbestellwert (Stand September 2013)
* 2 € Porto Österreich (Stand September 2013)
* 4 € Porto Deutschland (Stand September 2013)
* Leiterplattenfertigung auf Anfrage

==== Ragworm (GB) ====
Homepage http://www.ragworm.eu
* "All-inclusive"-Angebot mit:
:*orangenem Lötstopplack
:*weißem Bestückungsdruck
:*(beides beidseitig)
:*2-lagig
:*internationalem Versand (bei mir 2 Tage, Luftpolsterumschlag)
:*Fräsen/Trennen
:*Check der Gerber-Daten (innerhalb von ein paar Stunden bei mir)
* 10 Stück 5x5: je 8,53 Pfund (~ 10,40€ 23.01.14)
* Bearbeitung innerhalb von 10 AT
* sehr schneller und netter Mail-Kontakt
* gratis Geschenk (bei mir eine 7*9cm große Experimentierplatine + 2 Sticker)
* es wird ein unauffälliger, kleiner, süßer Wurm (der Ragworm) auf den Lötstopp hinzugefügt

==== The PCB Shop (Belgien) ====
Homepage http://www.thepcbshop.com
* Für einfache Sachen
* Preisrechner funktioniert nur mit IE

==== Vi&Rus International (Bulgarien) ====
Homepage: http://www.vrint-pcb.com
* 160x100 für Euro 58,- incl. Express-Versand
* 3 (!) Arbeitstage
* RoHS, ENIG
* 2 Lagen, durchkontaktiert
* Lötstop beideitig
* Bestückungsdruck
* E-Test
* incl. Vereinzelungen (gefräst)
* incl. Versand (1 AT), also am 4. AT geliefert
* Erstklassige Qualität, auch bei Fine-Pitch; schneller, freundlicher Support.

==== SET - Steiner Elektronik Technologie (Bulgarien) ====
Homepage: http://www.setpcb.bg und http://setgmbh.de
* Werk in Bulgarien
* Leiterplatten und Bestückung
* Standardlieferzeit: 8AT
* Gute Qualität, schneller unkomplizierter Support (deutsch und englisch)

==== Multi Circuit Boards Ltd. (GB) ====
Homepage: http://www.multi-circuit-boards.eu
* Versand erfolgt aus Deutschland, Herstellung in GB
* nur für Gewerbetreibende
* Eurokarte doppelseitig mit Lötstopplack, Bestückungsdruck und E-Test in 6AT: 68,54€ inkl. MwSt
* Online Kalkulator

* farbiger Lötstopplack und Bestückungsdruck möglich
* 48 Stunden Express
* Kompletter Design-Rule-Check der CAM-Daten
* Diverse Spezialfertigungen (Flex, Starrflex, Metallkern, HF, hoch-Tg, etc.)
* Sehr gute Qualität
* Liefertermine werden gerne etwas überschritten (auch bei Eilservice)
* Standard 125µm und 5 AT

==== Euro PCB Ltd. (GB) - obsolet ====
Homepage http://www.europcb.com
* Günstige Leiterplatten
* Schnelle Lieferung
* Qualitativ OK
12.02.2012: Webseite ist leer;
2015: Webseite verweist auf http://www.multi-circuit-boards.eu

==== Top-Tec-PCB (GB) - obsolet ====
'''Geschäftsbetrieb eingestellt'''

Homepage http://www.top-tec-pcb.com
* Günstig für Klein- bis Großserien
* Discount bei Nachbestellung
* sehr gute Technik (z. B. 100µm Bohren oder 75µm Leiterbahn)
* deutschsprechender Ansprechpartner
* liefern bleifreie Platinen (HAL, chem. Gold, Silber u. Zinn)
* 48h Eildienst

==== OLIMEX Ltd. (Bulgarien) - obsolet ====
'''Zur Zeit keine PCB-Fertigung (07.01.2015, 3.2015)'''

Homepage http://www.olimex.com

Habe mehrere Jahre bei Olimex meine Prototypen herstellen lassen. Stets saubere Arbeit erhalten. Bis ich denen mal falsche Gerber-Dateien zusandte. Als ich einige Stunden spaeter den Fehler bemerkt hatte, bat ich um Stornierung und Neuzusendung. Gegen ein zusaetzliches Entgelt wurde dies akzeptiert.
Die angesagten Zusatzkosten wurden zwar von mir nicht abgebucht, aber ich erhielt 1 Woche spaeter die anfaenglich falsch zugesandten PCB's.
Die Zusammenfassung des darauffolgenden Email-Verkehrs: Ein Schulterzucken seitens Olimex und die Bitte, eine neue, kostenpflichte Bestellung zu taetigen.

=== USA ===

==== OSH Park ====
Homepage: http://oshpark.com (USA)
* Vermittler und keine eigene Herstellung ("PCB pooling service"). Die Fertigung erfolgt in den USA.
* Nachfolger von BatchPCB.
* $5.00 pro Quadratzoll für drei Platinen inkl. Versand nach Deutschland. (2 Lagen, doppelseitiger Bestückungsdruck, Lila)
* An den Platinen sind noch Stege von der Fertigung, die sich allerdings gut entfernen lassen.
* Herstellung dauert meist ca. 1 Woche.
* Versand in der kostengünstigen Version nochmals ca. 2 Wochen. Schneller geht es mit Aufpreis.
* Auch Fertigung von 4 Layer und Kleinserien möglich.

'''Erfahrungsbericht 2015-12'''
Hatte IS51 Platine als Eagle BRD Datei in Auftrag gegeben (100x80 2-Layer). Es werden immer 3 Stk. gefertigt.
Kosten ca. 60€ (aufgrund des aktuell fast 1:1 Kurses). Das ganze Bestellsystem auf der Webseite hat mit sehr gut gefallen. Vor der Bestellung bekommt man Ansichten der Platine (Top/Bottom/etc.) was grobe Fehler vermeiden sollte. Auch danach bekommt man per Mail Statuswechsel seiner Bestellung (in Arbeit; gefertigt; Versandstatus+Trackingnummer). Macht Alles einen wohldurchdachten und professionellen Eindruck!
Platinen kamen insgesamt nach ca. 2,5 Wochen (davon ca. 1 Woche Transport von USA nach DE+Zoll).
Die Platinen sehen sehr gut aus. Violetter Lötstoplack und vergoldete Pads. Qualität ist auch sehr gut.
Die Platinen hatten allerdings ein vom Layout verursachtes Problem. Es wurden SMD Widerstände verwendet, die
eine Ausfräsung im Milling-Layer hatten. Analyse wurde nach Ticketaufgabe durch OSHPark durchgeführt.
Dabei sehr nett, zügige Antworten und professionell. Obwohl der Fehler im Layout lag und nicht beim Fertiger,
wurde trotzdem eine Nachfertigung ohne Kosten auf Kulanzbasis durchgeführt!

Also alles TOP! Nur mit der englischen Sprache sollte man gut zurecht kommen.

==== PAD2PAD ====
Homepage http://www.pad2pad.com (USA)
* Bestücken die Platinen auch mit Digikey-Bauteilen.

==== PCBPro ====
Homepage http://www.pcbpro.com (USA)
* Bei größeren Mengen (z. B. 100 Stück) sehr niedrige Preise

=== China ===

==== dfrobot ====
Homepage http://www.dfrobot.com (China)

* Mindestens 10Stk
* Größe in 5cm Preisrasterung
* 10Stk 5x5 cm 9.9USD => 1USD/Stk
* 200Stk 5x5 cm 69.5USD => 0.35USD/Stk
* 4 Lagig 10Stk 5x5 cm 64.90USD => 6.49USD/Stk

Bemerkung: auf der angegebenen Webseite sind jede Menge Robotik-Gadgets zu finden, von Leiterplattenherstellung keine Spur. Ist der Eintrag noch gültig? --[[Benutzer:Traumflug|Traumflug]] ([[Benutzer Diskussion:Traumflug|Diskussion]]) 21:24, 16. Aug. 2015 (CEST)
Er ist noch gültig http://www.dfrobot.com/index.php?route=product/category&path=135_134

==== Dirtypcbs ====
Homepage http://dirtypcbs.com (China)
* Mindestens 5Stk
* 2 Layer ca. 10Stk 5x5 cm $14
* 2 Layer ca. 10Stk 10x10 cm $25
* 4 Layer ca. 10Stk 5x5 cm $30 (nur grün)
* 4 Layer ca. 10Stk 10x10 cm $50 (nur grün)
* Versand: kostenlos 8 Wochen, DHL 30$ 9 Tage
* Thread: https://www.mikrocontroller.net/topic/362576#4071490

==== Elecrow ====
Homepage http://www.elecrow.com/services-c-73.html (China)
* Mindestens 5Stk
* Andere Farben ohne Aufpreis
* Größe in 5cm Preisrasterung
* 2 Layer 10Stk 5x5 cm $10
* 2 Layer 10Stk 10x10 cm $24
* 2 Layer 10Stk 10x10 cm $13 (nur grün)
* 4 Layer 10Stk 10x10 cm $24
* Nutzen sind möglich: http://www.elecrow.com/blog/pcb-panelize/
* Thread mit Bildern: https://www.mikrocontroller.net/topic/319266

==== Gold Phoenix ====
Homepage http://www.goldphoenixpcb.biz (VR China)

==== ITead Studio PCB prototyping service ====
Homepage http://iteadstudio.com/store/index.php?main_page=index&cPath=19_20 (VR China)
* Sehr günstige Leiterplatten
* Relativ günstige Lieferung
* 10 Stück mit jeweils 5x5cm für 9,90€
* Qulität relativ gut
* 100% E-Test
* Teilweise Probleme mit Gerberdateien, die knapp am Limit (6 mil) sind
* Testvideo: [http://www.eevblog.com/2011/03/11/eevblog-155-itead-studio-pcb-prototype-goof/ EEVBlog #155]

==== MakePCB ====
Homepage http://www.makepcb.com (Shanghai, VR China)
* Ich habe bei MakePCB Platinen geordert und als Zahlungsart Paypal angegeben. Die automatische Bestaetigung kam, es stand nochmal explizit drin dass ich Paypal als Zahlungsart gewaehlt habe und die Bemerkung, dass bei Zahlungsart Paypal in 2 Tagen eine Mail an die gleiche Adresse kaeme mit den Daten für Paypal. Naja, nach 4 Tagen war immernoch nichts da, ich habe denen eine Mail geschrieben und nochmal nach den "versprochenen" Paypaldaten gefragt. Drei Tage spaeter war immernoch nichts da, also habe ich die Bestellung abgebrochen. Am 8. Tag kam die Zahlungsforderung über Paypal, kein Wort der Erklaerung. Am 10. Tag kamen zwei identische Mails, die sagten man haette die PayPal-Zahlungsaufforderung schon geschickt. Irgendwas laeuft in dem Laden also schief.
* Weiterer Erfahrungsbericht zu MakePCB: Nach einiger Überlegung habe ich mich entschieden, es zu wagen, bei MakePCB Platinen zu bestellen. Meine Platine hatte halbes Euro-Format, aus Kostengründen habe ich gleich 5 Stück bestellt. Der gesamte Preis betrug ca. 45 €, Zahlung per PayPal funktionierte ohne Probleme. Auf der Internetseite von MakePCB wurde für die Produktion 14 Tage, für Shipment 10-14 Tage veranschlagt. Nach der Bestellung konnte ich den Status der Bestellung online in einer Tabelle einsehen. Nach etwas mehr als den veranschlagten 4 Wochen kamen heute die Platinen am. Die Verpackung wirkte nicht sehr professionell (gepolsterter Umschlag, auf den mit Filzstift meine Anschrift geschrieben war), nach dem Aufreissen des Umschlags hielt ich ein mehrfach mit gepolsterter Folie und Klebeband umklebtes Päckchen in der Hand. Erst als ich die Folie entfernt hatte kam eine professionell mit Luftpolsterfolie verschweisste Packung zum Vorschein. Die Platinen sehen, so weit ich bisher beurteilen kann, gut aus, lediglich der Bestückungsdruck ist ein wenig versetzt. Ein kurzer exemplarischer Test mit dem Multimeter sah auch in Ordnung aus. Alles in allem macht das Angebot, insbesondere zu dem Preis, einen echt guten Eindruck. Ich kann es nur empfehlen.

==== PCBCart ====
Homepage http://www.pcbcart.com (China)
* auch kompliziertere Designs
* schnell und zuverlässig
* Eurokarte doppelseitig mit Lötstopp beidseitig und Bestückungsdruck kostet 60€ ohne MwSt +15€ Versand
* 2Stück 64€ ohne MwSt +15€ Versand
* 10Stück 90€ ohne MwSt +15€ Versand
* Eurokarte einseitig ohne Lötstopp und ohne Bestückungsdruck kosten 10Stück 71€ ohne MwSt +19€ Versand
* Preiskalkulation inzwischen auch ohne Anmeldung (18.12.2015)

==== Seeed ====
Homepage http://www.seeedstudio.com (China)
* Mindestens 10Stk
* Größe in 5cm Preisrasterung
* 10Stk 5x5 cm 9.9USD => 1USD/Stk
* 4 Lagig 5Stk 5x5 cm 39.90USD => 8USD/Stk
* 4 Lagig 10Stk 5x5 cm 49.90USD => 5USD/Stk
* Blaue, weiße, rote, gelbe, schwarze platinen für 10USD Aufpreis
* Überproduktion wird mit geliefert, bei einer 2cmx1cm Platine wurden 24Stk anstatt 10Stk geliefert.
* Kostenloser Standardversand bei Bestellungen über 50USD

==== ShenZhen2u ====
Homepage http://www.shenzhen2u.com (China)
* Mindestens 10Stk
* Auch 6 lagige boards
* Größe in 5cm Preisrasterung
* Maximal 30x30cm
* 10Stk 5x5 cm 8.9 USD => 0.9 USD/Stk
* 2 Lagig 500Stk 5x5 cm 139 USD => 0.27 USD/Stk
* 4 Lagig 10Stk 5x5 cm 33 USD => 3.3 USD/Stk
* Dieser Eintrag wurde [http://www.mikrocontroller.net/articles/Spezial:Beitr%C3%A4ge/Shenzhen2u vom Hersteller] selbst erstellt.

Anmerkung: sehr günstige Preise, dafür hohe Versandkosten ("Swiss Post" 27 USD, keine kostenlose Versandoption)

==== smart prototyping ====
Homepage: http://smart-prototyping.com (China)
* Mindestens 10Stk
* Größe in 5cm Preisrasterung
* Auch 6 lagige boards
* Maximal 40x40cm
* 10Stk 5x5 cm 8.9USD => 0.9USD/Stk
* 500Stk 5x5 cm 132.92USD => 0.27USD/Stk
* 4 Lagig 10Stk 5x5 cm 39.9USD => 4USD/Stk
* 6 Lagig 10Stk 5x5 cm 239.9USD => 24USD/Stk
* Lieferzeit ca. 10 Tage (Standardversand mit der Deutschen Post nach DE)
* Schnellere Bearbeitung bei Aufpreis möglich
* Eagle *.brd Dateien werden akzeptiert
* Design Rules für Eagle von der Homepage ladbar
* Problemloser und schneller Kontakt per Mail (englisch)

== Preisvergleichstabellen (Stand Februar 2010) ==

Preise für 1, 2 Europlatinen (160x100), FR4 1.6mm, HAL bleifrei, 150µm Leiter, 0.3mm Bohren, doppelseitig, 8AT, kein Bestückungsdruck, inkl. MwSt, ohne Versand.

{| class="wikitable" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|-
!style="text-align:left" |Hersteller !!Preis (€) 1x !!Preis (€) 2x
|-
|style="text-align:left" colspan="3" |''ohne Lötstopp, ohne E-Test''
|-
|style="text-align:left" |'''Basista Leiterplatten'''|| 43,66 || 81,61
|-
|style="text-align:left" |'''Fischer Leiterplatten GmbH''' (10AT, immer mit LS.+E-T.)|| 46,41 || 73,07
|-
|style="text-align:left" |'''HAKA Elektronik-Leiterplatten GmbH'''|| 64,54 || 106,13
|-
|style="text-align:left" |'''LEITON'''|| 54,98 || 104,51
|-
|style="text-align:left" |'''MME-Leiterplatten''' (200µm Leiter)|| 41,44 || ?
|-
|style="text-align:left" |'''PCB Pool'''|| 50,27 || 100,54
|-
|style="text-align:left" |'''Q-print/Q-PCB'''|| 55,62 || 95,89
|-
|style="text-align:left" colspan="3" |''mit Lötstopp, mit E-Test''
|-
|style="text-align:left" |'''Basista Leiterplatten'''|| 77,66 || 115,61
|-
|style="text-align:left" |'''Fischer Leiterplatten GmbH''' (10AT)|| 46,41 || 73,07
|-
|style="text-align:left" |'''LEITON'''|| 88,79 || 147,39
|-
|style="text-align:left" |'''Multi PCB Ltd. Leiterplatten''' (6AT)|| 78,06 || 156,13
|-
|style="text-align:left" |'''M & V Leiterplatten - Vertriebs GmbH'''|| 62,83 || 125,66
|-
|style="text-align:left" |'''Onlineshop WEdirekt'''|| 128,75 || 172,38
|}

Preise für 1, 2, 10 Europlatinen (160x100), FR4 1.6mm, HAL bleifrei, 150µm Leiter, 0.3mm Bohren, doppelseitig, 8AT, 1x Bestückungsdruck, 2x Lötstopp, E-Test, inkl. MwSt, ohne Versand.

{| class="wikitable" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|-
!Hersteller !! Preis (€) 1x !!Preis (€) 2x !!Preis (€) 10x !! Nachbest. (€) 10x
|-
|style="text-align:left" colspan="5" |''mit Lötstopp, mit Bestückungsdruck, mit E-Test''
|-
|style="text-align:left" |'''Fischer Leiterplatten GmbH''' (10AT)|| 58,31 || 84,97 || 337,72 || 219,91
|-
|style="text-align:left" |'''HAKA Elektronik-Leiterplatten GmbH'''|| 82,54 || 124,13 || 302,08 || 284,08
|-
|style="text-align:left" |'''LEITON'''|| 124,37 || 187,15 || 389,84 || x
|-
|style="text-align:left" |'''Multi PCB Ltd. Leiterplatten'''|| 78,06 || 156,13 || 272,27 || 180,64
|-
|style="text-align:left" |'''M & V Leiterplatten - Vertriebs GmbH'''|| 110,43 || 173,26 || ? || ?
|-
|style="text-align:left" |'''PCB Pool'''|| 122,29 || 129,26 || 407,58 || x
|-
|style="text-align:left" |'''Q-print/Q-PCB'''|| 96,80 || 166,90 || 834,48 || x
|-
|style="text-align:left" |'''Onlineshop WEdirekt'''|| 145,18 || 190,64 || 379,49 || x
|}

== Lohnbestücker - Kleinserien ==

=== Deutschland ===

==== PCB Pool ====
Homepage: http://www.pcb-pool.com/ppde/info_pcb_assembling.html
* Prototyp & Kleinserien, Größere Stückzahlen auf Anfrage
* SMD bis 0402, THT
* 5 Tage ab Eingang aller Bauteile
* Produktionsstandort: ??

==== D-E-K Dischereit GmbH & Co. KG ====
Homepage: http://www.dischereit.de
* Prototyp, Kleinserien, Serie
* SMD bis 0402, THT
* Bauteilbeschaffung
* Standort: Ascheberg, Coesfeld, Deutschland

==== kessler systems GmbH ====
Homepage: http://www.kesslersystems.de
* SMD bis 0201, THT
* BGAs
* macht auch Großserien
* 5 Tage ab Eingang aller Bauteile, Express möglich
* Standort: Königseggwald nähe Ravensburg, Deutschland

==== PBS-Electronic ====
Homepage: http://www.pbs-electronic.de
* Prototyp, Kleinserien, Serie
* BGA, QFN, TQPF, Fine Pitch, SMD bis 0402, THT
* Einzel IC Bestückung möglich
* Spezialist für LED Technik
* Standort: Arnsberg, Hochsauerland, Deutschland

==== riese electronic GmbH ====
Homepage: http://www.riese-electronic.de
* SMD bis 0201, THT
* BGAs inkl Röntgen
* macht auch Großserien
* 5 Tage ab Eingang aller Bauteile, Express möglich
* Standort: Horb am Neckar, Deutschland

==== Gardow Engineering ====
Homepage: http://www.gardow-engineering.de
* SMD ab 0201, THT, THR, Mischbestückung, BGA Bestückung
* ab 1 Stück bis zur Serie
* Frontplattenfertigung
* Materialbeschaffung, Lieferzeiten zwischen 1-6AT, niedrige Einmalkosten
* Onlinekalkulator zur schnellen Kostenermittlung
* http://www.gardow-engineering.de/leiterplattenbestückung/onlinekalkulation.html
* Standort: Nordheim bei Heilbronn, Deutschland

==== M.Richter GmbH&Co.&KG ====
Homepage: http://www.richter-pforzheim.de
* SMD ab0201, THT, THR, Mischbestückung
* ab 1 Stück bis zur mittleren Serie
* Wickeln von Sonderspulen und Kabelkonfektion
* Materialbeschaffung, Schnelldienste möglich
* Standort: Pforzheim, Deutschland

==== SYSTART GmbH ====
Homepage: http://www.systart.de
* Online-Kalkulator für Prototypen- und Kleinserienbestückung: http://www.systart.de/prototypen-kalkulator
* Größere Stückzahlen auf Anfrage
* 4 Tage ab Eingang aller Bauteile
* Günstige Einmalkosten
* SMD- und THT-Bestückung, beidseitig
* Gerätemontage
* Materialbeschaffung (falls gewünscht)
* Ingenieurbüro und Fertigung in einem Haus: bei technischen Rückfragen stehen auch Entwickler zur Verfügung
* Standort: Emmering bei München

==== Traffitec ====
Homepage: http://www.traffitec.de
* Bestückt Prototypen, Kleinserien, Normalserien
* In THT, SMD und gemischt.
* und von allen Seiten
* Einpresstechnik
* Starrflex
* Komponentenbau
* Standort: [http://www.openstreetmap.de/karte.html?zoom=17&lat=51.6904&lon=6.14378&layers=B000TT Goch nähe Moers, Deutschland]

==== VTS Elektronik GmbH ====
Homepage: http://www.vts-elektronik.de
* SMD bis 0402, BGA, THT auch gemischt und beidseitig
* Dampfphasenlöten
* Prototyp, Kleinserien, Serie
* Komplette Materialbeschaffung
* Schnell und flexibel
* Standort: Fürstenau nähe Osnarbrück, Deutschland

==== JL-Elektronik ====
Homepage: http://www.jl-elektronik.de 
mailto:info@jl-elektronik.de
* Prototyp, Kleinserien
* ab 1 Stück
* SMD bis 0402, THT, gemischt und beidseitig
* Gerätemontage
* Standort: Rheinland Pfalz, Deutschland

=== International ===

==== Kaufmann Automotive GmbH ====
Homepage: http://www.kaufmann-automotive.ch
* SMD bis 0201, THT
* BGA, QFN, TQFP, Fine Pitch, SMD bis 0402
* Prototyp, Kleinserien, Serie
* Komplette Materialbeschaffung
* Standort: Eichberg nähe Bregenz, Schweiz

==== Profiants ====
Homepage: http://www.ProfiAnts.com
* SMD bis 0201, THT
* ab 1 Stück
* macht auch Großserien
* Komplette Materialbeschaffung
* 5 Tage ab Eingang aller Bauteile
* Standort: Bulgarien

==== REDER Domotic GmbH ====
Homepage: http://reder.eu
* Prototypen, Kleinserie, Serie
* THT, SMD ab 0201 Baugröße
* Komplette Materialbeschaffung
* Prototypen über Nacht möglich
* riesen Vorteil: der Mann an der Maschine ist selbst Entwickler
* Standort: Berndorf, Österreich

== Siehe auch ==
* [http://www.cadsoft.de/services/board-houses/?language=de Übersicht von Cadsoft, sortiert nach PLZ]
* [http://www.mikrocontroller.net/topic/245590 Forum: Platinensammler - Leiterkarten für 30ct/cm²]
* [http://www.elektroniknet.de/anbieterkompass/produktuebersicht/?tx_wmvs_pi1%5Bid%5D=1130 Übersichtsseite von www.elektroniknet.de]
* [[Elektronikversender]]

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

AVR Net-IO Bausatz von Pollin

2015-05-03T08:16:13Z

Df2au: /* Funktionsumfang der Originalsoftware */ Typo

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* bzw. 5V DC, 1A (Steckernetzteil) an J6
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. <s>Eine 10µF-Version für den MAX232 gibt es nicht</s>. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Betrieb mit Steckernetzteil
** Wenn man ein energieeffizientes Stecker-Schaltnetzteil mit 5V, 1A direkt an J6 kontaktiert, kann man sich die o.g. Um- und Ausbauten sparen. Kein Spannungsregler wird mehr heiß, kein Kühlkörper wird benötigt, das Board arbeitet absolut stabil.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches am Port 50290 eine Textschnittstelle bereit stellt. Diese Schnittstelle kann sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge sowie alle Ausgänge anzusprechen, als auch die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
Einen digitalen Ausgang auf 0 oder 1 schalten
* GETPORT
Den Status eines digital Ausgangs/Eingangs abfragen
* GETSTATUS
Den Status aller digital Ausgänge abfragen
* GETADC
Den Messwert eines analogen Eingangs ermitteln
* SETIP
Die IP-Adresse des Boards ändern
* GETIP
Die eingestellte IP-Adresse abfragen
* SETMASK
Die Netzwerkmaske verändern
* GETMASK
Die eingestelle Netzwerkmaske abfragen
* SETGW
Das Netzwerk-Gateway verändern
* GETGW
Das eingestellte Netzwerk-Gateway abfragen
* INITLCD
Ein angeschlossenes LCD initialisieren
* WRITELCD
Einen Text am LCD ausgeben
* CLEARLCD
Ein angeschlossenes LCD löschen
* VERSION
Die Versionsnummer des Programms ausgeben

Dazu gibt es ein auf Java basierendes Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Java-Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt. Auch kann die grafische Aufbereitung der Anzeige- und Kontrollelemente nicht befriedigen.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

* Januar 2014, Bausatz komplett, Aufbau ohne Probleme, Betrieb mit 9V DC, LAN funktioniert auf Anhieb, RS232 noch nicht getestet.

* März 2014, Komplettgerät, von ca. 100 Versuchen gerade mal 2 erfolgreiche Zugänge. Weder LAN noch RS232 mit Putty funktionierten.

* Dezember Bausatz komplett, Aufbau ohne Probleme und mit zusätzlichen Kondensatoren gesichert, Betrieb mit 9V DC, LAN funktioniert auf Anhieb, RS232 getestet.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mit dem E2000-NET-IO-Multi-Control ist es möglich, die von dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Webseite: http://netioapp.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netioapp.com/editor/ Online Editor] vorher am PC erstellen.
Eine fertige [http://netioapp.com/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===
'''(Projekt scheint erloschen - Links all down - Jan. 2014)'''

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

Wellenwiderstand

2015-01-19T09:02:56Z

Df2au: /* Eine schöne und verständliche Erklärung aus einem Forumsthread */ Pleonasmus, Typo

== Einleitung ==

Schnelle Digitalschaltkreise bzw. hochfrequente Analogschaltungen stellen erhöhte Anforderungen an die Verbindungsleitungen zwischen ICs und Baugruppen. Wo ein langsamer CMOS-Baustein der 4000 Serie mit ein paar Megahertz (wobei die Flankensteilheit entscheidet - nicht die Frequenz) noch problemlos auf dem Steckbrett mit wilder Klingeldrahtverkabelung funktioniert, dort versagt ein moderner, schneller IC seinen Dienst. Ähnliches passiert auf geätzten Leiterplatten. Nicht nur die Packungsdichte der Gehäuse, auch die immer kürzer werdenden Schaltzeiten der Signale verlangen mehr und mehr einen durchdachten, hochfrequenzgerechten Aufbau mit zwei, vier oder mehr Lagen. Die Verbindungsleitungen, welche bei niedrigen Frequenzen praktisch nicht auffallen, sind plötzlich sichtbare Bauelemente, welche die zwei wichtigen Parameter Wellenwiderstand und Laufzeit aufweisen.

== Wellenwiderstand ==

[[bild:wellenwiderstand_ersatzschaltbild.png|thumb|right|372px|Modell eines elektrischen Leiters mit Widerständen, Kapazitäten und Induktivitäten]]
Eine elektrische Leitung muß bei hohen Frequenzen als ein Netzwerk aus folgenden Komponenten betrachtet werden:

* Serienwiderstand Rs
* Parallelwiderstand Rp
* Serieninduktivität Ls
* Parallelkapazität Cp

Praktisch kann man sich das so vorstellen: Jeder elektrische Leiter hat einen [[Widerstand|ohmschen Widerstand]] Rs. Vorsicht! Das ist nicht der Wellenwiderstand! Ebenso hat jede elektrische Leitung einen Widerstand zwischen den Leitern, denn der Isolator ist nie ideal. Praktisch kann man den allerdings meist vernachlässigen, da er im Bereich von Gigaohm liegt.

Die unvermeidlichen und ausschlaggebenden Parameter sind jedoch Ls und Cp. Jeder elektrische Leiter, welcher von einem Strom durchflossen wird, erzeugt ein Magnetfeld. Das ist gleichbedeutend mit der Induktivität Ls. Ebenso besteht zwischen zwei isolierten Leitern immer ein elektrisches Feld, wodurch der Kondensator Cp gebildet wird. Ls und Cp sind die entscheidenden Größen zur Bestimmung des Wellenwiderstandes. Je nach geometrischer Anordnung der Leiter kann man sie in gewissen Grenzen variieren (Koaxialkabel, Twisted Pair, Flachbandkabel etc.).

Der Wellenwiderstand berechnet sich aus

:<math>Z_0= \sqrt{\frac{L_s}{C_p}}</math>

Er ist eine charkteristische Größe einer Leitung. Er ist unabhängig von der Länge der Leitung.

Beispiele:

* Koaxialkabel RG58 und RG174, 50Ω
* Koaxialkabel RG59, 75Ω;
* Twisted Pair CAT3/5/7 für Ethernet, 100Ω
* Flachbandkabel, 150Ω typ.
* Leiterbahnen auf Platinen mit 30...150Ω

== Laufzeit ==

Elektrische Signale haben eine sehr hohe, aber dennoch begrenzte Ausbreitungsgeschwindigkeit. In Luft bzw. im Vakuum breiten sich Funksignale mit Lichtgeschwindigkeit aus, das sind 300.000 km/s, oder 30cm/ns. Auf Leitungen breiten sich Signale langsamer aus, da das elektromagnetische Feld mit der Umgebung interagiert. Je nach Leitungstyp etwa mit 50..70% der Lichtgeschwindigkeit, sprich mit ca. 15..21 cm/ns.

== Terminierung ==

Wenn eine elektrische Leitung als lang betrachtet werden muß, dann treten Reflexionen auf. Diese sind unerwünscht und können von sporadischen Fehlern bis zum völligen Versagen einer Schaltung alles verursachen. Deshalb müssen solche Leitungen terminiert werden. Die Terminierung absorbiert die einlaufenden Signale und verhindert damit ungewollte Reflexionen. Eine Leitung wird mit einem ohmschen Widerstand terminiert, welcher den gleichen Wert wie der Wellenwiderstand aufweist. Die Terminierungswiderstände müssen möglichst am Ende der Leitung plaziert werden.

:'''Eine Leitung ist dann als elektrisch lang zu betrachten, wenn die einfache Laufzeit der Leitung größer als ca. 1/6 der minimalen Anstiegszeit der Signale ist.'''

;Ein Beispiel:

Ein [[AVR]] ist ein recht typischer, digitaler IC. Die minimale Anstiegszeit beträgt ca. 5ns. Nach obiger Formel darf die Laufzeit nur
: 1/6 · 5ns ≈ 0,83ns
betragen. Bei einer Ausbreitungsgeschwindigkeit von 21cm/ns ergibt das eine maximal zulässige Leitungslänge von
: 21cm/ns · 0,83ns ≈ 17,5cm
Das heißt, bei einer Leitungslänge von bis zu 17,5cm ''und'' halbwegs sauberer Leitungsführung treten keine nennenswerten Reflexionen auf und eine Terminierung ist nicht notwendig. Darüber muss man aufpassen: spätestens bei dem doppelten bis dreifachen Wert ist eine Terminierung meist unverzichtbar.

=== Serienterminierung ===

[[bild:wellenwiderstand_serienterminierung.png|thumb|right|350px|Serienterminierung]]
Serienterminierung arbeitet bewußt mit Reflexionen. Von der Quelle wird ein Signal mit einem Innenwiderstand gleich dem Wellenwiderstand eingespeist. Dadurch ergibt sich ein Spannungsteiler von 1:2, d.h. Das Signal hat kurzzeitig nur die halbe Amplitude. Damit läuft es bis zum Ende der Leitung, welches offen ist. Es wird zu 100% reflektiert. Dadurch entsteht der volle Spannungspegel. Wenn die rücklaufende Reflexion die Quelle wieder erreicht wird sie vom Innenwiderstand der Quelle, welcher gleich dem Wellenwiderstand ist, absorbiert, es entsteht keine weitere Reflexion. Idealerweise sollte der externe Serienwiderstand Rs plus der Innenwiderstand des Ausgangs Ri gleich dem Wellenwiderstand sein. CMOS-ICs haben Ausgangswiderstände zwischen 15..50Ω.

Der Terminierungswiderstand muss in der Nähe des Ausgangs des treibenden Bausteins platziert werden -> Quellenterminierung.

Datensignale können meist problemlos mit Serienterminierung betrieben werden. Taktsignale dürfen nur bei Punkt zu Punkt Verbindungen mit Serienterminierung betrieben werden (ein Sender und nur ein Empfänger). Anderenfalls kann es zu Fehlfunktionen kommen, da ein Takteingang, welcher in der Mitte der Leitung sitzt für ein paar Nanosekunden eine Spannung am Eingang anliegen hat die etwa VCC/2 entspricht. Das ist aber genau die Schaltschwelle von CMOS-ICs. Kleinste eingekoppelte Störungen können nun dafür sorgen, daß der Takteingang mehrere Flanken "sieht", wo eigentlich nur eine sein sollte.

=== Parallelterminierung ===

[[bild:wellenwiderstand_parallelterminierung.png|thumb|right|350px|Parallelterminierung]]
Parallelterminierung absorbiert die ankommende Welle am Ende einer Leitung. Damit treten zu keinem Zeitpunkt Reflexionen auf. Nachteilig ist der Stromverbrauch bei HIGH-Pegel. Diese Terminierung ist nicht für 5 oder 3.3V CMOS geeignet. Parallelterminierung wird typisch bei Ethernet sowie beim RS485-Bus verwendet, dort sogar an beiden Enden. Es gibt diverse IO-Standards wie HSTL, SSTL etc., welche für schnelle ICs entwickelt wurden (DDR-RAM, DDR2-RAM), diese arbeiten mit Parallel- sowie Serienterminierung.

[[bild:wellenwiderstand_vt-terminierung.png|thumb|right|350px|Terminierungsspannung]]
Den Stromverbrauch kann man halbieren, indem man mit einem speziellen Spannungsregler eine sog. ''Terminierungsspannung'' generiert (z. B. bei SCSI). Dieser Spannungsregler muss sowohl Strom liefern können (source) als auch Strom aufnehmen können (sink). Allerdings ist auch hier der Stromverbrauch noch recht beachtlich, jedoch hat man mit etwas stärkeren Bustreibern eine Chance, auch mit 5/3.3V CMOS eine Terminierung treiben zu können.

Der Terminierungswiderstand muss in der Nähe des Eingangs des empfangenden Bausteins platziert werden -> Senkenterminierung.

{{Absatz}}

[[bild:wellenwiderstand_theveninterminierung.png|thumb|right|350px|Thevenin-Terminierung]]

Ohne Terminierungsspannung kommt man mit der sog. ''Thevenin-Terminierung'' aus. Dabei wird der Terminierungswiderstand durch zwei doppelt so große Widerstände ersetzt. Aus Sicht des Kabels sind diese beiden Widerstände ''parallel'' geschaltet! Wichtig ist der zusätzliche Kondensator an VCC und GND, er stellt einen hochfrequenten Kurzschluß dar und ist wichtig für die Funktion dieser speziellen Terminierung. Er muss wie ein [[Kondensator#Entkoppelkondensator | Entkoppelkondensator]] bei einem IC betrachtet und dementsprechend nah platziert werden.

Daher auch der Name: ''Thevenin Equivalent'' ist im Englischen die Bezeichung für eine Ersatzschaltung mit anderem Aufbau aber im Endeffekt gleichen Eigenschaften. Hier spart man auch die Hälfte des Stroms ein, allerdings fliesst jetzt auch bei LOW ein Strom durch die Terminierung. Der Stromverbrauch bzw. die Treiberbelastung ist identisch zur Nutzung einer Terminierungsspannung.

{{Absatz}}

=== AC-Terminierung ===

[[bild:wellenwiderstand_ac-terminierung.png|thumb|rigt|350px|AC-Terminierung]]
Um den Stromverbrauch allgemein zu senken kann AC-Terminierung eingesetzt werden.

Dazu wird ein Kondensator in Reihe zum Terminierungswiderstand geschaltet. Damit fliesst nur für eine kurze Zeit ein Strom, wenn der Pegel wechselt. Nachteilig ist die bisweilen kritische Dimensionierung des Kondensators. Er darf nicht zu klein sein, damit die Spannung nicht zu schnell steigt und somit der Terminierungswiderstand nicht voll wirksam ist. Andererseits darf er nicht zu groß sein, damit der Umladevorgang vor dem nächsten Flankenwechsel abgeschlossen ist (Taktfrequenz). Hier muß man ggf. experimentieren und ''richtig'' messen. Typische Werte liegen zwischen 100pF und 10nF.

Für Takte und Signale mit konstantem Mittelwert ([[Manchester]]kodierung, 8B10B Kodierung) kann man den Kondensator sehr groß wählen (100nF Keramik + großen Elko). Dann lädt sich der Kondensator über mehrere hundert Takte auf den Mittelwert der Spannung auf und hält diese. Damit wirkt er wie eine Spannungsquelle für die Terminierungsspannung.

Der Vorteil ist der eingesparte Spannungsregler, der Stromverbrauch ist identisch mit der Parallelterminierung mit Terminierungsspannng. Als grobe Orientierung sollte die Zeitkonstante aus Terminierungswiderstand mal Kondensator ca. 1000 mal größer sein als die Periodendauer des Taktes bzw. die Bitdauer das Datenstroms sein:

:<math>R_T \cdot C_T \;\gtrapprox\; 1000 \cdot T_\text{CLK}</math>

== Takt- und Datensignale ==

Bei Datensignalen ist es meist durchaus akzeptabel, wenn ein erhöhtes Maß an Überschwingern und Reflexionen auftreten. Auf synchronen [[Bus]]systemem werden die Daten mittels eines Taktes abgetastet. Nur zu diesem Zeitpunkt müssen die Daten sauber anliegen, ein wenig davor (Setup Time) und ein wenig danach (Hold time). Ganz anders bei Takten, asynchronen Resets und Interruptsignalen. Auf diese reagiert ein digitaler IC '''sofort''' und sehr schnell. Durch Reflexionen kann es zu "Zacken" auf Taktflanken kommen, welche ein langsamer IC ignoriert aber ein schneller darauf reagiert und zwei Taktflanken "sieht", wo eigentlich nur eine ist. Hier muss man aufpassen. Diese Signale sollten

* sehr solide layoutet werden
* etwas Abstand zu allen anderen Signalen bekommen
* ggf. sauber terminiert werden

Dann gibt es auch keine Probleme mit instabilen Datenübertragungen etc.

== Leitungsführung und Layout ==

Der Zusatz "und halbwegs saubere Leitungsführung" ist eine entscheidende Komponente bei der Verteilung schneller Signale! Irgendwelche wilde Klingeldrahtorgien oder lieblos auf die Platine geschmissene Leitungen zählen nicht dazu. Im Idealfall sind die Leitungen mit einer Impedanz von 50 oder 75Ω layoutet, bei differentiellen Signalen auch 100Ω (Ethernet, LVDS etc.). Dazu muß eine bestimmte Geometrie der Leiterbahn eingehalten werden, im wesentlichen bestimmt durch Breite und Abstand zur Referenzfläche (GND oder VCC). Die Stichworte für eine Suche im Internet lauten Microstrip und Stripline. Bei zwei- oder vierlagigen Platinen werden die Leitungen mit 50/75Ω ziemlich breit, deshalb kann man sich dort dem Ideal nur sehr grob nähern. Dennoch sollte man es vor allem für Takte versuchen und möglichst die Leitung über einer Referenzfläche führen. Das grundlegende Prinzip lautet:

'''Die Fläche der Leiterschleife zwischen Signal und Massefläche muß minimiert werden.'''

Man muß immer daran denken. Strom fließt immer im Kreis, deshalb heißt es ja auch Stromkreis. Der Stromkreis beginnt am Versorgungspin des ICs, welcher das Signal generiert, läuft über den Ausgang und die Signalleitung zum Eingang des Empfängers bzw. der dort platzierten Terminierung, dort nach Masse und über die Masse zurück zum Sender-IC. Die Rückleitung über Masse ist genauso wichtig wie die Hinleitung des Signals! Eine wild geschlungene Masseleitung macht das beste Layout zunichte. Optimal sind komplette Masseflächen, doch die sind meist nur bei Platinen mit vier oder mehr Lagen machbar. Bei hochfrequenten Analogschaltungen gönnt man sich den "Luxus" auch bei zweilagigen, weil man sonst in Teufels Küche kommt. Bei schnellen Digitalschaltungen auf zweilagigen Platinen muß man Kompromisse eingehen. Aber auch hier gilt die alte Weisheit, daß die Masse möglichst sternförmig verteilt werden sollte. Entgegen der weit verbreiteten Meinung spielen 90° Winkel keine große Rolle, auch nicht weit in den den Bereich von 1 GHz! Siehe [[#Links | Abschnitt Links]].

Wenn Kabel als Verbindung zwischen ICs verwendet werden, sollte man auch hier Sorgfalt walten lassen.

* Idealerweise sollte man bei Flachbandkabeln jede 2. Ader auf Masse legen und auf BEIDEN Seiten der Verbindung am Stecker mit der Masse der Platine verbunden werden.
* Meist reicht es, jede 4. bis 10. Ader auf Masse zu legen, wobei man Takte direkt neben die Masse legen sollte.
* Bei Steuerkabeln (verdrillt oder auch nicht) gilt ähnliches.

== Zusammenfassung ==

* Entscheidend für das Entstehen von Reflexionen ist '''NICHT''' die Taktfrequenz sondern die Anstiegszeit der Signale. Eine Schaltung mit schnellen ICs wird auch bei niedrigen Taktfrequenzen sehr schnell schalten, auch wenn das nicht unbedingt notwendig wäre.
* Mit Reflexionen muß man rechnen, wenn die einfache Laufzeit der Leitung grösser als ca. 1/6 der minimalen Anstiegszeit der Signale ist.
* Serienterminierung ist für Takte nur bei Punkt-zu-Punkt-Verbindungen sicher nutzbar.
* Parallelterminierung ist für 5/3,3V CMOS ungeeignet (Stromverbrauch).
* Auch mit Terminierung ist bei schnellen Signalen eine halbwegs saubere Leitungsführung notwendig.
* Man sollte nach Möglichkeit immer die langsamsten Logikbausteine verwenden, um Probleme mit Reflexionen zu minimieren (Wozu braucht man 1ns Anstiegszeit bei 5 MHz Takt?).
* Ausgänge sollten möglichst identische Ausgangswiderstände für LOW und HIGH haben (wie z. B. die HC-Familie), sonst wird eine Serienterminierung schwierig bis unmöglich (wie. z. B. die ABT-Familie); siehe [http://www.ti.com/litv/pdf/szza008 "Input and Output Characteristics of Digital Integrated Circuits"]

== Eine schöne und verständliche Erklärung aus einem Forumsthread ==

→ [http://www.mikrocontroller.net/topic/238751 Forum: ''Was ist der Wellenwiderstand?'']
# Bei einer kurzen Leitung (kürzer als ein Viertel der Wellenenlänge)
#* Bei einer Leitung ohne Last (Re = ∞) wirkt die Leitung wegen ihrer verteilten Kapazität (Kapazitätsbelag) kapazitiv.
#* Bei einer Leitung mit Kurzschluss am Ende (Re = 0) wirkt die Leitung wegen ihrer verteilten Induktivität (Induktivitätsbelag) induktiv.
#* Irgendwo dazwischen gibt es einen Wert, wo Induktivität und Kapazität sich gerade kompensieren: Das ist der Wellenwiderstand. Er ermöglicht eine kapazitäts- und induktivitätsfreie Übertragung.
# Eine Leitung gibt an einen Lastwiderstand volle Leistung nur bei einem bestimmten Strom/Spannungsverhältnis ab. Wenn der Lastwiderstand ein anderes Strom/Spannungsverhältnis erzwingt, wird ein Teil des Stroms oder der Spannung in die Leitung reflektiert. Der Widerstand, bei dem z.B. Impulse reflexionsfrei übergeben werden, ist der Wellenwiderstand.
# Durch die Geometrie einer Leitung werden Kapazitätsbelag und/oder Induktivitätsbelag verändert. Aus dem Verhältnis Kapazität/Induktivität lässt sich ein Widerstand errechnen, dies ist der Wellenwiderstand.

== Wellenwiderstand messen ==

Siehe hier: http://www.mikrocontroller.net/topic/106235

== 90° Ecken in Leiterbahnen ==

Das Thema wird seit Jahrzehnten diskutiert, real gemessen haben die Wenigsten. Hier die kurze Zusammenfassung aus zwei guten Quellen.

[http://www.ultracad.com/articles/90deg.pdf Messung] von Ultraboard
*sieben Leiterzüge mit 20,3cm Länge, 0,25mm Breite, Microstrip mit 50 Ohm; verschiedene Winkel
*Messung mit TDR und 17ps Anstiegszeit, ~2,8mm Pulslänge auf der Leitung, etwa 10fache Leiterbahnbreite
*Auf keiner Leitung konnten Effekte nachgewiesen werden!
*Eine Messung der Abstrahlung mittels Antenne bis 1,3 GHz zeigte auch keine sichtbaren Unterschiede jenseits der Messungenauigkeit

[http://www.theamphour.com/the-amp-hour-77-winsome-waveform-wizardry/ Interview] mit [http://www.signalintegrity.com/hj.htm Dr. Howard Johnson], HF-Guru
* Die Legende kommt aus dem Bereich der Mikrowellen, wo die Theorie und Praxis in den 1960er Jahren sehr umfangreich erarbeitet wurde
* Direkte Übertragung vom Mikrowellengebiet 1-100GHz auf schnelle Digitalsignale (100MHz-10GHz) ist direkt nicht möglich, weil die Parameter anders sind
* Typische Leiterbahnbreiten für Digitalsignale sind 0,25mm und weniger, eine 90 Grad Ecke fügt ca. 0,02pF hinzu, typische Frequenz 1GHz bei Signalamplituden von 400mV und mehr (PECL, LVDS), hoher Störabstand (Digitalsignale), der Effekt ist kaum nachweisbar
* Typische Leiterbahnbreite für Mikrowellentechnik ist 3mm, Kapazitätszuwachs liegt bei ca. 0,2pF, Frequenzen von 10 GHz und mehr, Signalamplituden im Millivoltbereich mit engen Toleranzen über eine lange, analoge Verstärkerkette (+/-0,5dB über 10 Stufen)

Fazit. Die Winkel spielen unter 1 GHz keine Rolle, darüberhinaus nur sehr wenig. VIAs spielen bei 1GHz und mehr eine Rolle. 10fach wichtiger ist jedoch immer eine solide Bezugsfläche unter der HF-Leitung!

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/181484?goto=1752540#1752540 Forumsbeitrag]: Warum HF-Leitungen abrunden?
* [http://www.mikrocontroller.net/topic/299855?goto=new#3220070 Forumsbeitrag:] Skurriles Problem mit BS170 Mosfets; erfolgreiche Anwendung einer Thevenin-Terminierung für einen [[SPI]]-[[Bus]] mit langen Kabeln
* [http://www.mikrocontroller.net/topic/299855?page=1#3216635 Forumsbeitrag]: Einfacher Treiber für Parallelterminierung.

== Links ==

* [http://de.wikipedia.org/wiki/Wellenimpedanz Wellenwiderstand bei Wikipedia]
* [http://www.signalintegrity.com www.signalintegrity.com], Die Bibel der hochfrequenten Digitalsignale
* [http://www.onsemi.com/pub/Collateral/AND8020-D.PDF AppNote von ON Semiconductor: Termination of ECL Logic Devices] (ausführlicher als der Artikel)
* [http://www.ti.com/litv/pdf/szza008 "Input and Output Characteristics of Digital Integrated Circuits"]
* http://www.forelec.ch/fichiers/HS-PCB-1.PDF (Sehr gutes Dokument zum Thema)
* [http://wiki.fed.de/fed-wiki/images/3/3f/Impedanzarten_-_Lagenaufbauten.pdf Striplines/Microstrip schnell berechnet] (PDF)
* [http://www1.sphere.ne.jp/i-lab/ilab/tool/cpw_e.htm Online Calculator]
* [http://www.hp.woodshot.com/appcad/version302/setup.exe Noch ein Offline Calculator]
* Linksammlung [http://www.circuitsage.com/tline.html Transmission Line Design and Analysis]
* [http://www.epanorama.net/circuits/tdr.html TDR Circuit], ein einfaches Time Domain Reflektometer zum selber bauen
*[http://www.theamphour.com/the-amp-hour-77-winsome-waveform-wizardry/ The Amp Hour #77 — Winsome Waveform Wizardry], Podcast mit Dr. Howard Johnson, HF-Guru (Ab 01:15:00 kommt die Stelle zum Thema 90° Leiterbahnen)
* [http://www.ultracad.com/articles/90deg.pdf Messung] von verschiedenen Winkeln von Leiterbahnen mit 17ps TDR, keinerlei Unterschiede!
* [http://www.afug-info.de/Tipps-Tricks/Impedanz-messen/ Impedanzen einfach und praktisch messen]

[[Kategorie:Grundlagen]]
[[Kategorie:Bauteile]]
[[Kategorie:Datenübertragung]]

Entprellung

2014-10-16T08:03:36Z

Df2au: /* Funktionsweise */ Typo

== Problembeschreibung ==
Mechanische [[Schalter]] wie [[Drehgeber]] neigen beim Ein- und Ausschalten zum sogenannten '''Prellen''', d.h sie schalten schnell mehrfach aus und ein, verursacht durch mechanische Vibrationen des Schaltkontaktes, sofern sie nicht dagegen geschützt sind. Vereinfacht dargestellt, sieht eine von einem Schalter oder Taster geschaltete Spannung beim Schalten wie folgt aus:

[[Bild:Entprellen.png]]

Für die Vermeidung bzw. Auswertung dieses unsauberen Signals gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Prellfreie Schalter===

Für Spezialanwendungen hält die elektromechanische Industrie verschiedene Sonderkonstruktionen bereit, die saubere Schaltzustände nach Aussen generieren, indem sie entweder eine mechanische Dämpfung in Form eines selbsthemmenden Federmechanismus oder eine integrierte elektronische Signalverzögerung benutzen.

Solche Systeme sind jedoch teuer und werden meist nur im Leistungsbereich eingesetzt.

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[Flipflop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|thumb|left|350px|'''Taster entprellen mit NAND-RS-Flipflop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das Flipflop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet, dass der Ausgang des Flipflops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt, beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des Flipflops bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-Flipflop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1 und 10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100kOhm verwendet werden.

====Wechselschalter ohne Flip-Flop====

Wenn man mal gerade kein Flip-Flop zur Hand hat, kann man sich auch mit dieser Schaltung behelfen.

[[Bild:WechselEntprellC.PNG|thumb|left|350px|'''Wechsler entprellen mit Kondensator''']]

 

Zur Funktionsweise:
Beim Umschalten wird der Kondensator immer sofort umgeladen.
Während der Kontakt prellt, befindet er sich in der Luft und hat keinerlei Verbindung. Während dieser Zeit übernimmt der Kondensator das halten des Pegels.

Dimensionierung:
Ist der entprellte Taster an ein IC Angeschlossen, ist der ''Input Leakage Current'' der ausschlaggebende Strom. Falls weitere Ströme fließen sind diese mit zu berücksichtigen. Bei einem Mikrocontroller von Atmel sind 1µA typisch.
Es gilt:
:<math>\frac{dU}{dt} = \frac{I}{C}</math>
Da eine Prellung ca. 10ms dauert und die Spannung in dieser Zeit beispielsweise um maximal 0,5V fallen soll kommt man auf folgende Kapazität:
:<math> C = \frac{I \cdot dt}{dU} = \frac{1\mu A \cdot 10ms}{0,5V} = 20nF </math>

Um Stromspitzen zu verringern kann ein Widerstand mit eingefügt werden. Eine Zeitkonstante von 1µs bis 1ms scheint sinnvoll. Also 500 Ohm bis 500kOhm sind nutzbar, wobei bei niedrigem Widerstand die Stromspitzen höher sind, und bei 500kOhm der Pinstrom störend wird.

===Einfacher Taster===

Auch wenn das RS-Flipflop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen, kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|thumb|left|300px|Taster entprellen mit RC-Entpreller]]

[[Datei:Entprellen1a.png|thumb|350px| Entstehender Spannungsverlauf]]
{{Absatz}}

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt, kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Außerdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit der Ausgang des Inverters prellfrei.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]]-Eingängen sein muss, weil bei Standard-Logikeingängen im Bereich von üblicherweise 0,8V - 2,0V der Ausgang nicht definiert ist. Als Inverter kann zum Beispiel der 74HC14 oder der CD40106 (pinkompatibel) eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Bei dem CD4093 handelt es sich um NAND-Gatter mit Schmitt-Trigger-Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Für eine geeignete Dimensionierung muss man etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters über der Spannung bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung des Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Beim 74HC14 beträgt der gesuchte Wert 2,0V. Nimmt man für den Kondensator 1µF und beträgt die Betriebsspannung 5V, ergibt sich für den Widerstand ein Wert von etwa 22kOhm.

Wird der Schalter geöffnet, lädt sich der Kondensator nach folgender Formel auf:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt ein Wert von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 ein Wert von 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z. B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Entladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

In den Zeiten der elektronischen Auswertung von Tastern und Schaltern ist das softwaretechnische Entprellen oft billiger, als die Benutzung eines teuren Schalters. Daher werden heute z.B. auch Computertastaturen nicht mehr mit prellarmen Tasten oder Entprellkondensatoren ausgestattet.

Bei Verwendung des in den meisten Geräten ohnehin vorhandenen Mikrocontrollers z.B., kann man sich die zusätzliche Hardware sparen, da die Entprellung in Software praktisch genauso gut funktioniert. Dabei ist nur zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch einige Hardwareressourcen (z.B. Timer) benötigt werden.

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 theoretische Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms. Die Taster werden hierbei als Active-Low angeschlossen, um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<syntaxhighlight lang="c">
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</syntaxhighlight>

Eine Erweiterung, damit beliebig lange das Halten einer Taste erkannt wird kann man ganz einfach so implementieren:

<syntaxhighlight lang="c">
// zustand kann entweder zum ersten mal als gehalten detektiert werden oder aber jedes weitere mal
else if (((zustand == 1) || (zustand == 2)) && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
</syntaxhighlight>

=== Warteschleifen-Verfahren ===

Soll nun mit einem Mikrocontroller gezählt werden, wie oft ein Kontakt oder ein Relais geschaltet wird, muss das Prellen des Kontaktes exakt berücksichtigt - und von einem gewollten Mehrfachschalten abgegrenzt werden, da sonst möglicherweise Fehlimpulse gezählt- oder andererseits echte Schaltvorgänge übersprungen werden. Dies muss beim Schreiben des Programms hinsichtlich des Abtastens des Kontaktes unbedingt Rechnung getragen werden.

Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritischen Anwendungen sollte man ein anderes Verfahren nutzen (z. B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( !(*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // Maximalwert des Parameters an _delay_ms
_delay_ms(50); // beachten, vgl. Dokumentation der avr-libc
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0))
{
/* Falls Taster an PIN PB0 gedrueckt */
/* LED an Port PD7 an- bzw. ausschalten: */
PORTD = PORTD ^ ( 1 << PD7 );
}
...
}
</syntaxhighlight>

Die obige Routine hat leider mehrere Nachteile:
* sie detektiert nur das Loslassen (unergonomisch)
* sie verzögert die Mainloop immer um 100ms bei gedrückter Taste
* sie verliert Tastendrücke, je mehr die Mainloop zu tun hat.

Eine ähnlich einfach zu benutzende Routine, aber ohne all diese Nachteile findet sich im Forenthread
[http://www.mikrocontroller.net/topic/164194#new Entprellung für Anfänger]

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt standardmäßig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Eine C-Implementierung für eine Tastenabfrage mit Warteschleife ist im Artikel [[AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen|AVR-GCC-Tutorial: IO-Register als Parameter und Variablen]] angeben.

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion, um Taster zu entprellen: Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150µs = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 Mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut eingesetzt werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<syntaxhighlight lang="c">
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</syntaxhighlight>
Die Funktion wird wie folgt aufgerufen:
<syntaxhighlight lang="c">
// Bugfix 20100414
// http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
entprellung( &PINB, (1<<PINB2) ); // ggf. Prellen abwarten
if( PINB & (1<<PINB2) ) // dann stabilen Wert einlesen
{
// mach was
}
else
{
// mach was anderes
}
</syntaxhighlight>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nichtverwendete Taster die Entprellzeit negativ beeinflussen.

==== Debounce-Makro von Peter Dannegger ====

Peter Dannegger hat in [http://www.mikrocontroller.net/topic/164194#1566921 "Entprellen für Anfänger"] folgende vereinfachtes Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion mit ''active low'' geschalteten Tastern, kann aber einfach für ''active high'' geschaltete Taster angepasst werden ([[Pollin Funk-AVR-Evaluationsboard#Tasty Reloaded|Tasty Reloaded]]).

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Not so powerful Debouncing Example */
/* No Interrupt needed */
/* */
/* Author: Peter Dannegger */
/* */
/************************************************************************/
// Target: ATtiny13

#include <avr/io.h>
#define F_CPU 9.6e6
#include <util/delay.h>

#define debounce( port, pin ) \
({ \
static uint8_t flag = 0; /* new variable on every macro usage */ \
uint8_t i = 0; \
\
if( flag ){ /* check for key release: */ \
for(;;){ /* loop ... */ \
if( !(port & 1<<pin) ){ /* ... until key pressed or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms released */ \
flag = 0; /* clear press flag */ \
i = 0; /* 0 = key release debounced */ \
break; \
} \
} \
}else{ /* else check for key press: */ \
for(;;){ /* loop ... */ \
if( (port & 1<<pin) ){ /* ... until key released or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms pressed */ \
flag = 1; /* set press flag */ \
i = 1; /* 1 = key press debounced */ \
break; \
} \
} \
} \
i; /* return value of Macro */ \
})

/*
Testapplication
*/
int main(void)
{
DDRB &= ~(1<<PB0);
PORTB |= 1<<PB0;
DDRB |= 1<<PB2;
DDRB &= ~(1<<PB1);
PORTB |= 1<<PB1;
DDRB |= 1<<PB3;
for(;;){
if( debounce( PINB, PB1 ) )
PORTB ^= 1<<PB2;
if( debounce( PINB, PB0 ) )
PORTB ^= 1<<PB3;
}
}

</syntaxhighlight>

Wenn das Makro für die gleiche Taste (Pin) an mehreren Stellen aufgerufen werden soll, muss eine Funktion angelegt werden, damit beide Aufrufe an die gleiche Zustandsvariable ''flag'' auswerten [http://www.mikrocontroller.net/topic/195914#1918727]:

<syntaxhighlight lang="c">
// Hilfsfunktion
uint8_t debounce_C1( void )
{
return debounce(PINC, PC1);
}

// Beispielanwendung
int main(void)
{
DDRB |= 1<<PB2;
DDRB |= 1<<PB3;
DDRC &= ~(1<<PC1);
PORTC |= 1<<PC1; // Pullup für Taster

for(;;){
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB2;
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB3;
}
}
</syntaxhighlight>

=== Timer-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell

Außerdem können 8 Tasten (aktiv low) gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z. B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt, oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register ''key_state''. Mit nur 2 weiteren Instruktionen wird dann der Wechsel von ''Taste offen'' zu
''Taste gedrückt'' erkannt und im Register ''key_press'' abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flipflops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z. B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<syntaxhighlight lang="avrasm">
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</syntaxhighlight>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

'''Anmerkung''' Wenn statt active-low (Ruhezustand High) active-high (Ruhezustand Low) verwendet wird muss eine Zeile geändert werden siehe:
[http://www.mikrocontroller.net/forum/read-4-310276.html gesamter Beitrag im Forum],
[http://www.mikrocontroller.net/topic/48465#606555 Stelle 1 im Beitrag], ([http://www.mikrocontroller.net/topic/48465#2306398 Stelle 2 im Beitrag] muss *nicht* geändert werden, da hier die Polarität gar keinen Einfluß hat).

'''Anmerkung 2''' Zur Initialisierung siehe [http://www.mikrocontroller.net/topic/48465#3572793 Forum]

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z. B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0, ct1, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported being pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key is pressed right now
//
uint8_t get_key_state( uint8_t key_mask )

{
key_mask &= key_state;
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
LED_PORT = 0xFF;
LED_DDR = 0xFF;

// Configure debouncing routines
KEY_DDR &= ~ALL_KEYS; // configure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms
TIMSK |= 1<<TOIE0; // enable timer interrupt

sei();

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</syntaxhighlight>

Das single-press-und-repeat-Beispiel geht nicht in jeder Beschaltung; folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<syntaxhighlight lang="c">
// single press and repeat
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 ))
LED_PORT ^=0x08;
</syntaxhighlight>

===== Funktionsweise =====
Der Code basiert auf 8 parallelen vertikalen Zählern, die über die Variablen ct0 und ct1 aufgebaut werden

[[Bild:VertCount.png|framed|center|'''8 vertikale Zähler in 2 8-Bit Variablen''']]

wobei jeweils ein Bit in ct0 mit dem gleichwertigen Bit in ct1 zusammengenommen einen 2-Bit-Zähler bildet.
Der Code der sich um die 8 Zähler kümmert, ist so geschrieben, daß er alle 8 Zähler gemeinsam parallel behandelt.

<syntaxhighlight lang="c">
i = key_state ^ ~KEY_PIN; // key changed ?
</syntaxhighlight>
i enthält an dieser Stelle für jede Taste, die sich im Vergleich mit dem vorhergehenden entprellten Zustand (keystate) verändert hat, ein 1 Bit.

<syntaxhighlight lang="c">
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
</syntaxhighlight>

Diese beiden Anweisungen erniedrigen den 2-Bit Zähler ct0/ct1 für jedes Bit um 1, welches in i gesetzt ist. Liegt an der entsprechenden Stelle in i ein 0 Bit vor (keine Änderung des Zustands), so wird der Zähler ct0/ct1 für dieses Bit auf 1 gesetzt.
Der Grundzustand des Zählers ist als ct0 == 1 und ct1 == 1 (Wert 3). Der Zähler zählt daher mit jedem ISR Aufruf, bei dem die Taste im Vergleich zu keystate als verändert erkannt wurde

ct1 ct0
1 1 // 3
1 0 // 2
0 1 // 1
0 0 // 0
1 1 // 3

<syntaxhighlight lang="c">
i &= ct0 & ct1; // count until roll over ?
</syntaxhighlight>
in i bleibt nur dort ein 1-Bit erhalten, wo sowohl in ct1 als auch in ct0 ein 1 Bit vorgefunden wird, der betreffende Zähler also bis 3 zählen konnte. Durch die zusätzliche Verundung mit i wird der Fall abgefangen, dass ein konstanter Zählerwert von 3 in i ein 1 Bit hinterlässt. Im Endergebnis bedeutet dass, dass nur ein Zählerwechsel von 0 auf 3 zu einem 1 Bit an der betreffenden Stelle in i führt, aber auch nur dann, wenn in i an dieser Bitposition ebenfalls ein 1 Bit war (welches wiederrum deswegen auf 1 war, weil an diesem Eingabeport eine Veränderung zum letzten bekannten entprellten Zustand festgestellt wurde). alles zusammengenommen heißt das, dass ein Tastendruck dann erkannt wird, wenn die Taste 4 mal hintereinander in einem anderen Zustand vorgefunden wurde als dem zuletzt bekannten entprellten Tastenzustand.

An dieser Stelle ist i daher ein Vektor von 8 Bits, von denen jedes einzelne der Bits darüber Auskunft gibt, ob die entsprechende Taste mehrmals hintereinander im selben Zustand angetroffen wurde, der nicht mit dem zuletzt bekannten Tastenzustand übereinstimmt. Ist das der Fall, dann wird eine entsprechende Veränderung des Tastenzustands in key_state registriert
<syntaxhighlight lang="c">
key_state ^= i; // then toggle debounced state
</syntaxhighlight>
und wenn sich in key_state das entsprechende Bit von 0 auf 1 verändert hat, wird dieses Ereignis als 'Taste wurde niedergedrückt' gewertet.
<syntaxhighlight lang="c">
key_press |= key_state & i; // 0->1: key press detect
</syntaxhighlight>

Damit ist der Tasteneingang entprellt. Und zwar sowohl beim Drücken einer Taste als auch beim Loslassen (damit Tastenpreller beim Loslassen nicht mit dem Niederdrücken einer Taste verwechselt werden). Der weitere Code beschäftigt sich dann nur noch damit, diesen entprellten Tastenzustand weiter zu verarbeiten.

Der Codeteil sieht durch die Verwendung der vielen bitweisen Operationen relativ komplex aus. Behält man aber im Hinterkopf, dass einige der bitweisen wie ein 'paralles If' gleichzeitig auf allen 8 Bits eingesetzt werden, dann vereinfacht sich vieles. Ein
<syntaxhighlight lang="c">
key_press |= key_state & i;
</syntaxhighlight>
ist nichts anderes als ein
<syntaxhighlight lang="c">
// teste ob Bit 0 sowohl in key_state als auch in i gesetzt ist
// und setze Bit 0 in key_press, wenn das der Fall ist
if( ( key_state & ( 1 << 0 ) ) &&
( i & ( 1 << 0 ) )
key_press |= ( 1 << 0 );

// Bit 1
if( ( key_state & ( 1 << 1 ) ) &&
( i & ( 1 << 1 ) )
key_press |= ( 1 << 1 );

// Bit 2
if( ( key_state & ( 1 << 2 ) ) &&
( i & ( 1 << 2 ) )
key_press |= ( 1 << 2 );

...
</syntaxhighlight>
nur als wesentlich kompaktere Operation ausgeführt und für alle 8 Bits gleichzeitig.
Die Kürze und Effizienz dieser paar Codezeilen ergibt sich aus dem Umstand, dass jedes Bit in den Variablen für eine Taste steht und alle 8 (maximal möglichen) Tasten gleichzeitig die Operationen durchlaufen.

===== Reduziert auf lediglich 1 Taste =====
Diskussionen im Forum zeigen immer wieder, dass viele eine Abneigung gegen diesen Code haben, weil er ihnen sehr kompliziert vorkommt.

Der Code ist nicht leicht zu analysieren und er zieht alle Register dessen, was möglich ist, um sowohl Laufzeit als auch Speicherverbrauch einzusparen. Oft hört man auch das Argument: Ich benötige ja nur eine Entprellung für 1 Taste, gibt es da nichts Einfacheres?

Hier ist die 'Langform' des Codes, so wie man das für lediglich 1 Taste schreiben würde, wenn man exakt dasselbe Entprellverfahren einsetzen würde. Man sieht: Da ist keine Hexerei dabei: In key_state wird der letzte bekannte entprellte Zustand der Taste gehalten. Der Pin-Eingang wird mit diesem Zustand verglichen und wenn sich die beiden unterscheiden, dann wird ein Zähler heruntergezählt. Produziert dieses herunterzählen einen Unterlauf des Zählers, dann gilt die Taste als entprellt und wenn dann auch noch die Taste gerade gedrückt ist, dann wird dieses in key_press entsprechend vermerkt.

<syntaxhighlight lang="c">
uint8_t key_state;
uint8_t key_counter;
volatile uint8_t key_press;

ISR( ... Overflow ... )
{
uint8_t input = KEY_PIN & ( 1 << KEY0 );

if( input != key_state ) {
key_counter--;
if( key_counter == 0xFF ) {
key_counter = 3;
key_state = input;
if( input )
key_press = TRUE;
}
}
else
key_counter = 3;

}

uint8_t get_key_press()
{
uint8_t result;

cli();
result = key_press;
key_press = FALSE;
sei();

return result;
}
</syntaxhighlight>

Der vollständige Entprellcode, wie weiter oben gelistet, besticht jetzt aber darin, dass er compiliert kleiner ist als diese anschaulichere Variante für lediglich 1 Taste. Und das bei gleichzeitig erhöhter Funktionalität. Denn zb. ein Autorepeat ist in diesem Code noch gar nicht eingebaut. Und spätestens wenn man dann eine 2.te Taste entprellen möchte, dann ist auch der SRAM-Speicherverbrauch dieser Langform höher als der des Originals für 8 Tasten. Daraus folgt: Selbst für lediglich 1 Taste ist die Originalroutine die bessere Wahl.

Und wegen der Komplexität mal eine Frage: Sind Sie selbst in der Lage eine entsprechend effiziente sqrt() Funktion zu schreiben, wie die, die sie in der Standard-C-Bibliothek vorfinden? Nein? Dann dürften Sie eigentlich Ihrer Argumentation nach die Bibliotheksfunktion sqrt() nicht verwenden, sondern müssten sich statt dessen selbst eine Wurzel-Funktion schreiben.

=== Selbstsättigender Filter (nach Jürgen Schuhmacher) ===
Durch die Nutzung der diskreten Signalanalyse in Software kann die Funktionalität einer einfachen Entprellung mit einem Widerstand, einem Kondensator und einem Schmitttrigger wie in Hardware nachgebildet werden, indem ein abstrakter IIR-Filter benutzt wird, der eine Kondensatorladekurve emuliert. Mit der Vorschrift Y(t) = k Y(t-1) + Input wird ein einfaches Filter erzeugt, dass dem Eingangswert träge folgt. Bei Überschreiten eines bestimmten Wertes erfolgt mit einer einfachen Abfrage das Schalten des Ausgangssignals.

Für Assembler und VHDL bei FPGAs eignet sich aufgrund der leicht zu implementierenden binären Operationen folgende Darstellung mit einer Auflösung des Filterwertspeichers von nur 8 bit: Wert_Neu = Wert_Alt - Wert_Alt/16 + 16*(Taste = True). Der Filterwert bildet dann den gedämpften Verlauf des Eingangs (flankenverschliffen) ab und kann Prellen bis nahe an den Grenzbereich zum schnellen Tasten unterdrücken. Der Ausgangswert ist dann einfach das höchstwertige Bit des Filterwertes.

[[Datei:Entprellung mit IIR-Filter.gif]]

Dazu muss das Signal des Tasters idealerweise um den Faktor 10-20 schneller abgetastet werden, als die höchste gewünschte Tippgeschwindigkeit vorgibt. Noch schneller abzutasten ist möglich, führt aber zu mehr Bedarf an Bits beim Filter. Die Schmittriggerfunktion kann dadurch gebildet werden, dass eine 1 am Ausgang bei z.B. Überschreiten einer 55% Grenze und eine 0 bei Unterschreitung der 45%-Grenze ausgeben wird. Im Zwischenbereich wird der alte Wert gehalten.

=== Einfacher Mittelwertfilter (nach Lothar Miller) ===
Für digitale Schaltungen oder PLDs empfiehlt sich ein FIR-Filter mit aneinandergereihten FlipFlops. Man schiebt das Eingangssignal in eine FlipFlop-Kette und schaltet oberhalb der Mitte um:

SignalInput -> FF1 -> FF2 -> FF3 -> FF4 -> FF5 -> FF6 -> FF7 -> FF8

Wenn alle FFs = 1 (Summe der FFs=8) dann SignalOutput = 1 
Wenn alle FFs = 0 (Summe der FFs=0) dann SignalOutput = 0

Dieses Verfahren kann sehr einfach in Logik abgebildet werden, weil für die Berechnung des Ausgangs nur ein NOR bz. ein AND Gatter nötig ist.

== Gegenüberstellung der Verfahren ==
* HW - "entprellte Schalter": Sehr teuer, grosse Bauform, verschleissbelastet, geringe Haltbarkeit
* HW - "Umschalter" : benötigt aufwändigeren Schalter, benötigt Elektronik
* HW - "Umschalter ohne FF" : benötigt aufwändigeren Schalter und kleiner Kondensator
* HW - "Kondensatorentprellung" : benötigt etwas mehr Platz, kommt mit schlechten Schaltern zurecht

* SW - Flankenverfahren:
* SW - Warteschleife: Durch die Warteschleifen eine nicht zu vernachlässigende Verzögerung im Code. Speziell wenn mehrere Tasten zu überwachen sind, nicht unproblematisch
* SW - Timer: Universalfunktionalität, die durch geringen Speicherverbrauch, geringen Rechenzeitverbrauch und gute Funktion besticht. Der 'Verbrauch' eines Timers sieht auf den ersten Blick schlimmer aus, als er ist, denn in den meisten Programmen hat man sowieso einen Basistimer für die Zeitsteuerung des Programms im Einsatz, der für die Tastenentprellung mitbenutzt werden kann.
* SW - Filter: sehr geringer Platzbedarf in FPGAs, relativ gute Wirkung
* SW - Filter 2: sehr geringer Platzbedarf, gute Wirkung

== Links zum Thema ==

* [http://www.edn.com/design/analog/4324067/Contact-debouncing-algorithm-emulates-Schmitt-trigger Contact-debouncing algorithm (Artikel)], [http://www.edn.com/file/13370-70705di.pdf als PDF]
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* [http://www.mikrocontroller.net/forum/read-4-20435.html Beitrag im Forum, AVR Assembler]
* [http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware]
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Kategorie:AVR]]
[[Kategorie:Signalverarbeitung]]

AVR-GCC-Tutorial

2014-06-11T15:43:01Z

Df2au: /* __flash, progmem und Portierbarkeit */ Typo

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.

Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.

= Vorwort =

In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.

Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (nicht immer auf aktuellem Stand).

== Weiterführende Kapitel ==

Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].

;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''

;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''

;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''

;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''

;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''

;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''

;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''

;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:

* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.

Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-an-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugge und Simulator in gewissen Grenzen möglich.

Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:

* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig.

:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].

* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).

* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].

* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].

= Was tun, wenn's nicht klappt? =

* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.

* Die [[AVR Checkliste]] durcharbeiten.

* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).

* Google oder yahoo befragen schadet nie.

* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.

* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z. B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses).

* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.

Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.

= Einführungsbeispiel =

Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.

Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden.

Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<syntaxhighlight lang="c">
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xFF; // (3)
PORTB = 0x03; // (4)

while(1) { // (5)
/* "leere" Schleife*/ // (6)
} // (7)

/* wird nie erreicht */
return 0; // (8)
}
</syntaxhighlight>

# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein <code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein <code>\</code>.
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight>
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.

Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].

<pre>
D:\beispiel>dir

Verzeichnis von D:\beispiel

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist.
<pre>
D:\beispiel>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.

Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.

= Ganzzahlige Datentypen (Integer) =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight>

{| {{Tabelle}}
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''  
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenbehaftete int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −27 ⋯ 27−1 || <code>signed char</code>
|-
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −215 ⋯ 215−1 || <code>signed short</code>, <code>signed int</code>
|-
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −231 ⋯ 231−1 || <code>signed long</code>
|-
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −263 ⋯ 263−1 || <code>signed long long</code>
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenlose int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 28−1 || <code>unsigned char</code>
|-
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 216−1 || <code>unsigned short</code>, <code>unsigned int</code>
|-
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 232−1 || <code>unsigned long</code>
|-
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 264−1 || <code>unsigned long long</code>
|}

Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

[[Image:Sequentielle Programme.gif|left]]
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".
{{Absatz}}

== Interruptgesteuerter Programmablauf ==

[[Image:Interrupt Programme.gif|left]]
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.
{{Absatz}}

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.

Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.

Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:

<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Ist im Makefile der MCU-Typ z. B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.


Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z. B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<syntaxhighlight lang="c">
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</syntaxhighlight>

Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z. B. die des UART, ADC, SPI) analog.

== Schreiben in Register ==

Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref>

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

while (1);
}
</syntaxhighlight>

Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].

Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z. B. DDRB = 0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.

== Verändern von Registerinhalten ==

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<syntaxhighlight lang="c">
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</syntaxhighlight>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</syntaxhighlight>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */
</syntaxhighlight>

Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen
</syntaxhighlight>

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.

Beispiel:

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

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</syntaxhighlight>

Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:

<syntaxhighlight lang="c">
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5)
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von Bit 0
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit not-Operator
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</syntaxhighlight>

== Warten auf einen bestimmten Zustand ==

Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers).

Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}
...
</syntaxhighlight>

Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) {}
...
</syntaxhighlight>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==

Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.
<syntaxhighlight lang="c">
#include <avr/io.h>
...
uint16_t foo;

/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
foo = ADC;
</syntaxhighlight>

Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:

<syntaxhighlight lang="c">
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

...
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;

UBRRH = (uint8_t) (baud >> 8);
UBRRL = (uint8_t) baud;
...
</syntaxhighlight>

Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge:
* Lesezugriff: Erst Low-Byte, dann High-Byte
* Schreibzugriff: Erst High-Byte, dann Low-Byte

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!

In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <util/delay.h>

uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if (last_state == (*inputreg & (1<<inputbit)))
return 0; /* keine Änderung */

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = *inputreg & (1<<inputbit);

/* und den entprellten Tastendruck zurückgeben: */
return *inputreg & (1<<inputbit);
}

/* Beispiel für einen Funktionsaufruf: */

void foo (void)
{
uint8_t i = key_pressed (&PINB, PB1);
}
</syntaxhighlight>

Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.

Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]

= Zugriff auf IO-Ports =

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen
* bei Ausgängen deren Zustand festzulegen
* bei Eingängen deren Zustand zu erfassen

Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).

Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.

Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.

Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:

{| class="wikitable"
|-
! DDRx
| Datenrichtungsregister für Port'''x'''.
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.
|-
! PINx
| Eingangsadresse für Port'''x'''.
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.
|-
! PORTx
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

In C liest sich das dann so:

<syntaxhighlight lang="c">
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

int main()
{
// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
// direkte Zuweisung - standardkonform */
DDRB = 0x1F; /*

// übersichtliche Alternative - Binärschreibweise, aber kein ISO-C
DDRB = 0b00011111;

// Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
// aber übersichtlicher und selbsterklärend:
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
</syntaxhighlight>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<syntaxhighlight lang="c">
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~(1 << DDB0);
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~((1 << DDB3) | (1 << DDB4));
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= (1 << DDB0) | (1 << DDB3);
// Alle Pins auf Eingang:
DDRB = 0x00;
</syntaxhighlight>

== Vordefinierte Bitnummern für I/O-Register ==

Die Bitnummern (z. B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):

<syntaxhighlight lang="c">
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</syntaxhighlight>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */

// übersichtliche Alternative - Binärschreibweise
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */

</syntaxhighlight>
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).

Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</syntaxhighlight>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</syntaxhighlight>
Siehe auch [[Bitmanipulation]]

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.

''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.

Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z. B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.

Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.

{| class="wikitable" style="text-align:center"
|+ '''Spannungstabelle''' (ca. Grenzwerte)
|
! Low || High
|-
! bei 5 V
| 1 V || 3,5 V
|-
! bei 3,3 V
| 0,66 V || 2,31 V
|-
! bei 1,8 V
| 0,36 V || 1,26 V
|}

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</syntaxhighlight>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</syntaxhighlight>
Siehe auch [[Bitmanipulation#Bits_prüfen]]

=== Interne Pull-Up Widerstände ===

Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z. B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.

Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.

Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.

Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</syntaxhighlight>

=== Taster und Schalter ===

Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.

<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC">
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.
</gallery>

Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z. B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.

==== Taster entprellen ====

Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.

Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z. B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z. B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.

Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.

Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen bis 1.6 ==

Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z. B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms)
{
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) // Endlosschleife
{
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z. B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</syntaxhighlight>

== avr-libc Versionen ab 1.7 ==

_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.

Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</syntaxhighlight>

Trick zur Übergabe einer Variablen an _delay_ms():
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

void sleep ( uint8_t ms )
{
for(; ms > 0; ms--) _delay_ms(1);
}

int main( void )
{
int x = 0; // Variable als Wartezeit erstellen
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
sleep(x);
x++;
}
return 0;
}
</syntaxhighlight>

Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]

= Programmieren mit Interrupts =

<div style="float:right; margin:2em;">
[[Image:Interrupt Programme.gif]]
</div>
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).

Um Interrupts verarbeiten zu können, ist folgendes zu beachten:

* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).

Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.

Siehe auch

* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]
* Artikel [[Interrupt]]
* Artikel [[Multitasking]]
{{Clear}}

== Anforderungen an Interrupt-Routinen ==

Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.

Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammenhängen.

{| class="wikitable"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''
|-
! R/W
| R || R || R/W || R/W || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt über den Schlafmodus.
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC11 || ISC10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}

'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC01 || ISC00 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}

|}

== Allgemeines über die Interrupt-Abarbeitung ==

Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Obwohl es möglich ist, zu diesem Zeitpunkt bereits wieder das GIE-bit zu setzen, wird dringend davon abgeraten. Dieses wird nämlich automatisch gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen.



== Interrupts mit avr-gcc ==



Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<syntaxhighlight lang="c">
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</syntaxhighlight>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<syntaxhighlight lang="c">
sei();
</syntaxhighlight>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<syntaxhighlight lang="c">
cli();
</syntaxhighlight>

Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</syntaxhighlight>


Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.

=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</syntaxhighlight>

Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.

Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.

<syntaxhighlight lang="c">
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</syntaxhighlight>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</syntaxhighlight>

Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.

Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */
{
/* Interrupt-Code */
}
</syntaxhighlight>

Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z. B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden – auch XXX-Interrupts.

Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.

Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR (XXX)
{
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen

<<Deaktiviere die XXX-IRQ>>

// Erlaube alle Interrupts (ausser XXX)
sei();

//... Code ...

// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos
// aktivieren zu koennen
cli();

<<Aktiviere die XXX-IRQ>>
}
</syntaxhighlight>
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.

Siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z. B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</syntaxhighlight>

Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:

<syntaxhighlight lang="c">
//...
ISR(TIMER1_COMPA_vect)
{
uint8_t tmp_kc;

tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (tmp_kc < CNTREPEAT) {
tmp_kc++;
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc; // Zurueckschreiben
}
//...
</syntaxhighlight>

Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
876: ca 99 sbic 0x19, 2 ; 25
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24>
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
87a: 80 91 2a 03 lds r24, 0x032A
87e: 88 3c cpi r24, 0xC8 ; 200
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28>
882: 80 91 2a 03 lds r24, 0x032A
886: 8f 5f subi r24, 0xFF ; 255
888: 80 93 2a 03 sts 0x032A, r24
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28>
}
else {
gKeyCounter = 0;
88e: 10 92 2a 03 sts 0x032A, r1
892: 8f 91 pop r24
894: 0f 90 pop r0
896: 0f be out 0x3f, r0 ; 63
898: 0f 90 pop r0
89a: 1f 90 pop r1
89c: 18 95 reti
</pre>

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
uint8_t tmp_kc;

tmp_kc = gKeyCounter;
876: 80 91 2a 03 lds r24, 0x032A

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
87a: ca 9b sbis 0x19, 2 ; 25
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18>
87e: 80 e0 ldi r24, 0x00 ; 0
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e>
if (tmp_kc < CNTREPEAT) {
882: 88 3c cpi r24, 0xC8 ; 200
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e>
tmp_kc++;
886: 8f 5f subi r24, 0xFF ; 255
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc;
888: 80 93 2a 03 sts 0x032A, r24
88c: 8f 91 pop r24
88e: 0f 90 pop r0
890: 0f be out 0x3f, r0 ; 63
892: 0f 90 pop r0
894: 1f 90 pop r1
896: 18 95 reti
</pre>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.

<syntaxhighlight lang="c">
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</syntaxhighlight>

Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.

=== Variablen größer 1 Byte ===

Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:

<syntaxhighlight lang="c">
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interrupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</syntaxhighlight>

Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.
<syntaxhighlight lang="c">
//...
#include <util/atomic.h>
//...

// analog zu cli, Zugriff, sei:
ATOMIC_BLOCK(ATOMIC_FORCEON) {
tmpCnt = gMyCounter16Bit;
}

// oder:

// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
tmpCnt = gMyCounter16Bit;
}

//...
</syntaxhighlight>

* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]

== Interrupt-Routinen und Registerzugriffe ==

Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</syntaxhighlight>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z. B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben.

Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)

== Interruptflags löschen ==

Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben.

Hinweis: Dazu '''nicht''' übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen ([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).

== Was macht das Hauptprogramm? ==

Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.

Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z. B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).

Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</syntaxhighlight>

In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():

<syntaxhighlight lang="c">
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</syntaxhighlight>

== Sleep Modi ==
Zu beachten ist, dass unterschiedliche Prozessoren aus der AVR Familie unterschiedliche Sleep-Modi unterstützen oder nicht unterstützen. Auskunft über die tatsächlichen Gegebenheiten gibt, wie immer, das zum Prozessor gehörende Datenblatt. Die unterschiedlichen Modi unterscheiden sich dadurch, welche Bereiche des Prozessors abgeschaltet werden. Damit korrespondiert unmittelbar welche Möglichkeiten es gibt, den Prozessor aus den jeweiligen Sleep Modus wieder aufzuwecken.

;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.

;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann. Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.

;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator) gestoppt. Geweckt werden kann die CPU durch einen externen Level Interrupt, TWI, Watchdog, Brown-Out-Reset

;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.

;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators (also einer externen Taktquelle). Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus ist eine kürzere Aufwachzeit.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Zeiger =
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.

Siehe auch: [[Zeiger]]

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z. B. Kalibrierungswerte von Sensoren abgelegt.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.

Siehe auch:
* [[Binäre Daten zum Programm hinzufügen]]
== RAM ==

Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).

malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.

Beispiel zur Verwendung von malloc():
<syntaxhighlight lang="c">
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</syntaxhighlight>

Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Programmspeicher (Flash) ==

Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''load from program memory'') erzeugt erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELMP. Zum Erzeugen dieser Instruktionen gibt es die im folgenden dargestellten zwei Wege.

=== progmem und pgm_read_xxx ===

→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]

<tt>progmem</tt> ist ein AVR-spezifisches GCC-Attribut, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:
<syntaxhighlight lang="c">
const int value __attribute__((progmem)) = 1;
</syntaxhighlight>

Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus dem RAM gelesen und nicht aus dem Flash!

Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

const int value PROGMEM = 1;
</syntaxhighlight>

<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.

==== Integer und float ====

Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref>

:{| {{Tabelle}}
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus dem Header <tt>avr/pgmspace.h</tt> der avr-libc
|-
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes
|-
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1
|-
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2
|-
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4
|-
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4
|}

Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.

;Beispiele:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Byte */
const uint8_t aByte PROGMEM = 123;

/* int-Array */
const int anArray[] PROGMEM = { 18, 3 ,70 };

void foo (void)
{
/* Zeiger */
static const uint8_t* const aPointer PROGMEM = &aByte;

uint8_t a = pgm_read_byte (&aByte);
int a2 = (int) pgm_read_word (&anArray[2]);
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);
}
</syntaxhighlight>

==== Blöcke ====

In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.

==== Strings ====

Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

size_t my_string_length (const char* addr)
{
size_t length = 0;

while (pgm_read_byte (addr++))
{
len++;
}
return length;
}
</syntaxhighlight>

Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Liefert true zurück, wenn string_im_ram gleich "Hallo Welt" ist. */
int foo (const char* string_im_ram)
{
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));
}
</syntaxhighlight>

Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.

; Array aus Strings:

Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:

# Zuerst die einzelnen Elemente des Arrays und
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.

Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char str1[] PROGMEM = "Hund";
static const char str2[] PROGMEM = "Katze";
static const char str3[] PROGMEM = "Maus";

const char * const array[] PROGMEM =
{
str1, str2, str3
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Lese die Adresse des i-ten Strings aus array[]
const char *parray = (const char*) pgm_read_word (&array[i]);

// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM
strcpy_P (buf, parray);
}
</syntaxhighlight>

Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.

Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref>

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")
const char array[][6] PROGMEM =
{
"Hund", "Katze", "Maus"
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM
strcpy_P (buf, array[i]);
}
</syntaxhighlight>

Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]

==== Warum so kompliziert? ====

Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.

Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.

Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.

Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities

==== Variablenzugriff >64kB ====

Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil FUnktionsadressen immer gerade sind. Für den Datenzugriff jenseits von 64kiB stellt die AVR-Libc die Funktionen <tt>pgm_read_xxx_far</tt> zur Verfügung. Diese Funktionen erwarten einen 32-Bit Pointer auf die Daten. Unverständlicherweise gibt es aber in der AVR-Libc keine Funktion, um diesen 32-Bit Pointer zu erhalten. Hier schafft ein eigenes Makro Abhilfe:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/pgmspace.h>

//====================================================================
// Macro to access strings defined in PROGMEM above 64kB
//--------------------------------------------------------------------
#define FAR(var) \
({ uint_farptr_t tmp; \
__asm__ ( \
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" \
: "=d" (tmp) \
: "i" (&(var))); \
tmp; \
})
//-------------------------------------------------------------------

//===================================================================
// Define a section above 64kiB (FAR_SECTION)
// and add the required linker argument below
// -Wl,--section-start=.far_section=0x10000
//--------------------------------------------------------------------
#define FAR_SECTION __attribute__((__section__(".far_section")))
//--------------------------------------------------------------------

//====================================================================
// Just a Sample
//--------------------------------------------------------------------

char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";
char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};

int main(void)
{
char MyChar;
DDRC = 0xFF;
do
{
MyChar = pgm_read_byte_far(FAR(MyBmp64));
PORTC = MyChar;
}
while(MyChar);
}
</syntaxhighlight>

D.h. man muss
* Das Makro FAR im Quellcode einfügen
* Die Definition der neuen Sektion FAR_SECTION einfügen
* Die Variablen mit dieser Sektion kennzeichnen
* Dem Linker mittels Kommandozeilenoption diese Sektion mitteilen

Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich.

<syntaxhighlight lang="c">
int n=3;
MyChar = pgm_read_byte_far(FAR(MyBmp64)+n);
</syntaxhighlight>

=== __flash und Embedded-C ===

Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.

GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> compiliert werden.

<syntaxhighlight lang="c">
static const __flash int value = 10;

int get_value (void)
{
return value;
}
</syntaxhighlight>

# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.

Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse

<syntaxhighlight lang="c">
// val ist eine Variable im Flash
const __flash int val = 42;

// pval liegt auch im Flash und enthält die Adresse von val
const __flash int* const __flash pval = &val;

char get_val (void)
{
// liest den Wert von val über die in pval abgelegte Adresse
return *pval;
}
</syntaxhighlight>

==== Blöcke ====

Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// buf wird auf dem Stack angelegt
data_t buf;

// Kopiere Daten vom Flash nach buf ins RAM
memcpy_P (&buf, pdata, sizeof (data_t));

// Sende die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:

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

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt
const data_t buf = *pdata;

// Verwendet die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

==== Strings ====

Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char * const __flash array[] =
{
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")
};

size_t get_len (uint8_t tier)
{
return strlen_P (array[tier]);
}
</syntaxhighlight>

Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.

Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:

<syntaxhighlight lang="c">
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"
const __flash char array[][6] =
{
"Hund", "Katze", "Maus"
};
</syntaxhighlight>

Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:

<syntaxhighlight lang="c">
static const __flash char strHund[] = "Hund";
static const __flash char strKatze[] = "Katze";
static const __flash char strMaus[] = "Maus";

const __flash char * const __flash array[] =
{
strHund, strKatze, strMaus
};
</syntaxhighlight>

==== Casts ====

Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>:

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

char read_char (const char *address, bool data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
</syntaxhighlight>

Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.

==== Jenseits von __flash ====

Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:

* <tt>__flash</tt>''N'', ''N'' = 1..5, sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist. Dies wird in Binutils noch nicht unterstützt<ref>[http://sourceware.org/PR14406 Binutils PR14406]: Support .progmem<N>.data sections to work with GCC's [http://gcc.gnu.org/PR49868 PR49868].</ref> (Stand Binutils 2.23) Die Unterstützung kann durch ein eigenes Linker-Skript erhalten werden, dass diese Sections wie vom Compiler erwartet lokatiert.
* Address-Space <tt>__memx</tt> implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:

:{|
|-
|<syntaxhighlight lang="c">
const __memx int a_flash = 42;
const int a_ram = 100;

static int get_a (const __memx int* pa)
{
return *pa;
}

int main (void)
{
return get_a (&a_flash) + get_a (&a_ram);
}</syntaxhighlight>
|}Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob aus dem RAM oder aus dem Flash gelesen werden soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik.

=== __flash, progmem und Portierbarkeit ===

Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.

Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.

Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.
<syntaxhighlight lang="c">
static const __flash char x[] = { 'A', 'V', 'R' };

char foo (void)
{
return x[2];
}
</syntaxhighlight>
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.

==== progmem → __flash ====

Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.

Eine Portierung wird man in zwei Schritten vornehmen:

;1. Definitionen von Flash-Variablen werden angepasst:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char hund[] PROGMEM = "Hund";
static const char katze[] PROGMEM = "Katze";
static const char maus[] PROGMEM = "Maus";

const char * const tier[] PROGMEM =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
static const __flash char hund[] = "Hund";
static const __flash char katze[] = "Katze";
static const __flash char maus[] = "Maus";

const __flash char * const __flash tier[] =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.

Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt

; 2. Der Code wird von <tt>pgm_reg</tt>-Aufrufen bereinigt:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

extern const char *tier[];

char first_letter (uint8_t i)
{
const char* ptier = (const char*) pgm_read_word (&tier[i]);
return (char) pgm_read_byte (&ptier[0]);
}
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
#include <stdint.h>

extern const __flash char * const __flash tier[];

char first_letter (uint8_t i)
{
return tier[i][0];
}
</syntaxhighlight>
|}

==== __flash → progmem ====

=== Flash in der Anwendung schreiben ===

Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.

Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]

== EEPROM ==

Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch vorhanden sind und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.

Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16bit), Fließkommawerte (32-Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.

Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMS normalerweise notwendig sind:
* EEPROM Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sicher gestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.
* Es ist darauf zu achten, dass die EEPROM Funktionen nicht durch einen Interrupt unterbrochen werden können. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten Anzahl Takte durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.

Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle.

Bei geschickter Programmierung (z. B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers wahrscheinlich nicht erreicht. In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.

Eine weitere Möglichkeit Schreibzyklen einzusparen besteht darin, dass geprüft wird, ob im EEPROM bereits der zu speichernde Wert enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).

Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl.

=== EEMEM ===
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:

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

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Array */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
</syntaxhighlight>

Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.

Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM Adressen hantieren zu müssen - etwas das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.

=== Bytes lesen/schreiben ===

Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:

<syntaxhighlight lang="c">
#define EEPROM_DEF 0xFF

void eeprom_example (void)
{
uint8_t myByte;

// myByte lesen (Wert = 123)
myByte = eeprom_read_byte (&eeFooByte);

// der Wert 99 wird im EEPROM an die Adresse der
// Variablen eeFooByte geschrieben
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben

myByte = eeprom_read_byte (&eeFooByteArray1[1]);
// myByte hat nun den Wert 3

// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-
// zugriff, da die Werte gleich sind.
eeprom_update_byte(&eeFooByte, myByte);

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

uint8_t fooByteDefault = 222;
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)
{
myByte = fooByteDefault;
}
}
</syntaxhighlight>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<syntaxhighlight lang="c">
// lesen
uint16_t myWord = eeprom_read_word (&eeFooWord);

// schreiben
eeprom_write_word (&eeFooWord, 2222);
</syntaxhighlight>

=== Block lesen/schreiben ===

Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Addresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.
<syntaxhighlight lang="c">
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

void eeprom_block_example (void)
{
/* Datenblock aus EEPROM lesen */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));

/* und nun mit 16-Bit Array */
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));

/* Datenblock in EEPROM schreiben */
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));
}
</syntaxhighlight>

=== Fließkommawerte lesen/schreiben ===

In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

float eeFloat EEMEM = 12.34f;

float void eeprom_float_example(float value)
{
/* float in EEPROM schreiben */
eeprom_write_float(&eeFloat, value);

/* float aus EEPROM lesen */
return eeprom_read_float(&eeFloat);
}</syntaxhighlight>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden.

Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].

Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.

Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen.

=== Direkter Zugriff auf EEPROM-Adressen ===

Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende Funktionen hilfreich, um sich die Typecasts zu ersparen:

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

// Byte aus dem EEPROM lesen
uint8_t EEPReadByte(uint16_t addr)
{
return eeprom_read_byte((uint8_t *)addr);
}

// Byte in das EEPROM schreiben
void EEPWriteByte(uint16_t addr, uint8_t val)
{
eeprom_write_byte((uint8_t *)addr, val);
}
</syntaxhighlight>

oder als Makro:

<syntaxhighlight lang="c">
#define EEPReadByte(addr) eeprom_read_byte((uint8_t *)addr)
#define EEPWriteByte(addr, val) eeprom_write_byte((uint8_t *)addr, val)
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="c">
EEPWriteByte(0x20, 128); // Byte an die Adresse 0x20 schreiben
...
Val=EEPReadByte(0x20); // EEPROM-Wert von Adresse 0x20 lesen
</syntaxhighlight>

=== EEPROM Register ===
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.
;EECR: Ist das Kontrollregister für das EEPROM

Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:

:{| class="wikitable" style="text-align:center"
|+ '''Aufbau des EECR-Registers'''
|-
!Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE
|-
! Read/Write
| R || R || R || R || R/W || R/W || R/W || R/W
|-
!Init Value
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''Bedeutung der Bits'''

;Bit 4-7: nicht belegt

;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.

;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.

;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:
:# EEPROM-Bereitschaft abwarten (EEWE=0)
:# Adresse übergeben an EEAR
:# Daten übergeben an EEDR
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist

;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:
:# Bereitschaft zum Lesen prüfen (EEWE=0)
:# Adresse übergeben an EEAR
:# Lesezyklus auslösen mit EERE = 1
:# Warten, bis Lesevorgang abgeschlossen EERE = 0
:# Daten abholen aus EEDR

= Die Nutzung von sprintf und printf =

Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.

Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.

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

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

// Ausgabe eines unsigned Integerwertes
void uart_puti( uint16_t value )
{
uint8_t puffer[20];

sprintf( puffer, "Zählerstand: %u", value );
uart_puts( puffer );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</syntaxhighlight>

Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z. B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);

// a. Deklaration der primitiven Ausgabefunktion
int uart_putchar(char c, FILE *stream);

// b. Umleiten der Standardausgabe stdout (Teil 1)
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

// c. Definition der Ausgabefunktion
int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int main(void)
{
int16_t antwort = 42;
uart_init();

// b. Umleiten der Standardausgabe stdout (Teil 2)
stdout = &mystdout;

// Anwendung
printf( "Die Antwort ist %d.\n", antwort );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</syntaxhighlight>

Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.

= Anmerkungen =
<references/>

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* "naked"-Funktionen

[[Kategorie:avr-gcc Tutorial| ]]

AVR-Tutorial: Servo

2014-05-18T07:34:53Z

Df2au: Typo

Die Seite ist noch im Entstehen und, bis sie einigermaßen vollständig ist, noch kein Teil des Tutorials

= Vorbemerkung =
Dieses Tutorial überschneidet sich inhaltlich mit dem Artikel [[Modellbauservo_Ansteuerung]]. Wir beschreiben hier die grundsätzliche Vorgehensweise zur Ansteuerung von Servos und geben ein Beispiel in Assembler, während der genannte Artikel ein in C formuliertes Beispiel zur Ansteuerung mehrerer Servos liefert.

= Allgemeines über Servos =

= Stromversorgung =
Werden Servos an einem µC betrieben, so ist es am Besten, sie aus einer eigenen Stromquelle (Akku) zu betreiben. Manche Servos erzeugen kleine Störungen auf der Versorgungsspannung, die einen µC durchaus zum Abstürzen bringen können. Muss man Servos gemeinsam mit einem µC von derselben Stromquelle betreiben, so sollte man sich gleich darauf einrichten, diesen Störimpulsen mit Kondensatoren zu Leibe rücken zu müssen. Unter Umständen ist hier auch eine Mischung aus kleinen, schnellen Kondensatoren (100nF) und etwas größeren, aber dafür auch langsameren Kondensatoren (einige µF) notwendig.

Die eindeutig beste Option ist es aber, die Servos strommäßig vom µC zu entkoppeln und ihnen ihre eigene Stromquelle zu geben. Servos sind nicht besonders heikel. Auch im Modellbau müssen sie mit unterschiedlichen Spannungen zurechtkommen, bedingt durch die dort übliche Versorgung aus Akkus, die im Laufe der Betriebszeit des Modells natürlich durch die Entladung ihre Voltzahl immer weiter reduzieren. Im Modellbau werden Akkus mit 4 oder 5 Zellen verwendet, sodass Servos mit Spannungen von ca. 4V bis hinauf zu ca. 6V zurecht kommen müssen, wobei randvolle Akkus diese 6V schon auch mal überschreiten können. Bei sinkenden Spannungslage verlieren Servos naturgemäß etwas an Kraft bzw. werden in ihrer Stellgeschwindigkeit unter Umständen langsamer.

Die Servos werden dann nur mit ihrer Masseleitung und natürlich mit ihrer Impulsleitung mit dem µC verbunden.

= Das Servo-Impulstelegram =
Das Signal, das an den Servo geschickt wird, hat eine Länge von ungefähr 20ms. Diese 20ms sind nicht besonders kritisch und sind ein Überbleibsel von der Technik mit der mehrere Kanäle über die Funkstrecke einer Fernsteuerung übertragen werden. Für das Servo wichtig ist die Impulsdauer in der ersten Phase eines Servosignals. Nominell ist dieser Impuls zwischen 1ms und 2ms lang. Wobei das jeweils die Endstellungen des Servos sind, an denen es noch nicht mechanisch begrenzt wird. Eine Pulslänge von 1.5ms wäre dann Servomittelstellung. Für die Positionsauswertung des Servos haben die 20ms Wiederholdauer keine besondere Bedeutung, sieht man einmal davon ab, dass ein Servo bei kürzeren Zeiten entsprechend öfter Positionsimpulse bekommt und daher auch öfter die Position gegebenenfalls korrigiert, was möglicherweise in einem etwas höheren Stromverbrauch resultiert.

Umgekehrt lässt sich definitiv Strom sparen, indem die Pulse ganz ausgesetzt werden: Der Servo bleibt in der Position, in der er sich gerade befindet - korrigiert sich aber auch nicht mehr. Kommen die Impulse selten, also z.B. alle 50ms, läuft der Servo langsamer in seine Zielposition (praktische Erfahrungen, vermutlich nirgends spezifiziert). Dieses Verhalten lässt sich nutzen, um die manchmal unerwünschten ruckartigen Bewegungen eines Servos abzumildern.

[[Bild:Servo.gif|framed|center| Servo Impulsdiagramm]]

Den meisten Servos macht es nichts aus, wenn die Länge des Servoprotokolls anstelle von 20ms auf zb 10ms verkürzt wird. Bei der Generierung des Servosignals muss man daher den 20ms keine besondere Beachtung schenken. Eine kleine Pause nach dem eigentlichen Positionssignal reicht in den meisten Fällen aus und es spielt keine allzugroße Rolle, wie lange diese Pause tatsächlich ist. Generiert man das Imulsdiagramm zb. mit einem Timer, so orientiert man sich daher daran, dass man den 1.0 - 2.0ms Puls gut generieren kann und nicht an den 20ms.

Reale Servos haben allerdings in den Endstellungen noch Reserven, so dass man bei vielen Servos auch Pulslängen von 0.9 bis 2.1 oder sogar noch kleinere/größere Werte benutzen kann. Allerdings sollte man hier etwas Vorsicht walten lassen. Wenn das Servo unbelastet in einer der Endstellungen deutlich zu 'knurren' anfängt, dann hat man es übertrieben. Das Servo ist an seinen mechanischen Endanschlag gefahren worden und auf Dauer wird das der Motor bzw. das Getriebe nicht aushalten.

= Programmierung =
== einfache Servoansteuerung mittels Warteschleifen ==

Im folgenden Programm wurden einfache Warteschleifen auf die im Tutorial übliche Taktfrequen von 4Mhz angepasst, so dass sich die typischen Servo-Pulsdauern ergeben. Ein am Port D, beliebiger Pin angeschlossenes Servo dreht damit ständig vor und zurück. Die Servoposition kann durch laden eines Wertes im Bereich 1 bis ca 160 in das Register r18 und anschliessendem Aufruf von servoPuls in einen Puls für ein Servo umgewandelt werden.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.equ XTAL = 4000000

rjmp init

init:
ldi r16, HIGH(RAMEND) ; Stackpointer initialisieren
out SPH, r16
ldi r16, LOW(RAMEND)
out SPL, r16

ldi r16, 0xFF
out DDRD, r16

loop: ldi r18, 0

loop1: inc r18
cpi r18, 160
breq loop2

rcall servoPuls

rjmp loop1

loop2: dec r18
cpi r18, 0
breq loop1

rcall servoPuls

rjmp loop2

servoPuls:
push r18
ldi r16, 0xFF ; Ausgabepin auf 1
out PORTD, r16

rcall wait_puls ; die Wartezeit abwarten

ldi r16, 0x00 ; Ausgabepin wieder auf 0
out PORTD, r16

rcall wait_pause ; und die Pause hinten nach abwarten
pop r18
ret
;
wait_pause:
ldi r19, 15
w_paus_1: rcall wait_1ms
dec r19
brne w_paus_1
ret
;
wait_1ms: ldi r18, 10 ; 1 Millisekunde warten
w_loop2: ldi r17, 132 ; Es muessen bei 4 Mhz 4000 Zyklen verbraten werden
w_loop1: dec r17 ; die innerste Schleife umfasst 3 Takte und wird 132
brne w_loop1 ; mal abgearbeitet: 132 * 3 = 396 Takte
dec r18 ; dazu noch 4 Takte für die äussere Schleife = 400
brne w_loop2 ; 10 Wiederholungen: 4000 Takte
ret ; der ret ist nicht eingerechnet
;
; r18 muss mit der Anzahl der Widerholungen belegt werden
; vernünftige Werte laufen von 1 bis ca 160
wait_puls:
w_loop4: ldi r17, 10 ; die variable Zeit abwarten
w_loop3: dec r17
brne w_loop3
dec r18
brne w_loop4

rcall wait_1ms ; und noch 1 Millisekunde drauflegen
ret
</syntaxhighlight>

Wie meistens gilt auch hier: Warteschleifen sind in der Programmierung nicht erwünscht. Der Prozessor kann in diesen Warteschleifen nichts anderes machen. Etwas ausgeklügeltere Programme, bei denen mehrere Dinge gleichzeitig gemacht werden sollen, sind damit nicht vernünftig realisierbar.
Daher sollte die Methode mittels Warteschleifen nur dann benutzt werden, wenn dies nicht benötigt wird, wie zb einem simplen Servotester, bei dem man die Servoposition zb durch Auslesen eines Potis mit dem ADC festlegt.

Ausserdem ist die Berechnung der Warteschleifen auf eine bestimmte Taktfrequenz unangenehm und fehleranfällig :-)

== einfache Servoansteuerung mittels Timer ==

=== Ansteuerung mit dem 16-Bit Timer 1 ===
Im Prinzip programmiert man sich hier eine Software-PWM. Beginnt der Timer bei 0 zu zählen (nach Overflow Interrupt oder Compare Match Interrupt im CTC-Modus (Clear Timer on Compare)), so setzt man den gewünschten Ausgangspin auf 1. Ein Compare Match Register wird so mit einem berechneten Wert versorgt, daß es nach der gewünschten Pulszeit einen Interrupt auslöst. In der zugehörigen Interrupt Routine wird der Pin dann wieder auf 0 gesetzt.

Auch hier wieder: Der Vorteiler des Timers wird so eingestellt, dass man die Pulszeit gut mit dem Compare Match erreichen kann, die nachfolgende Pause, bis der Timer dann seinen Overflow hat (oder den CTC Clear macht) ist von untergeordneter Bedeutung. Man nimmt was vom Zählbereich des Timers übrig bleibt. Beispiel:
* F_CPU = 16 MHz
* Vorteiler = 8
* 16 Bit Registerbreite = Overflow nach 2^16 Zyklen
* CTC-Modus *aus*, steigende Flanke durch Overflow-Interrupt erzeugen
* Overflow-Interrupt: 16 MHz / 2^16 / 8 = 30,52 Hz, 32,8 ms, Ausgangspin auf 1 setzen
* Servostellung links .. rechts = Pulsbreite 1 .. 2 ms = 1 s / 16000000 * 8 * OCR1; OCR1 = 2000 .. 4000
* Output-Compare-Match-Interrupt: Ausgangspin auf 0 setzen

Alternativ zum Overflow-Interrupt könnte, um eine Gesamtpulsbreite von exakt 20 ms zu erreichen, z.B. im Output-Compare-Match-Interrupt (sofern nur einer pro Timer verfügbar ist) im Wechsel
* der Ausgangspin auf 1 und OCR1 auf 1000 .. 2000 gesetzt sowie das CTC-Bit gelöscht werden
* der Ausgangspin auf 0 und OCR1 auf 40000 gesetzt sowie das CTC-Bit gesetzt werden
Neuere ATmegas verfügen über zwei Output-Compare-Register (Suffix ''A'' und ''B'') ebenso wie zwei OCR-Interrupt-Vektoren pro Timer, wobei das CTC-Bit nur bei einem Match mit dem Output-Compare-Register ''A'' wirkt. Damit können für die Pulserzeugung zwei getrennte Interrupt-Handler angelegt werden, und ein Umbelegen von OCR und CTC-Bit entfällt.

=== Ansteuerung mit dem 8-Bit Timer 2 ===

Mit einem 8 Bit Timer ist es gar nicht so einfach, sowohl die Zeiten für den Servopuls als auch die für die Pause danach unter einen Hut zu bringen. Abhilfe schafft ein Trick.

Der Timer wird so eingestellt, dass sich der Servopuls gut erzeugen lässt. Dazu wird der Timer in den CTC Modus gestellt und das zugehörige Vergleichsregister so eingestellt, dass sich die entsprechenden Interrupts zeitlich so ergeben, wie es für einen Puls benötigt wird. In einem Aufruf des Interrupts wird der Ausgangspin für das Servo auf 1 gestellt, im nächsten wird er wieder auf 0 gestellt. Die kleine Pause bis zum nächsten Servoimpuls wird so erzeugt, dass eine gewisse Anzahl an Interrupt Aufrufen einfach nichts gemacht wird. Ähnlich wie bei einer PWM wird also auch hier wieder ein Zähler installiert, der die Anzahl der Interrupt Aufrufe mitzählt und immer wieder auf 0 zurückgestellt wird.

Die eigentliche Servoposition steht im Register OCR2. Rein rechnerisch beträgt ihr Wertebereich:

1ms 4000000 / 64 / 1000 OCR2 = 62.5

2ms 4000000 / 64 / 500 OCR2 = 125

mit einer Mittelstellung von ( 62.5 + 125 ) / 2 = 93.75

<syntaxhighlight lang="avrasm">
.include "m16def.inc"

.equ XTAL = 4000000

rjmp init

.org OC2addr
rjmp Compare_vect

init:
ldi r16, HIGH(RAMEND) ; Stackpointer initialisieren
out SPH, r16
ldi r16, LOW(RAMEND)
out SPL, r16

ldi r16, 0x80
out DDRB, r16 ; Servo Ausgangspin -> Output

ldi r17, 0 ; Software-Zähler

ldi r16, 120
out OCR2, r16 ; OCR2 ist der Servowert

ldi r16, 1<<OCIE2
out TIMSK, r16

ldi r16, (1<<WGM21) | (1<<CS22) ; CTC, Prescaler: 64
out TCCR2, r16

sei

main:
rjmp main

Compare_vect:
in r18, SREG
inc r17
cpi r17, 1
breq PulsOn
cpi r17, 2
breq PulsOff
cpi r17, 10
brne return
ldi r17, 0
return: out SREG, r18
reti

PulsOn: sbi PORTB, 0
rjmp return

PulsOff: cbi PORTB, 0
rjmp return
</syntaxhighlight>

== Ansteuerung mehrerer Servos mittels Timer ==

----

{{Navigation_zurückhochvor|
zurücktext=7-Segment-Anzeige|
zurücklink=AVR-Tutorial: 7-Segment-Anzeige|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=Watchdog|
vorlink=AVR-Tutorial: Watchdog}}

[[Category:AVR-Tutorial|Servo]]
[[Category:Servos]]

Sonnenfolger / Heliostat

2014-04-02T16:38:27Z

Df2au: /* Heliostat Software */

== Einleitung ==
===Allgemeines===
Ursache für den Tageslauf der Sonne ist die Rotation der Erde um sich selbst. Die Höhen-Änderung der Sonnenbahn resultiert aus dem jährlichen Umlauf der Erde (Erdbahn) um die Sonne in Kombination mit der im Weltall annähernd fixen Richtung der gegen die Erdbahn geneigten Erdachse (Schiefe der Ekliptik). (Quelle Wikipedia)

Würde man die Sonne an jedem Tag des Jahres immer genau um 12:00 Uhr Mittags (DCF77 Uhr) fotografieren und die Fotos alle übereinander legen, erhielte man die Analemma-Figur mit zusätzlichen Sprüngen von einer Stunde Ende März und Ende Oktober. Dass heißt, eine Sonnenuhr geht bis zu 15 Minuten zuzüglich Sommerzeitverschiebung falsch, da die Sonne mal rechts und mal links von der Position steht, die man vereinfacht erwarten würde.

[[Bild:Analemma_pattern_in_the_sky.jpg|400px]]

(Foto Quelle Wikipedia)

Wie alle sicherlich beobachtet haben, ändert sich je nach Jahreszeit und nach dem Breitengrad der Aufstellung der Solaranlage die Sonnenhöhe (Höhenwinkel, Azimuth)

Weiterhin leben wir in einer recht großen Zeitzone vom östlichsten Zipfel von Norwegen bis nach Spanien. Daher kann die Sonne um 12:00 Uhr nicht überall genau im Süden stehen. Je nach Längengrad der Aufstellung der Solaranlage ändert sich die Himmelsrichtung für die Stellung der Sonne in der Mittagszeit. Hinzu kommt die Sommer- Winterzeitumstellung.

===Lösungsansätze===
Durch eine Nachführung wird entweder eine Solarzelle genau zur Sonne ausgerichtet oder ein Spiegel lenkt das Sonnenlicht auf einen Zielpunkt. Der Spiegel muss dann auf der Winkelhalbierenden zwischen Sonnenstand und dem Ziel stehen.

Es kann generell zwischen analogen Lösungen mit Messung der Helligkeit ohne Inteligenz, Messung der Helligkeit mit Mikrocontrollerauswertung und Uhrzeitnachführungen mit Berechung der Sonnenposition unterscheiden. Die Berechnung der Sonnenposition ist durch die oben beschriebene Problematik recht aufwendig, hat aber den Vorteil, dass keine Optik sauber gehalten werden muss.

==einachsige Nachführung==
Zur Nachführung einer Solarzelle oder thermischen Solarpanels kann auf die Nachführung in der vertikalen Achse verzichtet werden. Man spart Mechanik, verliert aber Leistungsausbeute.

===Analog===

[[Bild:Lichtfolger_analog.png|400px]]

hier eine der vielen analogen Lichtfolgerschaltungen. An den Ausgängen wird eine H-Brücke als Motortreiber und ein Getriebemotor angeschlossen.

In der Schaltung befinden sich zwei Spannungsteiler. Zu einen die
Reihenschaltung aus den beiden LDR´s. Werden beide gleichmäßig
beleuchtet, teilt sich die Spannung gleichmäßig auf.
Die Spannung Vcc teilt sich an der Reihenschaltung der Widerstände in
drei Teile auf:
Spannung U1 über Poti R1 und R3, Spannung U2 über Poti R2 und die
Spannung U3 über R4.

Die Spannung U2 ist die Hysterese bei der sich beide Ausgänge auf 0 V
Potential befinden.
Die Spannungen U1 und Vcc-U3 sind die Schaltpunkte.

Google nach: Fensterkomparator

===Mikrocontroller===

[[Bild:Lichtfolger_Tiny.png|400px]]

Ähnliche Signalbildung, aber Auswertung durch einen Tiny. Hier kann die Hysterese und Schaltverzögerungen per Software eingestellt werden.

==zweiachsige Nachführung==
Nach einer Weile an Überlegung habe ich mich für die Lösung mit DCF 77 Uhr, Berechnung des Sonnenstandes und Schrittmotoren entschieden.

===Hardware===

[[Bild:Base_Board_L317_alles.png|400px]]

Beim Anschluss der ISP Schnittstelle bin ich etwas vom "Kanda-Standard" abgewichen und nur Pin10 des Wannensteckers für Masse benutzt. Dadurch waren die Pins 8,6,4 noch für das LCD frei. Zum Programmieren benutze ich einen Adapter, der diese Pins isoliert, um einen Kurzschluss zu vermeiden. Der Vorteil, ich habe nur einen Stecker für das LCD und zur Programmierung.

Download Hardware: [[Media:Heliostep Hardware.zip‎|download zip-File]]

===Software===
Der Programmteil DCF77 Empfang ist von Ulrich Rading, die Sonnenstandsberechnung von Clueso hier aus dem Forum, die LCD Anzeige ist ebenfalls aus dem Forum.
Da möchte ich mich nicht mit falschen Federn schmücken. Aber es blieben noch genügend Herausfordeungen zum Testen und Probieren.

* http://www.mikrocontroller.net/forum/codesammlung?filter=sonne*
* http://www.mikrocontroller.net/topic/111783
* http://www.mikrocontroller.net/topic/121049

====Motortest Software====
Download Software zum Motortest: [[Media:Heliostep 05 Motor Test.zip‎|download zip-File]]

Fährt die Schrittmotre zuerst in die Homeposition. Fährt dann die Steppermotore bei Tastendruck jeweils 2000 Schritte vorwärts, bzw wieder zurück in die Homeposition.

====Heliostat Software====
Download Software zur Steuerung: [[Media:Heliostep_15.zip‎|download zip-File]]

Wartet auf DCF Empfang, fährt den Heliostat in die Homeposition Down und Ost, berechnet die Sonnenposition alle Minute und fährt den Spiegel entsprechend der Berechnung.

Während der Wartezeit auf den ersten gültigen DCF77 Empfang wird das Trägersignal als blinkende 1 oder 0 im Sekundentakt auf den LCD angezeigt. Dies eignet sich gut zur Ausrichtung der DCF Antenne.

Nach dem ersten gültigen Empfang wird nochmals 20 Sekunden auf das Signal Sommer- oder Winterzeit gewartet.
Mit diesem Signal und der aktuellen Uhrzeit wird die UTC Zeit berechnet (MEZ - 1h, oder MESZ - 2h). Die aktuelle Zeit in UTC wird auf dem LCD in der ersten Zeile angezeigt.

Mit der UTC Zeit und dem Standort des Heliostaten wird die Position der Sonne in Radiant berechnet. Die Elevation und der Azimut multipliziert mit jeweils einem Faktor ergeben die Anzahl der Schritte die der jeweilige Schrittmotor fahren muss. Die beiden Faktoren werden in der zweiten Zeile auf den LCD angezeigt.

===Video Mechanik===
Hier noch ein kleiner Videofilm von der Mechanik:

http://www.youtube.com/watch?v=s7gXmlWX7Ro

== Links ==

* http://de.wikipedia.org/wiki/Sonnenstand
* http://de.wikipedia.org/wiki/Heliostat
* Programm "Orbitron" http://www.stoff.pl/
* [http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2009/nw59_yt322/nw59_yt322/index.html Heliostat Skylight] (ECE 476 Final Project by Yinan Tang and Nana Wu)
* http://de.wikipedia.org/wiki/Windlast

[[Category:AVR-Projekte]]
[[Kategorie:DCF77]]

4000 Stellen von Pi mit ATtiny2313

2014-03-12T18:02:00Z

Df2au: Typos

[[Bild:attiny2313.jpg|thumb|right|ATtiny2313 im [[IC-Gehäuseformen|DIL]]-Gehäuse]]
Als neulich im Foren nach einem
: ''"rechenintensiven Beispielprogramm für den kleinen ATtiny2313 in C oder ASM"''<ref>[http://www.mikrocontroller.net/topic/248373 Forum: AVR Atiny2313: ''"Suche rechenintensivs Beispielprogramm für ATtiny2313"'']</ref>
gesucht wurde und als Vorschlag ein
: ''"Pi auf 1000 Stellen"''<ref>[http://www.mikrocontroller.net/topic/248373#2544249 Forum: AVR Atiny2313: ''"Pi auf 1000 Stellen"'']</ref>
kam, wolle ich es genauer wissen. Auch wenn der Vorschlag eher als Scherz aufzufassen ist — sind C-Compiler inzwischen so gut, daß damit π auf tausende Stellen berechnet werden kann? Bei einem Assembler-Programm hätte ich da keine Bedenken; aber C?

Der [[AVR]] ATtiny2313 ist bekanntlich ein 8-Bit [[Mikrocontroller]] mit 2048 Bytes an Programmspeicher und 128 Bytes RAM. Die Aufgabe erfordert also eine spezielle Herangehensweise, denn nicht alle zu berechnenden Stellen sind gleichzeitig im RAM des µC speicherbar: bereits berechnete Stellen sollen ausgegeben werden und an der Ausgabe-Schnittstelle sollen Ziffernweise die Nachkommastellen von π heraus purzeln.

== Die Formel ==

Das theoretisch-algorithmische Rüstzeug dafür ist lange bekannt und das Web ist voll davon: Eine 1995 von Simon Plouffe gefundene Reihendarstellung<ref>Für einen Beweis siehe [http://www.pi314.net/eng/plouffe.php The World of π: Proof: Formula BBP].</ref> für π:
:<math>
\pi=\sum_{k=0}^\infty \frac1{16^k}
\left(\frac4{8k+1}-\frac2{8k+4}-\frac{1}{8k+5}-\frac1{8k+6}\right)
</math>
Die Anwendung der Darstellung besteht dabei nicht in stupidem Auswerten bis zur gewünschten Genauigkeit, sondern es wird die n-te Nachkommastelle von π damit bestimmt ''ohne'' vorherige oder nachfolgende Ziffern der Darstellung zu bestimmen.
Der einzige Wehrmutstropfen ist, daß die Darstellung zur Basis 16 erhalten wird und nicht wie gewohnt zur Basis 10 — aber immerhin liefert die Formel ''überhaupt'' erst einen Weg, um die Berechnung auf einer kleinen Hardware mit 2k Programmspeicher ausführen zu können.
Auch dieser Weg ist hinreichend oft im Internet erklärt — je nach Seite mehr oder weniger gut. Eine gute Erklärung findet sich etwa in der Wikipedia<ref>[http://fr.wikipedia.org/wiki/Formule_BBP#Exploitation_de_la_formule_pour_calculer_les_chiffres_apr.C3.A8s_la_virgule_de_.CF.80 Wikipédia: Formule BBP]: Exploitation de la formule pour calculer les chiffres après la virgule de π</ref>

Die ganze Aufgabe besteht also nur noch darin, den Algorithmus hinzuschreiben und zu compilieren — und zu hoffen, daß das erzeugte Programm in den kleinen Programmspeicher eines ATtiny hineinpasst.

Gerade der letzte Punkt ist nicht selbstverständlich, denn die Anwendung der obigen Formel verlangt den Einsatz von Fließkomma-Arithmetik. Zwar ist auch eine
Implementierung mittels Festkomma-Zahlen möglich, aber ich wollte mit den Bordmitteln der C-Sprache auskommen: Ohne Inline-Assembler Hacks, ohne umständliches Hin-und-Herwandeln und Skalieren, ohne Implementierung eigener Divisionroutinen, etc. Das Programm kann somit als Stresstest für die Tools verstanden werden.

Als Sprache wählte ich C99 und als Compiler avr-gcc<ref>[http://gcc.gnu.org/ GCC]: The GNU Compiler Collection</ref> 4.7 oder neuer, so daß ein Executable erzeugen wird, das in die 2k Programmspeicher eines ATtiny2313 hineinpasst.

== Der Quelltext: C99 ==

Zur Implementierung ist hier nicht viel zu sagen; die Quellen sind ausführlich kommentiert. Nur noch einige Anmerkungen:
* Die Quellen sind so allgemein gehalten, daß das Programm auch für einen PC übersetzt und dort gestartet werden kann.
* Wird für AVR übersetzt, erfolgt die Ausgabe der berechneten Ziffern auf der UART-Schnittstelle. Für Compiler- und Linker-Optionen siehe die Quellkommentare.
* Bei einer Taktfrequenz von 20 MHz dauert die Berechnung der ersten 1000 hex-Ziffern etwa 3–4 Minuten. Verdoppelt man die Anzahl der Ziffern, ist die 4-fache Rechenzeit zu erwarten.
* Der Algorithmus liefert brauchbare Resultate für die ersten 4096 Nachkommastellen von π. Danach reichten die verwendeten 16-Bit int für ganze Zahlen nicht mehr aus, und für 32-Bit Zahlen ist der Speicher zu klein.
* Der Algorithmus berechnet wie gesagt Nachkommastellen der Hexadezimaldarstellung von π. 4000 hex-Nachkommastellen entsprechen übrigens ca. 4800 Dezimalstellen: log 16 / log 10 ≈ 6/5.
* Die Ausgabe lässt sich etwa vergleichen mit "First 8366 Hex Digits of PI"<ref>[http://www.herongyang.com/Cryptography/Blowfish-First-8366-Hex-Digits-of-PI.html www.herongyang.com]: First 8366 Hex Digits of π</ref>

<pre>
/* pi.c: Compute the first 4000 hexadecimal digits of pi
on an AVR ATtiny2313 microcontroller. */
/*
Language: C99
Compiler: An AVR toolchain based on avr-gcc 4.7 and AVR-Libc if you like
to compile for AVR ATtiny2313, or a C99-compliant compiler if
you like to run this program on a PC.

Hardware: AVR ATtiny2313 which is an 8-bit microcontroller with
128 Bytes of RAM and 2048 Bytes of program memory.
http://www.atmel.com/Images/doc2543.pdf (Manual, PDF, 4 MB)
http://www.atmel.com/Images/doc2543S.pdf (Summary, PDF, 500 kB)

Compile: You need a reasonably optimizing compiler and floating point
implementation, or otherwise the program won't fit into the
tiny silicon. Notice that the code below is *vanilla* C with
IEEE-754 floating point arithmetic and without assembler or
fixed point hacks.

The program in generic enough to run on a PC. If you use GCC,
just compile with the following command line and run pi.exe

gcc pi.c -o pi.exe -std=c99 -O2 -lm

The only compiler that produces code small enough for the
AVR ATtiny2313 hardware is avr-gcc 4.7 together with AVR-Libc.

avr-gcc pi.c -o pi.elf $(CFLAGS) $(OPT) $(DEFS) $(LDFLAGS)

with the following abbreviations for convenience:

CFLAGS = -std=c99 -mmcu=attiny2313
OPT = -Os -mcall-prologues -fno-split-wide-types
-fno-caller-saves -fno-tree-loop-optimize
LDFLAGS = -Wl,--relax -Wl,--gc-sections -lm
DEFS = -DF_CPU=22118400 -DBAUDRATE=115200 -DHOST_WINDOWS

For documentation of GCC see http://gcc.gnu.org/onlinedocs

DEFS represents the UART setup. In my circuit I use a
22.1184 MHz quartz which is a bit of overclocking but is so
comfortable with baud rates. Depending on your configuration,
you will use other values for F_CPU and BAUDRATE, see below.

The first 1000 digits of pi take about 3 Minutes at 22 MHz.
For 4000 digits, multiply this time by 16.

The time to get the first n digits of pi with this method is roughly

T(n) = K * n^2

so that, given the time for the computation of n digits, you can easily
compute K and estimate how long the computation will take for other
values of n. K will depend on the clock speed you use, for example.

Some software metrics for the AVR binary compiled as above:

Program Size: Less than 2000 of 2048 bytes

RAM Usage:
Static storage : 0 bytes
Static stack usage : ~ 50 bytes
Dynamic : 0 bytes
Total : 40% of 128 bytes

Coding Style: Stroustrup
Indentation: 4 Space
*/

#include <stdlib.h>
#include <stdint.h>
#include <math.h>

// Factor out some platform/compiler dependencies

#if defined (__AVR__) && defined (__GNUC__)

// Running on AVR
# include <avr/io.h>
# include <avr/wdt.h>
# define cput(C) uart_putc(C)
static void uart_init (void);
static void uart_putc (const char);

#else // ! avr-gcc

// Running on PC
# include <stdio.h>
# define wdt_reset() (void) 0
# define uart_init() (void) 0
static void cput (char c)
{
fputc (c, stdout);
fflush (stdout);
}

#endif // avr-gcc

// return a * b mod n
//
// 0 <= a < n
// 0 <= b < n
//
// This is a school-book implementation of multiplication.
//
// First, ATtiny2313 has no hardware multiplyer or divider, anyway.
// We have to cope with 2048 bytes of program memory and
// thus avoid dragging in library routines if possible.
//
// Second, this implementation widens the range of valid moduli from
// \sqrt{1+UINT_MAX} to (1+UINT_MAX)/2. Or vice versa, it allows us
// to use a smaller type for the modulus -- 16 bits in the AVR case.

static unsigned mod_mul (unsigned a, unsigned b, unsigned n)
{
unsigned ab = 0;

while (1)
{
if (a % 2 == 1)
{
ab += b;
if (ab >= n)
ab -= n;
}

a = a / 2;
if (a == 0)
return ab;

b = b * 2;
if (b >= n)
b -= n;
}
}

// Return 16^k mod n
//
// Exponentiation with the same approach as above except
// that we binary-expand the exponent instead of a factor.

static unsigned mod_pow16 (unsigned k, unsigned n)
{
unsigned p = 1;
unsigned _16 = 16;

if (n == 1)
return 0;

while (_16 >= n)
_16 -= n;

while (1)
{
if (k % 2 == 1)
p = mod_mul (_16, p, n);

k = k / 2;
if (k == 0)
break;

_16 = mod_mul (_16, _16, n);
}

return p;
}

// Helper for the function below.

static float tame (float s)
{
int8_t si = (int8_t) lrintf (s);

if (si <= -2 || si >= 2)
s -= si;

return s;
}

// The finite part mod 1 of sigma_j, i.e. partial sum where the exponent
// of 16 is >= 0. By "mod 1" we always mean "up to some integer",
// i.e. the result needs not to be normalized to [0,1).

static float sigma_a (unsigned n, uint8_t j)
{
float s = 0.0f;

for (unsigned k = n-1; k+1 != 0; k--)
{
unsigned j_8k = j + 8*k;

s += mod_pow16 (n-k, j_8k) / (float) j_8k;

// Cut down the sum and don't let it grow too big.
// The bigger the number grows the less precision is
// left for the fractional part we are interested in.

s = tame (s);

wdt_reset();
}

return s;
}

#define MARGIN 10

static float sigma_b (unsigned n, uint8_t j)
{
float s = 0;
float _16 = 1.0f;

for (unsigned k = n; k <= n + MARGIN; k++)
{
s += _16 / (8*k + j);
_16 /= 16;

wdt_reset();
}

return s;
}

// Compute an approximation of 16^n * sigma(j) mod 1
// where
//
// sigma_j = \sum_0^oo 1 / (16^k * (8k + j))
//
// The sum is split into two parts:
// sigma_a is the finite sum up to n.
// sigma_b is the finite sum from n+1 to oo
// and approximated by a sum from n+1 to n+MARGIN

float sigma (unsigned n, uint8_t j)
{
return sigma_a (n, j) + sigma_b (n, j);
}

// Compute pi * 16^n up to some integer
// using a Bailey-Borwein-Plouffe formula for pi:
//
// pi = 4*sigma_1 - 2*sigma_4 - sigma_5 - sigma_6
//
// with the definition of sigma_j from above. All this
// is explained very nicely in the French wikipedia at
// http://fr.wikipedia.org/wiki/Formule_BBP
//
// For a proof define the power series
//
// sigma_j (x) = \sum x^{8k} / (8k + j)
//
// write the sum as integral and evaluate it at
// x = sqrt(1/2), see http://www.pi314.net/eng/plouffe.php

float pi_n (unsigned n)
{
float s = 0.0;

for (uint8_t i = 0; i < 4; i++)
{
// j[i] = 1, 4, 5, 6
uint8_t j = i ? i + 3 : 1;

// c[i] = 4, -2, -1, -1
int8_t c = -1;
if (i == 0) c = 4;
if (i == 1) c = -2;

s += c * sigma (n, j);
}

return s;
}

// We computed pi_n = 16^n * pi mod 1
// Get the first fractional hexadecimal digit by multiplying
// with 16 and extracting digit 0 of the result. Voila!

static uint8_t pi_dig16 (unsigned n)
{
return 15 & lrintf (floorf (16 * pi_n (n)));
}

// Map 0 <= n < 16 to its hexadecimal ASCII digit
// '0', '1', ... 'F'

static uint8_t hexdigit (uint8_t n)
{
n += '0';
return n > '9' ? n + 'A'-'0'-10 : n;
}

int main (void)
{
uart_init();

cput ('\n');
cput ('3');
cput ('.');

// As explained above, 16-bit integers limitate us to moduli <= 2^15.
// The biggest modulus for n is 8n+6 so that for n >= 4096 we expect
// garbage from the implementation if 16-bit integers are used like
// with avr-gcc. In fact, we get garbage for n > 4100.
// It's not exacly 4095 because of the denominators in sigma_a that
// delay the garbage for some values of n.

// Easy going 4000 hex-digits of pi.

for (unsigned n = 0; n < 4000; n++)
{
// Print a line break after every 64 digits. That way the output
// can easily be compared with, e.g. the hexadecimal representation
// of pi from blowfish listed in "First 8366 Hex Digits of PI" from
// http://www.herongyang.com/Cryptography/

if (n % 64 == 0)
cput ('\n');

// Get the n+1-th hexadecimal digit of pi and
// output it as ASCII character.

cput (hexdigit (pi_dig16 (n)));
}

cput ('\n');

return 0;
}

/************************************************************************/
// We are running on ATtiny2313 bare metal, of course.
// Provide some minimalist output routines that write to UART.
/************************************************************************/

#ifdef __AVR__

// !!! You must have set the fuses appropriately to run the !!!
// !!! controller at desired F_CPU. Defining F_CPU is needed !!!
// !!! to get correct values to set up UART. !!!
// !!! !!!
// !!! DEFINING F_CPU WILL NOT CHANGE THE FREQUENCY! !!!

void uart_init (void)
{
// Define F_CPU and BAUDRATE depending on your hardware setup.
// For my setup, it's the followin defines in avr-gcc's command line:
// -DF_CPU=22118400 -DBAUDRATE=115200

unsigned ubrr = -.6 + F_CPU / (8L * BAUDRATE);

UBRRH = ubrr >> 8;
UBRRL = ubrr;

// Enable UART Transmitter, data mode 8N1, asynchronous

UCSRA = (1 << U2X) | (1 << TXC);
UCSRB = (1 << TXEN);
UCSRC = (1 << UCSZ1) | (1 << UCSZ0);
}

/////////////////////////////////////////////////////////////////

// Write one char to UART (non-buffered, blocking version)

void uart_putc (char c)
{
while (!(UCSRA & (1 << UDRE)))
wdt_reset();
UDR = c;

#ifdef HOST_WINDOWS
if (c == '\n')
uart_putc ('\r');
#endif // HOST_WINDOWS
}

void exit (int x)
{
(void) x;

while (1)
wdt_reset();
}
#endif // __AVR__
</pre>

== Weblinks ==
<references/>

[[Kategorie:AVR-Projekte]]
[[Kategorie:AVR-Arithmetik]]
[[Kategorie:PC-Programmierung]]

Hack-O-Copter

2013-11-24T10:25:16Z

Df2au: /* Funkfernbedienung */

Der Begriff '''Hack-O-Copter''' beschreibt einen Nachbau des Quadrocopters „Hubsan X4“, der er sich einfach „hacken“ lässt; die Original-Firmware kann also überschrieben und durch eigene ersetzt werden. Er wird für ca. 21€ verkauft, siehe Beitrag [http://www.mikrocontroller.net/topic/309185?page=single „Hackbarer(?) 21 EUR Quadcopter“.]

Die Original-Firmware kann nicht ausgelesen werden, es muss also eine komplett neue Firmware erstellt werden.

'''Hinweis:''' Der Artikel enthält Infos bis zu [http://www.mikrocontroller.net/topic/309185?page=1#3356755 diesem Beitrag]. Weitere Inhalte aus dem Thread werden asap ergänzt.

= Beschreibung des Quadrocopters =
* Abmessungen ''→ Infos ergänzen''
* Gewicht ''→ Infos ergänzen''
* Lieferumfang ''→ Infos ergänzen''
* Reichweite ''→ Infos ergänzen''
* Flugdauer und Ladezeit ''→ Infos ergänzen''
* Funktionen ''→ Infos (3 Empfindlichkeiten, umdrehen, Rekalibrierung, ...) ergänzen''
* Link zur Bedienungsanleitung
== Bedienung ==
Auf ebenen Untergrund legen, nach ein paar Sekunden blinken die LEDs er langsamer, dann den linken Steuerhebel einmal hoch und wieder runter fahren.
== Komponenten ==
Der Quadrocopter wird von vier kernlosen Gleichstrommotoren („Coreless DC“) angetrieben. Im Inneren des Gehäuses ist eine Platine. Ihre vergleichsweise modernen Hardware-Komponenten (Mikrocontroller, Sensoren, MOSFETs und Funkmodul) sind in den folgenden Kapiteln beschrieben.
=== Mikrocontroller ===
Der „Nuvoton Mini54ZAN“ ist ein Cortex-M0 MCU mit 16KiB Flash, 2KB SRAM und SWD.
''→ Links zu Datenblättern ergänzen''
=== Sensoren zur Flugstabilisierung ===
Für die Flugstabilisierung ist der Quadrocopter mit drei Gyroskopen und drei Beschleunigungssensoren ausgestattet. Diese sind alle zusammen im Intertialsensor „Invensense MPU-6050“ integriert.
''→ Link zum Datenblatt''
=== ESC ===
Die Ansteuerung der Gleichstrommotoren erfolgt über PWM und MOSFETs. Die verwendeten N-Kanal MOSFETs „G2310“ haben einen „Drain-Source On-Resistance“ von etwa 120mΩ.

Siehe http://www.mikrocontroller.net/attachment/193854/G2310.pdf
=== Funk- Transceiver ===
Für die 2,4GHz Funkstrecke zur Fernsteuerung ist mit einem „Beken BK3423“ integriert. Die Vermutung, dass dieser voll kompatibel zum NRF24L01 ist, liegt nahe, da der NRF24L01 die Daten der Fernbedienung empfangen kann.

[[Bild:HOC_Fernbedienung_Platine_Ausschnitt2.jpeg|200px]]
== Zubehör ==
=== Lade-Adapter ===

Schaltplan des beiliegenden Ladeadapters:

http://www.mikrocontroller.net/attachment/197005/ladeanzeige.png

Auf der Platine vorgesehen sind weiter eine in Reihe zu R2 geschaltete Diode und ein Parallel zum Akku liegender Widerstand R5, welche allerdings nicht bestückt sind.

Bei vollem Akku erlischt die LED

=== Funkfernbedienung ===
Die Außenantenne ist nur „Verarsche“ ...

''→ Infos ergänzen''

''→ Hinweis auf Idee: Neuen Sender entwickeln''

[[Bild:HOC_Fernbedienung_Platine_B-Seite.jpeg|200px]]
[[Bild:HOC_Fernbedienung_Platine_Ausschnitt.jpeg|200px]]
[[Bild:HOC_Fernbedienung_Platine_total.jpeg|200px]]
[[Datei:HOC_Fernbedienung_Platine_Ausschnitt2.jpeg|200px]]

==== Schaltbild der Fernbedienung ====
Das Schaltbild enthält alle funktionsrelevanten Bauteile. Es fehlen noch diverse Bauteilwerte. Auch der eine oder andere Stützkondensator fehlt eventuell.

[[Medium:copter05.pdf]]

==== Pinbelegung des Mikrocontrollers ====

Pinbelegung für CPU N79E814

Pin Name Funktion
1 P0.0 LCD, CS
2 P1.7 LCD, CLK
3 P1.6 LCD, DATA
4 RST Reset (10k - C)
5 VSS an Masse
6 P3.1 RF-Modul, MOSI
7 P3.0 RF-Modul, SCK
8 P1.4 RF-Modul, MISO
9 SDA RF-Modul, CSN
10 SCL 2K2 Pullup, unbestückter Schaltungsteil
11 P1.1 LED via 1kOhm
12 P1.0 Buzzer (via Transistor)
13 AD6 über Widerstände an Batteriespannung vor Regler
14 AD5 Auswertung Taster (Seite Yaw-Throttle)
15 VDD Versorgung
16 AD4 Poti "Throttle"
17 AD3 Poti "Yaw"
18 AD2 Poti "Roll", Dämpfung mit RC Glied
19 AD1 Poti "Pitch", Dämpfung mit RC Glied
20 AD0 Auswertung Taster (Seite Pitch-Roll)

==== Pinbelegung des Sendemoduls ====
[[Bild:HOC_Fernbedienung_Sendemodul.jpeg|200px]]

1 3.3V
2 MOSI an PIN6 MCU
3 SCK an PIN7 MCU
4 MISO an PIN8 MCU
5 CE
6 GND
7 IRQ
8 CSN an PIN9 MCU
9 RXEN

==== Protokoll ====

Es handelt sich um das V202 Protokoll.

* Die Payload hat eine Länge von 16-Byte
* Das letzte Byte entspricht der Summe aller vorherigen Bytes (bzw. den unteren 8 Bit der Summe)
* Das Datenformat passt zu dem im GitRepo beschriebenen (https://github.com/hackocopter/Documentation/tree/master/RemoteControl)
* Das Datenformat passt zu der Implementierung des V202 Protokolls in der Deviation firmware (https://bitbucket.org/PhracturedBlue/deviation/src...)

Zum Channel Hopping:
* jedes Packet wird zweimal versendet
* es immer 16-Channel durchgehoppt (dann gehts wieder von vorne los)
* auch das passt zur Implementierung in der Deviation firmware

Siehe auch: http://www.mikrocontroller.net/topic/309185?goto=3410375#3410373

=== Propeller ===
''→ Infos ergänzen''
== Schnittstellen ==
=== SWD-Port ===
Der SWD-Port ist über … herausgeführt. ''→ Infos ergänzen''
=== Serielle Schnittstelle ===
Die Anschlüsse führen zu den RX und TX Pins des MCUs.
''→ Infos ergänzen''
=== PIN 9 ===
''→ Infos ergänzen''
=== I²C-Schnittstelle ===
''→ Infos ergänzen''
= Tipps und Tricks =
== Bezugsquellen und Kauf ==
=== Direktkauf aus China ===
''→ Infos zu Aliexpress, ebay, Einfuhrumsatzsteuer und Käuferschutz ergänzen''
=== Lieferanten aus Europa ===
''→ Infos ergänzen''
== Ersatzakkus ==
Der Original-Akku hat …mAh und wiegt …g. ''→ Infos ergänzen''
(380mAh, ca. 2,31€, …g) ''→ Infos ergänzen''
== Reduzierung der Unfallfolgen ==
''→ Infos ergänzen''
= Ideen für neue Funktionen =
== Bessere Flugstabilisierung mit bestehender Sensorik ==
== Neue Funktionen mit GPS-Sensor ==
[[Bild:HOC_GPS_Groessenvergleich.jpg|200px]]

''→ Ideen ergänzen''
== Neue Funktionen mit Luftdruck-Sensor ==
''→ Ideen ergänzen''
== Neue Funktionen mit Kamera ==
Alternativen: Keycam, Y3000, … ''→ Infos ergänzen''
== Neue Funktionen mit Ultraschallsensor ==
''→ Ideen ergänzen''
== Neue Funktionen mit Infrarot-Entfernungssensor ==
[[Bild:HOC_IR-Entfernungsmesser-Testplatine.jpg|200px]]

''→ Ideen ergänzen''
== Neue Funktionen mit Bluetooth ==
''→ Ideen ergänzen''
== Erweiterung der Original-Fernbedienung ==
=== Funkmodul mit PA + LNA ===
''→ Details ergänzen''
=== Erweiterung um ein Display ===
[[Bild:HOC_Fernbedienung_mit_C0802-04.jpeg|200px]]

''→ Details ergänzen''
== Neue Funktionen mit alternativer Fernbedienung ==
''→ Ideen ergänzen''
= Programmierung neuer Firmware =
== Beschreibung der Toolkette ==
''→ Details ergänzen''
=== Notwendige Hardware und Software ===
''→ Details ergänzen''
=== Installation der Toolkette ===
''→ Details ergänzen''
=== ISP und ICD ===
== Beschreibung der Firmware-Varianten ==
=== „Blinky“ ===
''→ Details ergänzen''
= Weiterführende Links und Quellen =
* http://www.jann.cc/2013/10/13/tiny_hackable_quadcopter.html ''→ Details ergänzen''
* Multiwii ''→ Details ergänzen''
* Paparazzi (http://paparazzi.enac.fr/wiki/Main_Page) ''→ Details ergänzen''

Datei:Copter05.pdf

2013-11-24T10:20:20Z

Df2au: Schaltbild der Fernbedienung des JD-385 Quadcopters

Schaltbild der Fernbedienung des JD-385 Quadcopters

Hack-O-Copter

2013-11-24T10:10:36Z

Df2au: /* Pinbelegung des Mikrocontrollers */

Der Begriff '''Hack-O-Copter''' beschreibt einen Nachbau des Quadrocopters „Hubsan X4“, der er sich einfach „hacken“ lässt; die Original-Firmware kann also überschrieben und durch eigene ersetzt werden. Er wird für ca. 21€ verkauft, siehe Beitrag [http://www.mikrocontroller.net/topic/309185?page=single „Hackbarer(?) 21 EUR Quadcopter“.]

Die Original-Firmware kann nicht ausgelesen werden, es muss also eine komplett neue Firmware erstellt werden.

'''Hinweis:''' Der Artikel enthält Infos bis zu [http://www.mikrocontroller.net/topic/309185?page=1#3356755 diesem Beitrag]. Weitere Inhalte aus dem Thread werden asap ergänzt.

= Beschreibung des Quadrocopters =
* Abmessungen ''→ Infos ergänzen''
* Gewicht ''→ Infos ergänzen''
* Lieferumfang ''→ Infos ergänzen''
* Reichweite ''→ Infos ergänzen''
* Flugdauer und Ladezeit ''→ Infos ergänzen''
* Funktionen ''→ Infos (3 Empfindlichkeiten, umdrehen, Rekalibrierung, ...) ergänzen''
* Link zur Bedienungsanleitung
== Bedienung ==
Auf ebenen Untergrund legen, nach ein paar Sekunden blinken die LEDs er langsamer, dann den linken Steuerhebel einmal hoch und wieder runter fahren.
== Komponenten ==
Der Quadrocopter wird von vier kernlosen Gleichstrommotoren („Coreless DC“) angetrieben. Im Inneren des Gehäuses ist eine Platine. Ihre vergleichsweise modernen Hardware-Komponenten (Mikrocontroller, Sensoren, MOSFETs und Funkmodul) sind in den folgenden Kapiteln beschrieben.
=== Mikrocontroller ===
Der „Nuvoton Mini54ZAN“ ist ein Cortex-M0 MCU mit 16KiB Flash, 2KB SRAM und SWD.
''→ Links zu Datenblättern ergänzen''
=== Sensoren zur Flugstabilisierung ===
Für die Flugstabilisierung ist der Quadrocopter mit drei Gyroskopen und drei Beschleunigungssensoren ausgestattet. Diese sind alle zusammen im Intertialsensor „Invensense MPU-6050“ integriert.
''→ Link zum Datenblatt''
=== ESC ===
Die Ansteuerung der Gleichstrommotoren erfolgt über PWM und MOSFETs. Die verwendeten N-Kanal MOSFETs „G2310“ haben einen „Drain-Source On-Resistance“ von etwa 120mΩ.

Siehe http://www.mikrocontroller.net/attachment/193854/G2310.pdf
=== Funk- Transceiver ===
Für die 2,4GHz Funkstrecke zur Fernsteuerung ist mit einem „Beken BK3423“ integriert. Die Vermutung, dass dieser voll kompatibel zum NRF24L01 ist, liegt nahe, da der NRF24L01 die Daten der Fernbedienung empfangen kann.

[[Bild:HOC_Fernbedienung_Platine_Ausschnitt2.jpeg|200px]]
== Zubehör ==
=== Lade-Adapter ===

Schaltplan des beiliegenden Ladeadapters:

http://www.mikrocontroller.net/attachment/197005/ladeanzeige.png

Auf der Platine vorgesehen sind weiter eine in Reihe zu R2 geschaltete Diode und ein Parallel zum Akku liegender Widerstand R5, welche allerdings nicht bestückt sind.

Bei vollem Akku erlischt die LED

=== Funkfernbedienung ===
Die Außenantenne ist nur „Verarsche“ ...

''→ Infos ergänzen''

''→ Hinweis auf Idee: Neuen Sender entwickeln''

[[Bild:HOC_Fernbedienung_Platine_B-Seite.jpeg|200px]]
[[Bild:HOC_Fernbedienung_Platine_Ausschnitt.jpeg|200px]]
[[Bild:HOC_Fernbedienung_Platine_total.jpeg|200px]]
[[Datei:HOC_Fernbedienung_Platine_Ausschnitt2.jpeg|200px]]

==== Pinbelegung des Mikrocontrollers ====

Pinbelegung für CPU N79E814

Pin Name Funktion
1 P0.0 LCD, CS
2 P1.7 LCD, CLK
3 P1.6 LCD, DATA
4 RST Reset (10k - C)
5 VSS an Masse
6 P3.1 RF-Modul, MOSI
7 P3.0 RF-Modul, SCK
8 P1.4 RF-Modul, MISO
9 SDA RF-Modul, CSN
10 SCL 2K2 Pullup, unbestückter Schaltungsteil
11 P1.1 LED via 1kOhm
12 P1.0 Buzzer (via Transistor)
13 AD6 über Widerstände an Batteriespannung vor Regler
14 AD5 Auswertung Taster (Seite Yaw-Throttle)
15 VDD Versorgung
16 AD4 Poti "Throttle"
17 AD3 Poti "Yaw"
18 AD2 Poti "Roll", Dämpfung mit RC Glied
19 AD1 Poti "Pitch", Dämpfung mit RC Glied
20 AD0 Auswertung Taster (Seite Pitch-Roll)

==== Pinbelegung des Sendemoduls ====
[[Bild:HOC_Fernbedienung_Sendemodul.jpeg|200px]]

1 3.3V
2 MOSI an PIN6 MCU
3 SCK an PIN7 MCU
4 MISO an PIN8 MCU
5 CE
6 GND
7 IRQ
8 CSN an PIN9 MCU
9 RXEN

==== Protokoll ====

Es handelt sich um das V202 Protokoll.

* Die Payload hat eine Länge von 16-Byte
* Das letzte Byte entspricht der Summe aller vorherigen Bytes (bzw. den unteren 8 Bit der Summe)
* Das Datenformat passt zu dem im GitRepo beschriebenen (https://github.com/hackocopter/Documentation/tree/master/RemoteControl)
* Das Datenformat passt zu der Implementierung des V202 Protokolls in der Deviation firmware (https://bitbucket.org/PhracturedBlue/deviation/src...)

Zum Channel Hopping:
* jedes Packet wird zweimal versendet
* es immer 16-Channel durchgehoppt (dann gehts wieder von vorne los)
* auch das passt zur Implementierung in der Deviation firmware

Siehe auch: http://www.mikrocontroller.net/topic/309185?goto=3410375#3410373

=== Propeller ===
''→ Infos ergänzen''
== Schnittstellen ==
=== SWD-Port ===
Der SWD-Port ist über … herausgeführt. ''→ Infos ergänzen''
=== Serielle Schnittstelle ===
Die Anschlüsse führen zu den RX und TX Pins des MCUs.
''→ Infos ergänzen''
=== PIN 9 ===
''→ Infos ergänzen''
=== I²C-Schnittstelle ===
''→ Infos ergänzen''
= Tipps und Tricks =
== Bezugsquellen und Kauf ==
=== Direktkauf aus China ===
''→ Infos zu Aliexpress, ebay, Einfuhrumsatzsteuer und Käuferschutz ergänzen''
=== Lieferanten aus Europa ===
''→ Infos ergänzen''
== Ersatzakkus ==
Der Original-Akku hat …mAh und wiegt …g. ''→ Infos ergänzen''
(380mAh, ca. 2,31€, …g) ''→ Infos ergänzen''
== Reduzierung der Unfallfolgen ==
''→ Infos ergänzen''
= Ideen für neue Funktionen =
== Bessere Flugstabilisierung mit bestehender Sensorik ==
== Neue Funktionen mit GPS-Sensor ==
[[Bild:HOC_GPS_Groessenvergleich.jpg|200px]]

''→ Ideen ergänzen''
== Neue Funktionen mit Luftdruck-Sensor ==
''→ Ideen ergänzen''
== Neue Funktionen mit Kamera ==
Alternativen: Keycam, Y3000, … ''→ Infos ergänzen''
== Neue Funktionen mit Ultraschallsensor ==
''→ Ideen ergänzen''
== Neue Funktionen mit Infrarot-Entfernungssensor ==
[[Bild:HOC_IR-Entfernungsmesser-Testplatine.jpg|200px]]

''→ Ideen ergänzen''
== Neue Funktionen mit Bluetooth ==
''→ Ideen ergänzen''
== Erweiterung der Original-Fernbedienung ==
=== Funkmodul mit PA + LNA ===
''→ Details ergänzen''
=== Erweiterung um ein Display ===
[[Bild:HOC_Fernbedienung_mit_C0802-04.jpeg|200px]]

''→ Details ergänzen''
== Neue Funktionen mit alternativer Fernbedienung ==
''→ Ideen ergänzen''
= Programmierung neuer Firmware =
== Beschreibung der Toolkette ==
''→ Details ergänzen''
=== Notwendige Hardware und Software ===
''→ Details ergänzen''
=== Installation der Toolkette ===
''→ Details ergänzen''
=== ISP und ICD ===
== Beschreibung der Firmware-Varianten ==
=== „Blinky“ ===
''→ Details ergänzen''
= Weiterführende Links und Quellen =
* http://www.jann.cc/2013/10/13/tiny_hackable_quadcopter.html ''→ Details ergänzen''
* Multiwii ''→ Details ergänzen''
* Paparazzi (http://paparazzi.enac.fr/wiki/Main_Page) ''→ Details ergänzen''