Mikrocontroller.net - Benutzerbeiträge [de]

Bus-Pirate

2022-06-06T08:18:41Z

Prx:

= Beschreibung =

Der Bus Pirate ist ein Analyzer für etliche serielle Signale und Schnittstellen.

Es handelt sich um ein Open-Source Projekt, welches auf [http://hackaday.com/2009/06/25/how-to-the-bus-pirate-v2-with-usb/ Hackaday] vorgestellt wurde. Entwickelt wurde der Bus Pirate von Ian Lesnet (DangerousPrototypes).

Die stabile Version ist aktuell der BusPirate v3.6. Eine v4 mit deutlich erweiterten Hardware-Ressourcen befindet sich seit mehreren Monaten in der Entwicklung.

Die Homepage des Projektes ist [http://dangerousprototypes.com/docs/Bus_Pirate http://dangerousprototypes.com/docs/Bus_Pirate].

= Unterstützte Protokolle: =

* 1-Wire
* I²C (ohne Clock Stretching)
* SPI
* JTAG
* Asynchron Seriell
* MIDI
* PC Keyboard
* HD44780 LCD
* 2- und 3-wire Bibliotheken mit bitweiser Pin-Kontrolle
* Programmierbare binäre Bitbang, 1-Wire, I²C, SPI und UART-Modi

Hier gibt es noch eine bessere Auflistung: http://dangerousprototypes.com/bus-pirate-manual/bus-pirate-feature-overview/

= Möglichkeiten =

* 0 - 5,5 Volt Pegel
* 0-6 Volt Spannungsmessung
* 1Hz-40MHz Frequenzmessung
* 1kHz - 4MHz Pulsweitengenerator, Frequenzgenerator
* On-board Mehrfachspannungs Pull-up Widerstände
* On-board 3,3 Volt und 5 Volt Spannungsversorgung mit Software-Reset
* Makros für gebräuchliche Funktionen
* Busverkehr-Sniffer (SPI, I²C)
* Bootloader für einfache Firmwareupdates
* Transparenter USB->serieller Modus
* 10Hz-1MHz low-speed Logikanalyzer
* Programmierung vieler AVR-Mikrocontroller
* Unterstützt von AVRdude
* Kann AVR STK500 v2 emulieren (Durch Laden der STK500-Clone Firmware)
* Programmierbar via Perl, Python, usw.
* Internationalisierung (zur Zeit spanisch und italienisch)
* Öffentlich zugänglicher (Creative Commons Zero) Source-Code. Prototypen mit dem Bus-Pirate bauen und den verwendeten Code überall im eigenen Projekt benutzen

= Gehäuse =

http://www.seeedstudio.com/depot/plastic-case-for-small-project-bus-pirate-v3-compatible-p-581.html (nicht mehr lieferbar)

Alternativ ein sogenanntes Sick-of-Beige (SoB) "Gehäuse": 
http://www.seeedstudio.com/depot/bus-pirate-v36-acrylic-case-v1-dp6037-p-1229.html

= Bezugsquellen =

* http://www.seeedstudio.com/depot/bus-pirate-v36-universal-serial-interface-p-609.html
* http://www.watterott.com/de/Bus-Pirate
* https://www.sparkfun.com/products/9544

= Kompatible Firmware =

* STM32 https://github.com/hydrabus/hydrafw

[[Kategorie:Oszilloskope und Analyzer]]

Nachttischlampe

2016-03-13T07:52:53Z

Prx: Änderung 92319 von 184.168.27.152 (Diskussion) rückgängig gemacht.

''von [http://www.mikrocontroller.net/user/show/mclausen Martin Clausen]''

== Einleitung ==
Ausgehend von den von den Unzulänglichkeiten meiner bisherigen Nachttischlampe und der mich nicht überzeugenden Funktion einer Beleuchtung für den Schlafraum eines niederländischen Herstellers, entstand die Idee zu diesem Projekt.
Im Ergebnis ergeben sich ein angenehmeres Aufstehen, mehr Komfort und die Möglichkeit bei einem von zwei Personen bewohntem Schlafzimmer einander weniger zu stören.
=== Features für den Nutzer ===
* Zwei separate Beleuchtungskanäle
** Hintergrundbeleuchtung
** Leselicht
* Intuitive Bedienung über einen Drehencoder mit Tastfunktion
** Dynamische Schrittweitenanpassung für die schnelle und genaue Einstellung der Helligkeit und anderer Werte
* Anzeige mit 16x2 hintergrundbeleuchtetem LCD
* Anpassung der Helligkeitssteuerung an die Empfindlichkeitskurve des menschlichen Auges
* Anpassung der Helligkeit an das Umgebungslicht
* Fernbedienbar
* Vernetzbar innerhalb eines Raumes
** Synchronlauf der Helligkeiten von Lampen aktivierbar
** Alarmfunktion kann andere Lampen aktivieren
* Weck-Funktion
** Bis zu 7 wochentagsabhängige oder - unabhängige Alarme
** Alarme überspringbar
** Alarmsignal durch
*** separat in Zeit und Helligkeit einstellbares Eindimmen von Hintergrund- und Leselicht
*** angenehmes akustisches Signal mit einstellbarer Verzögerung zum Alarmstart und ansteigender Lautstärke

=== Technische Eigenschaften ===
* LEDs
** Nichia NS6W183 auf Star-Platine
** 4 Stück warmweis für die Hintergrundbeleuchtung
** 2 Stück kaltweiss für das Leselicht
** andere LED Bestückungen bis 5 LED je Strang bei 24V Eingangsspannung möglich
* LED-Treiber
** Zwei unabhängige PWM-gesteuerte Kanäle
** Nachführung der PWM-Frequenz zur Vergrößerung des dynamischen Bereiches der LED-Treiber ohne Flackern der Beleuchtung
** Zwei verschiedene Treiber möglich:
*** Diodes ZXLD1362
*** Diodes ZXLD1374
** Hysteric Step-Down-LED-Driver
** maximal 60V, 1A bzw. 1,5A; 24V, 500mA in diesem Projekt
* Step-Down Regler für Steuer-Modul
** Zwei verschieden Schaltregler möglich
*** LM2674 ADJ auf 3,3V eingestellt, maximale Eingangsspannung 40V
*** LT1676 auf 3,3V eingestellt, maximale Eingangsspannung 60V
* MCU
** NXP 89LPC936, 8051 mit 2-Takt Kern
** 16k Byte Flash (ca. 10k Byte belegt), 768 Byte RAM, 512 Byte EEPROM, ISP
** 3,3 Volt, niedriger Stromverbrauch
** 6 MHz Takt mittels Resonator, 18 MHz maximal
** 8 Bit DAC und ADC
** 16 Bit CCU mit PLL und 4 Kanälen
* LCD
** Electronic Assembly DOGM162W-A mit amber-farbener Hintergrundbeleuchtung
** Hintergrundbeleuchtung mit PWM-Ansteuerung
** Anschluss an MCU via SPI
* RTC RV 3029-C2 mit integriertem Quarz
* Erzeugung des akustischen Signals
** DDS zur Erzeugung eines sauberen und angenehmen Sinussignals
** Alternativ: Hardware vorbereitet für das Abspielen von unkomprimierten Audiodaten aus 4M Byte Flash
** Ausgabe über DAC im MCU
** Tiefpassfilter 3. Ordnung, 8,6kHz Frequenz , mit 3/4 MCP6404
** Einstellung der Lautstärke in 4 Stufen mit CMOS-Schalter 1/2 74HC4052
** Lautsprecheransteuerung durch Brückenverstärker LM4861
* Messung der Umgebungshelligkeit
** Linearer I-U Wandler mit 1/4 MCP6404
** Widerstand über CMOS-Schalter 1/2 74HC4052 1:1000 umschaltbar in 4 Stufen
** 8-Bit ADC der MCU
** Gesamtdynamikbereich von 1:256000
** Moving-Average-Filter mit 64 Datenpunkten
* Kommunikation
** Empfängt und sendet IR-Signale gemäß RC5-Protokoll
* Stromversorgung
** Phihong, PSAA 30R-240 (30W, 24V)
** Niedrige Standby-Leistung von 300mW
** Ausreichend für zwei Lampen
** Messung der Leistungsaufnahme von der 24V Versorgung am Prototypen mit LM2674 und 2x ZXLD1362:
*** Standby: 170mW
*** Volllast: 11,5W
** Messung der Leistungsaufnahme von der 230V Versorgung an einem Netzteil mit zwei Prototypen mit LM2674 und 2x ZXLD1362:
*** Standby: 0,5W
*** Volllast: 26W
** Messung der Leistungsaufnahme von der 24V Versorgung am Prototypen mit LT1676 und 2x ZXLD1374:
*** Standby: 72mW

* Struktur
** Steuerplatine 36x100mm², doppelseitig
** Leistungsplatine 80x100mm², einseitig
** Verbindung über einzelnes 10 pol. Flachbandkabel
** Stromversorgung über Steckernetzteil

* Mechanik
** Konstruktion aus eloxierten Aluminium Profilen von Item

* Software
** Open Source C für SDCC 3.2
** Verwendet Stromsparmodi der MCU
** State-Machines für Drehencoder und RC5-Dekodierung

== Bilder ==

=== Design ===
* Symmetrisches Pärchen, Vorder- und Rückseite
[[Bild:Symmetrisches Pärchen.jpg|200px]]
[[Bild:Symmetrisches Pärchen Rückseite.jpg|200px]]
* Detail Ansteuerung, Vorder- und Rückseite
[[Bild:Detail Ansteuerung.jpg|200px]]
[[Bild:Detail Ansteuerung Rückseite.jpg|200px]]
* Detail Leselicht
[[Bild:Detail Leselicht.jpg|200px]]

=== Lichtwirkung ===
* Leselicht allein mit 10% Helligkeit
[[Bild:Leselicht 10%.jpg|300px]]
* Leselicht allein mit 100% Helligkeit
[[Bild:Leselicht 100%.jpg|300px]]
* Hintergrundlicht allein mit 10% Helligkeit
[[Bild:Hintergrundlicht 10%.jpg|300px]]
* Lese- und Hintergrundlicht zusammen mit 100% Helligkeit
[[Bild:Lese- und Hintergrundlicht 100%.jpg|300px]]

Die Bilder wurden alle bei den gleichen fixen Kamera-Einstellungen aufgenommen. Der effektive dimmbare Bereich liegt zwischen 3 und 100%. Zur PWM-Ansteuerung der LEDs wird der quadrierte Wert verwendet.

== Beschreibung ==

=== Software ===

Die Software besteht aus folgenden Teilen:
* Hauptschleife

* Interrupt-Routinen
** RC5 Decoder, ausgelöst durch Timer 0
** Update der Zeit, jede Minute durch RTC ausgelöst
** Drehencoder, ausgelöst durch Timer 1 bei 366Hz
** Update PWM-Werte und einlesen der Tasten, ausgelöst durch Timer aus RTC der MCU bei 25Hz

* Ansteuerung des Display via SPI

* Initialisierung der MCU
** Core Funktionen, hauptsächliche Stromsparfunktionen
** I/O Pins
** SPI auf Master mit 1,5MHz Takt, MSB first
** I2C auf 375kHz
** ADC fixed channel, single conversion mode für ADC0 bei 3MHz
** DAC
** Interne RTC als 25Hz Taktgeber: 6*10^6/128/25=1875 reload
** Watchdog wird abgeschaltet
** CCU output compare: non-inverted PWM, PLL: auf Lock-in abwarten
** Interrupts freischalten

* Auswertung Drehencoder

* Helligkeitsmessung

* I2C und RTC
Die Funktionen stellen einerseits die Kommunikation via I2C sicher und sind anderseits in der Lage, die RTC nach einem Batteriewechsel automatisch zu konfigurieren, die Zeit zu lesen und zu schreiben.
Die Kommunikation via I2C nutzt bisher nicht den zugehörigen Interrupt und ist nicht fehlertolerant.

* RC5 Decoder und Sender
Der RC5 Decoder beruht auf einer State-Machine, die schrittweise die einzelnen Bits erkennt und dann in Adresse und Daten zerlegt. Nach der Erkennung eines kompletten Komandos wird steht rCounter auf dem Wert 12 und das Hauptprogramm beginnt mit der Decodierung (Aufruf "DecodeRemote()").
Der Sender ist mittels Bit-Banging realisiert. Aufgrund des strikten Timings werden alle Interrupts abgeschaltet. Die Adresse für die Fernbedienung kann vom Benutzer eingestellt werden oder angelernt werden. Die Adressen für die Kommunikation der Lampen untereinander lauten 27, 28, 29.

* Optionsmenü

* Setzen der Helligkeit

* Auswertung Tasten
Es werden die Tasten entprellt und die Dauer des Tastendrucks wird festgestellt.

* Erzeugung des akustischen Signals in "AcusticDDSAlarm()"
Das Sinussignal wird mittels direkter digitaler Signalsynthese erzeugt. Dazu erzeugt ein in einer Schleife laufender Akkumulator mit Hilfe einer Tabelle von Sinuswerten einen Datenstrom der dem DAC zugeführt wird. Frequenz und Dauer der einzelnen Töne wird in einem zweidimensionalen Array in Code abgelegt.
Aufgrund des strikten Timings werden alle Interrupts abgeschaltet. Die Helligkeitsmessung wird auch unterbrochen, da die gleichen Pins die Lautstärke steuern.
Parallel werden nur die Tasten überwacht.

[[Bild:Menüstruktur V2.svg|400px]]

=== Elektronik ===
Die Elektronik gliedert sich in zwei Teile:
* Leistungsteil
* Steuerung

Der Leistungsteil entspricht im wesentlichen den Applikationsvorschlägen der Hersteller. Um Wechselwirkungen zwischen den Schaltreglern zu reduzieren wurden in den Stromzuführungen PI-Filter mit Feriten und Keramikkondensatoren eingesetzt und die gemeinsame Versorgung über einen größeren schaltfesten Elko abgeblockt.
Zur Erhöhung der Betriebssicherheit sind ferner eine Suppressor-Diode und ein Verpolschutz vorgesehen.

Variante für ZXLD1362
Die einseitige Leiterplatte kann weitestgehend in SMD aufgebaut werden. Wo möglich wurde die Bauform 1206 verwendet, damit auch selbst gefertigte Platinen verwendbar sind. Große Masseflächen dienen auch zur Verteilung der Wärme. Die Anschlussklemmen und der Elko sind so platziert, dass sie im Inneren des Aluminium-Profils Platz finden.

Variante für ZXLD1374
Gegenüber dem Entwurf mit ZXLD1362 wurde ein sparsamer Schaltregler (LT1676) für die Versorgung der Steuerung verwendet. Mit diesem Chip erhöht sich, wenn Kondensatoren und Suppressordiode angepasst werden auch die maximale zulässige Eingangsspannung.
Der LED-Treiber lässt sich deutlich besser kühlen und bietet eine bessere Dynamik in der PWM-Ansteuerung bei gleichzeitig höherer Wiederhohlrate. Letzteres reduziert den Stroboskop-Effekt beim Dimmen. Das Gehäuse erfordert jedoch eine doppelseitige Platine mit Durchkontaktierung.

Die Steuerung gruppiert sich um eine MCU von NXP der 8051 Serie. Praktisch ist die 4-kanalige 16-bit CCU mit PLL, die sowohl die beiden LED-Stränge als auch die Hintergrundbeleuchtung des LCD steuern. Das kärgliche On-Chip der klassischen 8051 hat NXP um 512 Byte aufgebessert, was die Programmierung mit dem SDCC erleichtert. Die Einstellungen vom Benutzers werden im internen EEPROM abgelegt. Ein Resonator sorgt für einen genaueren Takt als der interne RC-Oszilator und eine "bequeme, glatte" Frequenz von 6MHz.
Als RTC kommt ein externer Baustein mit integriertem Quarz, Temperaturkompensation und Batterieumschaltung zum Einsatz. Damit lässt sich eine sehr gute Frequenzkonstanz erreichen. Die Lithiumbatterie sollte eine Zeit von 220mAh/1µA = 220kh = 25a erreichen. Die Stützbatterie wird durch einen Reihenwiderstand vor Defekten in der Schaltung die zu einem Stromfluss in die Batterie führen könnten geschützt. Der Anschluss der RTC zum Datenaustausch erfolgt über die I2C-Hardware des MCU. Die interne RTC des MCU wird als Timer verwendet.
Als Display kommt eine moderne Variante des klassischen 16x2 Zeichen LCD zum Einsatz. Die Modernisierungen betreffen die digitale Kontrast-Einstellung, 3,3V-Betrieb und das SPI mit passend zur MCU geringer Pin-Anzahl.
Die Kommunikation per IR erfordert nur das entsprechende Empfangsmodul und einen kleinen MOSFET zur Ansteuerung der Sendediode. Es sind zwei positionen auf der Platine vorgesehen, damit die Richtung der Abstrahlung gewählt werden kann. Falls beide Sendedioden bestückt werden, sollten die Vorwiderstände auf je 10 Ohm verdoppelt werden. Um das den 3,3V Schaltregler und den MOSFET nicht zu überfordern wird die Sendediode nur mit 300mA bei 25% Duty-Cycle betrieben. Ferner sind großzügige keramische Stützkondensatoren vorgesehen. Die Empfänger können parallel betrieben werden, um der Schaltung eine Rund-um-Sicht zu ermöglichen.
Recht aufwändig sind dagegen die Messung der Umgebungshelligkeit und die Erzeugung des akustischen Signales geraten. Zu nächst zur Helligkeitsmessung: Für diese Aufgabenstellung gibt es spezialisierte IC, die jedoch schwer erhältlich sind. Deshalb wurde ein Transimpedanzverstärker mit umschaltbarem Rückkoppelwiderstand aufgebaut. Die MCU ist zwar mit einem ADC ausgestattet, jedoch ist deren Dynamikbereich allein nicht ausreichend. Zusammen wird jedoch ein Bereich von 1:255000 entsprechend 108dB abgedeckt. In Software wird das Signal noch gefiltert und die Messwerte, zu die von der Hintergrundbeleuchtung des LCDs oder der IR-Sendediode beeinflusst worden sein könnten, übersprungen.
Die das akustische Signal sollte einen möglichst angenehmen Klang haben. Daher läuft auf der MCU eine DDS mit ca. 20kHz zur Erzeugung eines Sinussignals, welches über den ADC ausgegeben wird. Dann folgt zu nächst ein Buffer und eine Pegelanpassung, die ein Übersteuern der OPVs im folgenden Tiefpass mit ca. 7kHz verhindern. Über einen CMOS Schalter lässt sich das Signal in drei 10dB Stufen abgeschwächt dem ausgangsseitigen Brückenverstärker zuführen. Dieser wird zur Reduktion des Stromverbrauches von der MCU nur bei Bedarf aktiviert. Er ist auch auf eine Bandbreite von 8kHz begrenzt, um die Oberwellen weiter zu reduzieren.
Die beiden letztgenannten Schaltungsteile profitieren besonders von einem PI-Filter mit einer 4,7µH Drossel und größeren keramischen Kondensatoren. So werden Störungen aus Schaltreglern und der PWM-Ansteuerung der Hintergrundbeleuchtung ferngehalten.
RC-Glieder schützen die MCu vor Störeinstrahlung- und leitung durch die Kabel zu Drehencoder und Leistungsteil.
Die recht hohe Packungsdichte, der enge Pin-Abstand von MCU, OPV und RTC und die notwendigen Masseflächen erfordern eine professionelle doppelseitige Platine. Die Masseflächen wurden durch eine Vielzahl von vergrößerten und verteilten Vias verbunden. Die Entstörkondensatoren an den Halbleitern sind mit 1µF recht groß gewählt. Ob die Störfestigkeit unter der gegenüber 100nF reduzierten Resonanzfrequenz der Kondensatoren geringer ist, wurde nicht untersucht. (Es funktioniert.) Ein keramischer 1nF Kondensator hält Störungen vom Reset-Pin der MCU fern.

Die Steuerplatine trägt zwei 5*2 polige Pfostenleisten. Die äußere dient primär zur Programmierung der MCU, kann aber auch für Erweiterungen mit I2C-Anschluss verwendet werden. Die innere stellt die Anschlüsse für Drehencoder und Leistungsteil zur Verfügung. Dazu muss somit ein Flachbandkabel mit drei Enden gepresst werden: 5*2 polig (Steuerung), offen (Drehencoder), 3*2 polig (Leistungsteil)

Die MCU wird mit der kostenlosen Software [http://www.flashmagictool.com/ FlashMagic] und einer [http://www.keil.com/mcb900/mcb900-schematics.pdf Schaltung von Keil] über RS232 geflasht. Bei der Inbetriebnahme müssen folgende Punkte beachtet werden:
* Die Kondensatoren auf der Steuerungsplatine müssen schnell genug entladen werden können, damit die MCU beim Start in den Programmiermodus gebracht werden kann. Eine zusätzliche Last von z.B. 100 Ohm über die Betriebsspannung hilft.
* Es muss keine "echte" RS232 Schnittstelle sein. Ein USB-RS232 Adapter mit FTDI-Chip funktioniert bei mir auch.
* Einstellungen Flash Magic:
** Select: 89LPC936
** Baud Rate: 7200
** Interface: None (ISP)
** Oscillator (MHz): 7,373
** Erase block used by Hex File
* Unter ISP, Device Configuration wird die MCU konfiguriert:
** Statt des internen Oszillators muss ein externer High-Speed Oszillator gewählt werden. Die in FlashMagic einzustellende Frequenz ändert sich dann von 7.373 MHz auf 6 MHz
** Der Reset-Pin muss ausgeschaltet werden.

Das Netzteil ist so ausgelegt, dass zwei Lampen mittels eines Y-Kabels versorgt werden können. Dadurch entfallen die Leerlaufverluste, Kosten und Platzbedarf des zweiten Netzteils.

Kosten der Steuerplatine (Teile: Reichelt, MCU: Ebay, 5 Platinen von PCB-Pool): ca. 56€ je Stück

=== Optoelektronik ===

Die Auswahl der LEDs wird primär von den Wünschen nach der Lichtwirkung bestimmt. Hier ist nur ein Vorschlag angegeben. Daneben gibt es noch die Schnittstellen zur Mechanik und zur Elektronik.
Die Ansteuerung kann bei Versorgung mit 24V 1 bis 5 LEDs je Strang bedienen. Der Strom ist auf 500mA eingestellt, auch wenn der ZXLD1362 auch größere Ströme verkraften sollte. Beim SOT23-5 Gehäuse hatte ich jedoch dann in einem anderen Projekt insbesondere bei höheren Spannungen Probleme mit der Wärmeabführung. Mittlerweile können auch andere Gehäuseformen mit geringerem Wärmewiderstand bzw. leistungsfähigere Chips wie der ZXLD1374 eingesetzt werden. Der ZXLD1374 kann auch kürzere PWM-Impulse noch sauber in Stromimpulse für die LEDs umsetzen, womit ein größerer dimbarer Bereich erzielt wird. Jedoch muss der PWM-Pin von einem Push-Pull- statt einem Open-Drain-Ausgang angesteuert werden, da der interne Pull-Up des LED-Treibers sehr schwach ist und der Chip dann nur bei relativ langen Pulsen aus dem Standby aufwacht. Zum ZXLD1374 ist ein zusätzlicher Schaltplan mit Layout im Repository abgelegt. Der LM267X musste bei diesem Entwurf einem sparsameren und spannungsfesteren LT1676 weichen.
Sollen mehr als 5 LEDs je Strang angesteuert werden, muss die Supressor-Diode am Stromversorgungseingang angepasst und der LT1676 zur Versorgung der Steuerplatine verwendet werden. Die ZXLD1362 vertragen bis zu 60V, sollten jedoch mit mindestens 17V versorgt werden, damit der Schalt-MOSFET voll durchschaltet.

{| class="wikitable"
|+ '''Teile von Leds.de'''
|-
! Anzahl || Artikel-Nr. || Bezeichnung || Kommentar
|-
| 4 || 65659 || Nichia NS6L183BT, warmweiß, CRI 80, mit Platine (Star) || bessere Farbwiedergabe bei schlechterer Effizienz: austauschbar gegen NS6L183AT-H3 (CRI 85) oder NS6L183AT-H1 (CRI 90+)
|-
| 2 || 65656 || Nichia NS6W183BT, weiß, CRI 80, mit Platine (Star) ||
|-
| 2 || 60354 || Carclo Linse für Luxon Rebel, frosted wide || passt auch für Nichia NS6_183T
|-
| 2 || 60456 || Linsenhalter rund für Luxon Rebel, transparent || muss deutlich mit Säge und Feile angepasst werden
|}

Kosten ca. 27€

=== Mechanik ===
Bei einer Nachttischlampe ist natürlich auch das Design eine wichtiges Merkmal. Ich bevorzuge ein klares einfaches Design und Materialien wie Glas und eloxiertes Aluminium. Die verwendeten Profile (Item, Profil X 8, leicht) ermöglichen es die Kabel und die Leistungselektronik im Inneren zu verstecken.
Es haben aber auch einige Kunststoffteile Verwendung gefunden, da sie mir den Verschluss der Aluminiumprofile ohne sichtbare Schrauben ermöglichen.

Der sichere Stand wird durch die Füllung des Profil X 8 80x80 mit kleinen Kieseln für Aquarien gewährleistet. Die Oberen 1 bis 2cm bleiben frei und dienen dem Lautsprecher als Resonanzraum.

Die Frontplatte wird laut Zeichnung von der Schaeffer AG (Datei bei Downloads) gefertigt. Sie "schwebt" auf vier Distanzhülsen über der Steuerungselektronik. Dadurch bleibt umlaufend ein Spalt von 12mm Höhe, durch den die Steuerung per RC5 kommuniziert, die Umgebungshelligkeit gemessen wird und der Schall vom Lautsprecher abgestrahlt wird.

{| class="wikitable"
|+ '''Teile von Item'''
|-
! Anzahl || Länge || Art.-Nr. || Bezeichnung
|-
| 1 || 160mm || 0.0.493.04 || Profil X 8 80x80 8N leicht
|-
| 1 || 160mm || 0.0.492.88 || Profil X 8 40x40 4N leicht
|-
| 1 || 480mm || 0.0.492.88 || Profil X 8 40x40 4N leicht
|-
| 1 || - || 0.0.601.13 || Gelenk X 8 40x40 mit Klemmhebel
|-
| 4 || - || 0.0.026.07 || Standard-Verbindungssatz 8
|-
| 1 || - || 0.0.489.98 || Abdeckkappe X 8 80x80 grau
|-
| 1 || - || 0.0.489.61 || Abdeckkappe X 8 80x40 grau
|-
| 1 || - || 0.0.489.60 || Abdeckkappe X 8 40x40 grau
|}

Kosten: Item ca. 90€, Schaeffer AG ca. 25€

Der Klemmhebel kann bei ästhetischen Bedenken auch gegen eine Schraube getauscht werden. Von zwei Standard-Verbindungssätzen wird nur die Schraube zur Befestigung des Gelenks verwendet.

Die Bohr- und Fräsarbeiten habe ich durch [http://dw-metall.de/ Daniel Wulfänger] durchführen lassen.

Ein 3D-Model für FreeCAD befindet sich im SVN-Repository (s.u.).

2D-Zeichnungen auf Anfrage per PM bei [http://www.mikrocontroller.net/user/show/mclausen Martin Clausen]

== Montage ==

Wenn alle Teile laut Zeichnung bearbeitet worden sind, werden zunächst die Standard-Verbinder für die Verbindung von Arm und Fuß eingeschraubt. Da aus optischen Gründen kein Loch zum Festziehen der Schrauben vorhanden ist, werden die Standardverbinder vorsichtig angezogen, so dass der Arm beim Aufschieben beginnt zu klemmen. Dann wir die Fläche zwischen Arm und Fuß mit Alkohol geschmiert und der Arm mit einigen Hammerschlägen montiert. Dabei sollte eine Unterlage (z.B. ein Stück Holz) verwendet werden.

Nun wird der Drehencoder verdrahtet und in die große Abdeckkappe geschraubt und mit Heißkleber versiegelt.

[[Bild:Drehencoder mit Kabel.jpg|300px]]

Im folgenden wird die Stromversorgungsbuchse in die 80x40 Abdeckkappe geschraubt und diese in den Fuß gepresst.

[[Bild:Durchführung Kabel.jpg|200px]]

Dann werden die LEDs mit etwas Wärmeleitpaste und einer Isolierscheibe unter jeder Schraube montiert. Kabel werden in das Profil gefädelt und an gelötet. Ein fester Draht kann dabei nützlich sein. Dann wird die Leistungselektronik im Fuß platziert. Für die Positionierung sorgen 10 und 12 mm Distanzbuchsen jeweils mit und ohne Außengewinde.
Jetzt bietet sich ein kurzer Funktionstest an.

[[Bild:Montage LEDs.jpg|300px]]

Für die Front-LEDs werden nun die Halter modifiziert und aufgeklemmt. Dann werden die Linsen eingerastet.

Nun wird grober Aquarien-Kies gewaschen, gründlich getrocknet und in den Fuß gefüllt. Dabei muss ausreichend Raum für die Halter der großen Abdeckkappe gelassen werden. Diese wird nun aufgepresst. Dann wird der Fuß weiter verfüllt.

[[Bild:Verfüllung Fuß.jpg|200px]]

Jetzt werden noch Steuerelektronik mit 5mm Distanzbuchsen und M3x10 Schrauben montiert. Zum Schluss wird die Frontplatte mit M3x20 Edelstahl Senk-Inbusschrauben und 12mm Distanzbuchsen befestigt.

== Downloads ==

* [https://github.com/martinclausen2/Nachttischlampe.git Link zum Repository für Software, Schaltpläne, Platinen und Mechanik]
* [[Datei:Hex-File Nachttischlampe.zip|Hex-File jeweils für ZXLD1374 ZXLD1362 V5]]

== Siehe auch ==

* [[Wake-Up Light]]
* [[LED-Pendellampe]]
* [[LED]]
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/297859#3182303

[[Kategorie:Projekte]]
[[Kategorie:8051]]
[[Kategorie:Timer und Uhren]]

Pulsdichtemodulation

2016-03-13T07:51:46Z

Prx: Änderung 92321 von 184.168.27.152 (Diskussion) rückgängig gemacht.

Die Pulsedichtemodulation ist eine Methode, einen zunächst digitalen Wert über einen einzelnen Port-Pin eines PLDs auszugeben und in der Folge mittels einer analogen Filterung einen Analogwert zu erzeugen.

== Funktion ==
Sie beruht auf der Methode der s.g. Delta-Sigma-Modulation, bei der das Verhalten des Ausgangs (meist ein idealer Integrator) vorrausgerechnet und permanent die Differenz zu dem steuernden Eingangssignal, der Sollgröße, gebildet wird. Ist der vorausberechnete Wert grösser, als der Eingang, wird das 1-Bit-Signal auf low geschaltet, im umgekehrten Fall auf high. Das so erzeugte 1-Bit-Signal ist der Eingang für diesen virtuellen Integrator.

Hierdurch entsteht eine Art Blindregelung, die das Tastverhältnis des Ausgangssignals so einstellt, dass der spätere gefilterte Wert dem Eingangssignal theoretisch exakt folgt. Im Idealfall (siehe erstes Bild) bewegt die Regelung den Istwert somit permanent um den Sollwert herum und zeichnet das eingeprägte Signal (hier ein Sinus) nach.
{{Absatz}}

[[Datei:PDM-image1-ideal-case.gif|thumb|right|350px|Theoretisch ideales PDM-Signal]]
Praktisch gibt es aber einige Probleme: Infolge der Verluste der Schaltung und des teilweise nichtlinearen Verhaltens der Bauelemente (speziell des nachgeschalteten Filters) sowie des prinzipiellen Verschluckens des DC-Anteils bei typischen Filtern, driftet der reale Analogwert vom erzeugten virtuellen Wert mehr oder weniger weit weg. Zudem gibt es durch die Filterdämpfung nachfolgender RC-Glieder (grüne Kurve) wie auch bei aktiven Verstärkern (rail-to-rail-Problem) eine Amplitudenverzerrung und eine Phasenverschiebung. Diese lassen sich schätzen und in die Steuerung der PDM mit einbeziehen, indem die Amplitude linear (bzw. wie bei der "non-linear-predistortion" auch durchaus nichtlinear) vorkorrigiert wird. Ferner lassen sich die Ungenaugigkeiten aktiv wegregeln, indem das erzeugte Signal gemessen- und digital rückgeführt wird, wobei es relevant ist, *wo* das Signal abgegriffen wird.
{{Absatz}}

[[Datei:PDM-image2-real-case.gif|thumb|right|350px|Verlustbehaftetes PDM-Signal]]
Im zweiten Bild wird deutlich, dass die Phasen, in welchen extreme duty cycle Werte vorliegen, eigentlich überproportional steigen müssten, um vor allem die zeitabhängigen Verluste auszugleichen, d.h. kurze An-Phasen wären noch kürzer, lange An-Phasen noch länger. Auch das prinzipielle stark nichtlineare Verhalten eines einfachen RC-Dämpungsgliedes erfordert ein Aufdehnen der Phasen. Dies alles kann man beim virtuellen Integrator modellieren und auf diese Weise mit in die Regelung einfließen lassen. Damit wird dann auch der BIAS passend korrigiert, sofern das Modell genau genug ist. Zusätzlich wird in diesem Beispiel im Vergleich zum vorherigen Bild auch die Dämpfung des nachgeschalteten Filters erhöht, wodurch sich die Kurve besser glättet und ein noch besserer Sinus entsteht, bei den nur die Phase dem Ideal noch hinterher läuft.
{{Absatz}}

[[Datei:PDM-image3-feedback-control-case.gif|thumb|right|350px|Geregeltes PDM-Signal]]
Um die phasenverzögernde Filterwirkung zu kompensieren, muss das Signal hinter dem Filter abgegriffen und von dort in die Regelung rückgeführt werden. tut man dies, folgt die Kurve (hier grün) viel genauer dem blau dargestellten Sollwert. Wenn man bei bestimmten Anwendungen einen exakten Gleichanteil bzw. eine präzise Phase ausgeben will, muss demnach so oder ähnlich kompensiert und geregelt werden. Dies hat dann aber leider den Nachteil von mehr niederfrequenten Regelanteilen im Signal mit dem Ergebnis des insgesamt grösseren Rauschens. Die Verbesserung des DC-Aspekts führt also zu einer verschlechterten AC-Qualität.
{{Absatz}}

== Einsatzoptionen ==
Für Audio-Applikationen habe ich gefunden, dass es besser ist, das System im Wesentlichen zu steuern, also mehr oder weniger "stur" die ideale PDM auszugeben und dabei die Verluste zu schätzen und in den Integrator miteinzuberechnen. Konkret muss dabei das nichtlineare Kondensatorladeverhalten in Delta-Sigma-Regler abgebildet werden. Den DC-Anteil kann man dann langsam und träge regeln, indem die angenommenen Verluste angepasst werden. Damit ist es möglich, auch mit einem sehr simplen Filter eine erstaunliche Audio-Qualität zu erhalten.

== Siehe auch ==
* [[PWM]]
* [[Diskussion:Soft-PWM|Diskussionseite zu Soft-PWM]] - Diskussion über PDM

== Weblinks==

[[Kategorie:Grundlagen]]
[[Kategorie:Messtechnik]]
[[Kategorie:Signalverarbeitung]]

ESP8266

2016-03-13T07:50:44Z

Prx: Änderung 92322 von 184.168.27.152 (Diskussion) rückgängig gemacht.

[[Datei:ESP8266.jpg|thumb|300px|ESP8266, Funkmodul]]
Das [[ESP8266]] von dem Hersteller Espressif ist ein programmierbarer WLAN-SoC mit [[UART]]- und [[SPI]]-Schnittstelle. '''WLAN'''-Funkmodule mit ESP8266 sind ab 3€ verfügbar. Die UART-Schnitttstelle ermöglicht eine einfache Integration in Mikrocontrollerprojekte.

== Spezifikation ==
Laut Hersteller <ref>[http://espressif.com/en/products/esp8266 ''Herstellerseite - unter Details''] Abgerufen am 26. August 2014.</ref>. :
* 802.11 b/g/n
* Wi-Fi Direct (P2P), soft-AP
* Integrated TCP/IP protocol stack
* Integrated TR switch, balun, LNA, power amplifier and matching network
* Integrated PLLs, regulators, DCXO and power management units
* +19.5dBm output power in 802.11b mode
* Power down leakage current of <10uA
* Integrated low power 32-bit CPU could be used as application processor
* SDIO 1.1/2.0, SPI, UART
* STBC, 1×1 MIMO, 2×1 MIMO
* A-MPDU & A-MSDU aggregation & 0.4ms guard interval
* Wake up and transmit packets in < 2ms
* Standby power consumption of < 1.0mW (DTIM3)
* VCC: 3,3V (Achtung: Eingänge sind '''NICHT 5V TOLERANT'''!)
Weiterhin:
* GPIOs, ADC

=== Datendurchsatz/Performanz ===
[https://www.mikrocontroller.net/topic/342240?page=single#3857630 Beitrag im Forum mit Tests: TCP: bis zu 7 MBit/s] 
[http://bbs.espressif.com/viewtopic.php?f=7&t=24 Beitrag Espressif-Form: UART loopback: 4.5 Mbps]
 
Bei den chinesischen Modulen mit Firmware 0.9.1 werden Ping Befehle unabhängig von der Paketgröße typischerweise in 30-150ms beantwortet. Datenpakete, die man vom PC aus an das Modul sendet werden unabhängig von der Paketgröße typischerweise nach 100-200ms quittiert.

=== Power-/Sleep-Modes ===
Der Stromverbrauch des ESP8266 ist abhängig von vielen Faktoren, er läßt sich aber durch geschickte Programmierung durchaus deutlich senken. 
So ist es nicht notwendig, dass das WIFI-Modem oder der Mikrocontroller ständig läuft um z.B. eine WLAN-Türklingel zu realisieren. Im "Deep-Sleep" würde der ESP8266 dann nur 10uA verbrauchen, bis er über einen GPI-Interrupt geweckt wird und die Meldung absetzt. 
Zu beachten ist, dass in diesem Moment die WLAN und Netzwerkanmeldung neu startet und hierfür eine gewisse Zeit benötigt wird. 

[http://bbs.espressif.com/viewtopic.php?f=6&t=133 detailierte Übersicht der verschieden Modi und deren Stromverbrauch von Espressif] 

== WLAN-Module mit ESP8266 ==
Es existieren ca. 11 Varianten von chinesischen Herstellern. Beispielsweise mit PCB- oder Keramik-Antenne oder mit u.fl.
 
Die Firmware 0.9.1 unterstützt bis zu vier gleichzeitige TCP oder UDP Verbindungen. Sie kann sich in vorhandene WLAN Netze einbuchen, aber auch selbst Access-Point mit DHCP Server sein. Der Access-Point ist zu Android kompatibel (mit 4.1.2 getestet).
 
Die Firmware enthält jedoch keinen Router. Mehrere Computer, die mit dem Modul als Access-Point verbunden sind, können keine Verbindung zueinander aufbauen.
Das Feature nennt sich AP Isolation.
 
#Produktbeschreibung: [[http://playground.boxtec.ch/doku.php/wireless/esp8266]]

=== Pinbelegung einiger ESP8266-Module ===
====ESP8266-01====
<gallery>
Datei:ESP8266-PinBelegung1.jpg|Pinbelegung - Groß mit PCB-Antenne
Datei:ESP8266-PinBelegung2.jpg|Pinbelegung - Klein mit Keramik-Antenne
</gallery>
Quelle <ref>[http://pan.baidu.com/share/link?shareid=727869034&uk=1900861665 ''Seller Information''] Abgerufen am 26. August 2014.</ref>.
====ESP8266-07====
Achtung, beim ESP8266-07 Modul sind einige mit vertauschten Beschriftungen von GPIO4 und GPIO5 unterwegs!!.

== Möglichkeiten der Nutzung und Programmierung ==
===== Benutzung einer Firmware =====
Verschiedene Projekte betreiben die Entwicklung einer Firmware. Man kann die Firmware "einfach nur" flashen und benutzen oder sich auch aktiv an der Entwicklung beteiligen. Es gibt unter anderem folgende Projekte:
* AT-Befehle: Firmware, mit welcher das Modul über UART angesprochen wird.
* Micropython: Firmware, die das Ablaufen von Python Scripts ermöglicht
* NodeMCU: Firmware, die das Ablaufen von Lua-Scripts ermöglicht ([https://github.com/nodemcu/nodemcu-firmware Github])
* smartJS: Firmware, die das Ausführen von JavaScript erlaubt ([https://github.com/cesanta/smart.js Github])
* Arduino core for ESP8266 WiFi chip: Programmierumgebung & Firmware, die das Ausführen von C Programmen ermöglicht, im Stil der bekannten Arduino Plattform. [https://github.com/esp8266/Arduino Github - ink. Anleitung]
* ESP8266 Basic: Firmware, die das Ausführen von Basic Programmen und das Editieren über WLAN erlaubt [http://www.esp8266basic.com/]

===== Erstellen (Kompilieren) einer Firmware =====
Für die Erstellung einer individuellen Firmware gibt es zwei Möglichkeiten:
* Software Development Kit (SDK): Erstellen einer Firmware mit einer GCC-Toolchain
* Arduino IDE: Erstellen einer Firmware mit einer Arduino IDE
Projekte, die eine Firmware für das ESP8266 entwickeln (siehe vorheriger Abschnitt), benutzen eine dieser beiden Möglichkeiten.

=== Firmware flashen/updaten ===
Typischerweise wird eine kompilierte Firmware per UART-Bootloader des ESP8266-SoC auf einen Flash-Chip eines ESP8266-Moduls geladen. Von dort startet der ESP8266-SoC anschließend die Firmware.

[http://bbs.espressif.com/viewtopic.php?f=5&t=433 Flash Download Tool vom Hersteller] 
[http://github.com/themadinventor/esptool Python Tool zum Flashen (von Fredrik Ahlberg)] 
[http://github.com/3s1d/esp_prog Extension zum Tool von Fredrik Ahlberg] 
[http://www.mikrocontroller.net/topic/342240?page=2#3857075 Tool zum Flashen (von Christian Klippel)] 
[http://defcon-cc.dyndns.org/wiki/ESP8266#Update Anleitung, extern] 
[http://www.mikrocontroller.net/topic/342240?page=3#3810559 Anleitung, Forum]

Der Hersteller veröffentlich regelmässig [http://bbs.espressif.com/viewforum.php?f=5 Firmwareupdates] als Bestandteil des esp_iot_sdk. Die Firmware-Dateien befinden sich im Verzeichnis bin. Das Update wird beispielweise für Firmware 0.9.5 folgendermaßen durchgeführt: 
<pre>
python esptool.py --baud 9600 --port com6 write_flash 0x00000 boot_v1.2.bin 0x01000 at/user1.512.new.bin 0x3e000 blank.bin 0x7e000 blank.bin
</pre>

Abhängig von der Flashgröße muß man die Firmware ab Version 1.0.1 selbst compilieren. Siehe Diskussion [http://www.esp8266.com/viewtopic.php?p=16515 hier] und [http://bbs.espressif.com/viewtopic.php?f=16&t=400 hier].

== AT-Befehle für eine Firmware auf Basis des SDK-Beispiels "AT"==

Einstellen des Moduls als AP

Da wir nicht wissen, in welchem Modus sich das Modul gerade befindet, fragen wir diesen ab mit dem
Befehl AT+CWMODE? Das Modul antwortet mit

AT+CWMODE?<\r><\r><\n>+CWMODE:1<\r><\n>
<\r><\n>
OK<\r><\n>
In diesem Fall ist das Modul aktuell im Modus 1 ( Station) eingestellt. Also ändern wir den Modus auf 2 ( AP)
mit dem Befehl AT+CWMODE=2. Nach diesem Befehl ist ein Reset des Moduls erforderlich, damit die Änderung
sichtbar wird. Mit dem Befehl AT+RST führen wir diesen durch. Das Modul startet neu und die Stromaufnahme
steigt auf ca 80 mA. Das Modul ist jetzt als WLAN AP im Wireless Lan sichtbar.

Jetzt müssen wir noch einstellen, dass wir mehrere Verbindungen gleichzeitig haben wollen und den TCP Server starten und einstellen. Mit dem Befehl AT+CIPMUX=1 sagen wir dem Modul, dass wir mehrere Verbindungen haben wollen. Und mit dem Befehl AT+CIPSERVER=1,2526 starten wir den TCP Server und lassen ihn auf Port 2526 laufen. Sobald sich ein Client verbindet, sendet das Modul 'Link' + LF + CR. Beim Trennen einer Verbindung vom Client kommt 'Unlink' + LF + CR.

Ab hier können wir uns über einen TCP Socket auf Port 2526 mit dem Modul verbinden und Daten austauschen. Empfangene Daten werden folgendermaßen angezeigt. Gesendet wurde "Hallo Leute" + LF + CR.

<\r><\n>
+IPD,0,11:Hallo Leute<\r><\n>
OK<\r><\n>

+IPD kommt immer, 0 ist die erste Verbindung. Wenn 2 Geräte gleichzeitig eine Verbindung aufgebaut haben, steht dort eine 1. 11 Zeichen wurden empfangen, dann kommen die Daten.

Zum Senden von Daten vom Modul zum Client geht man folgenderweise vor. Erstmal sagen wir dem Modul, wieviele Daten wir an welche Verbindung schicken wollen. Mit dem Befehl AT+CIPSEND=0,5 z. B. sagen wir dem Modul wir möchten 5 Bytes an Verbindung 0 senden. Nach diesem Befehl werden die nächsten 5 Zeichen direkt an die Verbindung weitergereicht.
Sollte keine aktive Verbindung bestehen, sendet das Modul
AT+CIPSEND=0,5<\r><\r><\n>link is not<\r><\n>
ansonsten kommt
<\r><\n> >
und man kann Daten senden. Nach dem absenden der Daten 'Leute' + LF + CR sendet das Modul
Leute<\r><\r><\n>busy<\r><\n>
<\r><\n>
busy<\r><\n>
<\r><\n>
SEND OK<\r><\n>

Einstellen des Moduls als Station

== Software Development Kit (SDK) ==
Mit dem SDK können eigene Applikationen programmiert und die im SDK vorhandenen Beispiele "AT" und "IoT" verändert werden. Das SDK wird vom Hersteller zur Verfügung gestellt (Stand 25.10.2014). Passend zum SDK existiert eine virtuelle Maschine mit eingerichtetem gcc zum Kompilieren. Insbesondere der nun verfügbare gcc basiert auf einer Community-Entwicklung.

[http://bbs.espressif.com/viewforum.php?f=5&sid=3cf7540ab17805367e6a45d2c4682fc9 SDK0.9.2 + virtuelle Linuxmaschine mit eingerichtetem gcc]

[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Alternativlink für die virtuelle Maschine + Anleitung/HOWTO für das Setup sowie für das Kompilieren]

=== Anmerkung ===
Mit dem SDK wird der Mikrocontroller progammiert, der sich direkt auf dem ESP8266-SoC-Chip befindet. Dies ist nicht zu verwechseln mit Programmieranleitungen zur UART-Ansteuerung des ESP8266-SoC (meist mit AT-Firmware) mit einem anderen Mikrocontroller.

==Checkliste bei Problemen mit dem Modul/Compiler/SDK==
Bitte berücksichtige bei der Frage nach Hilfestellung zu Deinem Problem die folgende Checkliste.

'''Bei Problemen mit der AT-Firmware/UART-Ansteuerung mit Mikrocontroller'''
# Was nutzt Du für die Stromversorgung? (Ganz knapp benennen, so dass Rückschlüsse auf Spannung und Stromstärke möglich sind)
# Welche Firmware-Version verwendest Du und von woher hast Du sie?
# Welchen Mikrocontroller verwendest Du?
# Welche Baudrate verwendest Du?
# "Sieht" das Modul den AP, "sieht" der PC das Modul?
# Funktioniert ein Connect?
# Welche AT-Befehlssequenz verwendest Du und was antwortet das Modul?

'''Bei Problemen mit dem SDK/Compiler'''
# Benutzt Du die neuste, offizielle VM? (Diese ist ausgelegt für das neueste SDK)
# Benutzt Du das neueste, offizielle SDK? Welche Version benutzt Du? (Es werden regelmäßig Bugfixes und Erweiterungen eingepflegt)
# Kannst Du die SDK-Beispiele (IoT,AT) entsprechend der offiziellen Anleitung kompilieren, flashen und läuft es?

== Links ==
[https://en.wikipedia.org/wiki/ESP8266 ESP8266-Eintrag auf en.wikipedia.org] 
[http://www.esp8266.com/ ESP8266 Community Forum] 
[http://github.com/esp8266 ESP8266 Github mit Wiki und Source-Code Samples] 
[https://hackaday.com/tag/esp8266/ Hackaday Posts zu ESP8266] 
[http://espressif.com/en/products/esp8266/ ESP8266-Seite des Herstellers] 
[http://bbs.espressif.com/ ESP8266-Forum des Herstellers] 

[http://www.mikrocontroller.net/topic/348772 Topic neu im mikrocontroller.net-Forum] 

[http://www.mikrocontroller.net/topic/342240 Topic alt im mikrocontroller.net-Forum] 
[http://www.mikrocontroller.net/topic/342878 Sammelbestellungen im mikrocontroller.net-Forum]

[http://blog.thomasheldt.de/ Viele Projekte und Informationen zum ESP8266] 
[http://stefanfrings.de/wlan_io/ Projekt I/O Schnittstellen Modul mit WLAN]

=== Dokumente ===
[http://neilkolban.com/tech/esp8266/ Kolban’s book on the ESP8266] Sehr empfehlenswert! 
[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Anleitung/HOWTO für das Setup der virtuellen Maschine (SDK) sowie für das Kompilieren] 
[https://nurdspace.nl/ESP8266 Übersetztes Datenblatt] 
[http://www.electrodragon.com/w/Wi07c AT Instructions Set (English)] und [http://www.electrodragon.com/w/Wi07c#First_time_use_guide Anleitung zum Betrieb an einem Arduino (inkl. Code)] 
[http://thomaspfeifer.net/esp8266_wlan_seriell_modul_at_kommandos.htm Beschreibung der AT-Kommandos mit Beispielen] 
[http://www.mikrocontroller.net/attachment/229016/Espressif_IoT_AT____v0.1.5.906.pdf Espressif AT Instruction Set(Chinese)] 
[http://www.seeedstudio.com/document/pdf/ESP8266%20Specifications(Chinese).pdf ESP8266 Specifications(Chinese)] 
[http://nodemcu.readthedocs.org/en/dev/ NodeMCU Documentation] 
[https://cknodemcu.wordpress.com/2015/11/24/building-an-iot-node-for-less-than-15/ Building an IoT Node for less than 15$] (Paper, Kindle via Amazon)

===Daten===
[http://bbs.espressif.com/viewforum.php?f=5&sid=3cf7540ab17805367e6a45d2c4682fc9 SDK0.9.2 + virtuelle Linuxmaschine mit eingerichtetem gcc] 
[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Alternativlink für die virtuelle Maschine] 
[https://onedrive.live.com/#cid=C4DDF72E6EEA3826&id=C4DDF72E6EEA3826%21631 Dateien (Xplorer+SDK+PDF+etc.)] 
[http://www.mikrocontroller.net/attachment/230185/esp8266_config_v050.exe Config-Tool] 

=== Bezugsquellen ===
[http://espressif.com/en/espressif-systems/contact-us/ Offizieller Espressif Vertriebskanal] (Sample Purchase) 
[http://www.aliexpress.com/wholesale?SearchText=ESP8266 aliexpress.com] ~ 2€ 
[http://www.banggood.com/?zf=283997 banggood.com] ~ 3.50€ 
[http://www.ebay.de/ Ebay]
ab 3€ inkl. Versand, Einzelstückpreis: ESP-01/02/03/04/05 
(Suchbegriff: ESP8266, Option Artikelstandort: "Weltweit") 
(10 Stück ab 27 EUR inkl. Versand; Suchbegriff: 10pcs ESP8266) 
ab 3.20€ inkl. Versand, Einzelstückpreis: ESP-07/08/09/11 
[http://www.electrodragon.com/?s=esp8266&post_type=product electrodragon.com] ~ 3.50€ (zzgl. Versand) 
[https://ex-store.de/advanced_search_result.php?keywords=esp8266&x=0&y=0 eX-store.de] (ESP-01/02/03/05/07/12/13) ab 3.35€ (zzgl. Versand) 
[https://www.it-wns.de/themes/suche/index.php?suchekategorie=&sucheallgemein=esp8266 IT-WNS.de] (ESP-01/02/03/06/07/12E) je 3.99€ (zzgl. Versand) 
[http://www.seeedstudio.com/depot/WiFi-Serial-Transceiver-Module-w-ESP8266-p-1994.html seeedstudio.com] ~ 5.50€ 
[http://shop.in-circuit.de/index.php?cPath=21 In-Circuit.de] ESP-ADC DIL Modul mit ESP8266EX 9.90€ Einzelpreis 
[http://www.watterott.com/index.php?page=search&desc=off&sdesc=off&keywords=ESP8266 watterott.com] ab ~ 4€ (zzgl. Versand) 

==Anderes==
*[http://www.mikrocontroller.net/articles/ESP8266-CPCB PCB für Community-Modul (Vorschlag)]
*[http://fkainka.de/esp8266-in-der-arduino-ide/ ESP8266 mit Arduino IDE programmieren]
*[http://www.arduinesp.com Arduino IDE Integration (ab 1.6.x)]
*[https://cknodemcu.wordpress.com/ NodeMCU (Lua) Anwendungen]

== Einzelnachweise ==
<references />

--von [[axhieb]]

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]
[[Kategorie:Wlan]]

Entprellung

2016-03-13T07:48:44Z

Prx: Änderung 92324 von 184.168.27.152 (Diskussion) rückgängig gemacht.

== Problembeschreibung ==
Mechanische stromführende Komponenten wie [[Schalter]] und [[Taster]] neigen beim Ein- und Ausschalten zum sogenannten '''Prellen''', d.h sie schalten schnell mehrfach aus und ein, was durch mechanische Vibrationen des Schaltkontaktes verursacht wird, sofern sie nicht mit aufwändigen mechanischen Maßnahmen dagegen geschützt sind. Besonders die [[Drehgeber]] sind aufgrund der Raststellungen und der Bewegung des Bedieners dafür empfindlich. Auch optoelektronische Bauelemente und chemische Kontaktschalter, sowie Flüssigkeitsschalter haben das Problem.

Vereinfacht dargestellt, sieht eine von einem prellenden Schalter oder Taster geschaltete Spannung wie folgt aus:
[[Bild:Entprellen.png]]

Es existieren also mehrere kurze Einschaltimpules, welche bei Tastern als Mehrfachbefehl und bei Drehgebern als falsche Winkelbewegung interpretiert werden kann. Bei Schaltern wiederum, kommt es in der elektronischen Baugruppe zu mehreren Resets und Einschaltvorgängen, die unnötig Strom ziehen oder im schlechtesten Fall die Schaltung stressen oder beschädigen können. Wichtige Schalter und solche, die hohe Ströme führen sollen, werden dazu mit geeigneten Maßnahmen wie Redundanz, Stufenschaltkonzepten oder bei Gas- und Flüssigkeitschaltern durch elektrochemische Maßnahmen abgesichert. Bei einfachen Schaltern spart man sich dies jedoch.

Da es bei diesen einfachen, ungeschützten Schaltern keine sichere Möglichkeit gibt, diese Effekte zu vermeiden, muss das falsche Signal durch die Elektronik sinnvoll ausgewertet werden. Dafür gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Prellfreie Schalter===

Wie bereits angedeutet, hält die elektromechanische Industrie für Spezialanwendungen 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. Zudem sind sie nicht 100% sicher und fallen alterungsbedingt aus. Wo immer es geht, werden daher weitere Maßnahmen getroffen, ein Prellen zu unterdrücken.

===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. Dafür hat man aber den Vorteil, kurze Pulse, die offensichtlich keine Tastenbetätigung sein können sondern z. B. durch Einstreuungen hervorgerufen werden, einfach ausfiltern zu können.

=== 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>

Neuere Variante, die einer Taste folgende Funktionen erlaubt:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1753367
<syntaxhighlight lang="c">
- get_key_press()
- get_key_rpt()
- get_key_press() mit get_key_rpt()
- get_key_short() mit get_key_long()
- get_key_short() mit get_key_long_r() und get_key_rpt_l()
</syntaxhighlight>
Erweiterung für die Erkennung von zwei gleichzeitig gedrückten Tasten:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1753367
<syntaxhighlight lang="c">
- get_key_common()
</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.

Funktionsweisen der verschienden Modi anhand von Zeitstrahlen erklärt:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1844458

"Walkthrough" der verschiedenen Zuständer der Einzelnen Variablen anhand eines Tastendrucks (avrfreaks.net)
http://www.avrfreaks.net/comment/726676#comment-726676

===== 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. Die realen Grenzen dieser [[Hysterese]] müssen an die Applikation angepasst werden, da zu enge Grenzen sonst zu empfindlich gegenüber Störungen wären.

=== 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.

Das reale Signal muss dazu aber genügend langsam abgetastet werden, sodaß die Filterperiode die Prelldauer übersteigt, um zu verhindern, daß nicht inmitten einer passiven Phase eines Prellvorgangs ein 8fach 1 gesehen wird. Damit wird die Interetation vergleichsweise langsam.

== 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 kleinen 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/Pdf/ViewPdf?contentItemId=4324067 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]]

Multimeter

2016-01-10T23:58:15Z

Prx: Bluetooth

Ein Multimeter dient zur Messung verschiedener elektrischer Größen. Die Grundfunktionen sind Messung von Spannung, Strom, Widerstand. Darüber hinaus bieten viele Geräte noch weitere Funktionen wie Diodentest, Durchgangsprüfer, Kapazitätsmessung, Temperaturmessung, Frequenz und noch mehr.

== Wichtige Eigenschaften ==

Bei der Auswahl eines Multimeters sollte man sich zuerst einmal überlegen, was man damit machen möchte und welche Eigenschaften/Funktionen dafür benötigt werden. Neben der Funktionalität ist Sicherheit ein wichtiges Thema. Je nach Anwendungszweck sollte das Multimeter auch bestimmten Sicherheitsanforderungen genügen.

=== Sicherheit ===

=== Spannungsfestigkeit ===

Eine wesentliche Eigenschaft ist die Spannungfestigkeit des Geräts. Dazu gibt es üblicherweise eine Angabe der Nennspannung zusammen mit der [[Leiterbahnabstände#Überspannungskategorien|Überspannungskategorie]]. Diese Angabe bezieht sich nicht auf den Messbereich intern im Gerät, sondern auf die Stärke der Isolation nach außen.

Solange man nur mit Kleinspannung (< 50V AC bzw 120V DC) und kleinen Strömen arbeitet, sind die Sicherheitsanforderungen an das Multimeter nicht groß; da kann man eigentlich jedes Gerät einsetzen. So ziemlich alle Messgeräte sind für mindestens 300V Cat II spezifiziert, was auch für Messungen an Geräten, die über eine Steckdose am Niederspannungsnetz (230V) betrieben werden, ausreichend ist.

Für Messungen an Geräten, die fest mit dem Niederspannungsnetz verbunden sind, ist die Überspannungskategorie III notwendig. Kategorie IV braucht man für Messungen direkt an oder in der Nähe der Einspeisung in die elektrische Installation von Gebäuden, z.B. im bzw. vor dem Hauptverteiler.

Die Nennspannung bezieht sich dabei auf die Spannung Leiter gegen Erde. Einen guten Sicherheitsstandard bieten üblicherweise Geräte mit 600V Cat III/1000V Cat II; noch bessere Geräte haben 600V Cat IV/1000V Cat III oder sogar 1000V Cat IV.

=== Sicherung ===

Weiterhin ist die Sicherung bei der Strommessung ein sicherheitsrelevantes Bauteil. Viele preiswerte Multimeter haben eine einfache Glasrohrsicherung (5 x 20 mm) mit einer Nennspannung von 250V.

Diese Sicherungen haben nur eine begrenzte Abschaltfähigkeit, vor allem bei Messungen mit Gleichstrom und hoher Spannung bildet sich in so einer Sicherung ein Lichtbogen und die Sicherung trennt nicht. Das kann zur Zerstörung des Multimeters (Brand, Explosion) und ernsthaften Verletzungen führen.

Vor allem bei Strommessungen bei hoher Gleichspannung sollte darauf geachtet werden, dass im Multimeter eine Sicherung eingebaut ist, die ein Trennvermögen von 1000V und 20 kA hat. Diese Sicherungen haben meistens die Abmessungen 10 x 38 mm.

=== Analog oder Digital ===

Die große Masse an Multimetern heute ist digital, daher auch die weit verbreitete Abkürzung DMM ('''D'''igital'''m'''ulti'''m'''eter). Dennoch gibt es noch ein paar wenige, neue Analoggeräte. Wo liegen nun die Vor- und Nachteile?

==== Analoges Multimeter ====

Diese Geräte sind rein passiv aufgebaut und bestehen nur aus einem Drehspulmesswerk und vielen Widerständen zur Messbereichsumschaltung.

Vorteile:
* keine Stromversorgung nötig
* Intuitive Anzeige von Schwankungen des Messwerts, Trendanzeige
* unempfindlich gegen elektromagnetische Störungen

Nachteile:
* deutlich niedrigerer Innenwiderstand bei Spannungsmessungen
* Ablesefehler
* geringere Auflösung des Messwerts beim Ablesen
* keine automatische Bereichswahl möglich
* bedingt durch die Ablesefehler und mechanische Probleme nur eine begrenzte Genauigkeit erreichbar

==== Digitales Multimeter ====

Vorteile:
* Kein Ablesefehler
* Deutlich bessere Auflösung, dadurch mehr Genauigkeit möglich
* durch geeignete [[AD-Wandler]] sehr hohe [[Auflösung und Genauigkeit]] möglich
* sehr hoher Eingangswiderstand bei Spannungsmessungen
* hohe Empfindlichkeit durch Eingangsverstärker
* automatische Bereichswahl möglich

Nachteile:
* benötigt eine Stromversorgung
* keine intuitive Anzeige von Messwertschwankungen
* empfindlicher bezüglich Störeinkopplungen
* kann selber Störquelle bei extrem empfindlichen Messungen sein

Teilweise hat man heute erfolgreich einige Vorteile der analogen Anzeige in die digitalen Multimeter übernehmen können. So bieten einge Messgeräte eine quasianaloge Bandanzeige des Messwerts, welcher das Verhalten eines Zeigerinstruments brauchbar nachbildet.

==== Analoges Multimeter mit Messverstärker ====

Bei diesen Geräten wird versucht, einige Vorteile des DMM mit der Analoganzeige zu kombinieren.

Vorteile:
* Intuitive Anzeige von Schwankungen des Messwerts, Trendanzeige
* etwas unempfindlicher gegen elektromagnetische Störungen als digitale Multimeter
* sehr hoher Eingangswiderstand bei Spannungsmessungen
* hohe Empfindlichkeit durch Eingangsverstärker
* automatische Bereichswahl möglich

Nachteile:
* Ablesefehler
* geringere Auflösung des Messwerts beim Ablesen
* benötig eine Stromversorgung
* bedingt durch die Ablesefehler und mechanische Probleme nur eine begrenzte Genauigkeit erreichbar

Die meisten Anwender kaufen sich ein Digitalmultimeter mit einer guten Genauigkeit und nur für einfache Messungen, bei denen nicht die Genauigekeit sondern die intuitive Anzeige im Vordergrund steht, ein Analoggerät.

== Auflösung und Genauigkeit ==

Zur wichtigen Unterscheidung von [[Auflösung und Genauigkeit]] gibt es einen eigenen Artikel.

=== Auflösung ===

Beim Digitalmultimeter wird ein digitaler Wert angezeigt; der Zusammenhang zwischen Auflösung und Messbereich wird durch die Anzahl der Stellen bzw. die Anzahl der darstellbaren Zahlenwerte bestimmt. Ein 3-1/2-stelliges Display hat einen Bereich von 0 - 1999, der Dezimalpunkt kann dabei an jeder beliebigen Stelle sein. Man spricht hier auch von 2000 Schritten (engl. counts). Geräte mit 4 1/2 Stellen haben 20.000 Counts, das ist ein Anzeigeumfang von 0 - 19.999. Anzeigen mit 4.000 Counts werden manchmal auch als 3 3/4 Stellen bezeichnet, Geräte mit 6.000 Counts als 3 5/6 Stellen usw. 
(Die ''1/2'', ''3/4'' usw. sind dabei nicht als Brüche o.ä. zu verstehen, sondern als Angabe, welche Werte die linke, höchstwertigste Stelle des Geräts annehmen kann. So ist bei einer ''1/2''-Angabe für die linke Stelle eine 0 oder 1 möglich, bei ''3/4'' ein 0, 1, 2 oder 3, und bei ''5/6'' entsprechend 0, 1, …, 5)

Die Auflösung des Multimeters ist die kleinste Änderung im Messwert, die dargestellt werden kann. Ein Gerät mit z.B. 20.000 Counts hat im 2V-Messbereich eine Auflösung von 2V / 20000 = 0,1 mV.

=== Grundgenauigkeit ===

In den Datenblättern wird in der Regel die Grundgenauigkeit eines Multimeters angegeben. Damit wird die Genauigkeit der internen Referenz und des A/D-Wandler spezifiziert; meistens ist dieser Wert gleich der Genauigkeit bei DC-Spannungsmessung.

Oft wird der zu erwartende Meßfehler auch in der Form "% Reading + % Range" angegeben.
"% Reading" entspricht dem Meßfehler bezogen auf den aktuellen Meßwert, "% Range" entspricht dem Meßfehler bezogen auf den eingestellten Meßbereich. Die Abweichung. Beide Werte müssen addiert werden, um den Gesamtmeßfehler zu ergeben.

=== Toleranz ===

Wichtiger als die Grundgenauigkeit ist aber die Toleranz in den einzelnen Messbereichen. Üblich sind dabei Angaben in der Form +/- (0,2% + 3 Digits). Das bedeutet, dass die maximale Abweichung 0,2% vom angezeigten Messwert und zusätzlich 3 Digits beträgt. Ein Digit ist dabei die niedrigste Einheit in der Anzeige des Messwertes in dem aktuellen Messbereich. Bei einer angezeigten Spannung von z.B. 2,000V und einem Fehler von 3 Digits würde die tatsächliche Spannung daher in einem Bereich von 1,997V bis 2,003V liegen.

Üblicherweise hat ein Multimeter bei der DC-Spannungsmessung die höchste Genauigkeit. Bei der DC-Strommessung wird ein Shunt-Widerstand verwendet, dieser muss eine hohe Belastbarkeit und gleichzeitig einen niedrigen Temperaturkoeffizienten haben, was relativ teuer ist. Deshalb ist die Genauigkeit hier meistens deutlich schlechter als bei der Spannungsmessung.

Bei Wechselspannung bzw. -strom hängt die Genauigkeit vom verwendeten Messverfahren ab. Hier wird der Effektivwert angezeigt. Viele Multimeter messen die Signalamplitude oder einen Mittelwert und berechnen daraus den Effektivwert. Damit liefern diese Geräte nur bei einer exakten Sinusform einen genauen Messwert.

=== True-RMS, Crest-Faktor ===

Um bei anderen Kurvenformen einen genauen Effektivwert zu messen braucht man ein True-RMS Multimeter. Hier wird das Signal entweder analog quadriert oder digital mit einer hohen Frequenz abgetastet und ein quadratischer Mittelwert berechnet. Damit erhält man theoretisch für beliebige Signalformen einen genauen Messwert, allerdings gilt das nur in einem bestimmten Frequenzbereich. Im Datenblatt wird meistens auch ein maximaler Crest-Faktor angegeben, das ist das maximale Verhältnis zwischen dem Spitzenwert und dem Effektivwert, beim dem die Genauigkeit innerhalb der spezifizierten Toleranz liegt.

== Weitere Funktionen ==

=== Durchgangsprüfer ===

Diese Funktion wird in der Elektronikpraxis sehr oft benötigt, demzufolge sollte das Multimeter sie haben. Wichtig ist, daß ein Pieper zur Signalisierung verfügbar ist und dieser ohne nennenswerte Verzögerung reagiert. Einige Multimeter sind da recht langsam, eine "Denkpause" von einer Sekunde ist da sehr störend wenn man viele Verbindungen durchmessen will.

=== Diodentest ===

Auch eine sehr nützliche Funktion, auf die man nicht verzichten sollte.

=== Widerstandsmessung ===

Diese ist in vielen Multimetern vorhanden und für den Hobbybastler auch sehr wichtig.

=== Temperatursensor ===

Viele Multimeter werden mit einem [[Temperatursensor]] geliefert, dabei handelt es sich fast immer um ein Thermoelement. Damit kann man relativ einfach Temperaturen zwischen -50°C bis 350°C messen.

=== Schnittstelle ===

Einige Multimeter bieten eine Schnittstelle zum PC, damit können sie als per Software steuerbares Multimeter bzw. Datenschreiber verwendet werden. Diese Schnittstelle ist per [[Optokoppler]] [[Galvanische Trennung|galvanisch getrennt]], damit kann man gefahrlos messen. Will man das Multimeter per Mikrocontroller steuern, so sind Typen mit [[RS232]] Anschluß den Typen mit [[USB]] vorzuziehen.

Ebenso gibt es Geräte, die per Bluetooth mit einem Smartphone kommunizieren können.

Ältere Tischmultimeter, wie sie in der Industrie benutzt werden, besitzen hingegen stattdessen meist ein GPIB-Interface. Dabei handelt es sich um einen Messgerätebus von Hewlet Packard (heute Agilent), der zwar eine eigene Interfacekarte im PC benötigt (billig als ISA zu bekommen, relativ teuer als PCI; auch USB-GPIB ist möglich), aber recht universell für verschiedenste Messgeräte genutzt werden kann.

=== Transistortester ===

Damit kann man die Stromverstärkung eines Transistors bei kleinen Strömen messen. Bisweilen ganz nett, praktisch wird sie aber eher wenig gebraucht.

=== Messung von Induktivität, Kapazität und Frequenz ===

Diese Messmöglichkeiten sind in verschiedenster Kombination verfügbar, aber eher als nette Zugabe anzusehen. Sie erreicht meist keine sonderlich hohe Genauigkeit. Vor allem die Frequenzmessung ist eher eine Schätzung und hat mit einem echten Frequenzmesser wenig gemeinsam. Wer ernsthaft diese Größen messen will, kauft sich besser ein speziell dafür gebautes Messgerät. Zur groben Messung der Parameter sind die Funktionen ausreichend.

=== Beleuchtung ===

In bestimmten Situationen kann eine Beleuchtung der Anzeige recht nützlich sein, da aus Stromspargründen die Anzeige immer ein LCD ist. Die große Masse der Anwender braucht sie jedoch nicht.

=== Messwertspeicher ===

Viele Multimeter können auf Knopfdruck den Messwert einfrieren. Das ist dann hilfreich, wenn man an einem schwer zugänglichen Ort eine Messung machen muss und dabei das Display nicht ablesen kann, typisch an großen Maschinen und Anlagen.

=== Auto Range ===

Die meisten besseren Multimeter verfügen über eine automatische Messbereichswahl, d.h. das Multimeter stellt automatisch den optimalen Messbereich ein. Das hat Vor- und Nachteile.

Vorteile
* einfache Messung unbekannter Größen

Nachteile
* Durch die meist nötige Umschaltung des Messbereichs und Mehrfachmessung durch das Multimeter verlängert sich die Messzeit, welche man bei bestimmten Messungen nicht gebrauchen kann. Ausserdem schwankt dadurch die Anzeige zusätzlich, was das Ablesen bei sich ändernden Messwerten erschwert.

Ein Multimeter sollte auf jeden Fall die Möglichkeit bieten, die Auto Range Funktion abzuschalten.

== Vergleichstabelle Multimeter ==

In den folgende Tabellen werden wichtige technischen Daten einiger aktueller Multimeter zusammengestellt. Um die Übersichtlichkeit zu erhöhen, werden die Geräte in drei Kategorien eingeteilt.

Bei den Sicherungen ist entweder die Baugröße oder die Nennspannung und Abschaltstrom angegeben; wenn das Gerät mehrere Sicherungen enthält, dann kommt zuerst der Wert für den mA Messbereich und danach die Sicherung für den A Messbereich.

=== Einsteigergeräte ===

Das sind preiswerte Geräte, mit denen viele Messaufgaben durchgeführt werden können, wenn keine sehr hohen Anforderungen an Genauigkeit gestellt werden. Für Einsteiger und Fortgeschrittene findet sich im Bereich unter 50 Euro immer ein Gerät, das den Ansprüchen gerecht wird. '''Will man Messungen am 230V-Netz durchführen, sollte man auf keinen Fall Billigstgeräte aus der Ramschkiste verwenden sondern auf qualitativ hochwertige Ware zurückgreifen und.'''

{| border="1" class="wikitable sortable" id="multimeter"
|-
!Hersteller || Bezeichnung ||Preis [EUR] || Counts || Grundgenauigkeit [%] || Messbereich DC V || Spannungsklasse ||Sicherung
|-
|Keysight (vorm. Agilent)
|U1231A (1)
|122
|6.000
|0,5
|Ja
|600V Cat III
|10x38 mm
|-
|Amprobe
|30XR-A
|70
|2.000
|1
|600V
|300V Cat III, 600V Cat II
|10x38 mm
|-
|Amprobe
|33XR-A
|95
|4.000
|0,7
|1000V
|600V Cat III, 1000V Cat II
|6,3x32 mm / 10x38 mm
|-
|Benning
|MM 1
|70
|3.200
|0,5
|600V
|600V Cat III
|k. A.
|-
|Benning
|MM 2
|85
|2.000
|0,5
|1000V
|600V Cat III
|6,35x32 mm / 6,35x32 mm
|-
|Benning
|MM 3
|105
|2.000
|0,5
|600V
|300V Cat III
|6,35x32 mm / 6,35x32 mm
|-
|Benning
|MM 4
|120
|4.200
|0,5
|600V
|300V Cat III
|k. A.
|-
|Peaktech
|1070
|10
|2.000
|0,5
|250V
|250V Cat II
|k. A.
|-
|Peaktech
|2010
|25
|2.000
|0,5
|1000V
|600V Cat III, 1000V Cat II
|k. A.
|-
|UNI-T
|UT61E
|62
|22.000
|0,1
|600V
|300V Cat III, 600V Cat II
|6,3x32 mm / 10x38 mm
|}
1) keine Strommessung

=== Mittelklasse-Geräte===

Diese Geräte haben alle eine Grundgenauigkeit besser als 0,5 und sind besser ausgestattet als die Einsteigerklasse. Die Spannungsfestigkeit ist mindestens 600V Cat III.

{| border="1" class="wikitable sortable" id="multimeter"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Counts
!Grundgenauigkeit [%]
!TRMS
!Spannungsklasse
!Sicherung
|-
|Amprobe
|34XR-A
|125
|4.000
|0,5
|Ja
|600V Cat III, 1000V Cat II
|6,3x32 mm / 10x38 mm
|-
|Amprobe
|37XR-A
|140
|10.000
|0,1
|Ja
|600V Cat III, 1000V Cat II
|6,3x32 mm / 10x38 mm
|-
|Amprobe
|38XR-A
|165
|10.000
|0,25
|Ja
|600V Cat IV, 1000V Cat III
|6,3x32 mm / 10x38 mm
|-
|Keysight (vorm. Agilent)
|U1241B
|215
|10.000
|0,09
|Ja
|600V Cat IV, 1000V Cat III
|10x35 mm / 10x38 mm
|-
|Keysight (vorm. Agilent)
|U1232A
|166
|6.000
|0,5
|Ja
|600V Cat III
|10x38 mm
|-
|Benning
|MM 7-1
|220
|6.000
|0,08
|Ja
|600V Cat IV, 1000V Cat III
|10x35 mm / 10x38 mm
|-
|Benning
|MM 10
|165
|6.000
|0,5
|Ja
|600V Cat IV, 1000V Cat III
|6,35x32 mm
|-
|Benning
|MM 11
|350
|20.000
|0,08
|Ja
|600V Cat IV, 1000V Cat III
|10x35 mm / 10x38 mm
|-
|Fluke
|114
|145
|6.000
|0,5
|Ja
|600V Cat III
| -
|-
|Fluke
|115
|170
|6.000
|0,5
|Ja
|600V Cat III
|1000V / 15kA
|-
|Fluke
|117
|200
|6.000
|0,5
|Ja
|600V Cat III
|1000V / 15kA
|-
|Fluke
|77 IV
|400
|6000
|0,3
|Ja
|600V Cat IV, 1000V Cat III
|k. A.
|-
|Fluke
|175
|225
|6000
|0,15
|Ja
|600V Cat IV, 1000V Cat III
|k. A.
|-
|Fluke
|177
|270
|6000
|0,09
|Ja
|600V Cat IV, 1000V Cat III
|k. A.
|-
|Fluke
|179
|300
|6000
|0,09
|Ja
|600V Cat IV, 1000V Cat III
|k. A.
|-
|Peaktech
|P3320
|55
|6.000
|0,5
|Ja
|600V Cat III, 1000V Cat II
|k. A.
|-
|Peaktech
|P3360
|85
|40.000
|0,06
|Ja
|600V Cat IV, 1000V Cat III
|6,3x32 mm / 10x38 mm
|-
|Peaktech
|P3380
|190
|22.000
|0,12
|Ja
|600V Cat IV, 1000V Cat III
|k. A.
|-
|UNI-T
|UT71B
|97
|20.000
|0,08
|Ja
|600V Cat IV, 1000V Cat III
|5x20 mm
|-
|UNI-T
|UT71C
|120
|40.000
|0,05
|Ja
|600V Cat IV, 1000V Cat III
|5x20 mm
|}

=== Oberklasse-Geräte ===

Diese Geräte haben eine Grundgenauigkeit von mindestens 0,1 und bieten einen sehr hohen Sicherheitsstandard. Die Spannungsfestigkeit ist mindestens 1000V Cat III. Diese Geräte haben Zusatzfunktionen wie z.B. parametrierbare Tiefpassfilter, Messung der Grundfrequenz an Wechselrichtern, etc. Sie sind meist nur für Profis interessant und bezahlbar.

{| border="1" class="wikitable sortable" id="multimeter"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Counts
!Grundgenauigkeit [%]
!Bandbreite (TRMS)/kHz
!Zusatzfunktionen
|-
|Keysight
|U1251A/B
|350
|50.000
|0,025
|30
|
|-
|Fluke
|83 V
|380
|6.000
|0,1
|
|
|-
|Fluke
|87 V
|450
|20.000
|0,05
|
|
|-
|Gossen Metrawatt
|METRAHIT PRO
|360
|10.000
|0,05
|10
|
|-
|Gossen Metrawatt
|METRAHIT Tech
|360
|12.000
|0,05
|10
|
|-
|Gossen Metrawatt
|METRAHIT ENERGY
|810
|60.000
|0,05
|10
|
|-
|Gossen Metrawatt
|METRAHIT 30M
|1046
|1.200.000
|0,05
|10
|
|-
|Gossen Metrawatt
|METRAHIT X-TRA
|360
|12.000
|0,05
|10
|
|-
|Gossen Metrawatt
|METRAHIT OUTDOOR
|549
|12.000
|0,05
|10
| IP65
|-
|Metrix
|MTX 3281
|ab 375,-
|100.000
|0,1%
|50
|versch. Ausführungen: Com, BT, Temp ect.
|-
|Metrix
|MTX 3282
|ab 500,-
|100.000
|0,03%
|100
|versch. Ausführungen: Com, BT, Temp ect.
|-
|Metrix
|MTX 3283
|ab 560,-
|100.000
|0,02%
|200
|versch. Ausführungen: Com, BT, Temp ect.
|}

=== Tischmultimeter ===

Tischmultimeter bieten eine sehr hohe Genauigkeit und eine hohe Geschwindigkeit. Für genaue Widerstandsmessung gibt es eine [http://de.wikipedia.org/wiki/Vierdrahtmessung Vierdrahtmessung],
wodurch sich der Widerstand der Messleitungen nicht auf das Ergebnis auswirkt. Auf Grund ihrer sehr hohen Genauigkeit wird diese nicht in Prozent sondern ppm angegeben, u.a. weil niemand die vielen Nullen nach dem Komma zählen will.

1ppm = 0,0001% (engl. one part per million, der millionste Teil)

{| border="1" class="wikitable sortable" id="multimeter"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Counts
!Grundgenauigkeit [ppm]
!TRMS
|-
|Keysight
|34461A
|1050
|1.200.000
|19 (über 24 h)
|Ja
|-
|Keysight
|34401A
|985
|1.000.000
|15
|Ja
|-
|Keithley
|2000
|1050
|1.000.000
|20
|Ja
|-
|Picotest
|M3500A
|885
|1.000.000
|35
|Ja
|}

== Siehe auch ==

*[http://www.mikrocontroller.net/topic/204156#new Forumsbeitrag]: Welches Multimeter?
*[http://www.sprut.de/electronic/mess/spannung.htm Spannungsnormal - Betrachtungen zur Messgenauigkeit]
[[Kategorie:Grundlagen]]

Raspberry Pi Einführung

2015-02-02T15:10:41Z

Prx: /* Errata */

''von Robert Knauer''

{{Wettbewerb Header}}

'''Wichtig''': ''Alle Informationen und Anleitungen in diesem Artikel beziehen sich auf das Model B mit erweitertem Arbeitsspeicher.''

[[Datei:Raspberry_Pi.jpg|thumb|Der Raspberry Pi]]
Der '''Raspberry Pi''' ist ein Einplatinen-Computer im Kreditkarten-Format mit einem SoC (System-on-a-Chip) von Broadcom. Dieser verfügt über folgende Eigenschaften:
* eine 700MHz ARMv6-CPU
* eine Broadcom VideoCore IV GPU
* 512 MB Arbeitsspeicher
Außerdem kann der Raspberry Pi über folgende Schnittstellen mit der Außenwelt kommunizieren:
* 2 USB 2.0 Host-Anschlüsse
* einen Composite Video-Ausgang
* einen HDMI-Ausgang (Video+Audio)
* einen 3,5mm Klinke-Audio-Ausgang
* einen SD-/MMC-Karten-Slot (Unterstützung für SDIO und SDHC)
* einen Ethernet-Port (10/100 MBit)
* 21 GPIO-Pins, teilweise gedacht als [[UART]], [[SPI]] und [[I2C]]
Die Energieversorgung wird über einen microUSB-Anschluss gewährleistet. Man sollte jedoch darauf achten, dass der USB-Anschluss, über den man den Raspberry Pi mit Energie versorgt mindestens 700 mA liefern kann, da in der USB 2.0 Spezifikation nur 500 mA vorgesehen sind. In diesem Artikel wird noch darauf eingegangen, wie man sich selbst ein entsprechendes Netzteil bauen kann, alternativ funktioniert auch ein entsprechend starkes USB-Ladegerät in Verbindung mit einem USB-A auf microUSB-B Kabel. (siehe [[#Stromversorgung]])

Um diese umfangreichen Möglichkeiten zu nutzen muss man mit einem anderen Computer ein Betriebssystem auf die SD-Karte laden, das dann vom Raspberry Pi gebootet wird. Am naheliegendsten ist hier natürlich Linux (Raspbian, Fedora, Debian und Arch Linux sind offiziell unterstützt), aber auch Plan 9 wurde schon auf dem kleinen Computer [http://www.heise.de/open/meldung/Plan-9-laeuft-auf-dem-Raspberry-1761392.html zum Laufen gebracht].

In diesem Artikel soll Schritt für Schritt der Weg vom Anschließen des Computers über das Einrichten von Arch Linux ARM bis zum Verwenden der verschiedenen Schnittstellen des Raspberry Pi beschrieben werden.

== Bezugsquellen & Zubehör ==
Der Raspberry Pi kann über verschiedene Quellen bezogen werden. Wichtig ist darauf zu achten, dass man das Model B mit 512 MB Arbeitsspeicher bestellt, da alle Anleitungen in diesem Artikel nur damit getestet sind und unter anderen Modellen eventuell nicht funktionieren. Ein in Deutschland ziemlich bekannter Elektronik-Versand, bei dem man den Raspberry Pi bestellen kann, ist Pollin, dort ist er zur Zeit für 38,95 € erhältlich. (Bestell-Nr.: 701 697, Stand: 17.06.2013)

Doch neben dem eigentlichen Computer braucht man natürlich noch etwas Zubehör, wenn man es nicht eh schon zu Hause rumliegen hat:
* ein Netzteil, das 5V bei mindestens 700 mA auf einem microUSB-Stecker liefert (siehe [[Raspberry Pi#Stromversorgung]])
* eine SD(HC)-Speicherkarte
* einen SD(HC)-Cardreader an einem anderen Computer
* ein RJ45-Netzwerkkabel
* ein Ethernet-Netzwerk mit Zugang zum Internet
Mit diesem Zubehör kann man nur über SSH zugreifen, wenn man direkt am Raspberry Pi arbeiten will und später evtl. auch eine grafische Oberfläche einrichten will braucht man noch folgendes:
* ein HDMI-Kabel und einen Fernseher bzw. Monitor mit HDMI-Eingang '''oder'''
* ein Composite-Kabel und einen Fernseher mit entsprechendem Video-Eingang
* eine USB-Tastatur
* eine USB-Maus (für eine grafische Oberfläche)
* evtl. einen aktiven USB-Hub, wenn die Ports des Raspberry Pi nicht genug Leistung für Maus und Tastatur liefern können

== Das Betriebssystem ==
Als Betriebssystem für die Anleitungen in diesem Artikel wird [http://archlinuxarm.org/ Arch Linux ARM] verwendet, das Meiste funktioniert jedoch auch unter anderen Linux-Distributionen und alles andere zumindest mit kleinen Anpassungen.
Es basiert auf den Prinzipien und teilweise auch der Software von [https://www.archlinux.org/ Arch Linux], hat aber vollständig unabhängige Paketquellen, in denen nur für ARM kompilierte Software verfügbar ist.

Arch Linux ist ein gutes Betriebssystem für einen Computer wie den Raspberry Pi, da es am Anfang sehr leichtgewichtig ist und vorerst keine grafische Oberfläche installiert hat (was gut ist wenn man den Raspberry Pi als Server verwenden will). Andererseits kann aber auch problemlos eine grafische Oberfläche nachinstalliert werden, wenn man den Raspberry Pi als Desktop-Computer, HTPC oder ähnliches verwenden will.

Man muss jedoch auch sagen, dass Arch Linux kein Betriebssystem für jemanden ist, der Linux noch nie verwendet hat. Man sollte schon etwas Erfahrung mit dem Arbeiten auf der Konsole haben, da grundlegende Dinge über Linux hier nicht erklärt werden.
Außerdem ist es teilweise notwendig, sich selbst weiterführende Informationen zu Arch Linux anzusehen, die in diesem Artikel verlinkt werden.

== Anschluss & Installation ==
Nun muss man zuerst alles anschließen. Die Netzwerk-Buchse wird über das Netzwerk-Kabel mit dem Ethernet-Netzwerk verbunden. Hier ist wichtig, dass in dem Netzwerk ein DHCP-Server läuft (also IP-Adressen automatisch bezogen werden können) und Zugriff zum Internet möglich ist. Wenn man sich für die Variante mit eigenem Bildschirm entschieden hat muss man außerdem die HDMI-Buchse mit dem Fernseher oder Monitor bzw. den Composite-Ausgang mit dem Fernseher verbinden und Tastatur und Maus über USB anschließen.
Dann folgt die Installation von Arch Linux ARM auf die SD-Karte.

Arch Linux ARM für Raspberry Pi kann man über folgende Links downloaden:
* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-06-06/archlinux-hf-2013-06-06.zip.torrent Torrent-Download von Arch Linux ARM 2013-02-11]
* [http://downloads.raspberrypi.org/download.php?file=/images/archlinuxarm/archlinux-hf-2013-06-06/archlinux-hf-2013-06-06.zip HTTP-Download von Arch Linux ARM 2013-06-06]
Wenn der etwa 185 MB große Download abgeschlossen ist und man über HTTP gedownloadet hat sollte man zuerst die Checksum überprüfen.
Eine Anleitung dazu findet befindet sich auf der Downloadseite.
* SHA-1: 706037373bbb33ab6fb0af147a6e795bd04f1503
Nachdem man das getan oder falls man über Torrent gedownloadet hat (dann passiert das automatisch) kann man das zip-Archiv entpacken.

Man erhält eine etwa 2,0 GB große Datei namens archlinux-hf-2013-06-06.img. Diese muss man nun auf die SD-Karte bringen. Unter Linux funktioniert das mit dem kleinen Programm dd, das in den GNU coreutils enthalten ist und damit auf fast jedem System vorinstalliert sein sollte. Dazu gibt man folgendes in die Konsole ein (als root, /dev/sdX durch den Pfad zur Gerätedatei der SD-Karte ersetzen, Pfad der img-Datei anpassen):
* dd if=/pfad/zur/archlinux-hf-2013-02-11.img bs=1M of=/dev/sdX
Unter Windows kann man dafür [https://launchpad.net/win32-image-writer Image Writer for Windows] benutzen.

Danach entfernt man die Karte aus dem Cardreader des Computers und setzt sie in den Raspberry Pi ein. Dann verbindet man die Stromversorgung, indem man den microUSB-Stecker des Netzteils in die entsprechende Buchse auf der Platine steckt.

== Der erste Start ==
Wenn man ein Display angeschlossen hat, erscheint nach ein paar Sekunden ein Login-Prompt auf dem Bildschirm. Als Username gibt man ''root'' ein, wenn man dann nach dem Passwort gefragt wird gibt man wieder ''root'' ein.

Wenn man kein Display angeschlossen hat, muss man die IP-Adresse, die der Raspberry Pi sich vom DHCP-Server geholt hat, herausfinden. Wenn der DSL-Router diesen Dienst bereitstellt, kann man meistens auf der Web-Oberfläche eine Liste der verteilten IP-Adressen sehen. Alternativ kann man auch mit ''nmap'' einen Netzwerk-Scan machen, der die IP-Adressen von allen Computern im Netzwerk anzeigt. Das funktioniert unter Linux, indem man '''nmap -sn SUBNETZ''' im Terminal eingibt. Davor ersetzt man SUBNETZ durch das Subnetz, in dem auch der Raspberry Pi ist, in [https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR-Notation]. Wenn man z.B. in einem Netz ist, in dem IP-Adressen von ''192.168.1.0'' bis ''192.168.1.255'' verteilt werden, muss man
''192.168.1.0/24'' verwenden.

Nachdem man die IP-Adresse herausgefunden hat, verbindet man sich per SSH zu ihr und loggt sich als root, Passwort root ein. Unter Linux funktioniert das mit
* ssh root@IP-ADRESSE
Unter Windows verwendet man am besten [http://www.putty.org/ PuTTY].

Egal für welche Möglichkeit man sich entschieden hat, sitzt man jetzt vor einer root-Shell des Raspberry Pi, erkennbar am Shell-Prompt '''[root@alarmpi ~]#'''.

== Konfiguration ==
Nun geht es an die Konfiguration von Arch Linux ARM, diese erfolgt vollständig über das Editieren von Dateien auf der Konsole.

=== Lokalisierung ===
Man editiert die Datei /etc/locale.gen:
* nano /etc/locale.gen
und entfernt die Raute vor der Zeile mit der entsprechenden Sprache-Land-Kodierungs-Kombination, also z.B. vor '''de_DE.UTF-8 UTF-8''' für Deutschland.
Danach speichert man mit Strg+O -> Enter und Strg+X und erstellt die Lokalisierung neu:
* locale-gen
Danach editiert man die Datei /etc/locale.conf:
* nano /etc/locale.conf
Man ändert '''LANG=en_US.UTF-8''' zur entsprechenden Sprache, also z.B. '''LANG=de_DE.utf8''' und speichert mit Strg+O -> Enter und Strg+X.

=== Tastatur-Layout ===
Um das Tastatur-Layout auf der Konsole anzupassen, muss man die Datei /etc/vconsole.conf ändern:
* nano /etc/vconsole.conf
Man ändert '''KEYMAP=us''' zu z.B. '''KEYMAP=de-latin1''' für QWERTZ und speichert wieder mit Strg+O -> Enter und Strg+X.

=== Zeitzone ===
Um die Zeitzone zu ändern muss man einen Symlink zu /etc/localtime erstellen:
* ln -sf /usr/share/zoneinfo/ZEITZONE /etc/localtime
Also für Deutschland (Europe/Berlin):
* ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Um alle Änderungen zu übernehmen startet man den Raspberry Pi am besten neu:
* reboot
Wenn man per SSH verbunden war, wird die Verbindung geschlossen und man muss sich neu verbinden.

== Aktualisierung ==
Da das Image, das man auf die SD-Karte geschrieben hat, schon etwas veraltet sein kann, sollte man das System über die Paketverwaltung aktualisieren:
* pacman -Syu
Dieses Kommando downloadet die Datenbanken und alle neuen Pakete und installiert diese anschließend.

Dieses Kommando sollte man jede Woche mindestens einmal ausführen, um das System aktuell zu halten. Arch Linux ARM muss nie neu installiert werden, allein durch dieses Kommando wird es immer aktuell gehalten.

== Dateisystem vergrößern ==
Da das Image darauf ausgelegt ist, dass es auch auf nur 2GB großen SD-Karten geschrieben werden kann, ist auch das Haupt-Dateisystem etwa 2GB groß, selbst wenn man Arch Linux ARM auf eine größere SD-Karte geschrieben hat.

Doch das ist kein großes Problem. Um das Haupt-Dateisystem so zu vergrößern, dass es die gesamte SD-Karte ausfüllt, muss man den Raspberry Pi ausschalten und die SD-Karte in einen Cardreader an einem Linux-PC einsetzen.

In der folgenden Anleitung wird angenommen, dass die SD-Karte unter /dev/sdb und das Haupt-Dateisystem der SD-Karte unter /dev/sdb2 ist. Wenn das nicht zutrifft muss man die Pfade entsprechend ändern.

Zuerst muss man sicherstellen, dass keines der Dateisysteme gemountet ist:
* umount /dev/sdb1
* umount /dev/sdb2
Danach muss man einen Dateisystem-Test durchführen:
* fsck -n /dev/sdb2
... und das Journal entfernen:
* tune2fs -O "^has_journal" /dev/sdb2
Dann bearbeitet man die Partitionstabelle mit fdisk:
* fdisk /dev/sdb
Man kommt in eine Kommandozeile, in der man folgendes nacheinander eingibt:
* d
* 2
* n
* p
* 2
* <ohne Eingabe Enter>
* <ohne Eingabe Enter>
* w
Dadurch wird die zweite Partition gelöscht und neu angelegt, und zwar über den gesamten freien Bereich der SD-Karte.
Dann muss man wieder einen Dateisystem-Test durchführen:
* e2fsck -f /dev/sdb2
... und das Dateisystem vergrößern:
* resize2fs /dev/sdb2
Jetzt erfolgt erneut ein Dateisystem-Test:
* fsck -n /dev/sdb2
... und die Wiederherstellung des Journals:
* tune2fs -j /dev/sdb2
Jetzt kann man die SD-Karte aus dem Cardreader nehmen, in den Raspberry Pi einsetzen und ihn starten.

Wenn alles glatt gelaufen ist bootet der Raspberry Pi ganz normal und man hat plötzlich mehr Speicherplatz zur Verfügung. Aus
<pre># df -h /
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 1,8G 805M 869M 49% /</pre>
wird bei einer 16GB SD-Karte zum Beispiel:
<pre># df -h /
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 15G 905M 14G 7% /</pre>

''Dieser Abschnitt basiert auf einer [http://www.howtoforge.de/anleitung/wie-man-die-grose-von-ext3-partitionen-anpasst-ohne-daten-zu-verlieren/ Anleitung zum Verändern der Größe von ext3-Partitionen von HowtoForge].''

== Paketverwaltung ==
Arch Linux ARM setzt pacman als Paket-Manager ein. Das erste Kommando, das zur System-Aktualisierung, wurde schon in einem anderen Kapitel genannt:
* pacman -Syu
Dieses setzt sich aus zwei Teil-Kommandos zusammen:
* pacman -Sy
zum Downloaden der Paket-Datenbanken und
* pacman -Su
zum Downloaden und Installieren der neuen Pakete.

Um ein neues Paket zu installieren verwendet man folgendes Kommando:
* pacman -S PAKETNAME
oder um davor noch die Datenbanken zu aktualisieren:
* pacman -Sy PAKETNAME

Um ein Paket zu löschen verwendet man:
* pacman -R PAKETNAME
oder um alle danach nicht mehr benötigten Abhängigkeiten mit zu löschen:
* pacman -Rs PAKETNAME

Es gibt noch viele weitere Kommandos, z.B. zum Suchen von Paketen, Anzeigen von Informationen, Auflisten von Dateien. Einen Überblick findet man im [https://wiki.archlinux.de/title/Pacman Arch Linux Wiki] oder eine Auflistung aller Optionen in der Manpage:
* man pacman
Nach der Installation sind standardmäßig alle fünf Paketquellen von Arch Linux ARM aktiviert, eine Liste aller enthaltenen Pakete findet man [http://archlinuxarm.org/packages auf der Website].

== Datensicherung ==
Um neue Betriebssysteme auf dem Raspberry Pi auszuprobieren braucht man nicht zehn verschiedene SD-Karten, die man immer wechselt. Es reicht eine SD-Karte, von der man ein Backup macht, bevor man ein neues Betriebssystem aufspielt. Aber auch wenn man das nicht vorhat macht sich eine Datensicherung immer gut.

Dafür gibt es unter Linux verschiedene Möglichkeiten, einmal natürlich das Tool dd, mit dem man den gesamten Inhalt der SD-Karte Byte für Byte auf ein anderes Medium, z.B. die Festplatte, kopieren kann. Hier werden aber auch eigentlich leere Teile der SD-Karte mit gesichert, wodurch bei einer 16GB SD-Karte auch (unkomprimiert) ein 16GB-Backup entsteht, egal wie viel Daten man nun eigentlich auf der Karte gespeichert hat. Abhilfe schafft partclone, das die einzelnen Partitionen sichert, und zwar auch nur die wirklich verwendeten Teile. Die Handhabung ist etwas komplexer als bei dd, eine gute Anleitung und ein ausführlicherer Vergleich der beiden Tools ist auf [http://www.bitblokes.de/2013/03/sd-karte-des-raspberry-pi-sichern-dd-oder-partclone/ bitblokes.de] zu finden.

Unter Windows gibt es das Tool [http://sourceforge.net/projects/win32diskimager/ Win32DiskImager] welches komplette bitweise Images (von SD-Karten und USB-Medien) lesen und schreiben kann.

== SoC-Konfiguration ==
Generelle Einstellungen für den SoC, die noch vor dem Starten des Betriebssystems geladen werden, kann man in der Datei '''/boot/config.txt''' ändern.

Hier ist es z.B. möglich, Parameter für die Video-Ausgabe zu setzen, die Speicher-Aufteilung zwischen CPU und GPU zu ändern oder die CPU zu übertakten. Generell sollte man eher vorsichtig mit diesen Optionen umgehen, da sie bei falscher Verwendung auch mal dazu führen können, dass das Betriebssystem nicht mehr bootet oder das System instabil wird.

Eine genaue Auflistung der möglichen Konfigurations-Optionen findet man auf [http://elinux.org/RPiconfig eLinux.org].

== Die GPIO-Schnittstelle ==
[[Datei:Raspberry_Pi_GPIO.jpg|thumb|Die GPIO-Schnittstelle (P1-Anschluss)]]
Für Bastler besonders interessant ist die GPIO-Schnittstelle, diese kann man über verschiedene Wege ansteuern.
=== Belegung der Schnittstelle ===
'''Wichtig:''' Alle GPIO-Pins haben einen Pegel von 3,3V und sind '''nicht''' kompatibel zu 5V! Wenn man versucht, 5V anzuschließen, kann das zur Zerstörung des Raspberry Pi führen! Für Informationen zum Anschließen von 5V-Chips, siehe [[Pegelwandler]] oder [[Raspberry Pi#Erweiterungs-Boards]].
<gallery heights="300" widths="300">
Datei:Raspberry_Pi_GPIO.svg|Der P1-Anschluss
Datei:Raspberry_Pi_GPIO_P2.svg|Der P2-Anschluss (eigentlich das JTAG-Interface der GPU, aber trotzdem mit ein paar nützlichen Pins)
Datei:Raspberry_Pi_GPIO_P5.svg|Der P5-Anschluss auf der Rückseite der Platine
</gallery>

Im oberen Bild ist die Belegung der Anschlüsse zu sehen, die man als GPIO oder zur Stromversorgung nutzen kann. Die Beschriftungen sind genau so wie auf der Platine angebracht und sollen eine Orientierung ermöglichen.
Die 3,3V Anschlüsse (P1-1, P1-17, P2-1 und P5-2) dürfen maximal mit 50 mA belastet werden. Bei den 5V Anschlüssen (P1-2, P1-4 und P5-1) gibt es keine feste Grenze, hier kommt es auf den aktuellen Stromverbrauch des restlichen Boards und der Leistung des Netzteils an. Die Pins GPIO2 (P1-3) und GPIO3 (P1-5) sind jeweils mit einem 1,8 kΩ Pull-Up-Widerstand ausgestattet.

Der Anschluss P3 ist noch ein JTAG-Interface, der Anschluss P6 kann mit einem Reset-Knopf ausgestattet werden. Wenn man die beiden Pins verbindet verursacht das einen Soft Reset der CPU.

Hier eine Übersicht der Alternativ-Funktionen der Pins:
* P1-03 (GPIO2): I2C SDA (siehe [[Raspberry Pi#Der_I2C-Bus]])
* P1-05 (GPIO3): I2C SCL (siehe [[Raspberry Pi#Der_I2C-Bus]])

* P1-07 (GPIO4): GPCLK0 (General Purpose Clock)

* P1-08 (GPIO14): UART TXD (siehe [[Raspberry Pi#Der_UART]])
* P1-10 (GPIO15): UART RXD (siehe [[Raspberry Pi#Der_UART]])
* P1-11 (GPIO17): UART RTS (siehe [[Raspberry Pi#Der_UART]])

* P1-12 (GPIO18): PWM ([[Pulsweitenmodulation]])
* P1-13 (GPIO27): PCM (Puls-Code-Modulation) oder GPCLK1 (General Purpose Clock)

* P1-19 (GPIO10): SPI MOSI (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-21 (GPIO9): SPI MISO (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-23 (GPIO11): SPI SCLK (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-24 (GPIO8): SPI Chip Select 0 (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-26 (GPIO7): SPI Chip Select 1 (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])

=== Ansteuerung per sysfs ===
Ganz nach den UNIX-Prinzipien gibt es die Möglichkeit, auf die Schnittstelle über Dateien im sysfs zuzugreifen. Dafür existiert das Verzeichnis ''/sys/class/gpio/''.

Um einen GPIO-Pin zu verwenden muss man ihn zuerst aktivieren, indem man die Pin-Nummer in ''/sys/class/gpio/export'' schreibt. Wenn man über die Kommandozeile z.B. Pin 4 aktivieren will benutzt man folgendes Kommando:
* echo 4 > /sys/class/gpio/export
Dadurch wird automatisch ein Verzeichnis ''/sys/class/gpio/gpio4/'' erstellt. Nun kann man über die darin enthaltene Datei ''direction'' den Pin als Out- bzw. Input festlegen (standardmäßig sind alle Inputs):
* echo in > /sys/class/gpio/gpio4/direction
für einen Input und
* echo out > /sys/class/gpio/gpio4/direction
für einen Output. Jetzt kann man den Wert des Pins auslesen:
* cat /sys/class/gpio/gpio4/value
oder ihn setzen, wenn es ein Output-Pin ist:
* echo 1 > /sys/class/gpio/gpio4/value
* echo 0 > /sys/class/gpio/gpio4/value
Wenn man den Pin nicht mehr benutzen will sollte man ihn wieder deaktivieren:
* echo 4 > /sys/class/gpio/unexport
Dadurch verschwindet das Verzeichnis ''/sys/class/gpio/gpio4/'' wieder. All das kann man natürlich nicht nur auf der Shell verwenden, sondern auch in jeder Programmiersprache, indem man einfach in die entsprechenden Dateien schreibt bzw. aus ihnen liest.

=== Beispiel: Shell-Blinklicht ===
Dieses kleine Shellscript aktiviert den GPIO-Pin, den man als Argument übergeben hat, setzt ihn als Output und schaltet ihn alle 500ms um:
<pre>
#!/bin/bash
## Check arguments:
if [[ ! $# -eq 1 ]]; then
echo "Usage: $0 GPIO" > /dev/stderr
exit 1
fi
## Activate GPIO:
echo "Activating GPIO$1"
echo $1 > /sys/class/gpio/export || exit 1
## Create trap:
trap "echo 'Deactivating GPIO$1' && echo in > /sys/class/gpio/gpio$1/direction && echo $1 > /sys/class/gpio/unexport" EXIT
## Set as output:
echo "out" > /sys/class/gpio/gpio$1/direction || exit 1
## Reset value:
echo 0 > /sys/class/gpio/gpio$1/value || exit 1
## Blink loop:
while true; do
echo "Switching GPIO$1 on"
echo 1 > /sys/class/gpio/gpio$1/value || exit 1
sleep 0.5
echo "Switching GPIO$1 off"
echo 0 > /sys/class/gpio/gpio$1/value || exit 1
sleep 0.5
done
</pre>
Wenn man an dem entsprechenden Pin eine LED anschließt eignet sich das Script gut zum Testen der GPIO-Schnittstelle.

=== Ansteuerung per Python-Modul ===
Mit dem Modul [https://pypi.python.org/pypi/RPi.GPIO RPi.GPIO] kann man unter Python die GPIO-Pins steuern und auslesen. Auf der Projekt-Website gibt es auch ein Beispiel, mit dem man die Handhabung schnell lernt.

Jedes Python-Script, das dieses Modul nutzen will, muss als root laufen.

=== Ansteuerung mit Java ===
Das [http://pi4j.com/ Pi4J-Projekt] ermöglicht unter Java die Verwendung der GPIO-Pins, dem UART, des I2C-Bus und der SPI-Schnittstelle. Eine ausführliche Anleitung gibt es auf der Website.

Jedes Java-Programm, dass dieses Modul nutzen will, muss als root laufen.

=== Ansteuerung mit WiringPi ===
[https://projects.drogon.net/raspberry-pi/wiringpi/ WiringPi] bietet ein Kommandozeilen-Tool ('''gpio''', Details siehe '''man gpio'''), das man auch als normaler Nutzer (ohne root-Rechte) verwenden kann und eine C-Bibliothek (Header-Datei ''wiringPi.h'' und Linker-Option ''-lwiringPi''), mit der man die GPIO-Pins in C-Programmen verwenden kann.

Auf der Website gibt es Beispiele und eine Installationsanleitung. Bei Arch Linux ARM ist es auch in den Paketquellen und kann per Paketverwaltung installiert werden:
* pacman -S wiringpi

== Der I2C-Bus ==
Auch auf den I2C-Bus des Raspberry Pi kann man zugreifen. Die Pins dafür liegen an P1-03 (GPIO2, SDA) und P1-05 (GPIO3, SCL).
=== Ansteuerung per devfs ===
Den I2C-Bus kann man direkt über die Datei '''/dev/i2c-0''' oder '''/dev/i2c-1''' erreichen, je nach Version des Boards und gewünschter Schnittstelle.
=== Ansteuerung per i2c-tools ===
Komfortabler geht das aber über die i2c-tools. Dazu muss man erst einmal das Paket aus den Arch Linux ARM Paketquellen installieren:
* pacman -S i2c-tools
Nun muss man die nötigen Kernel-Module laden:
* modprobe i2c-bcm2708
* modprobe i2c-dev
Soll das beim Systemstart automatisch passieren, legt man eine *.conf-Datei im Verzeichnis '''/etc/modules-load.d/''' mit folgendem Inhalt an:
<pre>i2c-bcm2708
i2c-dev</pre>
Jetzt sollten folgende Kommandozeilen-Tools funktionieren:
* '''i2cdetect''' zum Auflisten der I2C-Busse und zum Anzeigen der Eigenschaften und Geräte
* '''i2cdump''' zum Herausfinden von I2C-Registern
* '''i2cget''' zum Lesen von I2C-Registern
* '''i2cset''' zum Setzen von I2C-Registern
Die Manpages und Hilfe-Meldungen der einzelnen Tools geben Auskunft über die genaue Verwendung. Wichtig ist, dass man den I2C-Bus 0, '''nicht''' den I2C-Bus 1 verwendet. Ein kleines Beispiel gibt es auch in der Ausgabe 5 des MagPi im Artikel „Temperature Sensor“. Dort wird ein Temperatursensor per I2C ausgelesen.
=== Errata ===
Der I2C Controller kann aufgrund eines Implementierungsfehlers des Chips nicht zuverlässig mit clock stretching genutzt werden. Insbesondere bei Mikrocontrollern als I2C Slave ist dies jedoch nur schwer zu vermeiden, weshalb die Kopplung eines Mikrocontrollers per I2C problematisch ist. Siehe http://www.advamation.de/technik/raspberrypi/rpi-i2c-bug.html.

== Der UART ==
Die Pins für den UART liegen auch an P1. TXD an Pin 08 (GPIO14), RXD an Pin 10 (GPIO15) und RTS an Pin 11 (GPIO17).

Zugreifen kann man über das devfs, genauer gesagt über die Datei '''/dev/ttyAMA0'''. Um zu testen, ob das funktioniert, kann man minicom benutzen:
* pacman -S minicom
* minicom -b 115200 -o -D /dev/ttyAMA0

== Die SPI-Schnittstelle ==
Die Pins für die SPI-Schnittstelle liegen genau wie I2C und UART an P1. MOSI an Pin 19 (GPIO10), MISO an Pin 21 (GPIO9), SCLK an Pin 23 (GPIO11), CS0 an Pin 24 (GPIO8) und CS1 an Pin 26 (GPIO7).

Der Zugriff erfolgt über die Dateien '''/dev/spidev0.0''' (Gerät an CS0) und '''/dev/spidev0.1''' (Gerät an CS1), in die man direkt schreiben und aus denen man auch direkt lesen kann.

== Audio-Ausgabe ==
[[Datei:Raspberry_Pi_Audio.jpg|thumb|Der 3,5mm Klinke-Anschluss]]
Der Raspberry Pi verfügt über zwei Möglichkeiten der Audio-Ausgabe, einmal digital per HDMI und wenn kein Display angeschlossen ist wird automatisch auf die analoge Ausgabe per 3,5mm-Klinken-Anschluss umgeschaltet.

Nach der Installation von Arch Linux ARM funktioniert jedoch vorerst keine der beiden Möglichkeiten, da das nötige Kernel-Modul nicht automatisch geladen wird.

Manuell lässt es sich mit '''modprobe''' laden, beim nächsten Neustart ist das Problem dann jedoch wieder da:
* modprobe snd_bcm2835
Wenn man will, dass das Modul bei jedem Start automatisch geladen wird, muss man eine *.conf Datei im Verzeichnis /etc/modules-load.d/ erstellen und dort den Namen des Moduls hineinschreiben. Es bietet sich z.B. der Name sound.conf an, über die Kommandozeile ist die Datei schnell erstellt:
* echo "snd_bcm2835" > /etc/modules-load.d/sound.conf
Jetzt sollte die Audio-Ausgabe problemlos funktionieren. Testen kann man das beispielsweise per '''aplay''', das im Paket '''alsa-utils''' enthalten ist:
* pacman -S alsa-utils
* aplay name_der_datei.wav
In diesem Paket ist auch '''alsamixer''' enthalten, ein Programm mit dem man über eine ncurses-Oberfläche die Ausgabe-Lautstärke regeln kann.

Man muss beachten, dass nur '''root''' und Nutzer in der Gruppe '''audio''' auf die Soundkarte zugreifen können. Wenn man nicht als '''root''' arbeiten will sollte man seinen Benutzer der Gruppe hinzufügen:
* gpasswd -a USERNAME audio

=== Standard-Ausgabegerät ===
Normalerweise wird der Sound automatisch über HDMI ausgegeben, wenn das angeschlossene Gerät das unterstützt, andernfalls über den Klinke-Anschluss. Will man das ändern, z.B. weil man einen Monitor per HDMI angeschlossen hat, den Sound aber trotzdem über die Anlage hören will, geht das ganz schnell über die Kommandozeile:
* amixer -c 0 cset numid=3 <nummer>
Dabei muss man ''<nummer>'' durch eine 0 für automatisches Wechseln, eine 1 für den Klinke-Anschluss oder eine 2 für den HDMI-Anschluss ersetzen. Soll das bei jedem Systemstart automatisch ausgeführt werden, erstellt man bei Arch Linux eine Service-Datei für systemd, z.B. so:
<pre>
[Unit]
Description=Set Default Audio Output

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer -c 0 cset numid=3 <nummer>

[Install]
WantedBy=multi-user.target
</pre>
Hier ersetzt man wieder ''<nummer>'' durch das gewünschte Ziel, speichert die Datei unter ''/etc/systemd/system/default-audio.service'' ab und aktiviert den soeben erstellten Service noch:
* systemctl enable default-audio.service
Ab dem nächsten Systemstart wird dadurch das Ausgabegerät automatisch eingestellt.

== Erweiterungs-Boards ==
Für die GPIO-Schnittstelle des Raspberry Pi gibt es verschiedene Erweiterungs-Boards, die zusätzliche Schnittstellen bereitstellen und 3,3V zu 5V Pegelwandler besitzen. Durch diese kann man den Raspberry Pi in bestehende, 5V-basierte Schaltungen und Projekte einbinden.

=== Prototyping-Board für den Raspberry Pi ===
In der Ausgabe 16 des embedded projects journal wurde auf Seite 13 ein Prototyping-Board für den Raspberry Pi vorgestellt.

Das Board besitzt eine Spannungsversorgung, an die man 7 bis 15V anschließen kann und die auch den Raspberry Pi mitversorgt. Dadurch wird ein per microUSB angeschlossenes Netzteil überflüssig. Außerdem gibt es einen Pegelwandler, der acht GPIO-Pins des Raspberry Pi als 5V-GPIO-Pins zur Verfügung stellt und einen I2C-Pegelwandler, durch den auch hier der Anschluss von 5V-Chips möglich wird.

Weitere Informationen gibt es im embedded projects journal und auf der [http://bastelstube.rocci.net/projects/MBS19_RasPi-GPIO/RasPi-GPIO.html Website des Projekts].

=== Berrybush Pi ===
Ebenfalls in der Ausgabe 16 des embedded projects journal wurde auf Seite 28 der „Berrybush Pi“ vorgestellt, der ein paar mehr Schnittstellen als das Prototyping-Board bietet.

Auch dieses Board bietet eine Spannungsversorgung für den Raspberry Pi und acht 5V-GPIO-Pins, diese sind jedoch mit Darlington-Transistoren und LEDs zur Status-Anzeige ausgestattet. Außerdem gibt es eine 3,3V (sic) SPI-Schnittstelle, die einfach zum Raspberry Pi durchgeschleift wird, einen 5V-I2C-Bus (mit Pegelwandler zum Raspberry Pi), einen RS485-Bus und eine RS232-Schnittstelle, die jedoch in den RS485-Bus gespeist wird.

Als kleines Highlight gibt es noch die Möglichkeit, ein LCD anzuschließen. Dafür sind Portexpander und Potentiometer für Helligkeit und Kontrast vorhanden.

Genauere Informationen, Schaltpläne und Bilder gibt es im embedded projects journal.

[http://www.mikrocontroller.net/topic/epj-16-seite-28 Weitere Informationen]

=== Arduino Shield Bridge ===
Mit diesem Board aus Spanien kann man Arduino-Aufsteckplatinen mit dem Raspberry Pi verwenden.
[http://www.cooking-hacks.com/index.php/raspberry-pi-to-arduino-shield-connection-bridge.html Cooking-hacks.com]

Dazu existiert eine Library "arduPi":
"In order to make complete the compatibility we have created the arduPi library which allows to use Raspberry with the same code used in Arduino. To do so, we have implemented conversion functions so that you can control in the same way as in Arduino all the I/O interfaces: i2C, SPI, UART, analog, digital, in Raspberry Pi."

=== I/O Module seriell/USB ===

Alternativ bieten sich Schnittstellen-Erweiterungen über seriellen Port oder USB an, zum Beispiel mit einem handelsüblichen AVR Mikrocontroller-Modul und der Firmware von Stefan Frings
[http://stefanfrings.de/avr_io/].

=== Gertboard ===
Webseite: http://www.raspberrypi.org/archives/tag/gertboard
Eine I/O-Aufsteckplatine mit zusätzlichem Mikrocontroller (bisher PIC, jetzt ATMega)

=== I2C-Repeater-Board für Raspberry PI ===
Die kleine Platine von "Horter & Kalb" wird direkt auf die GPIO-Schnittstelle des Raspberry PI gesteckt.
Es macht die Pegelanpassung von 3,3 auf 5V für den SDA- und den SCL-Pin.

Außerdem kann auch das INT-Signal, welches von digitalen Eingabebaugruppen verwendet wird, über den GPIO 17 abgefragt werden.

Das Board ist hier ausführlich beschrieben: http://www.horter.de/blog/i2c-repeater-pegelanpassung-fuer-raspberry-pi/

Im Onlineshop unter www.horter.de ist der Bausatz für 9,90€ zu haben.

== Projekte ==
Um den Raspberry Pi hat sich inzwischen eine große Community gebildet, von der immer wieder neue Projekte mit und Erweiterungen für den Raspberry Pi entwickelt werden. Eine Quelle, über die man von den Projekten erfährt ist z.B. der offizielle [http://www.raspberrypi.org/ Raspberry Pi Blog], aber es gibt auch noch viele andere Möglichkeiten, sich zu informieren.

Einige dieser Möglichkeiten und einige ausgewählte Projekte werden in diesem Artikel vorgestellt.

=== The MagPi ===
[http://www.themagpi.com/ The MagPi] ist ein freies Online-Magazin, das (normalerweise) monatlich erscheint und in dem interessante Projekte genauer vorgestellt werden. Außerdem gibt es Programmier-Tutorials, Anleitungen für Linux-Software und Interviews.

==== Ausgabe 1 ====
Die Ausgabe 1 vom Mai 2012 behandelt folgende Themen:
* „The Pioneers“ - eine kleine Übersicht, wie es zur Entwicklung des Raspberry Pi kam
* „Skutter“ - ein Roboterarm für den Raspberry Pi
* „RacyPy“ - eine Linux Live-CD, basierend auf Puppy Linux und speziell angepasst für einen leichten Einstieg in die Programmierung
* eine Anleitung zum Installieren von Debian in einer virtuellen Maschine
* „Scratch“ - eine Programmiersprache und Entwicklungsumgebung zum kinderleichten Einstieg in die Programmierung
* „the python pit“ - ein Einstieg in die Programmierung mit Python

==== Ausgabe 2 ====
Die Ausgabe 2 vom Juni 2012 behandelt folgende Themen:
* „PiSetup“ - eine Anleitung zum Einrichten des Raspberry Pi
* „In Control“ - ein Einstieg in die GPIO-Programmierung mit dem Raspberry Pi und Python
* „Pi Dissection“ - ein genauerer Blick auf die Einzelteile des Raspberry Pi
* Fortsetzung von „Skutter“ aus Ausgabe 1
* „Command Line Clinic“ - eine Einführung in die Benutzung der Linux-Shell
* „Computer Music“ - eine Anleitung zur Installation von „Schism Tracker“, einem Sequencer-Programm
* Fortsetzung der Debian-Anleitung aus Ausgabe 1, diesmal mit einer Anleitung zum Einrichten und Verwenden von Python
* Fortsetzung von „the python pit“ aus Ausgabe 1

==== Ausgabe 3 ====
Die Ausgabe 3 vom Juli 2012 behandelt folgende Themen:
* eine Anleitung zum automatischen Starten der grafischen Oberfläche von Debian
* Fortsetzung von „In Control“ aus Ausgabe 2
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2
* Fortsetzung von „Skutter“ aus Ausgabe 1 und 2
* „To Protect and Serve your Raspberry Pi“ - eine einfache Anleitung, um die GPIO-Pins des Raspberry Pi vor Kurzschlüssen zu schützen
* „Meeting Pi“ - Vorschäge, wie man Kinder an den Raspberry Pi heranführen kann
* „The C Cave“ - ein C-Tutorial
* Fortsetzung von „Scratch“ aus Ausgabe 1
* Fortsetzung von „the python pit“ aus Ausgabe 1 und 2
* „Programming Fundamentals“ - ein Artikel, der die Grundlagen (fast) aller Programmiersprachen auf einfachem Weg zeigen will

==== Ausgabe 4 ====
Die Ausgabe 4 vom August 2012 behandelt folgende Themen:
* Fortsetzung von „In Control“ aus Ausgabe 2 und 3
* „3-Axis Accelerometer“ - eine Anleitung für einen Beschleunigungs-Sensor am Raspberry Pi
* „Kernow Pi Launch“ - ein Artikel darüber, wie der Raspberry Pi an Schulen gebracht wurde
* „MagPi Exclusive Interview“ - ein Interview mit Eben und Liz von der Raspberry Pi Foundation
* „How to customise your LXDE menu“ - eine Anleitung zum Anpassen von LXDE
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2 und 3
* Fortsetzung von „The C Cave“ aus Ausgabe 3
* Fortsetzung von „Scratch“ aus Ausgabe 1 und 3
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2 und 3

==== Ausgabe 5 ====
Die Ausgabe 5 vom September 2012 behandelt folgende Themen:
* „Steady Hands“ - eine Anleitung zum Bau eines „Heißer Draht“-Spiels mit dem Raspberry Pi
* „Temperature Sensor“ - eine Anleitung zum Anschluss eines I2C-Temperatursensors an den Raspberry Pi
* „XBMC Media Center“ - eine Einführung in Rasbbmc, einer HTPC-Distribution für den Raspberry Pi
* „Squeezy or Wheezy?“ - ein Vergleich von Debian 6 „Squeeze“ und Debian 7 „Wheezy“
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2, 3 und 4
* Fortsetzung von „The C Cave“ aus Ausgabe 3 und 4
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3 und 4
* „RasPiThon 2012“ - ein Bericht über den Rasbperry Pi Programmier-Marathon
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3 und 4

==== Ausgabe 6 ====
Die Ausgabe 6 vom Oktober 2012 behandelt folgende Themen:
* „Skutter Returns“ - Fortsetzung von „Skutter“ aus Ausgabe 1, 2 und 3
* „Portable Power for your Pi“ - eine Anleitung für eine mobile Stromversorgung
* „Star Letter: An FET Buffer Stage for GPIO Access“ - eine Möglichkeit, wie man die GPIO-Pins des Raspberry Pi belastbarer machen kann
* „Pumpkin Pi“ - ein Kürbis mit Bewegungs-Sensor und RGB-LEDs
* „Camera Pi“ - ein Interview mit David Hunt, einem Bastler, der seine Kamera mit einem Raspberry Pi ausgestattet hat
* „Our Raspberry Pi Summer“ - ein Beispiel für ein kleines Spiel, das mit Scratch programmiert wurde
* „Baby steps in a Big World“ - ein Ada-Tutorial
* Fortsetzung von „The C Cave“ aus Ausgabe 3, 4 und 5
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4 und 5
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4 und 5

==== Ausgabe 7 ====
Die Ausgabe 7 vom November 2012 behandelt folgende Themen:
* „Raspberry Pi & Arduino“ - ein Artikel über die Kommunikation zwischen Arduino und Raspberry Pi mithilfe von Python
* „A little Ray of Sunshine“ - eine Solar-Stromversorgung für den Raspberry Pi und andere USB-Geräte
* „The Raspberry Ladder Board“ - ein Board zum Einstieg in die GPIO-Programmierung mit dem Raspberry Pi
* „Interrupts and Other Activities with GPIO Pins” - eine Anleitung für Interrupts und GPIO-Pins im Allgemeinen auf dem Raspberry Pi
* „Raspbian“ - ein Interview mit Mike Thompson, dem Erfinder von Raspbian
* „Turbopi“ - eine Anleitung zum Übertakten des Raspberry Pi
* „Pi-Evolution“ - eine Übersicht über die Entwicklung des Raspberry Pi
* „Make“ - eine Einführung in GNU Make und Makefiles
* „Welcome to the C++ Cache!“ - eine Einführung in C++
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5 und 6
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5 und 6

==== Ausgabe 8 ====
Die Ausgabe 8 vom Dezember 2012 behandelt folgende Themen:
* „Skutter Returns“ - Fortsetzung von „Skutter“ aus Ausgabe 1, 2 und 3 bzw. „Skutter Returns“ aus Ausgabe 6
* „The Santa Trap“ - Heimautomation mit dem Raspberry Pi
* „Control your Arduino board with Raspberry Pi and Python“ - ein Python-Modul zum Steuern eines Arduino
* „PiGauge“ - eine Anleitung, wie man Servo-Motoren übers Internet mithilfe des Raspberry Pi steuern kann
* „Quick2Wire“ - Erweiterungs-Board für den Raspberry Pi
* „Kickstarter“ - eine Vorstellung der Kickstarter-Kampagne, um The MagPi auf Papier zu bannen
* „Programming the Raspberry Pi: Getting Started with Python“ - eine kurze Vorstellung des gleichnamigen Buches von Simon Monk
* „pibow interview“ - ein Interview mit den Erfindern des PiBow, einem Gehäuse für den Raspberry Pi
* „CESIL Pi“ - ein CESIL Programmier-Tutorial für den Raspberry Pi
* Fortsetzung von „Welcome to the C++ Cache!“ aus Ausgabe 7
* Fortsetzung von „Baby steps in a Big World“ aus Ausgabe 6
* „MySQL Database Bootcamp“ - eine Einführung in MySQL
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6 und 7

==== Ausgabe 9 ====
Die Ausgabe 9 vom Februar 2013 (Januar wurde ausgelassen) behandelt folgende Themen:
* „adafruit Interview“ - Interview mit der Gründerin von adafruit, einem Shop für DIY Elektronik
* „WebIOPi“ - eine REST-Schnittstelle, um die GPIO-Pins des Raspberry Pi per Javascript zu steuern
* „Backup your Raspberry Pi“ - eine Anleitung für die Datensicherung der SD-Karte
* „Pi Interface Board Review Quick2Wire“ - ein genauerer Blick auf das Erweiterungs-Board „Quick2Wire“, das in Ausgabe 8 schon kurz gezeigt wurde
* „RISC OS Pi“ - eine Anleitung zur Installation von RISC OS auf dem Raspberry Pi
* „Installing & Configuring ArchLinux“ - eine Anleitung zur Installation von Arch Linux auf dem Raspberry Pi, die auch die Installation von XFCE umfasst
* „Introducing Vala“ - ein kleines Vala Programmier-Tutorial für den Raspberry Pi und das LedBorg Erweiterungs-Board
* Fortsetzung von „The C Cave“ aus Ausgabe 3, 4, 5 und 6
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6 und 7
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6, 7 und 8

==== Ausgabe 10 ====
Die Ausgabe 10 vom März 2013 behandelt folgende Themen:
* Fortsetzung von „WebIOPi“ aus Ausgabe 9
* „Try a Cocktail of Projects“ - ein Artikel, der verschiedene Erweiterungs-Möglichkeiten für den Raspberry Pi zeigt
* „Backing up - part 2“ - Fortsetzung von „Backup your Raspberry Pi“ aus Ausgabe 9
* „Bash Gaffer Tape“ - ein Bash-Tutorial
* „Charm on the Raspberry Pi“ - ein Charm Programmier-Tutorial für den Raspberry Pi
* „C++ Cache”: Fortsetzung von „Welcome to the C++ Cache!“ aus Ausgabe 7 und 8
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6, 7 und 9
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6, 7, 8 und 9

==== Ausgabe 11 ====
Die Ausgabe 11 vom April 2013 behandelt folgende Themen:
* Heizungssteuerung mithilfe des Raspberry Pi über ein Smartphone
* eine Vorstellung vom „Power and I/O Expansion Board“
* eine Anleitung zum Einrichten eines WLAN-Access-Points auf dem Raspberry Pi (per USB-WLAN-Dongle)
* Vorstellung von der Minecraft Pi-Edition
* „Printing with Cups“: Configuring Cups
* „Setting up a simple intranet“ mit einer Anleitung zum Einrichten vom Apache HTTPD
* eine Einführung in die Assembler-Programmierung auf dem Raspberry Pi
* Fortsetzung von „Charm on the Raspberry Pi“ aus Ausgabe 10
* kurze Anleitung zum Verwenden von Farben auf der Kommandozeile
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6, 7, 9 und 10

=== Raspberry Pi multi-effects ===
Ein Musiker hat mit einem Raspberry Pi, einem Arduino Uno und einer USB-Soundkarte ein Gitarren-Effektboard gebaut und das Ganze in seinem Blog [https://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ beschrieben]. Das alles sieht im [https://www.youtube.com/watch?v=NwJNeouLqgQ Video] noch etwas sperrig aus, es sollte aber kein Problem sein, die Soundkarte und den Raspberry Pi auch noch mit ins Effektboard zu integrieren.

Als Software verwendet er Raspbian, also das Standard-Betriebssystem des Raspberry Pi, und [http://puredata.info/ Pure Data], eine Echtzeit-Umgebung für Audio-, Video- und Grafik-Verarbeitung. Diese ist jedoch auch in den Arch Linux ARM Paketquellen verfügbar, einem Versuch, das ganze auch mit Arch Linux auszuprobieren, steht also theoretisch nichts im Wege.

Die Installation und Konfiguration von Pure Data hat er ebenfalls in seinem Blog [https://guitarextended.wordpress.com/2013/01/28/rpi-as-guitar-effects-processor-installing-and-configuring-pd/ beschrieben].

=== Raspberry Pi guitar tuner ===
Ein anderer Nutzer hat ein Gitarren-Stimmgerät gebaut. Dazu hat er einen Raspberry Pi, eine USB-Webcam zur Ton-Aufnahme, eine 7-Segment-Anzeige zur Anzeige des Tons und 15 LEDs zur Anzeige der Abweichung vom Ton verwendet.

Ausgewertet und angesteuert wird das Ganze über ein selbstgeschriebenes Java-Programm, ein Video und ein paar zusätzliche Informationen gibt es auf [https://www.youtube.com/watch?v=oB4F5VhzQf8 YouTube].

=== Circadian Lighting ===
Auch für Menschen, die sich mit dem Morgen manchmal schwer tun, gibt es ein Projekt mit dem Raspberry Pi, das im Blog [http://www.raspberrypi.org/archives/3267 vorgestellt wurde]. In Verbindung mit ein paar RGB-LEDs kann man den Raspbrry Pi zu einem Wecker machen, der einen nicht mit lautem, nervigen Piepsen aus dem Schlaf reißt, sondern langsam in Verbindung mit einem künstlichen Sonnenaufgang weckt. Fehlt nur noch ein Relais, über das die Kaffeemaschine angeschaltet wird, und der Morgen ist perfekt.

Bei diesem Projekt gibt es sogar den [https://github.com/rasathus/circadianLighting Quellcode], eine [http://rasathus.blogspot.co.uk/2013/01/circadian-lighting-part-one.html Hardware-Liste] und ein [https://www.youtube.com/watch?v=Q9_tqoOkmCU Video], das einige der Funktionen zeigt. Und mit ein paar Python-Kenntnissen kann man alles seinen Bedürfnissen anpassen und erweitern.

=== Raspberry Leaf ===
Die einfachsten Ideen sind doch manchmal die Besten. „Dr. Monk” hat in seinem Blog eine Pinbelegung des Raspberry Pi [http://www.doctormonk.com/2013/02/raspberry-pi-and-breadboard-raspberry.html veröffentlicht], die (in der richtigen Größe ausgedruckt) genau auf den P1-GPIO-Anschluss des Raspberry Pi passt. So vergisst man nie die Pinbelegung, wenn man gerade mal wieder mit dem Raspberry Pi bastelt und auch ein falsches Anschließen, das zur Zerstörung des Mini-Computers oder der angeschlossenen Teile führen kann, passiert nicht mehr so leicht.

=== raspberry-tools ===
Eine Tool-Sammlung für den Raspberry Pi, veröffentlicht unter der GNU General Public License Version 2 und gehostet auf [https://github.com/rookies/raspberry-tools github]. Momentan enthält diese Sammlung nur ein Programm, es folgen aber noch weitere nützliche Tools.

==== scope ====
Scope ist Teil von raspberry-tools. Es zeichnet digitale Signale von einem oder mehreren GPIO-Pins auf und bereitet die Daten für eine Auswertung mit [http://xoscope.sourceforge.net/ xoscope] auf.

Wenn man sich den Quellcode geholt hat, muss man erst einmal das Hauptprogramm für den Raspberry Pi kompilieren. Das geht entweder direkt auf dem Raspberry Pi oder per Cross-Compiler.
* g++ -o RasPi_logGPIO RasPi_logGPIO.cpp
Nachdem sowohl die entstandene Datei ''RasPi_logGPIO'' als auch das Script ''RasPi_logGPIO.sh'' im gleichen Ordner auf dem Raspberry Pi sind, kann man die Aufzeichnung starten:
* ./RasPi_logGPIO.sh [Liste mit GPIO-Pins] > ausgabedatei.txt
Für die Pins 14, 31 und 23 sieht das Kommando z.B. so aus:
* ./RasPi_logGPIO.sh 14 31 23 > ausgabedatei.txt
Die Aufzeichnung kann mit Strg+C gestoppt werden.

Jetzt kann man die entstandene Datei (z.B. hier ausgabedatei.txt) normalisieren und ins xoscope-Format umwandeln, das funktioniert auch problemlos auf einem anderen Computer:
* ./RasPi_normalizeGPIO.py ausgabedatei.txt > ausgabedatei.dat
Nun entsteht die Datei ''ausgabedatei.dat'', die man mit xoscope ansehen kann:
<gallery heights="300" widths="300">
Datei:RasPiTools_scope_sample1.png|eine Beispiel-Aufnahme
Datei:RasPiTools_scope_sample2.png|die gleiche Aufnahme, vergrößert
</gallery>
Dazu muss man nur die Datei laden und die entsprechenden Memory-Einträge anzeigen lassen. In diesem Beispiel ist Pin 14 in Mem A, Pin 31 in Mem B und Pin 23 in Mem C, also genau in der Reihenfolge, in der man die Pin-Nummern dem Programm übergeben hat.

== Anhang ==
=== Stromversorgung ===
[[Datei:Raspberry_Pi_Power.jpg|thumb|Der microUSB-Anschluss zur Stromversorgung]]
Um den Raspberry Pi mit Strom zu versorgen gibt es verschiedene Möglichkeiten. Entscheidend ist nur, dass möglichst konstante 5V bei bis zu 700 mA auf einem microUSB-Stecker geliefert werden.
==== mit USB-Netzteil ====
Wenn man ein genügend starkes USB-Netzteil mit einem microUSB-Kabel verbindet hat man eine passende Stromversorgung für den Raspberry Pi.
Gut funktioniert zum Beispiel das iPhone-Ladegerät, aber auch andere, günstigere Netzteile sollten keine Probleme machen.
==== Netzteil selbst bauen ====
Wenn man kein USB-Netzteil zur Hand hat kann man auch selbst ein Steckernetzteil, das 5V Gleichspannung liefert, mit einem microUSB-Kabel zusammenlöten.

Dafür braucht man erst einmal ein microUSB-Kabel und ein passendes Steckernetzteil. (siehe Abb. 1)
Man entfernt den USB-A-Stecker und befreit das Kabelende ein Stück von seinem Mantel, es kommen vier Adern zum Vorschein. (siehe Abb. 2)
Uns interessiert die grüne und die weiße Ader nicht, da wir keine Daten übertragen wollen.
Jetzt muss auch noch der Stecker vom Netzteil entfernt und die Adern abisoliert werden. (siehe Abb. 3)
Bei manchen Netzteilen ist eine Markierung für Plus- oder Minus-Pol angebracht. Wenn das nicht der Fall ist, muss man mit einem Multimeter nachmessen. (siehe Abb. 4)
Nun isoliert man auch noch die schwarze und rote Ader des USB-Kabels ab und verlötet die schwarze Ader mit dem Minus-Pol des Netzteils und die rote Ader mit dem Plus-Pol des Netzteils. Danach packt man um die Adern jeweils einen Schrumpfschlauch zur Isolation. Wenn man um die ganze Verbindung noch einen großen Schrumpfschlauch packt wird die Verbindung nochmal um einiges stabiler.
(siehe Abb. 5)
Es ist auch möglich den Raspberry Pi über jedes alte PC Netzteil zu betreiben, bei einem alten 300 Watt Netzteil hat man einen Verlust im Leerlauf von ca. 8 Watt.
Dafür kann man aber einige andere Komponenten (LEDs, usw.) mitbetreiben.
Hier ein Link zu einem deutschen Youtube Video:
http://www.youtube.com/watch?v=hqevlVn1Osk

Wer kein Micro-USB Kabel opfern möchte, kann zwar den GPIO-Pinheader verwenden, dabei umgeht man aber die interne Eingangssicherung sowie die TVS-Diode (Überspannungsschutz). Siehe Schema, Seite 1: http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspberry-Pi-Schematics-R1.0.pdf
<gallery>
Datei:RasPi_Netzteil_Selbstbau1.jpg|Abb. 1: Die Ausgangsmaterialien
Datei:RasPi_Netzteil_Selbstbau2.jpg|Abb. 2: Das USB-Kabel ohne Mantel mit der roten (+5V), schwarzen (GND), grünen (Data+) und weißen (Data-) Ader
Datei:RasPi_Netzteil_Selbstbau3.jpg|Abb. 3: Das Netzteil mit abisolierten Kabelenden
Datei:RasPi_Netzteil_Selbstbau4.jpg|Abb. 4: Das Multimeter zeigt eine positive Zahl an, daher ist das Kabel mit der roten Klemme der Plus-Pol, das Kabel mit der schwarzen Klemme der Minus-Pol.
Datei:RasPi_Netzteil_Selbstbau5.jpg|Abb. 5: Das fertige Netzteil, die Verbindung ist mit einem Schrumpfschlauch geschützt.
</gallery>

=== USB-Geräte ===
[[Datei:Raspberry_Pi_USB.jpg|thumb|Die beiden USB Host-Anschlüsse]]
Generell kann man am Raspberry Pi alle USB-Geräte verwenden, die vom Linux-Kernel unterstützt werden und somit auch an anderen Linux-PCs funktionieren.

Es ist allerdings zu beachten, dass die USB-Ports nur vergleichsweise wenig Strom liefern können (nicht die vollen 500 mA, die laut USB2.0 Standard maximal möglich sind), für größere Verbraucher wie z.B. 2,5-Zoll-Festplatten ohne externe Stromversorgung muss man daher einen externen USB-Hub mit Stromversorgung verwenden.
==== Maus & Tastatur ====
Da es für Mäuse und Tastaturen Standard-Profile gibt, die auch von allen (bis auf extrem wenige Ausnahmefälle) Geräten eingehalten werden, sollte es hier keine Probleme geben. Die Eingabegeräte sollten sofort verwendbar sein und auch Hot-Plugging stellt im Normalfall kein Problem dar.
==== USB-Sticks & USB-Festplatten ====
Wenn man seinem Raspberry Pi zusätzlichen Speicherplatz verpassen will bietet es sich an, USB-Sticks bzw. -Festplatten anzuschließen. Da es auch hier Standard-Profile gibt sollten diese sofort vom Linux-Kernel erkannt werden. Einhängen ([https://de.wikipedia.org/wiki/Mounten mounten]) muss man sie jedoch unter Arch Linux ARM generell selbst, wenn man nicht einen [https://de.wikipedia.org/wiki/Fstab fstab-Eintrag] erstellt hat oder eine Desktop-Oberfläche installiert hat, die das automatisch erledigt.
==== WLAN-Sticks ====
Wird der WLAN-Stick vom Kernel erkannt (erkennbar daran, dass ein entsprechendes Interface von '''ifconfig -a''' aufgelistet wird), kann man ein Netzwerk-Profil mit [https://wiki.archlinux.org/index.php/Netcfg netcfg] (Quasi-Standard unter ArchLinux, bei dem die Profile über Konfigurationsdateien erstellt werden), dem [https://wiki.archlinux.org/index.php/NetworkManager NetworkManager] oder [https://wiki.archlinux.org/index.php/Wicd Wicd] erstellen. Sollte die Karte nicht erkannt werden, hilft eventuell ein Blick auf die [https://wiki.archlinux.org/index.php/Wireless_Setup Wireless Setup] Seite im ArchLinux Wiki.
==== TV-Karten ====
Will man den Raspberry Pi als HTPC verwenden, kann es sinnvoll sein, eine TV-Karte per USB anzuschließen.
Hier gibt es generell 4 Möglichkeiten:
* '''DVB-T''', also digitales Fernsehen, das per Funk ausgestrahlt wird - kostenlos, jedoch nicht überall verfügbar
* '''DVB-S''', also digitales Fernsehen, das per Satellit ausgestrahlt wird - kostenlos und generell überall verfügbar, jedoch wird eine Satelliten-Schüssel benötigt
* '''DVB-C''', also digitales Fernsehen, das über das Kabelnetz ausgestrahlt wird - Kosten für den Kabelanschluss fallen an, Sender-Angebot vom Kabelanbieter abhängig
* '''Analog-TV''', also analoges Fernsehen, das über das Kabelnetz ausgestrahlt wird - Kosten für den Kabelanschluss fallen an, kein HD, Sender-Angebot vom Kabelanbieter abhängig

Nicht alle Geräte werden von Linux unterstützt, eine Übersicht, die nach Übertragungstechnik (DVB-T/-S/-C oder Analog) und Anschluss-Art (beim Raspberry Pi immer USB) geordnet ist, findet man im [http://linuxtv.org/wiki/index.php/Hardware_Device_Information LinuxTVWiki], zu dem man natürlich auch selbst beitragen kann, wenn man ein Gerät getestet hat.
==== Soundkarten ====
Da der Klinke-Ausgang des Raspberry Pi nicht mit einem D/A-Wandler, sondern nur per PWM funktioniert, ist die Sound-Qualität nicht gerade überragend. Wenn man das verbessern will, oder wenn man Sound per Line-Eingang oder per Mikrofon aufnehmen will, bietet es sich an, eine USB-Soundkarte anzuschließen.

Ist man unsicher, ob die Soundkarte unterstützt wird, hilft ein Blick ins [http://www.alsa-project.org/main/index.php/Matrix:Main Wiki vom ALSA-Projekt].

== Downloads ==

* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-02-11/archlinux-hf-2013-02-11.zip.torrent Torrent-Download von Arch Linux ARM 2013-02-11]
* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-02-11/archlinux-hf-2013-02-11.zip HTTP-Download von Arch Linux ARM 2013-02-11] (SHA-1: 1d2508908e7d8c899f4a5284e855cb27c17645dc)

== Siehe auch ==

* [http://www.raspberrypi.org/ offizielle Website des Raspberry Pi] (englisch)
* [https://de.wikipedia.org/wiki/Raspberry_Pi Wikipedia: Raspberry Pi] (deutsch)
* [http://www.themagpi.com/ The MagPi] (englisch)
* [http://archlinuxarm.org/ Arch Linux ARM] (englisch)
* [https://www.archlinux.org/ Arch Linux] (englisch)
* [https://de.wikipedia.org/wiki/Arch_Linux Wikipedia: Arch Linux] (deutsch)
* [http://www.kammerath.net/asterisk-virtuelle-telefonanlage.html Asterisk auf dem Raspberry Pi] (deutsch)

[[Kategorie:Raspberry Pi]]

Raspberry Pi Einführung

2015-01-31T08:00:41Z

Prx: /* Der I2C-Bus */

''von Robert Knauer''

{{Wettbewerb Header}}

'''Wichtig''': ''Alle Informationen und Anleitungen in diesem Artikel beziehen sich auf das Model B mit erweitertem Arbeitsspeicher.''

[[Datei:Raspberry_Pi.jpg|thumb|Der Raspberry Pi]]
Der '''Raspberry Pi''' ist ein Einplatinen-Computer im Kreditkarten-Format mit einem SoC (System-on-a-Chip) von Broadcom. Dieser verfügt über folgende Eigenschaften:
* eine 700MHz ARMv6-CPU
* eine Broadcom VideoCore IV GPU
* 512 MB Arbeitsspeicher
Außerdem kann der Raspberry Pi über folgende Schnittstellen mit der Außenwelt kommunizieren:
* 2 USB 2.0 Host-Anschlüsse
* einen Composite Video-Ausgang
* einen HDMI-Ausgang (Video+Audio)
* einen 3,5mm Klinke-Audio-Ausgang
* einen SD-/MMC-Karten-Slot (Unterstützung für SDIO und SDHC)
* einen Ethernet-Port (10/100 MBit)
* 21 GPIO-Pins, teilweise gedacht als [[UART]], [[SPI]] und [[I2C]]
Die Energieversorgung wird über einen microUSB-Anschluss gewährleistet. Man sollte jedoch darauf achten, dass der USB-Anschluss, über den man den Raspberry Pi mit Energie versorgt mindestens 700 mA liefern kann, da in der USB 2.0 Spezifikation nur 500 mA vorgesehen sind. In diesem Artikel wird noch darauf eingegangen, wie man sich selbst ein entsprechendes Netzteil bauen kann, alternativ funktioniert auch ein entsprechend starkes USB-Ladegerät in Verbindung mit einem USB-A auf microUSB-B Kabel. (siehe [[Raspberry Pi#Stromversorgung]])

Um diese umfangreichen Möglichkeiten zu nutzen muss man mit einem anderen Computer ein Betriebssystem auf die SD-Karte laden, das dann vom Raspberry Pi gebootet wird. Am naheliegendsten ist hier natürlich Linux (Raspbian, Fedora, Debian und Arch Linux sind offiziell unterstützt), aber auch Plan 9 wurde schon auf dem kleinen Computer [http://www.heise.de/open/meldung/Plan-9-laeuft-auf-dem-Raspberry-1761392.html zum Laufen gebracht].

In diesem Artikel soll Schritt für Schritt der Weg vom Anschließen des Computers über das Einrichten von Arch Linux ARM bis zum Verwenden der verschiedenen Schnittstellen des Raspberry Pi beschrieben werden.

== Bezugsquellen & Zubehör ==
Der Raspberry Pi kann über verschiedene Quellen bezogen werden. Wichtig ist darauf zu achten, dass man das Model B mit 512 MB Arbeitsspeicher bestellt, da alle Anleitungen in diesem Artikel nur damit getestet sind und unter anderen Modellen eventuell nicht funktionieren. Ein in Deutschland ziemlich bekannter Elektronik-Versand, bei dem man den Raspberry Pi bestellen kann, ist Pollin, dort ist er zur Zeit für 38,95 € erhältlich. (Bestell-Nr.: 701 697, Stand: 17.06.2013)

Doch neben dem eigentlichen Computer braucht man natürlich noch etwas Zubehör, wenn man es nicht eh schon zu Hause rumliegen hat:
* ein Netzteil, das 5V bei mindestens 700 mA auf einem microUSB-Stecker liefert (siehe [[Raspberry Pi#Stromversorgung]])
* eine SD(HC)-Speicherkarte
* einen SD(HC)-Cardreader an einem anderen Computer
* ein RJ45-Netzwerkkabel
* ein Ethernet-Netzwerk mit Zugang zum Internet
Mit diesem Zubehör kann man nur über SSH zugreifen, wenn man direkt am Raspberry Pi arbeiten will und später evtl. auch eine grafische Oberfläche einrichten will braucht man noch folgendes:
* ein HDMI-Kabel und einen Fernseher bzw. Monitor mit HDMI-Eingang '''oder'''
* ein Composite-Kabel und einen Fernseher mit entsprechendem Video-Eingang
* eine USB-Tastatur
* eine USB-Maus (für eine grafische Oberfläche)
* evtl. einen aktiven USB-Hub, wenn die Ports des Raspberry Pi nicht genug Leistung für Maus und Tastatur liefern können

== Das Betriebssystem ==
Als Betriebssystem für die Anleitungen in diesem Artikel wird [http://archlinuxarm.org/ Arch Linux ARM] verwendet, das Meiste funktioniert jedoch auch unter anderen Linux-Distributionen und alles andere zumindest mit kleinen Anpassungen.
Es basiert auf den Prinzipien und teilweise auch der Software von [https://www.archlinux.org/ Arch Linux], hat aber vollständig unabhängige Paketquellen, in denen nur für ARM kompilierte Software verfügbar ist.

Arch Linux ist ein gutes Betriebssystem für einen Computer wie den Raspberry Pi, da es am Anfang sehr leichtgewichtig ist und vorerst keine grafische Oberfläche installiert hat (was gut ist wenn man den Raspberry Pi als Server verwenden will). Andererseits kann aber auch problemlos eine grafische Oberfläche nachinstalliert werden, wenn man den Raspberry Pi als Desktop-Computer, HTPC oder ähnliches verwenden will.

Man muss jedoch auch sagen, dass Arch Linux kein Betriebssystem für jemanden ist, der Linux noch nie verwendet hat. Man sollte schon etwas Erfahrung mit dem Arbeiten auf der Konsole haben, da grundlegende Dinge über Linux hier nicht erklärt werden.
Außerdem ist es teilweise notwendig, sich selbst weiterführende Informationen zu Arch Linux anzusehen, die in diesem Artikel verlinkt werden.

== Anschluss & Installation ==
Nun muss man zuerst alles anschließen. Die Netzwerk-Buchse wird über das Netzwerk-Kabel mit dem Ethernet-Netzwerk verbunden. Hier ist wichtig, dass in dem Netzwerk ein DHCP-Server läuft (also IP-Adressen automatisch bezogen werden können) und Zugriff zum Internet möglich ist. Wenn man sich für die Variante mit eigenem Bildschirm entschieden hat muss man außerdem die HDMI-Buchse mit dem Fernseher oder Monitor bzw. den Composite-Ausgang mit dem Fernseher verbinden und Tastatur und Maus über USB anschließen.
Dann folgt die Installation von Arch Linux ARM auf die SD-Karte.

Arch Linux ARM für Raspberry Pi kann man über folgende Links downloaden:
* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-06-06/archlinux-hf-2013-06-06.zip.torrent Torrent-Download von Arch Linux ARM 2013-02-11]
* [http://downloads.raspberrypi.org/download.php?file=/images/archlinuxarm/archlinux-hf-2013-06-06/archlinux-hf-2013-06-06.zip HTTP-Download von Arch Linux ARM 2013-06-06]
Wenn der etwa 185 MB große Download abgeschlossen ist und man über HTTP gedownloadet hat sollte man zuerst die Checksum überprüfen.
Eine Anleitung dazu findet befindet sich auf der Downloadseite.
* SHA-1: 706037373bbb33ab6fb0af147a6e795bd04f1503
Nachdem man das getan oder falls man über Torrent gedownloadet hat (dann passiert das automatisch) kann man das zip-Archiv entpacken.

Man erhält eine etwa 2,0 GB große Datei namens archlinux-hf-2013-06-06.img. Diese muss man nun auf die SD-Karte bringen. Unter Linux funktioniert das mit dem kleinen Programm dd, das in den GNU coreutils enthalten ist und damit auf fast jedem System vorinstalliert sein sollte. Dazu gibt man folgendes in die Konsole ein (als root, /dev/sdX durch den Pfad zur Gerätedatei der SD-Karte ersetzen, Pfad der img-Datei anpassen):
* dd if=/pfad/zur/archlinux-hf-2013-02-11.img bs=1M of=/dev/sdX
Unter Windows kann man dafür [https://launchpad.net/win32-image-writer Image Writer for Windows] benutzen.

Danach entfernt man die Karte aus dem Cardreader des Computers und setzt sie in den Raspberry Pi ein. Dann verbindet man die Stromversorgung, indem man den microUSB-Stecker des Netzteils in die entsprechende Buchse auf der Platine steckt.

== Der erste Start ==
Wenn man ein Display angeschlossen hat, erscheint nach ein paar Sekunden ein Login-Prompt auf dem Bildschirm. Als Username gibt man ''root'' ein, wenn man dann nach dem Passwort gefragt wird gibt man wieder ''root'' ein.

Wenn man kein Display angeschlossen hat, muss man die IP-Adresse, die der Raspberry Pi sich vom DHCP-Server geholt hat, herausfinden. Wenn der DSL-Router diesen Dienst bereitstellt, kann man meistens auf der Web-Oberfläche eine Liste der verteilten IP-Adressen sehen. Alternativ kann man auch mit ''nmap'' einen Netzwerk-Scan machen, der die IP-Adressen von allen Computern im Netzwerk anzeigt. Das funktioniert unter Linux, indem man '''nmap -sn SUBNETZ''' im Terminal eingibt. Davor ersetzt man SUBNETZ durch das Subnetz, in dem auch der Raspberry Pi ist, in [https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR-Notation]. Wenn man z.B. in einem Netz ist, in dem IP-Adressen von ''192.168.1.0'' bis ''192.168.1.255'' verteilt werden, muss man
''192.168.1.0/24'' verwenden.

Nachdem man die IP-Adresse herausgefunden hat, verbindet man sich per SSH zu ihr und loggt sich als root, Passwort root ein. Unter Linux funktioniert das mit
* ssh root@IP-ADRESSE
Unter Windows verwendet man am besten [http://www.putty.org/ PuTTY].

Egal für welche Möglichkeit man sich entschieden hat, sitzt man jetzt vor einer root-Shell des Raspberry Pi, erkennbar am Shell-Prompt '''[root@alarmpi ~]#'''.

== Konfiguration ==
Nun geht es an die Konfiguration von Arch Linux ARM, diese erfolgt vollständig über das Editieren von Dateien auf der Konsole.

=== Lokalisierung ===
Man editiert die Datei /etc/locale.gen:
* nano /etc/locale.gen
und entfernt die Raute vor der Zeile mit der entsprechenden Sprache-Land-Kodierungs-Kombination, also z.B. vor '''de_DE.UTF-8 UTF-8''' für Deutschland.
Danach speichert man mit Strg+O -> Enter und Strg+X und erstellt die Lokalisierung neu:
* locale-gen
Danach editiert man die Datei /etc/locale.conf:
* nano /etc/locale.conf
Man ändert '''LANG=en_US.UTF-8''' zur entsprechenden Sprache, also z.B. '''LANG=de_DE.utf8''' und speichert mit Strg+O -> Enter und Strg+X.

=== Tastatur-Layout ===
Um das Tastatur-Layout auf der Konsole anzupassen, muss man die Datei /etc/vconsole.conf ändern:
* nano /etc/vconsole.conf
Man ändert '''KEYMAP=us''' zu z.B. '''KEYMAP=de-latin1''' für QWERTZ und speichert wieder mit Strg+O -> Enter und Strg+X.

=== Zeitzone ===
Um die Zeitzone zu ändern muss man einen Symlink zu /etc/localtime erstellen:
* ln -sf /usr/share/zoneinfo/ZEITZONE /etc/localtime
Also für Deutschland (Europe/Berlin):
* ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Um alle Änderungen zu übernehmen startet man den Raspberry Pi am besten neu:
* reboot
Wenn man per SSH verbunden war, wird die Verbindung geschlossen und man muss sich neu verbinden.

== Aktualisierung ==
Da das Image, das man auf die SD-Karte geschrieben hat, schon etwas veraltet sein kann, sollte man das System über die Paketverwaltung aktualisieren:
* pacman -Syu
Dieses Kommando downloadet die Datenbanken und alle neuen Pakete und installiert diese anschließend.

Dieses Kommando sollte man jede Woche mindestens einmal ausführen, um das System aktuell zu halten. Arch Linux ARM muss nie neu installiert werden, allein durch dieses Kommando wird es immer aktuell gehalten.

== Dateisystem vergrößern ==
Da das Image darauf ausgelegt ist, dass es auch auf nur 2GB großen SD-Karten geschrieben werden kann, ist auch das Haupt-Dateisystem etwa 2GB groß, selbst wenn man Arch Linux ARM auf eine größere SD-Karte geschrieben hat.

Doch das ist kein großes Problem. Um das Haupt-Dateisystem so zu vergrößern, dass es die gesamte SD-Karte ausfüllt, muss man den Raspberry Pi ausschalten und die SD-Karte in einen Cardreader an einem Linux-PC einsetzen.

In der folgenden Anleitung wird angenommen, dass die SD-Karte unter /dev/sdb und das Haupt-Dateisystem der SD-Karte unter /dev/sdb2 ist. Wenn das nicht zutrifft muss man die Pfade entsprechend ändern.

Zuerst muss man sicherstellen, dass keines der Dateisysteme gemountet ist:
* umount /dev/sdb1
* umount /dev/sdb2
Danach muss man einen Dateisystem-Test durchführen:
* fsck -n /dev/sdb2
... und das Journal entfernen:
* tune2fs -O "^has_journal" /dev/sdb2
Dann bearbeitet man die Partitionstabelle mit fdisk:
* fdisk /dev/sdb
Man kommt in eine Kommandozeile, in der man folgendes nacheinander eingibt:
* d
* 2
* n
* p
* 2
* <ohne Eingabe Enter>
* <ohne Eingabe Enter>
* w
Dadurch wird die zweite Partition gelöscht und neu angelegt, und zwar über den gesamten freien Bereich der SD-Karte.
Dann muss man wieder einen Dateisystem-Test durchführen:
* e2fsck -f /dev/sdb2
... und das Dateisystem vergrößern:
* resize2fs /dev/sdb2
Jetzt erfolgt erneut ein Dateisystem-Test:
* fsck -n /dev/sdb2
... und die Wiederherstellung des Journals:
* tune2fs -j /dev/sdb2
Jetzt kann man die SD-Karte aus dem Cardreader nehmen, in den Raspberry Pi einsetzen und ihn starten.

Wenn alles glatt gelaufen ist bootet der Raspberry Pi ganz normal und man hat plötzlich mehr Speicherplatz zur Verfügung. Aus
<pre># df -h /
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 1,8G 805M 869M 49% /</pre>
wird bei einer 16GB SD-Karte zum Beispiel:
<pre># df -h /
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 15G 905M 14G 7% /</pre>

''Dieser Abschnitt basiert auf einer [http://www.howtoforge.de/anleitung/wie-man-die-grose-von-ext3-partitionen-anpasst-ohne-daten-zu-verlieren/ Anleitung zum Verändern der Größe von ext3-Partitionen von HowtoForge].''

== Paketverwaltung ==
Arch Linux ARM setzt pacman als Paket-Manager ein. Das erste Kommando, das zur System-Aktualisierung, wurde schon in einem anderen Kapitel genannt:
* pacman -Syu
Dieses setzt sich aus zwei Teil-Kommandos zusammen:
* pacman -Sy
zum Downloaden der Paket-Datenbanken und
* pacman -Su
zum Downloaden und Installieren der neuen Pakete.

Um ein neues Paket zu installieren verwendet man folgendes Kommando:
* pacman -S PAKETNAME
oder um davor noch die Datenbanken zu aktualisieren:
* pacman -Sy PAKETNAME

Um ein Paket zu löschen verwendet man:
* pacman -R PAKETNAME
oder um alle danach nicht mehr benötigten Abhängigkeiten mit zu löschen:
* pacman -Rs PAKETNAME

Es gibt noch viele weitere Kommandos, z.B. zum Suchen von Paketen, Anzeigen von Informationen, Auflisten von Dateien. Einen Überblick findet man im [https://wiki.archlinux.de/title/Pacman Arch Linux Wiki] oder eine Auflistung aller Optionen in der Manpage:
* man pacman
Nach der Installation sind standardmäßig alle fünf Paketquellen von Arch Linux ARM aktiviert, eine Liste aller enthaltenen Pakete findet man [http://archlinuxarm.org/packages auf der Website].

== Datensicherung ==
Um neue Betriebssysteme auf dem Raspberry Pi auszuprobieren braucht man nicht zehn verschiedene SD-Karten, die man immer wechselt. Es reicht eine SD-Karte, von der man ein Backup macht, bevor man ein neues Betriebssystem aufspielt. Aber auch wenn man das nicht vorhat macht sich eine Datensicherung immer gut.

Dafür gibt es unter Linux verschiedene Möglichkeiten, einmal natürlich das Tool dd, mit dem man den gesamten Inhalt der SD-Karte Byte für Byte auf ein anderes Medium, z.B. die Festplatte, kopieren kann. Hier werden aber auch eigentlich leere Teile der SD-Karte mit gesichert, wodurch bei einer 16GB SD-Karte auch (unkomprimiert) ein 16GB-Backup entsteht, egal wie viel Daten man nun eigentlich auf der Karte gespeichert hat. Abhilfe schafft partclone, das die einzelnen Partitionen sichert, und zwar auch nur die wirklich verwendeten Teile. Die Handhabung ist etwas komplexer als bei dd, eine gute Anleitung und ein ausführlicherer Vergleich der beiden Tools ist auf [http://www.bitblokes.de/2013/03/sd-karte-des-raspberry-pi-sichern-dd-oder-partclone/ bitblokes.de] zu finden.

Unter Windows gibt es das Tool [http://sourceforge.net/projects/win32diskimager/ Win32DiskImager] welches komplette bitweise Images (von SD-Karten und USB-Medien) lesen und schreiben kann.

== SoC-Konfiguration ==
Generelle Einstellungen für den SoC, die noch vor dem Starten des Betriebssystems geladen werden, kann man in der Datei '''/boot/config.txt''' ändern.

Hier ist es z.B. möglich, Parameter für die Video-Ausgabe zu setzen, die Speicher-Aufteilung zwischen CPU und GPU zu ändern oder die CPU zu übertakten. Generell sollte man eher vorsichtig mit diesen Optionen umgehen, da sie bei falscher Verwendung auch mal dazu führen können, dass das Betriebssystem nicht mehr bootet oder das System instabil wird.

Eine genaue Auflistung der möglichen Konfigurations-Optionen findet man auf [http://elinux.org/RPiconfig eLinux.org].

== Die GPIO-Schnittstelle ==
[[Datei:Raspberry_Pi_GPIO.jpg|thumb|Die GPIO-Schnittstelle (P1-Anschluss)]]
Für Bastler besonders interessant ist die GPIO-Schnittstelle, diese kann man über verschiedene Wege ansteuern.
=== Belegung der Schnittstelle ===
'''Wichtig:''' Alle GPIO-Pins haben einen Pegel von 3,3V und sind '''nicht''' kompatibel zu 5V! Wenn man versucht, 5V anzuschließen, kann das zur Zerstörung des Raspberry Pi führen! Für Informationen zum Anschließen von 5V-Chips, siehe [[Pegelwandler]] oder [[Raspberry Pi#Erweiterungs-Boards]].
<gallery heights="300" widths="300">
Datei:Raspberry_Pi_GPIO.svg|Der P1-Anschluss
Datei:Raspberry_Pi_GPIO_P2.svg|Der P2-Anschluss (eigentlich das JTAG-Interface der GPU, aber trotzdem mit ein paar nützlichen Pins)
Datei:Raspberry_Pi_GPIO_P5.svg|Der P5-Anschluss auf der Rückseite der Platine
</gallery>

Im oberen Bild ist die Belegung der Anschlüsse zu sehen, die man als GPIO oder zur Stromversorgung nutzen kann. Die Beschriftungen sind genau so wie auf der Platine angebracht und sollen eine Orientierung ermöglichen.
Die 3,3V Anschlüsse (P1-1, P1-17, P2-1 und P5-2) dürfen maximal mit 50 mA belastet werden. Bei den 5V Anschlüssen (P1-2, P1-4 und P5-1) gibt es keine feste Grenze, hier kommt es auf den aktuellen Stromverbrauch des restlichen Boards und der Leistung des Netzteils an. Die Pins GPIO2 (P1-3) und GPIO3 (P1-5) sind jeweils mit einem 1,8 kΩ Pull-Up-Widerstand ausgestattet.

Der Anschluss P3 ist noch ein JTAG-Interface, der Anschluss P6 kann mit einem Reset-Knopf ausgestattet werden. Wenn man die beiden Pins verbindet verursacht das einen Soft Reset der CPU.

Hier eine Übersicht der Alternativ-Funktionen der Pins:
* P1-03 (GPIO2): I2C SDA (siehe [[Raspberry Pi#Der_I2C-Bus]])
* P1-05 (GPIO3): I2C SCL (siehe [[Raspberry Pi#Der_I2C-Bus]])

* P1-07 (GPIO4): GPCLK0 (General Purpose Clock)

* P1-08 (GPIO14): UART TXD (siehe [[Raspberry Pi#Der_UART]])
* P1-10 (GPIO15): UART RXD (siehe [[Raspberry Pi#Der_UART]])
* P1-11 (GPIO17): UART RTS (siehe [[Raspberry Pi#Der_UART]])

* P1-12 (GPIO18): PWM ([[Pulsweitenmodulation]])
* P1-13 (GPIO27): PCM (Puls-Code-Modulation) oder GPCLK1 (General Purpose Clock)

* P1-19 (GPIO10): SPI MOSI (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-21 (GPIO9): SPI MISO (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-23 (GPIO11): SPI SCLK (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-24 (GPIO8): SPI Chip Select 0 (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])
* P1-26 (GPIO7): SPI Chip Select 1 (siehe [[Raspberry Pi#Die_SPI-Schnittstelle]])

=== Ansteuerung per sysfs ===
Ganz nach den UNIX-Prinzipien gibt es die Möglichkeit, auf die Schnittstelle über Dateien im sysfs zuzugreifen. Dafür existiert das Verzeichnis ''/sys/class/gpio/''.

Um einen GPIO-Pin zu verwenden muss man ihn zuerst aktivieren, indem man die Pin-Nummer in ''/sys/class/gpio/export'' schreibt. Wenn man über die Kommandozeile z.B. Pin 4 aktivieren will benutzt man folgendes Kommando:
* echo 4 > /sys/class/gpio/export
Dadurch wird automatisch ein Verzeichnis ''/sys/class/gpio/gpio4/'' erstellt. Nun kann man über die darin enthaltene Datei ''direction'' den Pin als Out- bzw. Input festlegen (standardmäßig sind alle Inputs):
* echo in > /sys/class/gpio/gpio4/direction
für einen Input und
* echo out > /sys/class/gpio/gpio4/direction
für einen Output. Jetzt kann man den Wert des Pins auslesen:
* cat /sys/class/gpio/gpio4/value
oder ihn setzen, wenn es ein Output-Pin ist:
* echo 1 > /sys/class/gpio/gpio4/value
* echo 0 > /sys/class/gpio/gpio4/value
Wenn man den Pin nicht mehr benutzen will sollte man ihn wieder deaktivieren:
* echo 4 > /sys/class/gpio/unexport
Dadurch verschwindet das Verzeichnis ''/sys/class/gpio/gpio4/'' wieder. All das kann man natürlich nicht nur auf der Shell verwenden, sondern auch in jeder Programmiersprache, indem man einfach in die entsprechenden Dateien schreibt bzw. aus ihnen liest.

=== Beispiel: Shell-Blinklicht ===
Dieses kleine Shellscript aktiviert den GPIO-Pin, den man als Argument übergeben hat, setzt ihn als Output und schaltet ihn alle 500ms um:
<pre>
#!/bin/bash
## Check arguments:
if [[ ! $# -eq 1 ]]; then
echo "Usage: $0 GPIO" > /dev/stderr
exit 1
fi
## Activate GPIO:
echo "Activating GPIO$1"
echo $1 > /sys/class/gpio/export || exit 1
## Create trap:
trap "echo 'Deactivating GPIO$1' && echo in > /sys/class/gpio/gpio$1/direction && echo $1 > /sys/class/gpio/unexport" EXIT
## Set as output:
echo "out" > /sys/class/gpio/gpio$1/direction || exit 1
## Reset value:
echo 0 > /sys/class/gpio/gpio$1/value || exit 1
## Blink loop:
while true; do
echo "Switching GPIO$1 on"
echo 1 > /sys/class/gpio/gpio$1/value || exit 1
sleep 0.5
echo "Switching GPIO$1 off"
echo 0 > /sys/class/gpio/gpio$1/value || exit 1
sleep 0.5
done
</pre>
Wenn man an dem entsprechenden Pin eine LED anschließt eignet sich das Script gut zum Testen der GPIO-Schnittstelle.

=== Ansteuerung per Python-Modul ===
Mit dem Modul [https://pypi.python.org/pypi/RPi.GPIO RPi.GPIO] kann man unter Python die GPIO-Pins steuern und auslesen. Auf der Projekt-Website gibt es auch ein Beispiel, mit dem man die Handhabung schnell lernt.

Jedes Python-Script, das dieses Modul nutzen will, muss als root laufen.

=== Ansteuerung mit Java ===
Das [http://pi4j.com/ Pi4J-Projekt] ermöglicht unter Java die Verwendung der GPIO-Pins, dem UART, des I2C-Bus und der SPI-Schnittstelle. Eine ausführliche Anleitung gibt es auf der Website.

Jedes Java-Programm, dass dieses Modul nutzen will, muss als root laufen.

=== Ansteuerung mit WiringPi ===
[https://projects.drogon.net/raspberry-pi/wiringpi/ WiringPi] bietet ein Kommandozeilen-Tool ('''gpio''', Details siehe '''man gpio'''), das man auch als normaler Nutzer (ohne root-Rechte) verwenden kann und eine C-Bibliothek (Header-Datei ''wiringPi.h'' und Linker-Option ''-lwiringPi''), mit der man die GPIO-Pins in C-Programmen verwenden kann.

Auf der Website gibt es Beispiele und eine Installationsanleitung. Bei Arch Linux ARM ist es auch in den Paketquellen und kann per Paketverwaltung installiert werden:
* pacman -S wiringpi

== Der I2C-Bus ==
Auch auf den I2C-Bus des Raspberry Pi kann man zugreifen. Die Pins dafür liegen an P1-03 (GPIO2, SDA) und P1-05 (GPIO3, SCL).
=== Ansteuerung per devfs ===
Den I2C-Bus kann man direkt über die Datei '''/dev/i2c-0''' oder '''/dev/i2c-1''' erreichen, je nach Version des Boards und gewünschter Schnittstelle.
=== Ansteuerung per i2c-tools ===
Komfortabler geht das aber über die i2c-tools. Dazu muss man erst einmal das Paket aus den Arch Linux ARM Paketquellen installieren:
* pacman -S i2c-tools
Nun muss man die nötigen Kernel-Module laden:
* modprobe i2c-bcm2708
* modprobe i2c-dev
Soll das beim Systemstart automatisch passieren, legt man eine *.conf-Datei im Verzeichnis '''/etc/modules-load.d/''' mit folgendem Inhalt an:
<pre>i2c-bcm2708
i2c-dev</pre>
Jetzt sollten folgende Kommandozeilen-Tools funktionieren:
* '''i2cdetect''' zum Auflisten der I2C-Busse und zum Anzeigen der Eigenschaften und Geräte
* '''i2cdump''' zum Herausfinden von I2C-Registern
* '''i2cget''' zum Lesen von I2C-Registern
* '''i2cset''' zum Setzen von I2C-Registern
Die Manpages und Hilfe-Meldungen der einzelnen Tools geben Auskunft über die genaue Verwendung. Wichtig ist, dass man den I2C-Bus 0, '''nicht''' den I2C-Bus 1 verwendet. Ein kleines Beispiel gibt es auch in der Ausgabe 5 des MagPi im Artikel „Temperature Sensor“. Dort wird ein Temperatursensor per I2C ausgelesen.
=== Errata ===
Der I2C Controller kann aufgrund eines Implementierungsfehlers des Chips nicht zuverlässig mit clock stretching genutzt werden. Insbesondere bei Mikrocontrollern als I2C Slave ist dies jedoch nur schwer zu vermeiden, weshalb die Kopplung eines Mikrocontrollers per I2C problematisch ist.

== Der UART ==
Die Pins für den UART liegen auch an P1. TXD an Pin 08 (GPIO14), RXD an Pin 10 (GPIO15) und RTS an Pin 11 (GPIO17).

Zugreifen kann man über das devfs, genauer gesagt über die Datei '''/dev/ttyAMA0'''. Um zu testen, ob das funktioniert, kann man minicom benutzen:
* pacman -S minicom
* minicom -b 115200 -o -D /dev/ttyAMA0

== Die SPI-Schnittstelle ==
Die Pins für die SPI-Schnittstelle liegen genau wie I2C und UART an P1. MOSI an Pin 19 (GPIO10), MISO an Pin 21 (GPIO9), SCLK an Pin 23 (GPIO11), CS0 an Pin 24 (GPIO8) und CS1 an Pin 26 (GPIO7).

Der Zugriff erfolgt über die Dateien '''/dev/spidev0.0''' (Gerät an CS0) und '''/dev/spidev0.1''' (Gerät an CS1), in die man direkt schreiben und aus denen man auch direkt lesen kann.

== Audio-Ausgabe ==
[[Datei:Raspberry_Pi_Audio.jpg|thumb|Der 3,5mm Klinke-Anschluss]]
Der Raspberry Pi verfügt über zwei Möglichkeiten der Audio-Ausgabe, einmal digital per HDMI und wenn kein Display angeschlossen ist wird automatisch auf die analoge Ausgabe per 3,5mm-Klinken-Anschluss umgeschaltet.

Nach der Installation von Arch Linux ARM funktioniert jedoch vorerst keine der beiden Möglichkeiten, da das nötige Kernel-Modul nicht automatisch geladen wird.

Manuell lässt es sich mit '''modprobe''' laden, beim nächsten Neustart ist das Problem dann jedoch wieder da:
* modprobe snd_bcm2835
Wenn man will, dass das Modul bei jedem Start automatisch geladen wird, muss man eine *.conf Datei im Verzeichnis /etc/modules-load.d/ erstellen und dort den Namen des Moduls hineinschreiben. Es bietet sich z.B. der Name sound.conf an, über die Kommandozeile ist die Datei schnell erstellt:
* echo "snd_bcm2835" > /etc/modules-load.d/sound.conf
Jetzt sollte die Audio-Ausgabe problemlos funktionieren. Testen kann man das beispielsweise per '''aplay''', das im Paket '''alsa-utils''' enthalten ist:
* pacman -S alsa-utils
* aplay name_der_datei.wav
In diesem Paket ist auch '''alsamixer''' enthalten, ein Programm mit dem man über eine ncurses-Oberfläche die Ausgabe-Lautstärke regeln kann.

Man muss beachten, dass nur '''root''' und Nutzer in der Gruppe '''audio''' auf die Soundkarte zugreifen können. Wenn man nicht als '''root''' arbeiten will sollte man seinen Benutzer der Gruppe hinzufügen:
* gpasswd -a USERNAME audio

=== Standard-Ausgabegerät ===
Normalerweise wird der Sound automatisch über HDMI ausgegeben, wenn das angeschlossene Gerät das unterstützt, andernfalls über den Klinke-Anschluss. Will man das ändern, z.B. weil man einen Monitor per HDMI angeschlossen hat, den Sound aber trotzdem über die Anlage hören will, geht das ganz schnell über die Kommandozeile:
* amixer -c 0 cset numid=3 <nummer>
Dabei muss man ''<nummer>'' durch eine 0 für automatisches Wechseln, eine 1 für den Klinke-Anschluss oder eine 2 für den HDMI-Anschluss ersetzen. Soll das bei jedem Systemstart automatisch ausgeführt werden, erstellt man bei Arch Linux eine Service-Datei für systemd, z.B. so:
<pre>
[Unit]
Description=Set Default Audio Output

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer -c 0 cset numid=3 <nummer>

[Install]
WantedBy=multi-user.target
</pre>
Hier ersetzt man wieder ''<nummer>'' durch das gewünschte Ziel, speichert die Datei unter ''/etc/systemd/system/default-audio.service'' ab und aktiviert den soeben erstellten Service noch:
* systemctl enable default-audio.service
Ab dem nächsten Systemstart wird dadurch das Ausgabegerät automatisch eingestellt.

== Erweiterungs-Boards ==
Für die GPIO-Schnittstelle des Raspberry Pi gibt es verschiedene Erweiterungs-Boards, die zusätzliche Schnittstellen bereitstellen und 3,3V zu 5V Pegelwandler besitzen. Durch diese kann man den Raspberry Pi in bestehende, 5V-basierte Schaltungen und Projekte einbinden.

=== Prototyping-Board für den Raspberry Pi ===
In der Ausgabe 16 des embedded projects journal wurde auf Seite 13 ein Prototyping-Board für den Raspberry Pi vorgestellt.

Das Board besitzt eine Spannungsversorgung, an die man 7 bis 15V anschließen kann und die auch den Raspberry Pi mitversorgt. Dadurch wird ein per microUSB angeschlossenes Netzteil überflüssig. Außerdem gibt es einen Pegelwandler, der acht GPIO-Pins des Raspberry Pi als 5V-GPIO-Pins zur Verfügung stellt und einen I2C-Pegelwandler, durch den auch hier der Anschluss von 5V-Chips möglich wird.

Weitere Informationen gibt es im embedded projects journal und auf der [http://bastelstube.rocci.net/projects/MBS19_RasPi-GPIO/RasPi-GPIO.html Website des Projekts].

=== Berrybush Pi ===
Ebenfalls in der Ausgabe 16 des embedded projects journal wurde auf Seite 28 der „Berrybush Pi“ vorgestellt, der ein paar mehr Schnittstellen als das Prototyping-Board bietet.

Auch dieses Board bietet eine Spannungsversorgung für den Raspberry Pi und acht 5V-GPIO-Pins, diese sind jedoch mit Darlington-Transistoren und LEDs zur Status-Anzeige ausgestattet. Außerdem gibt es eine 3,3V (sic) SPI-Schnittstelle, die einfach zum Raspberry Pi durchgeschleift wird, einen 5V-I2C-Bus (mit Pegelwandler zum Raspberry Pi), einen RS485-Bus und eine RS232-Schnittstelle, die jedoch in den RS485-Bus gespeist wird.

Als kleines Highlight gibt es noch die Möglichkeit, ein LCD anzuschließen. Dafür sind Portexpander und Potentiometer für Helligkeit und Kontrast vorhanden.

Genauere Informationen, Schaltpläne und Bilder gibt es im embedded projects journal.

[http://www.mikrocontroller.net/topic/epj-16-seite-28 Weitere Informationen]

=== Arduino Shield Bridge ===
Mit diesem Board aus Spanien kann man Arduino-Aufsteckplatinen mit dem Raspberry Pi verwenden.
[http://www.cooking-hacks.com/index.php/raspberry-pi-to-arduino-shield-connection-bridge.html Cooking-hacks.com]

Dazu existiert eine Library "arduPi":
"In order to make complete the compatibility we have created the arduPi library which allows to use Raspberry with the same code used in Arduino. To do so, we have implemented conversion functions so that you can control in the same way as in Arduino all the I/O interfaces: i2C, SPI, UART, analog, digital, in Raspberry Pi."

=== I/O Module seriell/USB ===

Alternativ bieten sich Schnittstellen-Erweiterungen über seriellen Port oder USB an, zum Beispiel mit einem handelsüblichen AVR Mikrocontroller-Modul und der Firmware von Stefan Frings
[http://stefanfrings.de/avr_io/].

=== Gertboard ===
Webseite: http://www.raspberrypi.org/archives/tag/gertboard
Eine I/O-Aufsteckplatine mit zusätzlichem Mikrocontroller (bisher PIC, jetzt ATMega)

=== I2C-Repeater-Board für Raspberry PI ===
Die kleine Platine von "Horter & Kalb" wird direkt auf die GPIO-Schnittstelle des Raspberry PI gesteckt.
Es macht die Pegelanpassung von 3,3 auf 5V für den SDA- und den SCL-Pin.

Außerdem kann auch das INT-Signal, welches von digitalen Eingabebaugruppen verwendet wird, über den GPIO 17 abgefragt werden.

Das Board ist hier ausführlich beschrieben: http://www.horter.de/blog/i2c-repeater-pegelanpassung-fuer-raspberry-pi/

Im Onlineshop unter www.horter.de ist der Bausatz für 9,90€ zu haben.

== Projekte ==
Um den Raspberry Pi hat sich inzwischen eine große Community gebildet, von der immer wieder neue Projekte mit und Erweiterungen für den Raspberry Pi entwickelt werden. Eine Quelle, über die man von den Projekten erfährt ist z.B. der offizielle [http://www.raspberrypi.org/ Raspberry Pi Blog], aber es gibt auch noch viele andere Möglichkeiten, sich zu informieren.

Einige dieser Möglichkeiten und einige ausgewählte Projekte werden in diesem Artikel vorgestellt.

=== The MagPi ===
[http://www.themagpi.com/ The MagPi] ist ein freies Online-Magazin, das (normalerweise) monatlich erscheint und in dem interessante Projekte genauer vorgestellt werden. Außerdem gibt es Programmier-Tutorials, Anleitungen für Linux-Software und Interviews.

==== Ausgabe 1 ====
Die Ausgabe 1 vom Mai 2012 behandelt folgende Themen:
* „The Pioneers“ - eine kleine Übersicht, wie es zur Entwicklung des Raspberry Pi kam
* „Skutter“ - ein Roboterarm für den Raspberry Pi
* „RacyPy“ - eine Linux Live-CD, basierend auf Puppy Linux und speziell angepasst für einen leichten Einstieg in die Programmierung
* eine Anleitung zum Installieren von Debian in einer virtuellen Maschine
* „Scratch“ - eine Programmiersprache und Entwicklungsumgebung zum kinderleichten Einstieg in die Programmierung
* „the python pit“ - ein Einstieg in die Programmierung mit Python

==== Ausgabe 2 ====
Die Ausgabe 2 vom Juni 2012 behandelt folgende Themen:
* „PiSetup“ - eine Anleitung zum Einrichten des Raspberry Pi
* „In Control“ - ein Einstieg in die GPIO-Programmierung mit dem Raspberry Pi und Python
* „Pi Dissection“ - ein genauerer Blick auf die Einzelteile des Raspberry Pi
* Fortsetzung von „Skutter“ aus Ausgabe 1
* „Command Line Clinic“ - eine Einführung in die Benutzung der Linux-Shell
* „Computer Music“ - eine Anleitung zur Installation von „Schism Tracker“, einem Sequencer-Programm
* Fortsetzung der Debian-Anleitung aus Ausgabe 1, diesmal mit einer Anleitung zum Einrichten und Verwenden von Python
* Fortsetzung von „the python pit“ aus Ausgabe 1

==== Ausgabe 3 ====
Die Ausgabe 3 vom Juli 2012 behandelt folgende Themen:
* eine Anleitung zum automatischen Starten der grafischen Oberfläche von Debian
* Fortsetzung von „In Control“ aus Ausgabe 2
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2
* Fortsetzung von „Skutter“ aus Ausgabe 1 und 2
* „To Protect and Serve your Raspberry Pi“ - eine einfache Anleitung, um die GPIO-Pins des Raspberry Pi vor Kurzschlüssen zu schützen
* „Meeting Pi“ - Vorschäge, wie man Kinder an den Raspberry Pi heranführen kann
* „The C Cave“ - ein C-Tutorial
* Fortsetzung von „Scratch“ aus Ausgabe 1
* Fortsetzung von „the python pit“ aus Ausgabe 1 und 2
* „Programming Fundamentals“ - ein Artikel, der die Grundlagen (fast) aller Programmiersprachen auf einfachem Weg zeigen will

==== Ausgabe 4 ====
Die Ausgabe 4 vom August 2012 behandelt folgende Themen:
* Fortsetzung von „In Control“ aus Ausgabe 2 und 3
* „3-Axis Accelerometer“ - eine Anleitung für einen Beschleunigungs-Sensor am Raspberry Pi
* „Kernow Pi Launch“ - ein Artikel darüber, wie der Raspberry Pi an Schulen gebracht wurde
* „MagPi Exclusive Interview“ - ein Interview mit Eben und Liz von der Raspberry Pi Foundation
* „How to customise your LXDE menu“ - eine Anleitung zum Anpassen von LXDE
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2 und 3
* Fortsetzung von „The C Cave“ aus Ausgabe 3
* Fortsetzung von „Scratch“ aus Ausgabe 1 und 3
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2 und 3

==== Ausgabe 5 ====
Die Ausgabe 5 vom September 2012 behandelt folgende Themen:
* „Steady Hands“ - eine Anleitung zum Bau eines „Heißer Draht“-Spiels mit dem Raspberry Pi
* „Temperature Sensor“ - eine Anleitung zum Anschluss eines I2C-Temperatursensors an den Raspberry Pi
* „XBMC Media Center“ - eine Einführung in Rasbbmc, einer HTPC-Distribution für den Raspberry Pi
* „Squeezy or Wheezy?“ - ein Vergleich von Debian 6 „Squeeze“ und Debian 7 „Wheezy“
* Fortsetzung von „Command Line Clinic“ aus Ausgabe 2, 3 und 4
* Fortsetzung von „The C Cave“ aus Ausgabe 3 und 4
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3 und 4
* „RasPiThon 2012“ - ein Bericht über den Rasbperry Pi Programmier-Marathon
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3 und 4

==== Ausgabe 6 ====
Die Ausgabe 6 vom Oktober 2012 behandelt folgende Themen:
* „Skutter Returns“ - Fortsetzung von „Skutter“ aus Ausgabe 1, 2 und 3
* „Portable Power for your Pi“ - eine Anleitung für eine mobile Stromversorgung
* „Star Letter: An FET Buffer Stage for GPIO Access“ - eine Möglichkeit, wie man die GPIO-Pins des Raspberry Pi belastbarer machen kann
* „Pumpkin Pi“ - ein Kürbis mit Bewegungs-Sensor und RGB-LEDs
* „Camera Pi“ - ein Interview mit David Hunt, einem Bastler, der seine Kamera mit einem Raspberry Pi ausgestattet hat
* „Our Raspberry Pi Summer“ - ein Beispiel für ein kleines Spiel, das mit Scratch programmiert wurde
* „Baby steps in a Big World“ - ein Ada-Tutorial
* Fortsetzung von „The C Cave“ aus Ausgabe 3, 4 und 5
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4 und 5
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4 und 5

==== Ausgabe 7 ====
Die Ausgabe 7 vom November 2012 behandelt folgende Themen:
* „Raspberry Pi & Arduino“ - ein Artikel über die Kommunikation zwischen Arduino und Raspberry Pi mithilfe von Python
* „A little Ray of Sunshine“ - eine Solar-Stromversorgung für den Raspberry Pi und andere USB-Geräte
* „The Raspberry Ladder Board“ - ein Board zum Einstieg in die GPIO-Programmierung mit dem Raspberry Pi
* „Interrupts and Other Activities with GPIO Pins” - eine Anleitung für Interrupts und GPIO-Pins im Allgemeinen auf dem Raspberry Pi
* „Raspbian“ - ein Interview mit Mike Thompson, dem Erfinder von Raspbian
* „Turbopi“ - eine Anleitung zum Übertakten des Raspberry Pi
* „Pi-Evolution“ - eine Übersicht über die Entwicklung des Raspberry Pi
* „Make“ - eine Einführung in GNU Make und Makefiles
* „Welcome to the C++ Cache!“ - eine Einführung in C++
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5 und 6
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5 und 6

==== Ausgabe 8 ====
Die Ausgabe 8 vom Dezember 2012 behandelt folgende Themen:
* „Skutter Returns“ - Fortsetzung von „Skutter“ aus Ausgabe 1, 2 und 3 bzw. „Skutter Returns“ aus Ausgabe 6
* „The Santa Trap“ - Heimautomation mit dem Raspberry Pi
* „Control your Arduino board with Raspberry Pi and Python“ - ein Python-Modul zum Steuern eines Arduino
* „PiGauge“ - eine Anleitung, wie man Servo-Motoren übers Internet mithilfe des Raspberry Pi steuern kann
* „Quick2Wire“ - Erweiterungs-Board für den Raspberry Pi
* „Kickstarter“ - eine Vorstellung der Kickstarter-Kampagne, um The MagPi auf Papier zu bannen
* „Programming the Raspberry Pi: Getting Started with Python“ - eine kurze Vorstellung des gleichnamigen Buches von Simon Monk
* „pibow interview“ - ein Interview mit den Erfindern des PiBow, einem Gehäuse für den Raspberry Pi
* „CESIL Pi“ - ein CESIL Programmier-Tutorial für den Raspberry Pi
* Fortsetzung von „Welcome to the C++ Cache!“ aus Ausgabe 7
* Fortsetzung von „Baby steps in a Big World“ aus Ausgabe 6
* „MySQL Database Bootcamp“ - eine Einführung in MySQL
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6 und 7

==== Ausgabe 9 ====
Die Ausgabe 9 vom Februar 2013 (Januar wurde ausgelassen) behandelt folgende Themen:
* „adafruit Interview“ - Interview mit der Gründerin von adafruit, einem Shop für DIY Elektronik
* „WebIOPi“ - eine REST-Schnittstelle, um die GPIO-Pins des Raspberry Pi per Javascript zu steuern
* „Backup your Raspberry Pi“ - eine Anleitung für die Datensicherung der SD-Karte
* „Pi Interface Board Review Quick2Wire“ - ein genauerer Blick auf das Erweiterungs-Board „Quick2Wire“, das in Ausgabe 8 schon kurz gezeigt wurde
* „RISC OS Pi“ - eine Anleitung zur Installation von RISC OS auf dem Raspberry Pi
* „Installing & Configuring ArchLinux“ - eine Anleitung zur Installation von Arch Linux auf dem Raspberry Pi, die auch die Installation von XFCE umfasst
* „Introducing Vala“ - ein kleines Vala Programmier-Tutorial für den Raspberry Pi und das LedBorg Erweiterungs-Board
* Fortsetzung von „The C Cave“ aus Ausgabe 3, 4, 5 und 6
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6 und 7
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6, 7 und 8

==== Ausgabe 10 ====
Die Ausgabe 10 vom März 2013 behandelt folgende Themen:
* Fortsetzung von „WebIOPi“ aus Ausgabe 9
* „Try a Cocktail of Projects“ - ein Artikel, der verschiedene Erweiterungs-Möglichkeiten für den Raspberry Pi zeigt
* „Backing up - part 2“ - Fortsetzung von „Backup your Raspberry Pi“ aus Ausgabe 9
* „Bash Gaffer Tape“ - ein Bash-Tutorial
* „Charm on the Raspberry Pi“ - ein Charm Programmier-Tutorial für den Raspberry Pi
* „C++ Cache”: Fortsetzung von „Welcome to the C++ Cache!“ aus Ausgabe 7 und 8
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6, 7 und 9
* Fortsetzung von „the python pit“ aus Ausgabe 1, 2, 3, 4, 5, 6, 7, 8 und 9

==== Ausgabe 11 ====
Die Ausgabe 11 vom April 2013 behandelt folgende Themen:
* Heizungssteuerung mithilfe des Raspberry Pi über ein Smartphone
* eine Vorstellung vom „Power and I/O Expansion Board“
* eine Anleitung zum Einrichten eines WLAN-Access-Points auf dem Raspberry Pi (per USB-WLAN-Dongle)
* Vorstellung von der Minecraft Pi-Edition
* „Printing with Cups“: Configuring Cups
* „Setting up a simple intranet“ mit einer Anleitung zum Einrichten vom Apache HTTPD
* eine Einführung in die Assembler-Programmierung auf dem Raspberry Pi
* Fortsetzung von „Charm on the Raspberry Pi“ aus Ausgabe 10
* kurze Anleitung zum Verwenden von Farben auf der Kommandozeile
* Fortsetzung von „Scratch“ aus Ausgabe 1, 3, 4, 5, 6, 7, 9 und 10

=== Raspberry Pi multi-effects ===
Ein Musiker hat mit einem Raspberry Pi, einem Arduino Uno und einer USB-Soundkarte ein Gitarren-Effektboard gebaut und das Ganze in seinem Blog [https://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ beschrieben]. Das alles sieht im [https://www.youtube.com/watch?v=NwJNeouLqgQ Video] noch etwas sperrig aus, es sollte aber kein Problem sein, die Soundkarte und den Raspberry Pi auch noch mit ins Effektboard zu integrieren.

Als Software verwendet er Raspbian, also das Standard-Betriebssystem des Raspberry Pi, und [http://puredata.info/ Pure Data], eine Echtzeit-Umgebung für Audio-, Video- und Grafik-Verarbeitung. Diese ist jedoch auch in den Arch Linux ARM Paketquellen verfügbar, einem Versuch, das ganze auch mit Arch Linux auszuprobieren, steht also theoretisch nichts im Wege.

Die Installation und Konfiguration von Pure Data hat er ebenfalls in seinem Blog [https://guitarextended.wordpress.com/2013/01/28/rpi-as-guitar-effects-processor-installing-and-configuring-pd/ beschrieben].

=== Raspberry Pi guitar tuner ===
Ein anderer Nutzer hat ein Gitarren-Stimmgerät gebaut. Dazu hat er einen Raspberry Pi, eine USB-Webcam zur Ton-Aufnahme, eine 7-Segment-Anzeige zur Anzeige des Tons und 15 LEDs zur Anzeige der Abweichung vom Ton verwendet.

Ausgewertet und angesteuert wird das Ganze über ein selbstgeschriebenes Java-Programm, ein Video und ein paar zusätzliche Informationen gibt es auf [https://www.youtube.com/watch?v=oB4F5VhzQf8 YouTube].

=== Circadian Lighting ===
Auch für Menschen, die sich mit dem Morgen manchmal schwer tun, gibt es ein Projekt mit dem Raspberry Pi, das im Blog [http://www.raspberrypi.org/archives/3267 vorgestellt wurde]. In Verbindung mit ein paar RGB-LEDs kann man den Raspbrry Pi zu einem Wecker machen, der einen nicht mit lautem, nervigen Piepsen aus dem Schlaf reißt, sondern langsam in Verbindung mit einem künstlichen Sonnenaufgang weckt. Fehlt nur noch ein Relais, über das die Kaffeemaschine angeschaltet wird, und der Morgen ist perfekt.

Bei diesem Projekt gibt es sogar den [https://github.com/rasathus/circadianLighting Quellcode], eine [http://rasathus.blogspot.co.uk/2013/01/circadian-lighting-part-one.html Hardware-Liste] und ein [https://www.youtube.com/watch?v=Q9_tqoOkmCU Video], das einige der Funktionen zeigt. Und mit ein paar Python-Kenntnissen kann man alles seinen Bedürfnissen anpassen und erweitern.

=== Raspberry Leaf ===
Die einfachsten Ideen sind doch manchmal die Besten. „Dr. Monk” hat in seinem Blog eine Pinbelegung des Raspberry Pi [http://www.doctormonk.com/2013/02/raspberry-pi-and-breadboard-raspberry.html veröffentlicht], die (in der richtigen Größe ausgedruckt) genau auf den P1-GPIO-Anschluss des Raspberry Pi passt. So vergisst man nie die Pinbelegung, wenn man gerade mal wieder mit dem Raspberry Pi bastelt und auch ein falsches Anschließen, das zur Zerstörung des Mini-Computers oder der angeschlossenen Teile führen kann, passiert nicht mehr so leicht.

=== raspberry-tools ===
Eine Tool-Sammlung für den Raspberry Pi, veröffentlicht unter der GNU General Public License Version 2 und gehostet auf [https://github.com/rookies/raspberry-tools github]. Momentan enthält diese Sammlung nur ein Programm, es folgen aber noch weitere nützliche Tools.

==== scope ====
Scope ist Teil von raspberry-tools. Es zeichnet digitale Signale von einem oder mehreren GPIO-Pins auf und bereitet die Daten für eine Auswertung mit [http://xoscope.sourceforge.net/ xoscope] auf.

Wenn man sich den Quellcode geholt hat, muss man erst einmal das Hauptprogramm für den Raspberry Pi kompilieren. Das geht entweder direkt auf dem Raspberry Pi oder per Cross-Compiler.
* g++ -o RasPi_logGPIO RasPi_logGPIO.cpp
Nachdem sowohl die entstandene Datei ''RasPi_logGPIO'' als auch das Script ''RasPi_logGPIO.sh'' im gleichen Ordner auf dem Raspberry Pi sind, kann man die Aufzeichnung starten:
* ./RasPi_logGPIO.sh [Liste mit GPIO-Pins] > ausgabedatei.txt
Für die Pins 14, 31 und 23 sieht das Kommando z.B. so aus:
* ./RasPi_logGPIO.sh 14 31 23 > ausgabedatei.txt
Die Aufzeichnung kann mit Strg+C gestoppt werden.

Jetzt kann man die entstandene Datei (z.B. hier ausgabedatei.txt) normalisieren und ins xoscope-Format umwandeln, das funktioniert auch problemlos auf einem anderen Computer:
* ./RasPi_normalizeGPIO.py ausgabedatei.txt > ausgabedatei.dat
Nun entsteht die Datei ''ausgabedatei.dat'', die man mit xoscope ansehen kann:
<gallery heights="300" widths="300">
Datei:RasPiTools_scope_sample1.png|eine Beispiel-Aufnahme
Datei:RasPiTools_scope_sample2.png|die gleiche Aufnahme, vergrößert
</gallery>
Dazu muss man nur die Datei laden und die entsprechenden Memory-Einträge anzeigen lassen. In diesem Beispiel ist Pin 14 in Mem A, Pin 31 in Mem B und Pin 23 in Mem C, also genau in der Reihenfolge, in der man die Pin-Nummern dem Programm übergeben hat.

== Anhang ==
=== Stromversorgung ===
[[Datei:Raspberry_Pi_Power.jpg|thumb|Der microUSB-Anschluss zur Stromversorgung]]
Um den Raspberry Pi mit Strom zu versorgen gibt es verschiedene Möglichkeiten. Entscheidend ist nur, dass möglichst konstante 5V bei bis zu 700 mA auf einem microUSB-Stecker geliefert werden.
==== mit USB-Netzteil ====
Wenn man ein genügend starkes USB-Netzteil mit einem microUSB-Kabel verbindet hat man eine passende Stromversorgung für den Raspberry Pi.
Gut funktioniert zum Beispiel das iPhone-Ladegerät, aber auch andere, günstigere Netzteile sollten keine Probleme machen.
==== Netzteil selbst bauen ====
Wenn man kein USB-Netzteil zur Hand hat kann man auch selbst ein Steckernetzteil, das 5V Gleichspannung liefert, mit einem microUSB-Kabel zusammenlöten.

Dafür braucht man erst einmal ein microUSB-Kabel und ein passendes Steckernetzteil. (siehe Abb. 1)
Man entfernt den USB-A-Stecker und befreit das Kabelende ein Stück von seinem Mantel, es kommen vier Adern zum Vorschein. (siehe Abb. 2)
Uns interessiert die grüne und die weiße Ader nicht, da wir keine Daten übertragen wollen.
Jetzt muss auch noch der Stecker vom Netzteil entfernt und die Adern abisoliert werden. (siehe Abb. 3)
Bei manchen Netzteilen ist eine Markierung für Plus- oder Minus-Pol angebracht. Wenn das nicht der Fall ist, muss man mit einem Multimeter nachmessen. (siehe Abb. 4)
Nun isoliert man auch noch die schwarze und rote Ader des USB-Kabels ab und verlötet die schwarze Ader mit dem Minus-Pol des Netzteils und die rote Ader mit dem Plus-Pol des Netzteils. Danach packt man um die Adern jeweils einen Schrumpfschlauch zur Isolation. Wenn man um die ganze Verbindung noch einen großen Schrumpfschlauch packt wird die Verbindung nochmal um einiges stabiler.
(siehe Abb. 5)
Es ist auch möglich den Raspberry Pi über jedes alte PC Netzteil zu betreiben, bei einem alten 300 Watt Netzteil hat man einen Verlust im Leerlauf von ca. 8 Watt.
Dafür kann man aber einige andere Komponenten (LEDs, usw.) mitbetreiben.
Hier ein Link zu einem deutschen Youtube Video:
http://www.youtube.com/watch?v=hqevlVn1Osk

Wer kein Micro-USB Kabel opfern möchte, kann zwar den GPIO-Pinheader verwenden, dabei umgeht man aber die interne Eingangssicherung sowie die TVS-Diode (Überspannungsschutz). Siehe Schema, Seite 1: http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspberry-Pi-Schematics-R1.0.pdf
<gallery>
Datei:RasPi_Netzteil_Selbstbau1.jpg|Abb. 1: Die Ausgangsmaterialien
Datei:RasPi_Netzteil_Selbstbau2.jpg|Abb. 2: Das USB-Kabel ohne Mantel mit der roten (+5V), schwarzen (GND), grünen (Data+) und weißen (Data-) Ader
Datei:RasPi_Netzteil_Selbstbau3.jpg|Abb. 3: Das Netzteil mit abisolierten Kabelenden
Datei:RasPi_Netzteil_Selbstbau4.jpg|Abb. 4: Das Multimeter zeigt eine positive Zahl an, daher ist das Kabel mit der roten Klemme der Plus-Pol, das Kabel mit der schwarzen Klemme der Minus-Pol.
Datei:RasPi_Netzteil_Selbstbau5.jpg|Abb. 5: Das fertige Netzteil, die Verbindung ist mit einem Schrumpfschlauch geschützt.
</gallery>

=== USB-Geräte ===
[[Datei:Raspberry_Pi_USB.jpg|thumb|Die beiden USB Host-Anschlüsse]]
Generell kann man am Raspberry Pi alle USB-Geräte verwenden, die vom Linux-Kernel unterstützt werden und somit auch an anderen Linux-PCs funktionieren.

Es ist allerdings zu beachten, dass die USB-Ports nur vergleichsweise wenig Strom liefern können (nicht die vollen 500 mA, die laut USB2.0 Standard maximal möglich sind), für größere Verbraucher wie z.B. 2,5-Zoll-Festplatten ohne externe Stromversorgung muss man daher einen externen USB-Hub mit Stromversorgung verwenden.
==== Maus & Tastatur ====
Da es für Mäuse und Tastaturen Standard-Profile gibt, die auch von allen (bis auf extrem wenige Ausnahmefälle) Geräten eingehalten werden, sollte es hier keine Probleme geben. Die Eingabegeräte sollten sofort verwendbar sein und auch Hot-Plugging stellt im Normalfall kein Problem dar.
==== USB-Sticks & USB-Festplatten ====
Wenn man seinem Raspberry Pi zusätzlichen Speicherplatz verpassen will bietet es sich an, USB-Sticks bzw. -Festplatten anzuschließen. Da es auch hier Standard-Profile gibt sollten diese sofort vom Linux-Kernel erkannt werden. Einhängen ([https://de.wikipedia.org/wiki/Mounten mounten]) muss man sie jedoch unter Arch Linux ARM generell selbst, wenn man nicht einen [https://de.wikipedia.org/wiki/Fstab fstab-Eintrag] erstellt hat oder eine Desktop-Oberfläche installiert hat, die das automatisch erledigt.
==== WLAN-Sticks ====
Wird der WLAN-Stick vom Kernel erkannt (erkennbar daran, dass ein entsprechendes Interface von '''ifconfig -a''' aufgelistet wird), kann man ein Netzwerk-Profil mit [https://wiki.archlinux.org/index.php/Netcfg netcfg] (Quasi-Standard unter ArchLinux, bei dem die Profile über Konfigurationsdateien erstellt werden), dem [https://wiki.archlinux.org/index.php/NetworkManager NetworkManager] oder [https://wiki.archlinux.org/index.php/Wicd Wicd] erstellen. Sollte die Karte nicht erkannt werden, hilft eventuell ein Blick auf die [https://wiki.archlinux.org/index.php/Wireless_Setup Wireless Setup] Seite im ArchLinux Wiki.
==== TV-Karten ====
Will man den Raspberry Pi als HTPC verwenden, kann es sinnvoll sein, eine TV-Karte per USB anzuschließen.
Hier gibt es generell 4 Möglichkeiten:
* '''DVB-T''', also digitales Fernsehen, das per Funk ausgestrahlt wird - kostenlos, jedoch nicht überall verfügbar
* '''DVB-S''', also digitales Fernsehen, das per Satellit ausgestrahlt wird - kostenlos und generell überall verfügbar, jedoch wird eine Satelliten-Schüssel benötigt
* '''DVB-C''', also digitales Fernsehen, das über das Kabelnetz ausgestrahlt wird - Kosten für den Kabelanschluss fallen an, Sender-Angebot vom Kabelanbieter abhängig
* '''Analog-TV''', also analoges Fernsehen, das über das Kabelnetz ausgestrahlt wird - Kosten für den Kabelanschluss fallen an, kein HD, Sender-Angebot vom Kabelanbieter abhängig

Nicht alle Geräte werden von Linux unterstützt, eine Übersicht, die nach Übertragungstechnik (DVB-T/-S/-C oder Analog) und Anschluss-Art (beim Raspberry Pi immer USB) geordnet ist, findet man im [http://linuxtv.org/wiki/index.php/Hardware_Device_Information LinuxTVWiki], zu dem man natürlich auch selbst beitragen kann, wenn man ein Gerät getestet hat.
==== Soundkarten ====
Da der Klinke-Ausgang des Raspberry Pi nicht mit einem D/A-Wandler, sondern nur per PWM funktioniert, ist die Sound-Qualität nicht gerade überragend. Wenn man das verbessern will, oder wenn man Sound per Line-Eingang oder per Mikrofon aufnehmen will, bietet es sich an, eine USB-Soundkarte anzuschließen.

Ist man unsicher, ob die Soundkarte unterstützt wird, hilft ein Blick ins [http://www.alsa-project.org/main/index.php/Matrix:Main Wiki vom ALSA-Projekt].

== Downloads ==

* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-02-11/archlinux-hf-2013-02-11.zip.torrent Torrent-Download von Arch Linux ARM 2013-02-11]
* [http://downloads.raspberrypi.org/images/archlinuxarm/archlinux-hf-2013-02-11/archlinux-hf-2013-02-11.zip HTTP-Download von Arch Linux ARM 2013-02-11] (SHA-1: 1d2508908e7d8c899f4a5284e855cb27c17645dc)

== Siehe auch ==

* [http://www.raspberrypi.org/ offizielle Website des Raspberry Pi] (englisch)
* [https://de.wikipedia.org/wiki/Raspberry_Pi Wikipedia: Raspberry Pi] (deutsch)
* [http://www.themagpi.com/ The MagPi] (englisch)
* [http://archlinuxarm.org/ Arch Linux ARM] (englisch)
* [https://www.archlinux.org/ Arch Linux] (englisch)
* [https://de.wikipedia.org/wiki/Arch_Linux Wikipedia: Arch Linux] (deutsch)
* [http://www.kammerath.net/asterisk-virtuelle-telefonanlage.html Asterisk auf dem Raspberry Pi] (deutsch)

[[Kategorie:Raspberry Pi]]

Raspberry Pi als Universalprogrammer

2015-01-31T07:50:20Z

Prx: /* Der µC meldet sich nicht */

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

2014-12-27: Dieser Artikel hat "Reife", die Beschreibung wie man den RasPi als AVR Programmer nutzt ist komplett.

[[Datei:AllesPowerBar.JPG|thumb|400px|Raspberry Pi as AVR-programmer]]
=Vorüberlegungen=
==Grundkonzept==
Die nötigen GPIO's des Raspberries sind mit dem Programmierinterface des µC verbunden, ebenso die Stromversorgung
des zu programmierenden Devices. Die Programmierdatei wird von einem Host-PC auf den RasPi kopiert.
Über die Kommandozeile wird das Programmiertool auf dem RasPi gestartet.

===Variante Ethernet-Dongle===
Ein Raspi ist über Ethernet mit einem PC verbunden. Auf dem PC (Laptop, Windows, Apple, egal)
läuft ein Terminal-Programm mit dem die Programmiertools auf dem RasPi gesteuert werden.
Die Programmierdatei wird ebenfalls über Ethernet auf den RasPi übetragen. Falls diese Konfiguration auch
an einem Laptop laufen soll muss die Powersupply auch mobil sein, also kein Steckernetzteil.

===Variante Standalone Programmer===
Der RasPi läuft als StandAlone Programmer, also ohne verbundenen PC. Dann muss am RasPi eine Tastatur über
USB und ein Monitor über HDMI angeschlossen sein.

===Variante WLAN===
Erfordert Router?

===Headless Betrieb===
Für die Nutzung des RasPis ohne Monitor und RasPi eigene Tastatur nur über eine ''ssh''-Verbindung über Ethernet (headless Betrieb) werden oft Einstellungen vorgeschlagen, die leider dazu führen das eine Internetverbindung des RaspPis über WLAN nicht mehr möglich ist. Leider ist es dann auch nicht mehr möglich die Pakete für den Programmer zu installieren. Deshalb empfiehlt der Autor erst nachdem der RasPi nachweislich als Programmer funktioniert, diesen auf Headless-Betrieb umzustellen.

Der Autor hat seinen Raspi über zwei Subnetze eingebunden, eins um den WLAN-router (DHCP, subnetz 192.168.178.*/255.255.0.0) und eins zum über Ethernet angeschloßenen Steuer-PC. Letzteres als statische IP (subnetz 10.1.1.1/255.255.255.0).

Auszug ''/etc/network/interfaces'' :
<syntaxhighlight lang="bash">
iface eth0 inet static
address 10.1.1.1
netmask 255.255.255.0

allow-hotplug wlan0
iface wlan0 inet manual

wpa-roam /etc/wpa_supplicant/wpa_supplivant.conf
iface default inet dhcp
</syntaxhighlight>

===Filetransfer===
Um Dateien wie das Flash-Image für den µC zwischen Steuer-PC und RasPi zu transferien gibt es mehrere Möglichkeiten. Die typischen sind ''ftp'' oder ''SAMBA'' (Windows-PC). Bei beiden ist der jeweils der passende Server aus dem RasPi zu installieren und gegebenfalls der Port dafür in der firewall freizuschalten. FTP scheint die einfachere und universellere Variante zu sein, da diese mit beliebeigen ftp-programmen funktioniert. Als ftpserver macht ''proftpd'' eine gute Figur.
*Installationsanleitung für proftd: [http://www.gnet4u.de/raspberryweb/proFTPD.pdf]
*Firewallfreischaltungen beispielsweise für ftp: [http://www.gtkdb.de/index_36_2253.html]

==RasPi Hardware==
===Modell-Auswahl===
Für die stand-alone Variante (RasPi mit Tastatur und Monitor) eignen sich model-A und B gleichermaßen,
Dagegen ist eine Terminalverbindung über Ethernet mit dem Modell A oder A+ nicht möglich da diesem die Schnittstelle fehlt. Eine Terminalverbindung über WLAN dagegen ist mit allen RasPi's möglich. Die A+ und B+ Modelle bieten zwar mehr GPIO's, die Grundausstattung der RasPi ohne Plus genügt aber für den Einsatz als
Programmer völlig.

Der portable Betrieb mit Speisung über eine USB-Powerbar oder aus den USB-Ports
eines Laptops ist dem "Plus" Modellen einfacher da diese dank effizienter Regler weniger verbrauchen.
Ohne diese Regler gerät das Model B (ohne plus) schnell an die Grenze einer USB-Stromversorgung.
Das kann zu ungewollten Neustarts des RasPi führen, Abhilfe schafft nur ein sehr gutes USB-Netzteil.
Etwas geringer wird das Problem wenn der RasPi über ein sogenanntes Y-Kabel von zwei USB-Anschlüssen des Laptops betrieben wird.
Ein USB-Anschluss darf mit höchstens 500 mA belastet werden, mit dem genannten Kabel erhöht sich der verfügbare Strom auf 600 mA (Nach USB2.0.-Spec).

===Raspberry Pinleiste===
Der RasPi kann über seine Steckerleiste folgende Interface ansteuern
*Bitwackler (bitbanging) über 25 GPIO (Model b+)
*SPI (wie die ISP -Schnittstelle der Atmel AVR-controller) 2x SPI_CE ; 3 Pins MISO,MOSI,SCLK
*UART (ein Paar RxD/TxD)
*I2C (?ein Paar SDA,SCL)

Ebenso liegen an zwei Pins 3V3 an mit denen bspw. ein µC leicht versorgbar ist. An zwei weiteren Pins stellt
der RasPi 5V zur Verfügung, allerdings ist die Spannung verbrauchsabhängig meist etwas niedriger.
Massepotential liegt an 8 (Modell B+) Pins.

Das Bitwackler Interface kann natürlich auch SPI, UART und I2C nachstellen, allerdings mit erhöhten Programmieraufwand
und meist nicht so schnell wie mit den speziellen SPI-Pins. Dafür ist es erste Wahl bei anderen Schnittstellen
wie JTAG.

==Beschaltung==
Es gelten die üblichen RasPi GPIO Hinweise:
*An die Eingänge keine Signale mit Pegel höher 3.3V oder kleiner als 0V legen, diese können die CPU beschädigen.
*Schäden können auch auftreten falls ein Pin mit mehr Strom belastet wird als konfiguriert. Minimal sind 2 mA ein höherer Wert in 2 mA Schritten aber nicht mehr als 16 mA kann konfiguriert werden. Dieser Wert gilt für alle GPIO's, er kann nicht Pin-individuell geändert werden. Nach einem Reset ist ein Wert von 8 mA voreingestellt. Nie mehr Strom "ziehen" als konfiguriert, ganz vorsichtige Naturen begrenzen den Strom durch einen Serienwiderstand (bspw. 10k).
*Die 3V3 Spannung an der Pin-leiste wird über einen IC erzeugt, der höchstens 50 mA zur Verfügung stellt. (Dieser Wert wurde für die nicht '+' Modelle angegeben, möglichweise bei den im Bereich der Stromversorgung überarbeiteten '+' Modellen höher.

===Bitwackler===
nicht unbedingt schnell (über Python 60 KHz ermittelt), mit passenden Treibern sollten
aber mehrere Hundert kHz möglich sein. Dafür ist das timing nach belieben programmierbar, was bspw. für
JTAG nützlich ist.

===SPI-Schnittstelle und -Treiber===
Der RasPi hat in den betrachten Modellen ("model A", "model B", "model B+") nur eine SPI-Schnittstelle, die
bei allen dreien die selben Pins nutzt. Varianten sind nur in der Nutzung der beiden Pins ''SPI_CE0'' und ''SPI_CE1'' möglich, welche eines der angeschlossenen SPI-Geräte auswählen (bis zu zwei möglich). Befindet sich nur ein Gerät an dieser Schnittstelle können die beiden ''SPI_CE'' Pins unbenutzt bleiben.

Für die Nutzung der SPI - Schnittstelle des RasPi muß der passende SPI-Treiber (module) laufen. Das ist an dem
vorhandenen device ''/dev/spi0.0'' erkennbar. Findet sich unter ''/dev/'' kein SPI-device, dann ist das Module nicht gestartet. Dieses wird über ''modprobe spi-bcm2708'' manuell gestartet. Soll es automatisch gestartet werden, darf das SPI-module nicht auf der schwarzen Liste ''/etc/modprobe.d/raspi-blacklist.conf'' stehen. Falls dort die Zeile ''blacklist spi-bcm2708'' steht mit einem vorangestellten '#' deaktivieren oder die gesamte Zeile löschen:

<syntaxhighlight lang="bash">
# file: /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</syntaxhighlight>

Im Raspberry Konfigurations tool ''raspi-config'' wie es bspw. bei NOOB Installation automatisch gestartet wird, findet sich versteckt unter ''"8 Advanced Options "'' der Unterpunkt ''SPI'' der standardmäßig auf No steht und so das Laden das benötigten Kernel-moduls verhindert. Setzt man diese Option auf ''Yes'' entfällt u.U. die oben beschriebene manuelle Aktivierung des SPI-Moduls.

=AVR-Programmer=
Um AVR-µC zu programmieren, benötigt man ein modifiziertes ''avrdude'' - ein weit verbreitetes Programmiertool. Dieses findet mal als Quellcode in einem git-Source-Depot und kompiliert es direkt
auf dem RasPi. Dazu werden weitere Pakete benötigt die aber nach Installation des kompilierten ''avrdude'' wieder entfernt werden können. Der ''avrdude'' nutzt auf dem RasPi die SPI-Schnittstelle auf der GPIO-Leiste und ein weiteres GPIO-Pin für die Resetleitung.

[[Datei:RasPi prog ATMega328P.JPG|thumb|400px|ATmega328P auf breadboard mit RasPi als Programmer]]

==Verdrahtung==

{| class="wikitable"
|+ Wiring RasPi <-> AVR
|-
!Signal ||RasPi ||Atmel ||Mega32
|-
|MOSI ||GPIO 10 || ||
|-
|MISO ||GPIO 9 || ||
|-
|SCLK ||GPIO 11 || ||
|-
|RST_N ||GPIO 25 || ||
|-
|3V3 || || ||
|-
|GND || || ||
|}

==Installation der Compiler==
Um die Quelltexte für den ''avrdude'' aus den Depot runter zuladen, automatisch anzupassen und zu übersetzen
sind diese 6 Pakete nötig:

*''git'' - Source-Versionsverwaltung, nötig zum Download der avrdude-Sources, Paketname ''git-core''
*''make'' - zum Regelbasierten Built aus den Quelltexten
*''autoconf'' - zwecks Anpassung der Compiler-Skripte an das RasPi-Linux
*''gcc'' - C-Compiler
*''bison'' - mit Flex zusammen zum parsen von Quelltexten/Konfigdateien
*''flex'' - mit bison zusammen zum parsen von Quelltexten/Konfigdateien

Wer direkt auf dem RasPi in C/ASM für den AVR µC programmieren möchte, sollte auch folgende 3 Pakete installieren. Für die Nutzung des RasPi nur als avr-programmer sind sie nicht nötig:

*''gcc-avr''
*''binutils-avr''
*''avr-libc''

Kommando:
<syntaxhighlight lang="bash">
apt-get update
apt-get install gcc git-core make bison autoconf flex
</syntaxhighlight>

==avrdude Sourcen für RasPi aus Depot holen==
Depot:
https://github.com/kcuzner/avrude
Befehl:
<syntaxhighlight lang="bash">
git clone https://github.com/kcuzner/avrude
</syntaxhighlight>

Loginformationen zeigt ''git'' mit ''git log'' an, Aktualisierungen werden mit ''git pull origin'' heruntergeladen.

==avrdude übersetzen und installieren==
<syntaxhighlight lang="bash">
cd avrdude/avrdude
./bootstrap && ./configure
sudo make install
</syntaxhighlight>

==Einstellungen avrdude überprüfen und testen==

In der Datei ''/usr/local/etc/averdude.conf'' stehen die Einstellungen für die verschiedenen AVR Programmer wie die Pinzuordnung - Welches AVR-Pin mit welchem Programmer Pin verbunden ist.
Für den RasPi finden sich diese in der Sektion ''linuxspi''.

<syntaxhighlight lang="c">
programmer
id = "linuxspi";
desc = "Use Linux SPI device in /dev/spidev*";
type = "linuxspi";
reset = 25;
baudrate = 400000;
;
</syntaxhighlight>

Wichtig ist hier das Pin das mit dem Reset des AVR verbunden ist (Zeile ''reset = 25''). Das kann ein beliebiges GPIO-Pin sein, hier wurde das Pin ''GPIO25'' gewählt. Die SPI-Pins (''MISO'', ''MOSI'', ''CLK'') sind nicht wählbar, da der RasPi in allen betrachteten Modellen nur einen SPI-Port hat.

Kritisch ist ebenfalls der Eintrag unter baudrate. Mit diesen wird eingestellt wie schnell das Signal ''SPI_CLK'' schaltet und damit wie schnell der Controller programmiert wird. Die maximal mögliche Baudrate variiert je nach AVR-Typ, Versorgungsspannung, Taktbeschaltung und Konfigurationsregister. Ein sicherer Wert sind 125 kHz, die default Einstellung des avrdude liegt mit 400 000 deutlich darüber. Deshalb sollte man bei Problemen die Zeile zu:
<syntaxhighlight lang="c">
baudrate = 100000;
</syntaxhighlight>
ändern.

==Test==
Auslesen des Flash-Speichers des controllers, hinter ''-p'' den Typ des Controllers (hier ATmega 328P) angeben:
<syntaxhighlight lang="bash">
sudo /usr/local/bin/avrdude -c linuxspi -p m328p -P /dev/spidev0.0 -U flash:r:"/dev/null":r
</syntaxhighlight>

==Typische Fehler==
Der Fehler kann sein
*unvollständige Installation des Betriebssystem, wie Treiber für SPI nicht aktiv
*falsche Bedienung Programmiertool ''avrdude'' bspw. ohne root-Rechte (''sudo'')
*Verdrahtungsfehler bspw. Widerstand an der Reset-Leitung falsch

avrdude schreibt auch Fehlermeldungen von Folgefehlern wie ''avrdude initialization failed'' was auf einen Fehler
in der Verdrahtung deutet, die eigentlich Fehlermeldung allerdings einige Zeilen früher genannt
wird: "Unable to open SPI Port". Man tut also gut daran, die Ausgaben von avrdude komplett zu lesen.

===Zugriff auf SPI scheitert===
Die SPI-Schnittstelle liegt wie alle Geräte im Verzeichnis ''/dev/'' , am besten mit ''ls /dev/'' überprüfen. Findet sich dort kein ''spidev0.0'' ist der SPI-Treiber/-module nicht aktiv oder nicht installiert. Siehe dazu Abschnitt SPI oben.

Für den Zugriff auf die SPI - Schnittstelle sind root-Rechte erforderlich. ''avrdude'' ist also von root - login oder mit vorangestellten ''sudo'' zu starten.

===Der µC meldet sich nicht===
Oft sind fehlende oder falsche elektrische Verbindungen dafür verantwortlich. Man sollte jetzt die Spannungen
zwischen ''Vcc'' und ''GND'' resp. zwischen ''AVcc'' und ''GND'' am Controller messen. Die sollten 3.3 V betragen. Muss man den Controller mit 5V betreiben ist statt auf 3.3 V auf 5.0V zu prüfen und die Pegelwandler (levelshifter) zwischen Controller und RasPi. Die 5V sind an der GPIO-Leiste des RasPi's meist etwas geringer (~ 4.9V), eine leistungsstarke RasPi Stromversorgung (USB-Netzteil 1000 mA) und das Abziehen von beim AVR-Programmieren unbenutzte Hardware wie WLAN-Stick hilft dabei.

An der Reset-Leitung sollte im Normalfall die Betriebsspannung (3.3 V) anliegen, nur während der Programmierung misst man hier 0V. Die anderen Verbindungen klingelt man im stromlosen Zustand durch oder prüft die Signale mit einem Oszilloskop.

Für manche AVR-Typen muss der Code von avrdude leicht angepasst werden, sonst wird der µC nach Umstellung auf Quarztakt nicht mehr ansprechbar: [https://www.mikrocontroller.net/topic/356707#3985870 Patch].

Weitere Tipps zur Fehlersuche finden sich in der [[AVR_Checkliste]].

=JTAG dongle/ FPGA-programmer=
Über JTAG sind auch FPGA's und deren Firmware-PROMs programmierbar. Als Programmier-tool ist hierfür die OpenOCD-Software einsetzbar. Für JTAG wird nicht die SPI-Schnittstelle, sondern "normale" GPIO-Pins genutzt.

Achtung: der RasPi unterstützt nur 3V3 Pegel, die JTAG-Schnittstelle auf den FPGA's kann je nach Beschaltung auch andere Spannungspegel beispielsweise 2V5 erfordern.

=Links/Quellen=
*Deutschsprachige Beschreibung RasPi AVR programmer [http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller]
*Englischsprachige Beschreibung der avrdude Variante [https://gist.github.com/akavel/8832366]
--
*Website OpenOCD (JTAG-Software): [http://openocd.sourceforge.net/about/]
--
*Elektrische Kenn- und Grenzwerte GPIOs: [http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications]

[[Kategorie:AVR-Programmer und -Bootloader]]
[[Kategorie:Entwicklungstools]]
[[Kategorie:Raspberry Pi]]

Raspberry Pi als Universalprogrammer

2015-01-31T07:50:00Z

Prx: /* Der µC meldet sich nicht */

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

2014-12-27: Dieser Artikel hat "Reife", die Beschreibung wie man den RasPi als AVR Programmer nutzt ist komplett.

[[Datei:AllesPowerBar.JPG|thumb|400px|Raspberry Pi as AVR-programmer]]
=Vorüberlegungen=
==Grundkonzept==
Die nötigen GPIO's des Raspberries sind mit dem Programmierinterface des µC verbunden, ebenso die Stromversorgung
des zu programmierenden Devices. Die Programmierdatei wird von einem Host-PC auf den RasPi kopiert.
Über die Kommandozeile wird das Programmiertool auf dem RasPi gestartet.

===Variante Ethernet-Dongle===
Ein Raspi ist über Ethernet mit einem PC verbunden. Auf dem PC (Laptop, Windows, Apple, egal)
läuft ein Terminal-Programm mit dem die Programmiertools auf dem RasPi gesteuert werden.
Die Programmierdatei wird ebenfalls über Ethernet auf den RasPi übetragen. Falls diese Konfiguration auch
an einem Laptop laufen soll muss die Powersupply auch mobil sein, also kein Steckernetzteil.

===Variante Standalone Programmer===
Der RasPi läuft als StandAlone Programmer, also ohne verbundenen PC. Dann muss am RasPi eine Tastatur über
USB und ein Monitor über HDMI angeschlossen sein.

===Variante WLAN===
Erfordert Router?

===Headless Betrieb===
Für die Nutzung des RasPis ohne Monitor und RasPi eigene Tastatur nur über eine ''ssh''-Verbindung über Ethernet (headless Betrieb) werden oft Einstellungen vorgeschlagen, die leider dazu führen das eine Internetverbindung des RaspPis über WLAN nicht mehr möglich ist. Leider ist es dann auch nicht mehr möglich die Pakete für den Programmer zu installieren. Deshalb empfiehlt der Autor erst nachdem der RasPi nachweislich als Programmer funktioniert, diesen auf Headless-Betrieb umzustellen.

Der Autor hat seinen Raspi über zwei Subnetze eingebunden, eins um den WLAN-router (DHCP, subnetz 192.168.178.*/255.255.0.0) und eins zum über Ethernet angeschloßenen Steuer-PC. Letzteres als statische IP (subnetz 10.1.1.1/255.255.255.0).

Auszug ''/etc/network/interfaces'' :
<syntaxhighlight lang="bash">
iface eth0 inet static
address 10.1.1.1
netmask 255.255.255.0

allow-hotplug wlan0
iface wlan0 inet manual

wpa-roam /etc/wpa_supplicant/wpa_supplivant.conf
iface default inet dhcp
</syntaxhighlight>

===Filetransfer===
Um Dateien wie das Flash-Image für den µC zwischen Steuer-PC und RasPi zu transferien gibt es mehrere Möglichkeiten. Die typischen sind ''ftp'' oder ''SAMBA'' (Windows-PC). Bei beiden ist der jeweils der passende Server aus dem RasPi zu installieren und gegebenfalls der Port dafür in der firewall freizuschalten. FTP scheint die einfachere und universellere Variante zu sein, da diese mit beliebeigen ftp-programmen funktioniert. Als ftpserver macht ''proftpd'' eine gute Figur.
*Installationsanleitung für proftd: [http://www.gnet4u.de/raspberryweb/proFTPD.pdf]
*Firewallfreischaltungen beispielsweise für ftp: [http://www.gtkdb.de/index_36_2253.html]

==RasPi Hardware==
===Modell-Auswahl===
Für die stand-alone Variante (RasPi mit Tastatur und Monitor) eignen sich model-A und B gleichermaßen,
Dagegen ist eine Terminalverbindung über Ethernet mit dem Modell A oder A+ nicht möglich da diesem die Schnittstelle fehlt. Eine Terminalverbindung über WLAN dagegen ist mit allen RasPi's möglich. Die A+ und B+ Modelle bieten zwar mehr GPIO's, die Grundausstattung der RasPi ohne Plus genügt aber für den Einsatz als
Programmer völlig.

Der portable Betrieb mit Speisung über eine USB-Powerbar oder aus den USB-Ports
eines Laptops ist dem "Plus" Modellen einfacher da diese dank effizienter Regler weniger verbrauchen.
Ohne diese Regler gerät das Model B (ohne plus) schnell an die Grenze einer USB-Stromversorgung.
Das kann zu ungewollten Neustarts des RasPi führen, Abhilfe schafft nur ein sehr gutes USB-Netzteil.
Etwas geringer wird das Problem wenn der RasPi über ein sogenanntes Y-Kabel von zwei USB-Anschlüssen des Laptops betrieben wird.
Ein USB-Anschluss darf mit höchstens 500 mA belastet werden, mit dem genannten Kabel erhöht sich der verfügbare Strom auf 600 mA (Nach USB2.0.-Spec).

===Raspberry Pinleiste===
Der RasPi kann über seine Steckerleiste folgende Interface ansteuern
*Bitwackler (bitbanging) über 25 GPIO (Model b+)
*SPI (wie die ISP -Schnittstelle der Atmel AVR-controller) 2x SPI_CE ; 3 Pins MISO,MOSI,SCLK
*UART (ein Paar RxD/TxD)
*I2C (?ein Paar SDA,SCL)

Ebenso liegen an zwei Pins 3V3 an mit denen bspw. ein µC leicht versorgbar ist. An zwei weiteren Pins stellt
der RasPi 5V zur Verfügung, allerdings ist die Spannung verbrauchsabhängig meist etwas niedriger.
Massepotential liegt an 8 (Modell B+) Pins.

Das Bitwackler Interface kann natürlich auch SPI, UART und I2C nachstellen, allerdings mit erhöhten Programmieraufwand
und meist nicht so schnell wie mit den speziellen SPI-Pins. Dafür ist es erste Wahl bei anderen Schnittstellen
wie JTAG.

==Beschaltung==
Es gelten die üblichen RasPi GPIO Hinweise:
*An die Eingänge keine Signale mit Pegel höher 3.3V oder kleiner als 0V legen, diese können die CPU beschädigen.
*Schäden können auch auftreten falls ein Pin mit mehr Strom belastet wird als konfiguriert. Minimal sind 2 mA ein höherer Wert in 2 mA Schritten aber nicht mehr als 16 mA kann konfiguriert werden. Dieser Wert gilt für alle GPIO's, er kann nicht Pin-individuell geändert werden. Nach einem Reset ist ein Wert von 8 mA voreingestellt. Nie mehr Strom "ziehen" als konfiguriert, ganz vorsichtige Naturen begrenzen den Strom durch einen Serienwiderstand (bspw. 10k).
*Die 3V3 Spannung an der Pin-leiste wird über einen IC erzeugt, der höchstens 50 mA zur Verfügung stellt. (Dieser Wert wurde für die nicht '+' Modelle angegeben, möglichweise bei den im Bereich der Stromversorgung überarbeiteten '+' Modellen höher.

===Bitwackler===
nicht unbedingt schnell (über Python 60 KHz ermittelt), mit passenden Treibern sollten
aber mehrere Hundert kHz möglich sein. Dafür ist das timing nach belieben programmierbar, was bspw. für
JTAG nützlich ist.

===SPI-Schnittstelle und -Treiber===
Der RasPi hat in den betrachten Modellen ("model A", "model B", "model B+") nur eine SPI-Schnittstelle, die
bei allen dreien die selben Pins nutzt. Varianten sind nur in der Nutzung der beiden Pins ''SPI_CE0'' und ''SPI_CE1'' möglich, welche eines der angeschlossenen SPI-Geräte auswählen (bis zu zwei möglich). Befindet sich nur ein Gerät an dieser Schnittstelle können die beiden ''SPI_CE'' Pins unbenutzt bleiben.

Für die Nutzung der SPI - Schnittstelle des RasPi muß der passende SPI-Treiber (module) laufen. Das ist an dem
vorhandenen device ''/dev/spi0.0'' erkennbar. Findet sich unter ''/dev/'' kein SPI-device, dann ist das Module nicht gestartet. Dieses wird über ''modprobe spi-bcm2708'' manuell gestartet. Soll es automatisch gestartet werden, darf das SPI-module nicht auf der schwarzen Liste ''/etc/modprobe.d/raspi-blacklist.conf'' stehen. Falls dort die Zeile ''blacklist spi-bcm2708'' steht mit einem vorangestellten '#' deaktivieren oder die gesamte Zeile löschen:

<syntaxhighlight lang="bash">
# file: /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</syntaxhighlight>

Im Raspberry Konfigurations tool ''raspi-config'' wie es bspw. bei NOOB Installation automatisch gestartet wird, findet sich versteckt unter ''"8 Advanced Options "'' der Unterpunkt ''SPI'' der standardmäßig auf No steht und so das Laden das benötigten Kernel-moduls verhindert. Setzt man diese Option auf ''Yes'' entfällt u.U. die oben beschriebene manuelle Aktivierung des SPI-Moduls.

=AVR-Programmer=
Um AVR-µC zu programmieren, benötigt man ein modifiziertes ''avrdude'' - ein weit verbreitetes Programmiertool. Dieses findet mal als Quellcode in einem git-Source-Depot und kompiliert es direkt
auf dem RasPi. Dazu werden weitere Pakete benötigt die aber nach Installation des kompilierten ''avrdude'' wieder entfernt werden können. Der ''avrdude'' nutzt auf dem RasPi die SPI-Schnittstelle auf der GPIO-Leiste und ein weiteres GPIO-Pin für die Resetleitung.

[[Datei:RasPi prog ATMega328P.JPG|thumb|400px|ATmega328P auf breadboard mit RasPi als Programmer]]

==Verdrahtung==

{| class="wikitable"
|+ Wiring RasPi <-> AVR
|-
!Signal ||RasPi ||Atmel ||Mega32
|-
|MOSI ||GPIO 10 || ||
|-
|MISO ||GPIO 9 || ||
|-
|SCLK ||GPIO 11 || ||
|-
|RST_N ||GPIO 25 || ||
|-
|3V3 || || ||
|-
|GND || || ||
|}

==Installation der Compiler==
Um die Quelltexte für den ''avrdude'' aus den Depot runter zuladen, automatisch anzupassen und zu übersetzen
sind diese 6 Pakete nötig:

*''git'' - Source-Versionsverwaltung, nötig zum Download der avrdude-Sources, Paketname ''git-core''
*''make'' - zum Regelbasierten Built aus den Quelltexten
*''autoconf'' - zwecks Anpassung der Compiler-Skripte an das RasPi-Linux
*''gcc'' - C-Compiler
*''bison'' - mit Flex zusammen zum parsen von Quelltexten/Konfigdateien
*''flex'' - mit bison zusammen zum parsen von Quelltexten/Konfigdateien

Wer direkt auf dem RasPi in C/ASM für den AVR µC programmieren möchte, sollte auch folgende 3 Pakete installieren. Für die Nutzung des RasPi nur als avr-programmer sind sie nicht nötig:

*''gcc-avr''
*''binutils-avr''
*''avr-libc''

Kommando:
<syntaxhighlight lang="bash">
apt-get update
apt-get install gcc git-core make bison autoconf flex
</syntaxhighlight>

==avrdude Sourcen für RasPi aus Depot holen==
Depot:
https://github.com/kcuzner/avrude
Befehl:
<syntaxhighlight lang="bash">
git clone https://github.com/kcuzner/avrude
</syntaxhighlight>

Loginformationen zeigt ''git'' mit ''git log'' an, Aktualisierungen werden mit ''git pull origin'' heruntergeladen.

==avrdude übersetzen und installieren==
<syntaxhighlight lang="bash">
cd avrdude/avrdude
./bootstrap && ./configure
sudo make install
</syntaxhighlight>

==Einstellungen avrdude überprüfen und testen==

In der Datei ''/usr/local/etc/averdude.conf'' stehen die Einstellungen für die verschiedenen AVR Programmer wie die Pinzuordnung - Welches AVR-Pin mit welchem Programmer Pin verbunden ist.
Für den RasPi finden sich diese in der Sektion ''linuxspi''.

<syntaxhighlight lang="c">
programmer
id = "linuxspi";
desc = "Use Linux SPI device in /dev/spidev*";
type = "linuxspi";
reset = 25;
baudrate = 400000;
;
</syntaxhighlight>

Wichtig ist hier das Pin das mit dem Reset des AVR verbunden ist (Zeile ''reset = 25''). Das kann ein beliebiges GPIO-Pin sein, hier wurde das Pin ''GPIO25'' gewählt. Die SPI-Pins (''MISO'', ''MOSI'', ''CLK'') sind nicht wählbar, da der RasPi in allen betrachteten Modellen nur einen SPI-Port hat.

Kritisch ist ebenfalls der Eintrag unter baudrate. Mit diesen wird eingestellt wie schnell das Signal ''SPI_CLK'' schaltet und damit wie schnell der Controller programmiert wird. Die maximal mögliche Baudrate variiert je nach AVR-Typ, Versorgungsspannung, Taktbeschaltung und Konfigurationsregister. Ein sicherer Wert sind 125 kHz, die default Einstellung des avrdude liegt mit 400 000 deutlich darüber. Deshalb sollte man bei Problemen die Zeile zu:
<syntaxhighlight lang="c">
baudrate = 100000;
</syntaxhighlight>
ändern.

==Test==
Auslesen des Flash-Speichers des controllers, hinter ''-p'' den Typ des Controllers (hier ATmega 328P) angeben:
<syntaxhighlight lang="bash">
sudo /usr/local/bin/avrdude -c linuxspi -p m328p -P /dev/spidev0.0 -U flash:r:"/dev/null":r
</syntaxhighlight>

==Typische Fehler==
Der Fehler kann sein
*unvollständige Installation des Betriebssystem, wie Treiber für SPI nicht aktiv
*falsche Bedienung Programmiertool ''avrdude'' bspw. ohne root-Rechte (''sudo'')
*Verdrahtungsfehler bspw. Widerstand an der Reset-Leitung falsch

avrdude schreibt auch Fehlermeldungen von Folgefehlern wie ''avrdude initialization failed'' was auf einen Fehler
in der Verdrahtung deutet, die eigentlich Fehlermeldung allerdings einige Zeilen früher genannt
wird: "Unable to open SPI Port". Man tut also gut daran, die Ausgaben von avrdude komplett zu lesen.

===Zugriff auf SPI scheitert===
Die SPI-Schnittstelle liegt wie alle Geräte im Verzeichnis ''/dev/'' , am besten mit ''ls /dev/'' überprüfen. Findet sich dort kein ''spidev0.0'' ist der SPI-Treiber/-module nicht aktiv oder nicht installiert. Siehe dazu Abschnitt SPI oben.

Für den Zugriff auf die SPI - Schnittstelle sind root-Rechte erforderlich. ''avrdude'' ist also von root - login oder mit vorangestellten ''sudo'' zu starten.

===Der µC meldet sich nicht===
Oft sind fehlende oder falsche elektrische Verbindungen dafür verantwortlich. Man sollte jetzt die Spannungen
zwischen ''Vcc'' und ''GND'' resp. zwischen ''AVcc'' und ''GND'' am Controller messen. Die sollten 3.3 V betragen. Muss man den Controller mit 5V betreiben ist statt auf 3.3 V auf 5.0V zu prüfen und die Pegelwandler (levelshifter) zwischen Controller und RasPi. Die 5V sind an der GPIO-Leiste des RasPi's meist etwas geringer (~ 4.9V), eine leistungsstarke RasPi Stromversorgung (USB-Netzteil 1000 mA) und das Abziehen von beim AVR-Programmieren unbenutzte Hardware wie WLAN-Stick hilft dabei.

An der Reset-Leitung sollte im Normalfall die Betriebsspannung (3.3 V) anliegen, nur während der Programmierung misst man hier 0V. Die anderen Verbindungen klingelt man im stromlosen Zustand durch oder prüft die Signale mit einem Oszilloskop.

Für manche AVR-Typen muss der Code von avrdude leicht angepasst werden, sonst wird der µC nach Umstellung auf Quarztakt nicht meht ansprechbar: [https://www.mikrocontroller.net/topic/356707#3985870 Patch].

Weitere Tipps zur Fehlersuche finden sich in der [[AVR_Checkliste]].

=JTAG dongle/ FPGA-programmer=
Über JTAG sind auch FPGA's und deren Firmware-PROMs programmierbar. Als Programmier-tool ist hierfür die OpenOCD-Software einsetzbar. Für JTAG wird nicht die SPI-Schnittstelle, sondern "normale" GPIO-Pins genutzt.

Achtung: der RasPi unterstützt nur 3V3 Pegel, die JTAG-Schnittstelle auf den FPGA's kann je nach Beschaltung auch andere Spannungspegel beispielsweise 2V5 erfordern.

=Links/Quellen=
*Deutschsprachige Beschreibung RasPi AVR programmer [http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller]
*Englischsprachige Beschreibung der avrdude Variante [https://gist.github.com/akavel/8832366]
--
*Website OpenOCD (JTAG-Software): [http://openocd.sourceforge.net/about/]
--
*Elektrische Kenn- und Grenzwerte GPIOs: [http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications]

[[Kategorie:AVR-Programmer und -Bootloader]]
[[Kategorie:Entwicklungstools]]
[[Kategorie:Raspberry Pi]]

Raspberry Pi als Universalprogrammer

2015-01-31T07:47:42Z

Prx:

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

2014-12-27: Dieser Artikel hat "Reife", die Beschreibung wie man den RasPi als AVR Programmer nutzt ist komplett.

[[Datei:AllesPowerBar.JPG|thumb|400px|Raspberry Pi as AVR-programmer]]
=Vorüberlegungen=
==Grundkonzept==
Die nötigen GPIO's des Raspberries sind mit dem Programmierinterface des µC verbunden, ebenso die Stromversorgung
des zu programmierenden Devices. Die Programmierdatei wird von einem Host-PC auf den RasPi kopiert.
Über die Kommandozeile wird das Programmiertool auf dem RasPi gestartet.

===Variante Ethernet-Dongle===
Ein Raspi ist über Ethernet mit einem PC verbunden. Auf dem PC (Laptop, Windows, Apple, egal)
läuft ein Terminal-Programm mit dem die Programmiertools auf dem RasPi gesteuert werden.
Die Programmierdatei wird ebenfalls über Ethernet auf den RasPi übetragen. Falls diese Konfiguration auch
an einem Laptop laufen soll muss die Powersupply auch mobil sein, also kein Steckernetzteil.

===Variante Standalone Programmer===
Der RasPi läuft als StandAlone Programmer, also ohne verbundenen PC. Dann muss am RasPi eine Tastatur über
USB und ein Monitor über HDMI angeschlossen sein.

===Variante WLAN===
Erfordert Router?

===Headless Betrieb===
Für die Nutzung des RasPis ohne Monitor und RasPi eigene Tastatur nur über eine ''ssh''-Verbindung über Ethernet (headless Betrieb) werden oft Einstellungen vorgeschlagen, die leider dazu führen das eine Internetverbindung des RaspPis über WLAN nicht mehr möglich ist. Leider ist es dann auch nicht mehr möglich die Pakete für den Programmer zu installieren. Deshalb empfiehlt der Autor erst nachdem der RasPi nachweislich als Programmer funktioniert, diesen auf Headless-Betrieb umzustellen.

Der Autor hat seinen Raspi über zwei Subnetze eingebunden, eins um den WLAN-router (DHCP, subnetz 192.168.178.*/255.255.0.0) und eins zum über Ethernet angeschloßenen Steuer-PC. Letzteres als statische IP (subnetz 10.1.1.1/255.255.255.0).

Auszug ''/etc/network/interfaces'' :
<syntaxhighlight lang="bash">
iface eth0 inet static
address 10.1.1.1
netmask 255.255.255.0

allow-hotplug wlan0
iface wlan0 inet manual

wpa-roam /etc/wpa_supplicant/wpa_supplivant.conf
iface default inet dhcp
</syntaxhighlight>

===Filetransfer===
Um Dateien wie das Flash-Image für den µC zwischen Steuer-PC und RasPi zu transferien gibt es mehrere Möglichkeiten. Die typischen sind ''ftp'' oder ''SAMBA'' (Windows-PC). Bei beiden ist der jeweils der passende Server aus dem RasPi zu installieren und gegebenfalls der Port dafür in der firewall freizuschalten. FTP scheint die einfachere und universellere Variante zu sein, da diese mit beliebeigen ftp-programmen funktioniert. Als ftpserver macht ''proftpd'' eine gute Figur.
*Installationsanleitung für proftd: [http://www.gnet4u.de/raspberryweb/proFTPD.pdf]
*Firewallfreischaltungen beispielsweise für ftp: [http://www.gtkdb.de/index_36_2253.html]

==RasPi Hardware==
===Modell-Auswahl===
Für die stand-alone Variante (RasPi mit Tastatur und Monitor) eignen sich model-A und B gleichermaßen,
Dagegen ist eine Terminalverbindung über Ethernet mit dem Modell A oder A+ nicht möglich da diesem die Schnittstelle fehlt. Eine Terminalverbindung über WLAN dagegen ist mit allen RasPi's möglich. Die A+ und B+ Modelle bieten zwar mehr GPIO's, die Grundausstattung der RasPi ohne Plus genügt aber für den Einsatz als
Programmer völlig.

Der portable Betrieb mit Speisung über eine USB-Powerbar oder aus den USB-Ports
eines Laptops ist dem "Plus" Modellen einfacher da diese dank effizienter Regler weniger verbrauchen.
Ohne diese Regler gerät das Model B (ohne plus) schnell an die Grenze einer USB-Stromversorgung.
Das kann zu ungewollten Neustarts des RasPi führen, Abhilfe schafft nur ein sehr gutes USB-Netzteil.
Etwas geringer wird das Problem wenn der RasPi über ein sogenanntes Y-Kabel von zwei USB-Anschlüssen des Laptops betrieben wird.
Ein USB-Anschluss darf mit höchstens 500 mA belastet werden, mit dem genannten Kabel erhöht sich der verfügbare Strom auf 600 mA (Nach USB2.0.-Spec).

===Raspberry Pinleiste===
Der RasPi kann über seine Steckerleiste folgende Interface ansteuern
*Bitwackler (bitbanging) über 25 GPIO (Model b+)
*SPI (wie die ISP -Schnittstelle der Atmel AVR-controller) 2x SPI_CE ; 3 Pins MISO,MOSI,SCLK
*UART (ein Paar RxD/TxD)
*I2C (?ein Paar SDA,SCL)

Ebenso liegen an zwei Pins 3V3 an mit denen bspw. ein µC leicht versorgbar ist. An zwei weiteren Pins stellt
der RasPi 5V zur Verfügung, allerdings ist die Spannung verbrauchsabhängig meist etwas niedriger.
Massepotential liegt an 8 (Modell B+) Pins.

Das Bitwackler Interface kann natürlich auch SPI, UART und I2C nachstellen, allerdings mit erhöhten Programmieraufwand
und meist nicht so schnell wie mit den speziellen SPI-Pins. Dafür ist es erste Wahl bei anderen Schnittstellen
wie JTAG.

==Beschaltung==
Es gelten die üblichen RasPi GPIO Hinweise:
*An die Eingänge keine Signale mit Pegel höher 3.3V oder kleiner als 0V legen, diese können die CPU beschädigen.
*Schäden können auch auftreten falls ein Pin mit mehr Strom belastet wird als konfiguriert. Minimal sind 2 mA ein höherer Wert in 2 mA Schritten aber nicht mehr als 16 mA kann konfiguriert werden. Dieser Wert gilt für alle GPIO's, er kann nicht Pin-individuell geändert werden. Nach einem Reset ist ein Wert von 8 mA voreingestellt. Nie mehr Strom "ziehen" als konfiguriert, ganz vorsichtige Naturen begrenzen den Strom durch einen Serienwiderstand (bspw. 10k).
*Die 3V3 Spannung an der Pin-leiste wird über einen IC erzeugt, der höchstens 50 mA zur Verfügung stellt. (Dieser Wert wurde für die nicht '+' Modelle angegeben, möglichweise bei den im Bereich der Stromversorgung überarbeiteten '+' Modellen höher.

===Bitwackler===
nicht unbedingt schnell (über Python 60 KHz ermittelt), mit passenden Treibern sollten
aber mehrere Hundert kHz möglich sein. Dafür ist das timing nach belieben programmierbar, was bspw. für
JTAG nützlich ist.

===SPI-Schnittstelle und -Treiber===
Der RasPi hat in den betrachten Modellen ("model A", "model B", "model B+") nur eine SPI-Schnittstelle, die
bei allen dreien die selben Pins nutzt. Varianten sind nur in der Nutzung der beiden Pins ''SPI_CE0'' und ''SPI_CE1'' möglich, welche eines der angeschlossenen SPI-Geräte auswählen (bis zu zwei möglich). Befindet sich nur ein Gerät an dieser Schnittstelle können die beiden ''SPI_CE'' Pins unbenutzt bleiben.

Für die Nutzung der SPI - Schnittstelle des RasPi muß der passende SPI-Treiber (module) laufen. Das ist an dem
vorhandenen device ''/dev/spi0.0'' erkennbar. Findet sich unter ''/dev/'' kein SPI-device, dann ist das Module nicht gestartet. Dieses wird über ''modprobe spi-bcm2708'' manuell gestartet. Soll es automatisch gestartet werden, darf das SPI-module nicht auf der schwarzen Liste ''/etc/modprobe.d/raspi-blacklist.conf'' stehen. Falls dort die Zeile ''blacklist spi-bcm2708'' steht mit einem vorangestellten '#' deaktivieren oder die gesamte Zeile löschen:

<syntaxhighlight lang="bash">
# file: /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</syntaxhighlight>

Im Raspberry Konfigurations tool ''raspi-config'' wie es bspw. bei NOOB Installation automatisch gestartet wird, findet sich versteckt unter ''"8 Advanced Options "'' der Unterpunkt ''SPI'' der standardmäßig auf No steht und so das Laden das benötigten Kernel-moduls verhindert. Setzt man diese Option auf ''Yes'' entfällt u.U. die oben beschriebene manuelle Aktivierung des SPI-Moduls.

=AVR-Programmer=
Um AVR-µC zu programmieren, benötigt man ein modifiziertes ''avrdude'' - ein weit verbreitetes Programmiertool. Dieses findet mal als Quellcode in einem git-Source-Depot und kompiliert es direkt
auf dem RasPi. Dazu werden weitere Pakete benötigt die aber nach Installation des kompilierten ''avrdude'' wieder entfernt werden können. Der ''avrdude'' nutzt auf dem RasPi die SPI-Schnittstelle auf der GPIO-Leiste und ein weiteres GPIO-Pin für die Resetleitung.

[[Datei:RasPi prog ATMega328P.JPG|thumb|400px|ATmega328P auf breadboard mit RasPi als Programmer]]

==Verdrahtung==

{| class="wikitable"
|+ Wiring RasPi <-> AVR
|-
!Signal ||RasPi ||Atmel ||Mega32
|-
|MOSI ||GPIO 10 || ||
|-
|MISO ||GPIO 9 || ||
|-
|SCLK ||GPIO 11 || ||
|-
|RST_N ||GPIO 25 || ||
|-
|3V3 || || ||
|-
|GND || || ||
|}

==Installation der Compiler==
Um die Quelltexte für den ''avrdude'' aus den Depot runter zuladen, automatisch anzupassen und zu übersetzen
sind diese 6 Pakete nötig:

*''git'' - Source-Versionsverwaltung, nötig zum Download der avrdude-Sources, Paketname ''git-core''
*''make'' - zum Regelbasierten Built aus den Quelltexten
*''autoconf'' - zwecks Anpassung der Compiler-Skripte an das RasPi-Linux
*''gcc'' - C-Compiler
*''bison'' - mit Flex zusammen zum parsen von Quelltexten/Konfigdateien
*''flex'' - mit bison zusammen zum parsen von Quelltexten/Konfigdateien

Wer direkt auf dem RasPi in C/ASM für den AVR µC programmieren möchte, sollte auch folgende 3 Pakete installieren. Für die Nutzung des RasPi nur als avr-programmer sind sie nicht nötig:

*''gcc-avr''
*''binutils-avr''
*''avr-libc''

Kommando:
<syntaxhighlight lang="bash">
apt-get update
apt-get install gcc git-core make bison autoconf flex
</syntaxhighlight>

==avrdude Sourcen für RasPi aus Depot holen==
Depot:
https://github.com/kcuzner/avrude
Befehl:
<syntaxhighlight lang="bash">
git clone https://github.com/kcuzner/avrude
</syntaxhighlight>

Loginformationen zeigt ''git'' mit ''git log'' an, Aktualisierungen werden mit ''git pull origin'' heruntergeladen.

==avrdude übersetzen und installieren==
<syntaxhighlight lang="bash">
cd avrdude/avrdude
./bootstrap && ./configure
sudo make install
</syntaxhighlight>

==Einstellungen avrdude überprüfen und testen==

In der Datei ''/usr/local/etc/averdude.conf'' stehen die Einstellungen für die verschiedenen AVR Programmer wie die Pinzuordnung - Welches AVR-Pin mit welchem Programmer Pin verbunden ist.
Für den RasPi finden sich diese in der Sektion ''linuxspi''.

<syntaxhighlight lang="c">
programmer
id = "linuxspi";
desc = "Use Linux SPI device in /dev/spidev*";
type = "linuxspi";
reset = 25;
baudrate = 400000;
;
</syntaxhighlight>

Wichtig ist hier das Pin das mit dem Reset des AVR verbunden ist (Zeile ''reset = 25''). Das kann ein beliebiges GPIO-Pin sein, hier wurde das Pin ''GPIO25'' gewählt. Die SPI-Pins (''MISO'', ''MOSI'', ''CLK'') sind nicht wählbar, da der RasPi in allen betrachteten Modellen nur einen SPI-Port hat.

Kritisch ist ebenfalls der Eintrag unter baudrate. Mit diesen wird eingestellt wie schnell das Signal ''SPI_CLK'' schaltet und damit wie schnell der Controller programmiert wird. Die maximal mögliche Baudrate variiert je nach AVR-Typ, Versorgungsspannung, Taktbeschaltung und Konfigurationsregister. Ein sicherer Wert sind 125 kHz, die default Einstellung des avrdude liegt mit 400 000 deutlich darüber. Deshalb sollte man bei Problemen die Zeile zu:
<syntaxhighlight lang="c">
baudrate = 100000;
</syntaxhighlight>
ändern.

==Test==
Auslesen des Flash-Speichers des controllers, hinter ''-p'' den Typ des Controllers (hier ATmega 328P) angeben:
<syntaxhighlight lang="bash">
sudo /usr/local/bin/avrdude -c linuxspi -p m328p -P /dev/spidev0.0 -U flash:r:"/dev/null":r
</syntaxhighlight>

==Typische Fehler==
Der Fehler kann sein
*unvollständige Installation des Betriebssystem, wie Treiber für SPI nicht aktiv
*falsche Bedienung Programmiertool ''avrdude'' bspw. ohne root-Rechte (''sudo'')
*Verdrahtungsfehler bspw. Widerstand an der Reset-Leitung falsch

avrdude schreibt auch Fehlermeldungen von Folgefehlern wie ''avrdude initialization failed'' was auf einen Fehler
in der Verdrahtung deutet, die eigentlich Fehlermeldung allerdings einige Zeilen früher genannt
wird: "Unable to open SPI Port". Man tut also gut daran, die Ausgaben von avrdude komplett zu lesen.

===Zugriff auf SPI scheitert===
Die SPI-Schnittstelle liegt wie alle Geräte im Verzeichnis ''/dev/'' , am besten mit ''ls /dev/'' überprüfen. Findet sich dort kein ''spidev0.0'' ist der SPI-Treiber/-module nicht aktiv oder nicht installiert. Siehe dazu Abschnitt SPI oben.

Für den Zugriff auf die SPI - Schnittstelle sind root-Rechte erforderlich. ''avrdude'' ist also von root - login oder mit vorangestellten ''sudo'' zu starten.

===Der µC meldet sich nicht===
Oft sind fehlende oder falsche elektrische Verbindungen dafür verantwortlich. Man sollte jetzt die Spannungen
zwischen ''Vcc'' und ''GND'' resp. zwischen ''AVcc'' und ''GND'' am Controller messen. Die sollten 3.3 V betragen. Muss man den Controller mit 5V betreiben ist statt auf 3.3 V auf 5.0V zu prüfen und die Pegelwandler (levelshifter) zwischen Controller und RasPi. Die 5V sind an der GPIO-Leiste des RasPi's meist etwas geringer (~ 4.9V), eine leistungsstarke RasPi Stromversorgung (USB-Netzteil 1000 mA) und das Abziehen von beim AVR-Programmieren unbenutzte Hardware wie WLAN-Stick hilft dabei.

An der Reset-Leitung sollte im Normalfall die Betriebsspannung (3.3 V) anliegen, nur während der Programmierung misst man hier 0V. Die anderen Verbindungen klingelt man im stromlosen Zustand durch oder prüft die Signale mit einem Oszilloskop.

Für manche AVR-Typen muss der Code von avrdude leicht angepasst werden, sonst wird der µC nach Umstellung auf Quarztakt nicht meht ansprechbar.

Weitere Tipps zur Fehlersuche finden sich in der [[AVR_Checkliste]].

=JTAG dongle/ FPGA-programmer=
Über JTAG sind auch FPGA's und deren Firmware-PROMs programmierbar. Als Programmier-tool ist hierfür die OpenOCD-Software einsetzbar. Für JTAG wird nicht die SPI-Schnittstelle, sondern "normale" GPIO-Pins genutzt.

Achtung: der RasPi unterstützt nur 3V3 Pegel, die JTAG-Schnittstelle auf den FPGA's kann je nach Beschaltung auch andere Spannungspegel beispielsweise 2V5 erfordern.

=Links/Quellen=
*Deutschsprachige Beschreibung RasPi AVR programmer [http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller]
*Englischsprachige Beschreibung der avrdude Variante [https://gist.github.com/akavel/8832366]
--
*Website OpenOCD (JTAG-Software): [http://openocd.sourceforge.net/about/]
--
*Elektrische Kenn- und Grenzwerte GPIOs: [http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications]

[[Kategorie:AVR-Programmer und -Bootloader]]
[[Kategorie:Entwicklungstools]]
[[Kategorie:Raspberry Pi]]

Raspberry Pi als Universalprogrammer

2015-01-31T07:46:48Z

Prx: avrdude patch

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

2014-12-27: Dieser Artikel hat "Reife", die Beschreibung wie man den RasPi als AVR Programmer nutzt ist komplett.

[[Datei:AllesPowerBar.JPG|thumb|400px|Raspberry Pi as AVR-programmer]]
=Vorüberlegungen=
==Grundkonzept==
Die nötigen GPIO's des Raspberries sind mit dem Programmierinterface des µC verbunden, ebenso die Stromversorgung
des zu programmierenden Devices. Die Programmierdatei wird von einem Host-PC auf den RasPi kopiert.
Über die Kommandozeile wird das Programmiertool auf dem RasPi gestartet.

===Variante Ethernet-Dongle===
Ein Raspi ist über Ethernet mit einem PC verbunden. Auf dem PC (Laptop, Windows, Apple, egal)
läuft ein Terminal-Programm mit dem die Programmiertools auf dem RasPi gesteuert werden.
Die Programmierdatei wird ebenfalls über Ethernet auf den RasPi übetragen. Falls diese Konfiguration auch
an einem Laptop laufen soll muss die Powersupply auch mobil sein, also kein Steckernetzteil.

===Variante Standalone Programmer===
Der RasPi läuft als StandAlone Programmer, also ohne verbundenen PC. Dann muss am RasPi eine Tastatur über
USB und ein Monitor über HDMI angeschlossen sein.

===Variante WLAN===
Erfordert Router?

===Headless Betrieb===
Für die Nutzung des RasPis ohne Monitor und RasPi eigene Tastatur nur über eine ''ssh''-Verbindung über Ethernet (headless Betrieb) werden oft Einstellungen vorgeschlagen, die leider dazu führen das eine Internetverbindung des RaspPis über WLAN nicht mehr möglich ist. Leider ist es dann auch nicht mehr möglich die Pakete für den Programmer zu installieren. Deshalb empfiehlt der Autor erst nachdem der RasPi nachweislich als Programmer funktioniert, diesen auf Headless-Betrieb umzustellen.

Der Autor hat seinen Raspi über zwei Subnetze eingebunden, eins um den WLAN-router (DHCP, subnetz 192.168.178.*/255.255.0.0) und eins zum über Ethernet angeschloßenen Steuer-PC. Letzteres als statische IP (subnetz 10.1.1.1/255.255.255.0).

Auszug ''/etc/network/interfaces'' :
<syntaxhighlight lang="bash">
iface eth0 inet static
address 10.1.1.1
netmask 255.255.255.0

allow-hotplug wlan0
iface wlan0 inet manual

wpa-roam /etc/wpa_supplicant/wpa_supplivant.conf
iface default inet dhcp
</syntaxhighlight>

===Filetransfer===
Um Dateien wie das Flash-Image für den µC zwischen Steuer-PC und RasPi zu transferien gibt es mehrere Möglichkeiten. Die typischen sind ''ftp'' oder ''SAMBA'' (Windows-PC). Bei beiden ist der jeweils der passende Server aus dem RasPi zu installieren und gegebenfalls der Port dafür in der firewall freizuschalten. FTP scheint die einfachere und universellere Variante zu sein, da diese mit beliebeigen ftp-programmen funktioniert. Als ftpserver macht ''proftpd'' eine gute Figur.
*Installationsanleitung für proftd: [http://www.gnet4u.de/raspberryweb/proFTPD.pdf]
*Firewallfreischaltungen beispielsweise für ftp: [http://www.gtkdb.de/index_36_2253.html]

==RasPi Hardware==
===Modell-Auswahl===
Für die stand-alone Variante (RasPi mit Tastatur und Monitor) eignen sich model-A und B gleichermaßen,
Dagegen ist eine Terminalverbindung über Ethernet mit dem Modell A oder A+ nicht möglich da diesem die Schnittstelle fehlt. Eine Terminalverbindung über WLAN dagegen ist mit allen RasPi's möglich. Die A+ und B+ Modelle bieten zwar mehr GPIO's, die Grundausstattung der RasPi ohne Plus genügt aber für den Einsatz als
Programmer völlig.

Der portable Betrieb mit Speisung über eine USB-Powerbar oder aus den USB-Ports
eines Laptops ist dem "Plus" Modellen einfacher da diese dank effizienter Regler weniger verbrauchen.
Ohne diese Regler gerät das Model B (ohne plus) schnell an die Grenze einer USB-Stromversorgung.
Das kann zu ungewollten Neustarts des RasPi führen, Abhilfe schafft nur ein sehr gutes USB-Netzteil.
Etwas geringer wird das Problem wenn der RasPi über ein sogenanntes Y-Kabel von zwei USB-Anschlüssen des Laptops betrieben wird.
Ein USB-Anschluss darf mit höchstens 500 mA belastet werden, mit dem genannten Kabel erhöht sich der verfügbare Strom auf 600 mA (Nach USB2.0.-Spec).

===Raspberry Pinleiste===
Der RasPi kann über seine Steckerleiste folgende Interface ansteuern
*Bitwackler (bitbanging) über 25 GPIO (Model b+)
*SPI (wie die ISP -Schnittstelle der Atmel AVR-controller) 2x SPI_CE ; 3 Pins MISO,MOSI,SCLK
*UART (ein Paar RxD/TxD)
*I2C (?ein Paar SDA,SCL)

Ebenso liegen an zwei Pins 3V3 an mit denen bspw. ein µC leicht versorgbar ist. An zwei weiteren Pins stellt
der RasPi 5V zur Verfügung, allerdings ist die Spannung verbrauchsabhängig meist etwas niedriger.
Massepotential liegt an 8 (Modell B+) Pins.

Das Bitwackler Interface kann natürlich auch SPI, UART und I2C nachstellen, allerdings mit erhöhten Programmieraufwand
und meist nicht so schnell wie mit den speziellen SPI-Pins. Dafür ist es erste Wahl bei anderen Schnittstellen
wie JTAG.

==Beschaltung==
Es gelten die üblichen RasPi GPIO Hinweise:
*An die Eingänge keine Signale mit Pegel höher 3.3V oder kleiner als 0V legen, diese können die CPU beschädigen.
*Schäden können auch auftreten falls ein Pin mit mehr Strom belastet wird als konfiguriert. Minimal sind 2 mA ein höherer Wert in 2 mA Schritten aber nicht mehr als 16 mA kann konfiguriert werden. Dieser Wert gilt für alle GPIO's, er kann nicht Pin-individuell geändert werden. Nach einem Reset ist ein Wert von 8 mA voreingestellt. Nie mehr Strom "ziehen" als konfiguriert, ganz vorsichtige Naturen begrenzen den Strom durch einen Serienwiderstand (bspw. 10k).
*Die 3V3 Spannung an der Pin-leiste wird über einen IC erzeugt, der höchstens 50 mA zur Verfügung stellt. (Dieser Wert wurde für die nicht '+' Modelle angegeben, möglichweise bei den im Bereich der Stromversorgung überarbeiteten '+' Modellen höher.

===Bitwackler===
nicht unbedingt schnell (über Python 60 KHz ermittelt), mit passenden Treibern sollten
aber mehrere Hundert kHz möglich sein. Dafür ist das timing nach belieben programmierbar, was bspw. für
JTAG nützlich ist.

===SPI-Schnittstelle und -Treiber===
Der RasPi hat in den betrachten Modellen ("model A", "model B", "model B+") nur eine SPI-Schnittstelle, die
bei allen dreien die selben Pins nutzt. Varianten sind nur in der Nutzung der beiden Pins ''SPI_CE0'' und ''SPI_CE1'' möglich, welche eines der angeschlossenen SPI-Geräte auswählen (bis zu zwei möglich). Befindet sich nur ein Gerät an dieser Schnittstelle können die beiden ''SPI_CE'' Pins unbenutzt bleiben.

Für die Nutzung der SPI - Schnittstelle des RasPi muß der passende SPI-Treiber (module) laufen. Das ist an dem
vorhandenen device ''/dev/spi0.0'' erkennbar. Findet sich unter ''/dev/'' kein SPI-device, dann ist das Module nicht gestartet. Dieses wird über ''modprobe spi-bcm2708'' manuell gestartet. Soll es automatisch gestartet werden, darf das SPI-module nicht auf der schwarzen Liste ''/etc/modprobe.d/raspi-blacklist.conf'' stehen. Falls dort die Zeile ''blacklist spi-bcm2708'' steht mit einem vorangestellten '#' deaktivieren oder die gesamte Zeile löschen:

<syntaxhighlight lang="bash">
# file: /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</syntaxhighlight>

Im Raspberry Konfigurations tool ''raspi-config'' wie es bspw. bei NOOB Installation automatisch gestartet wird, findet sich versteckt unter ''"8 Advanced Options "'' der Unterpunkt ''SPI'' der standardmäßig auf No steht und so das Laden das benötigten Kernel-moduls verhindert. Setzt man diese Option auf ''Yes'' entfällt u.U. die oben beschriebene manuelle Aktivierung des SPI-Moduls.

=AVR-Programmer=
Um AVR-µC zu programmieren, benötigt man ein modifiziertes ''avrdude'' - ein weit verbreitetes Programmiertool. Dieses findet mal als Quellcode in einem git-Source-Depot und kompiliert es direkt
auf dem RasPi. Dazu werden weitere Pakete benötigt die aber nach Installation des kompilierten ''avrdude'' wieder entfernt werden können. Der ''avrdude'' nutzt auf dem RasPi die SPI-Schnittstelle auf der GPIO-Leiste und ein weiteres GPIO-Pin für die Resetleitung.

[[Datei:RasPi prog ATMega328P.JPG|thumb|400px|ATmega328P auf breadboard mit RasPi als Programmer]]

==Verdrahtung==

{| class="wikitable"
|+ Wiring RasPi <-> AVR
|-
!Signal ||RasPi ||Atmel ||Mega32
|-
|MOSI ||GPIO 10 || ||
|-
|MISO ||GPIO 9 || ||
|-
|SCLK ||GPIO 11 || ||
|-
|RST_N ||GPIO 25 || ||
|-
|3V3 || || ||
|-
|GND || || ||
|}

==Installation der Compiler==
Um die Quelltexte für den ''avrdude'' aus den Depot runter zuladen, automatisch anzupassen und zu übersetzen
sind diese 6 Pakete nötig:

*''git'' - Source-Versionsverwaltung, nötig zum Download der avrdude-Sources, Paketname ''git-core''
*''make'' - zum Regelbasierten Built aus den Quelltexten
*''autoconf'' - zwecks Anpassung der Compiler-Skripte an das RasPi-Linux
*''gcc'' - C-Compiler
*''bison'' - mit Flex zusammen zum parsen von Quelltexten/Konfigdateien
*''flex'' - mit bison zusammen zum parsen von Quelltexten/Konfigdateien

Wer direkt auf dem RasPi in C/ASM für den AVR µC programmieren möchte, sollte auch folgende 3 Pakete installieren. Für die Nutzung des RasPi nur als avr-programmer sind sie nicht nötig:

*''gcc-avr''
*''binutils-avr''
*''avr-libc''

Kommando:
<syntaxhighlight lang="bash">
apt-get update
apt-get install gcc git-core make bison autoconf flex
</syntaxhighlight>

==avrdude Sourcen für RasPi aus Depot holen==
Depot:
https://github.com/kcuzner/avrude
Befehl:
<syntaxhighlight lang="bash">
git clone https://github.com/kcuzner/avrude
</syntaxhighlight>

Loginformationen zeigt ''git'' mit ''git log'' an, Aktualisierungen werden mit ''git pull origin'' heruntergeladen.

==avrdude übersetzen und installieren==
<syntaxhighlight lang="bash">
cd avrdude/avrdude
./bootstrap && ./configure
sudo make install
</syntaxhighlight>

==Einstellungen avrdude überprüfen und testen==

In der Datei ''/usr/local/etc/averdude.conf'' stehen die Einstellungen für die verschiedenen AVR Programmer wie die Pinzuordnung - Welches AVR-Pin mit welchem Programmer Pin verbunden ist.
Für den RasPi finden sich diese in der Sektion ''linuxspi''.

<syntaxhighlight lang="c">
programmer
id = "linuxspi";
desc = "Use Linux SPI device in /dev/spidev*";
type = "linuxspi";
reset = 25;
baudrate = 400000;
;
</syntaxhighlight>

Wichtig ist hier das Pin das mit dem Reset des AVR verbunden ist (Zeile ''reset = 25''). Das kann ein beliebiges GPIO-Pin sein, hier wurde das Pin ''GPIO25'' gewählt. Die SPI-Pins (''MISO'', ''MOSI'', ''CLK'') sind nicht wählbar, da der RasPi in allen betrachteten Modellen nur einen SPI-Port hat.

Kritisch ist ebenfalls der Eintrag unter baudrate. Mit diesen wird eingestellt wie schnell das Signal ''SPI_CLK'' schaltet und damit wie schnell der Controller programmiert wird. Die maximal mögliche Baudrate variiert je nach AVR-Typ, Versorgungsspannung, Taktbeschaltung und Konfigurationsregister. Ein sicherer Wert sind 125 kHz, die default Einstellung des avrdude liegt mit 400 000 deutlich darüber. Deshalb sollte man bei Problemen die Zeile zu:
<syntaxhighlight lang="c">
baudrate = 100000;
</syntaxhighlight>
ändern.

==Test==
Auslesen des Flash-Speichers des controllers, hinter ''-p'' den Typ des Controllers (hier ATmega 328P) angeben:
<syntaxhighlight lang="bash">
sudo /usr/local/bin/avrdude -c linuxspi -p m328p -P /dev/spidev0.0 -U flash:r:"/dev/null":r
</syntaxhighlight>

==Typische Fehler==
Der Fehler kann sein
*unvollständige Installation des Betriebssystem, wie Treiber für SPI nicht aktiv
*falsche Bedienung Programmiertool ''avrdude'' bspw. ohne root-Rechte (''sudo'')
*Verdrahtungsfehler bspw. Widerstand an der Reset-Leitung falsch

avrdude schreibt auch Fehlermeldungen von Folgefehlern wie ''avrdude initialization failed'' was auf einen Fehler
in der Verdrahtung deutet, die eigentlich Fehlermeldung allerdings einige Zeilen früher genannt
wird: "Unable to open SPI Port". Man tut also gut daran, die Ausgaben von avrdude komplett zu lesen.

===Zugriff auf SPI scheitert===
Die SPI-Schnittstelle liegt wie alle Geräte im Verzeichnis ''/dev/'' , am besten mit ''ls /dev/'' überprüfen. Findet sich dort kein ''spidev0.0'' ist der SPI-Treiber/-module nicht aktiv oder nicht installiert. Siehe dazu Abschnitt SPI oben.

Für den Zugriff auf die SPI - Schnittstelle sind root-Rechte erforderlich. ''avrdude'' ist also von root - login oder mit vorangestellten ''sudo'' zu starten.

===Der µC meldet sich nicht===
Oft sind fehlende oder falsche elektrische Verbindungen dafür verantwortlich. Man sollte jetzt die Spannungen
zwischen ''Vcc'' und ''GND'' resp. zwischen ''AVcc'' und ''GND'' am Controller messen. Die sollten 3.3 V betragen. Muss man den Controller mit 5V betreiben ist statt auf 3.3 V auf 5.0V zu prüfen und die Pegelwandler (levelshifter) zwischen Controller und RasPi. Die 5V sind an der GPIO-Leiste des RasPi's meist etwas geringer (~ 4.9V), eine leistungsstarke RasPi Stromversorgung (USB-Netzteil 1000 mA) und das Abziehen von beim AVR-Programmieren unbenutzte Hardware wie WLAN-Stick hilft dabei.

An der Reset-Leitung sollte im Normalfall die Betriebsspannung (3.3 V) anliegen, nur während der Programmierung misst man hier 0V. Die anderen Verbindungen klingelt man im stromlosen Zustand durch oder prüft die Signale mit einem Oszilloskop.

Für manche AVR-Typen muss der Code von avrdude leicht angepasst werden, sonst wird der µC nach Umstellung auf Quarztakt nicht meht ansprechbar: [[https://www.mikrocontroller.net/topic/356707|Patch]]

Weitere Tipps zur Fehlersuche finden sich in der [[AVR_Checkliste]].

=JTAG dongle/ FPGA-programmer=
Über JTAG sind auch FPGA's und deren Firmware-PROMs programmierbar. Als Programmier-tool ist hierfür die OpenOCD-Software einsetzbar. Für JTAG wird nicht die SPI-Schnittstelle, sondern "normale" GPIO-Pins genutzt.

Achtung: der RasPi unterstützt nur 3V3 Pegel, die JTAG-Schnittstelle auf den FPGA's kann je nach Beschaltung auch andere Spannungspegel beispielsweise 2V5 erfordern.

=Links/Quellen=
*Deutschsprachige Beschreibung RasPi AVR programmer [http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller]
*Englischsprachige Beschreibung der avrdude Variante [https://gist.github.com/akavel/8832366]
--
*Website OpenOCD (JTAG-Software): [http://openocd.sourceforge.net/about/]
--
*Elektrische Kenn- und Grenzwerte GPIOs: [http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications]

[[Kategorie:AVR-Programmer und -Bootloader]]
[[Kategorie:Entwicklungstools]]
[[Kategorie:Raspberry Pi]]

Diode

2014-08-06T11:35:53Z

Prx: /* Z-Diode */

== Allgemeine Diode ==

Die Bezeichnung Diode wurde ursprünglich für Elektronenröhren mit zwei Elektroden verwendet, später für das Halbleiter-Bauteil mit dem selben elektrischen Verhalten. "Di" wegen '''zwei''' und "ode" vermutlich wegen Elektr'''ode''', auch wenn bei Wikipedia was anderes steht (Es gibt bei den Elektronenröhren z. B. auch ''Tri''oden mit drei oder ''Pent''oden mit fünf Elektroden).

Eine Diode sperrt den Stromfluss in einer Richtung und erlaubt ihn in der anderen. Als diskretes Bauteil besitzen Halbleiterdioden i.d.R. einen aufgedruckten Ring, der die Kathode kennzeichnet. Liegt an diesem Anschluss eine negativere Spannung als an der Anode, ist die Diode in Durchlassrichtung geschaltet, d.h. sobald die [[Durchlass-Spannung]] überschritten wird, setzt der Stromfluss ein. Bei der umgekehrten Polarität sperrt die Diode den Stromfluss.

Beim Betrieb von Dioden sind insbesondere drei wichtige Kenngrößen zu beachten:
* max. Durchlassstrom in Durchlassrichtung,
* max. Sperrspannung in Sperrrichtung und
* größte zulässige Verlustleistung aufgrund des Spannungsabfalls in Durchlassrichtung.

Das Überschreiten der zulässigen Grenzwerte führt zur Überlastung der Diode.

Dioden werden in elektronischen Schaltungen sehr häufig und zu ganz unterschiedlichen Zwecken eingesetzt, z. B.
* zur Gleichrichtung,
* als [[Spannungsreferenz]] (siehe auch Z-Diode),
* als elektrisch veränderliche Kapazität (Varaktor), oder
* zum Schutz gegen falsche Polung und Überspannung (Beispiel: [[Relais_mit_Logik_ansteuern#Freilaufdiode|Freilaufdiode]]).

Dioden mit der letzteren Funktion sind heute auch oft in ICs wie [[Mikrocontroller]]n integriert und helfen, die Ein- und Ausgangs-Pins dieser teilweise sehr teuren Bauelemente vor moderater Fehlbehandlung und elektrischen Entladungen (ESD) zu schützen.

Eine Sonderform der Dioden sind [[LED|LEDs]], die elektrisch zwar auch Diodenverhalten besitzen, deren eigentlicher Zweck aber die Erzeugung von sichtbarem oder infrarotem Licht ist.

== Z-Diode ==

Dieses auch ''Zener-Diode'' genannte Bauteil ist eine spezielle Variante der Halbleiter-[[Diode]], die produktionstechnisch so ausgelegt ist, dass sie nach Überschreiten der Durchbruchspannung unbeschadet einen bestimmten Strom in Sperrrichtung aushalten kann.

Halbleiter haben grundsätzlich die Eigenschaft, ab einer bestimmten Schwellspannung einen Stromfluss zu ermöglichen, was auch bei Z-Dioden der Fall ist. Sie sind damit wie normale Siliziumdioden verwendbar. In Sperrichtung können sie aber nicht so hohe negative Spannungen sperren (→ Durchbruch- oder Sperrspannung), besitzen dafür aber eine besonders scharf definierte Durchbruchspannung, die einen abrupten Stromfluss ermöglicht. Dieser Effekt wird nach dem Entdecker Zener-Effekt genannt und ist bis ca. 5 V dominierend. Danach überwiegt der Lawineneffekt. Beide sind ähnlich. [http://de.wikipedia.org/wiki/Z-Diode Z-Dioden] unterhalb ca. 6,5V haben eine eher weiche Kennlinie, der Knick ist schwächer ausgebildet. Diese Effekte treten auch bei Leuchtdioden und Diodenstrecken in Transistoren auf, sind dort aber nicht der angestrebte Arbeitspunkt, da dies zur Zerstörung der Bauteile führt.

Die Durchbruchspannung – auch Z-Spannung genannt – kann zur Spannungsstabilisierung verwendet werden und ist bei diesem Diodentyp der normale Arbeitspunkt. Als [[Spannungsreferenz]] sind Band-Gap-Referenzen einer Z-Diode wegen ihrer Temperatur-Drift von 20mV/K vorzuziehen. Z-Dioden werden neben der Anwendung zur Spannungsstabilisierung auch gerne als Spannungsbegrenzer in einem [[Pegelwandler]] eingesetzt. Beispiel: RS232-Pegel => TTL-Pegel (+-15V => 5.6V/-0.6V), das sind zwar die Maximalwerte von typischen Logik-Eingängen, funktioniert aber meist tadellos. Z-Dioden müssen immer mit einer Strombegrenzung betrieben werden, praktisch ist das meist ein Vorwiderstand.

Die Spannung von Z-Dioden unterhalb von 5V ist stark vom Strom abhängig und die Nennspannung wird je nach Typ bei unterschiedlichem Strom spezifiziert, so dass bei verschiedenen 3,3V Typen in gleicher Schaltung recht verschiedene Spannungen auftreten können.

== Suppressordiode ==

Dabei handelt es sich um spezielle Z-Dioden, welche durch ihre Konstruktion in der Lage sind, sehr hohe Pulsströme für kurze Zeit auszuhalten, je nach Typ zwischen 600-5000W. Sie werden als Schutzbauelemente gegen Überspannungen an Stromversorgungsleitungen oder Signalleitungen verwendet. Nachteilig ist die teilweise hohe Kapazität dieser Dioden, welche bei niedrigen Spannungen mehrere Nanofarad betragen kann. Allerdings gibt es mehr und mehr Typen, welche trotz hoher Pulsbelastbarkeit eine sehr geringe Kapazität haben und damit direkt zum Schutz von hochfrequenten Signalleitungen genutzt werden können.

== Avalanchediode ==

Avalancedioden sind praktisch wie Z-Dioden. Durch diese Eigenschaft kann man Avalancedioden ohne zusätzliche Symetrierungsmaßnahmen in Reihe schalten. Dioden mit weniger Sperrstrom weden dabei mit etwas mehr Sperrspannung belastet und zwar so weit, dass der einsetzende Avalanchestrom genau dem Sperrstrom der anderen Dioden entspricht.

== Siehe auch ==

* [[Dioden-Übersicht]]
* [http://www.mikrocontroller.net/topic/265145#2758976 Forumsbeitrag]: Präzisions-Z-Diode zur Symetrierung von Akkus in Reihenschaltung
* [http://www.mikrocontroller.net/topic/265367#2771241 Forumsbeitrag]: Aktive Nachbildung einer HV-Z-Diode, Linearregler für 2kV/2µA

== Weblinks ==

* [http://de.wikipedia.org/wiki/Diode Diode] bei Wikipedia

[[Category:Bauteile]]
[[Category:Grundlagen]]

Standardbauelemente

2014-08-06T11:33:57Z

Prx:

Gerade Neulinge kennen das Problem: Man hat eine tolle Schaltung mit vielen Operationsverstärkern, Spannungsreglern, Logikbausteinen, ADCs, was auch immer entwickelt und jetzt geht's an die Realisierung.

Aber welche Bausteine nehmen unter dem Wust der Angebote? Also erstmal auf die Seiten der Hersteller und die Produktpalette durchforsten. Nach einigen Stunden gewissenhafter Recherche hat man dann endlich alle Bauteile beisammen und will bestellen. Und dann kommt das böse Erwachen: Einige Bauelemente gibt's nur bei Reichelt, andere nur bei Conrad. Farnell hat zwar das meiste, aber da kann man als Privatperson leider nicht bestellen. Manche ICs bekommt man nur in 1000er Stückzahlen oder sind halt einfach nur viel zu teuer.

Nach einigen Jahren praktischer Erfahrung hat man dann seine "Standardbauelemente", die man immer wieder verwendet. Dieser Artikel soll helfen andere von dieser Erfahrung profitieren zu lassen. Ähnliche Anregungen findet man auch in der de.sci.electronics-FAQ: Grundausstattung des Bastlers [[http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.2]].

== Hinweise ==
Hier soll eine Liste von häufig anzutreffenden, preiswerten und verfügbaren Standardbauelementen entstehen. Diese Liste soll knapp und bündig sein, für technische Daten wird auf die Datenblätter verwiesen. Hier gilt: "weniger ist mehr", exotische Bauelemente sind also unerwünscht. Für hier gelistete Typen sollte gelten:
* für Privatpersonen verfügbar
* preiswert (nicht billig)

Nicht gelistet werden sollen:
* hunderte Typen, die alle den gleichen Zweck erfüllen, aber keinen Mehrwert bringen. Stattdessen auf die bekanntesten / preiswertesten beschränken.
* Details. Stattdessen die Felder "Besonderheiten" und "Anwendungen" benutzen, z. B. "I²C, 12bit" bei Besonderheiten für einen ADC oder "Präzision, Audio" bei Anwendungen für einen OpAmp.

Wer eine Sparte, oder eine Anwendung vermisst, aber selber nichts dazu beitragen kann: Einfach hinzufügen. Wer z. B. einen HF OpAmp sucht und hier nicht fündig wird sollte also eine neue Zeile einfügen und in die Spalte Anwendungen "HF" eintragen. Vielleicht kann ja jemand den Rest der Zeile füllen.

Immer den Grundtypen listen und nicht eine der Varianten, und schon gar nicht alle Varianten einzeln! Also z. B. "LM324" statt "LM324N".

Wenn möglich Direktlinks auf Datenblätter vermeiden und eine Suchmaschine befragen: "http://www.datasheetarchive.com/search.php?q=lm324"
* so werden alle Varianten gefunden
* und tote Links vermieden

Die wichtigsten, allgemeinen Standard-Typen ganz oben in der Tabelle listen, danach erst die Spezialtypen für bestimmte Anwendungen.

Und weil es mir so wichtig ist nochmal: Ich rufe geradezu dazu auf, überflüssige, unverfügbare Typen zu löschen!

= Aktive Bauelemente =
== Analog ==

=== Transistoren ===
''Siehe auch:'' '''[[Transistor-Übersicht#NPN|Transistor-Übersicht]]'''
====NPN====
{| {{Tabelle}} class="wikitable sortable" id="transistors-npn"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/BC337 BC337]
| 0,04
| Standardtyp (SMD: [http://www.mikrocontroller.net/part/BC817 BC817])
| bis ~300mA sinnvoll
| R,D,P,[https://www.IT-WNS.de/ I]
| [http://www.google.de/search?num=100&hl=de&q=datasheet+bc337+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-

| [http://www.mikrocontroller.net/part/MMBT2222A MMBT2222A]
| 0,05
| SMD TO-23 Gehäuse, Ptot bis 350mW
| bis ~ 300mA sinnvoll
| R,D
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=1;INDEX=0;FILENAME=A100%252F2N2222ASMD%2523FAI.pdf;SID=29Jo9LE6wQAR0AADnPx904c70c3257c398b8b92e44b2052e44b2f PDF]
|-
| [http://www.mikrocontroller.net/part/BC547 BC547]
| 0,03
| Standardtyp, [http://www.mikrocontroller.net/part/BC847 in SMD BC847]
| bis ~50mA sinnvoll
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.semiconductors.philips.com/acrobat_download/datasheets/BC847_BC547_SER_6.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/BC635 BC635]/[http://www.mikrocontroller.net/part/BC639 BC639]
| 0,07
| andere Pinbelegung als BC547 (= BD135 in anderem Gehäuse)
| bis ~500mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat/datasheets/BC635_BCP54_BCX54_6.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/BD433 BD433]/[http://www.mikrocontroller.net/part/BD437 BD437]
| 0,19
| niedrige Sättigungsspannung
| bis ~2A sinnvoll
| R
| [http://www.fairchildsemi.com/ds/BD%2FBD435.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/TIP41C TIP41C]
| 0,24
| Ptot: 65W, geringe Stromverstärkung (max.75)
| Grenzwert 10A
| R
| [http://www.datasheetcatalog.org/datasheet/fairchild/TIP41C.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/TIP102 TIP102]
| 0,42
| Ptot bis 80W mit Kühlkörper, hohe Stromverstärkung von über 1000 über einen sehr großen Bereich (Darlington).
| Grenzwert 8A
| R
| [http://www.fairchildsemi.com/ds/TI%2FTIP102.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/TIP3055 TIP3055]
| 0,75
| Ptot bis 90W mit Kühlkörper, Stromverstärkung sehr niedrig (bei großen Strömen << 100)
| Grenzwert 15A
| R
| [http://www.ortodoxism.ro/datasheets/PowerInnovations/mXvutwr.pdf PDF]
|-====
| [http://www.mikrocontroller.net/part/2N6284 2N6284]
| 4,50
| Lin. NPN-PowerDarlington, Ptot bis 160W, Stromverstärkung ~ 750
| 100V Ic 20A
| R
| [http://www.ortodoxism.ro/datasheets/SGSThomsonMicroelectronics/mXvsruq.pdf PDF]
|-
|}

====PNP====
{| {{Tabelle}} class="wikitable sortable" id="transistors-pnp"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/BC327 BC327]
| 0,04
| Komplementärtyp zu [http://www.mikrocontroller.net/part/BC337 BC337]
| bis ~300mA sinnvoll
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.google.de/search?num=100&hl=de&q=datasheet+bc327+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-
| [http://www.mikrocontroller.net/part/BC557 BC557]
| 0,03
| Komplementärtyp zu [http://www.mikrocontroller.net/part/BC547 BC547]
| bis ~50mA sinnvoll
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.semiconductors.philips.com/acrobat_download/datasheets/BC556_557_4.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/BC636 BC636]/[http://www.mikrocontroller.net/part/BC640 BC640]
| 0,07
| Komplementärtyp zu [http://www.mikrocontroller.net/part/BC635 BC635]
| bis ~500mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat/datasheets/BC640_BCP53_BCX53_6.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/TIP2955 TIP2955]
| 0,75
| Ptot bis 90W mit Kühlkörper
| Grenzwert 15A
| R
| [http://www.ortodoxism.ro/datasheets/motorola/TIP2955.pdf PDF]
|-
|}

====N-MOSFET====
''Siehe auch:'' '''[[MOSFET-Übersicht#N-Kanal_MOSFET|MOSFET-Übersicht]]'''

BUZ10, BUZ11 etc. sind wie alle BUZ Typen ziemlich veraltet. Bitte nicht listen; es gibt fast immer was besseres von IRF.
{| {{Tabelle}} class="wikitable sortable" id="mosfet-n"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/IRF1010N IRF1010N]
| 0,78
| max 50V, max 85A, 11 mOhm On-Widerstand
| Alles, was mit POWER zu tun hat ...
| R
| [http://www.irf.com/product-info/datasheets/data/irf1010n.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/IRF1404 IRF1404]
| 0,96
| max 40V, max 162A, 4 mOhm, 200W
| sehr geringer Rds, TO-220
| R
| [http://www.irf.com/product-info/datasheets/data/irf1404.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/IRLZ34N IRLZ34N]
| 0,43
| max 55V, max 30A, 35 mOhm On-Widerstand
| Gatespannung kompatibel mit 5V-Controllern.
| R, D, [https://www.IT-WNS.de/ I]
| [http://www.irf.com/product-info/datasheets/data/irlz34n.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/IRLML2502 IRLML2502]
| 0,17
| max 20V, max 4,2A (cont.), 45 mOhm On-Widerstand
| SOT23 SMD-FET, extrem niedrige V_GS_th, bei niedrigem R_DS_on
| R, D
| [http://www.irf.com/product-info/datasheets/data/irlml2502.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/BS170 BS170]
| 0,10
| max 60V, bis 500mA, 5Ω On-Widerstand
| veraltete Technik, aber in bastelfreundlichem TO-92 Gehäuse
| R,D
| [http://www.fairchildsemi.com/ds/BS/BS170.pdf PDF] (Fairchild)
|-
| [http://www.mikrocontroller.net/part/BSS123 BSS123]
| 0,05
| max 100V, max 170mA (cont.), Thresholdspannung 1,7V, On-Widerstand 1,3Ω
| SOT23 SMD-FET, auch für 3V3-versorgte Schaltungen bestens geeignet
| R,D
| [http://www.fairchildsemi.com/ds/BS/BSS123.pdf PDF] (Fairchild)
|-
| BUK100-50GL
| 1,15
| Logic-Level Power
|
| R
| [http://www.nxp.com/pip/BUK100-50GL_1.html PDF] (NXP)
|-
| [http://www.mikrocontroller.net/part/IRLIZ44N IRLIZ44N]
| 1,45
| Logic-Level Power 30A 55V 22mohm
| TO-220
| R, [https://www.IT-WNS.de/ I]
|
|-
| [http://www.mikrocontroller.net/part/IRLR2905 IRLR2905]/[http://www.mikrocontroller.net/part/IRLU2905 IRLU2905]
| 0,60
| Logic-Level Power 36A 55V RDS=27 mOhm
| D-Pak
| C, P
|
|-
| [http://www.mikrocontroller.net/part/IRLU3410 IRLU3410]
| 0,71
| Logic-Level Power, 100V, 17A, 105mOhm RDS(on), I-PAK
|
| R
| [http://www.datasheetarchive.com/pdf-datasheets/Datasheets-303/37622.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/IRF7301 IRF7301]
| 0,91
| Dual N-MOSFET mit nur 70mOhm RDS(on) bei 2.7 V, SO-8
| Laststromschaltung bei kleinen Spannungen, z. B. an Akkus
| C, R
| [http://www.irf.com/product-info/datasheets/data/irf7301.pdf PDF]
|-
| PMV30UN,
| 0.35
| max 20V, 5.7A (5s), <36mOhm(@4.5V), <63mOhm(@1.8V) On-Widerstand, Ultra-Low-Level: 1.8V.
| SOT-23 SMD, Treiber für Microcontroller-Ausgänge, Motortreiber, Verpolschutz.
| D
| (NXP)
|}

====P-MOSFET====
''Siehe auch:'' '''[[MOSFET-Übersicht#P-Kanal_MOSFET|MOSFET-Übersicht]]'''

{| {{Tabelle}} class="wikitable sortable" id="mosfet-p"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/IRLML6401 IRLML6401]
| 0,18
| max -12V, ca -4,3A (cont.), ca. 0,05Ω On-Widerstand
| SOT-23 SMD FET, extrem niedrige V_GS_th, bei niedrigem R_DS_on
| R, D
| [http://www.irf.com/product-info/datasheets/data/irlml6401.pdf]
|-
| [http://www.mikrocontroller.net/part/IRF7220 IRF7220]
| 0,50
| max -14V, ca -10A (cont.), ca. 0,02Ω On-Widerstand
| Gehäuse SO-8, brauchbar in 3,3V Systemen
| R
| [http://www.irf.com/product-info/datasheets/data/irf7220.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/IRFR5305 IRFR5305]
| 0,56
| max -55V, -31A (cont.), ca. 0,065Ω On-Widerstand
| Gehäuse D-Pak (SMD, TO-252AA), Uth=-2 bis -4V
| R
| [http://www.irf.com/product-info/datasheets/data/irfr5305.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/BS250 BS250]
| 0,26
| max -45V, bis -230mA (cont.), 14 (und mehr) Ohm On-Widerstand
| veraltete Technik aber in bastelfreundlichem TO-92 Gehäuse von R lieferbar
| R
| [http://www.vishay.com/docs/70209/70209.pdf PDF] (Vishay)
|-
| [http://www.mikrocontroller.net/part/NDS0610 NDS0610]
| 0,07
| max -60V, bis -120mA (cont.), 20 (und mehr) Ohm On-Widerstand
| SOT-23 SMD Gehäuse Anwendung z. B. als [http://www.mikrocontroller.net/topic/42113#317220 Verpolschutz mit geringem Spannungsabfall]
| R, D DK
| [http://www.fairchildsemi.com/ds/ND%2FNDS0610.pdf PDF] (Fairchild)
|-
| PMV33UPE,
| 0.52
| max -20V, 5.3A (5s), <36mOhm(@4.5V), <65mOhm(@1.8V) On-Widerstand, Ultra-Low-Level: 1.8V.
| SOT-23 SMD, Treiber für Microcontroller-Ausgänge, Motortreiber, Verpolschutz.
| D
| (NXP)
|-
|}

====MOSFET-Pärchen====

{| {{Tabelle}} class="wikitable sortable" id="mosfet-n-p"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/IRF7389 IRF7389]
| 0,51
| 30 V, >2,5 A, 30/60 mOhm On-Widerstand
| Gehäuse SO-8
| D,R
| [http://www.irf.com/product-info/datasheets/data/irf7389.pdf PDF]
|-
|}

=== Dioden ===
==== Standarddioden ====
''Siehe auch:'' '''[[Dioden-Übersicht]]'''

{| {{Tabelle}} class="wikitable sortable" id="mosfet-p"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/1N4148 1N4148]
| 0,02
| Kleinsignal-Gleichrichterdiode
| 75V/150mA
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.fairchildsemi.com/ds/1N/1N4148.pdf D]
|-
| [http://www.mikrocontroller.net/part/1N4007 1N4001]..[http://www.mikrocontroller.net/part/1N4007 1N4007]
| 0,02
| Mehrzweck-Gleichrichterdiode, 1N4001..1N4007 mit gestaffelter Sperrspannung
| 1A 50..1000V
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.fairchildsemi.com/ds/1N/1N4001.pdf D]
|-
| [http://www.mikrocontroller.net/part/UF4001 UF4001]..[http://www.mikrocontroller.net/part/UF4007 UF4007]
| 0,06 - 0,07
| UltraFast-Gleichrichterdiode, gestaffelte Sperrspannung, trr<50ns bzw 75ns
| 1A
| R, D
| [http://www.ortodoxism.ro/datasheets/vishay/uf4001.pdf Datenblatt]
|-
| [http://www.mikrocontroller.net/part/1N5400 1N5400]..[http://www.mikrocontroller.net/part/1N5408 1N5408]
| 0,06
| Mehrzweck-Gleichrichterdiode, 1N5400..1N5408 mit gestaffelter Sperrspannung
| 3A, 50..1000V
| R, D
| [http://www.ortodoxism.ro/datasheets/fairchild/1N5401.pdf D]
|-
| [http://www.mikrocontroller.net/part/UF5404 UF5404], [http://www.mikrocontroller.net/part/UF5408 UF5408]
| 0,11 bzw 0,22
| UltraFast-Gleichrichterdiode, gestaffelte Sperrspannung, trr<50ns bzw 75ns
| 3A, 50..1000V
| R
|
|-
| [http://www.mikrocontroller.net/part/BAT46 BAT46]
| 0,10
| Kleinsignal-Schottky-Diode
| 150mA
| D,R
| [http://www.alldatasheet.com/view.jsp?Searchword=BAT46 D]
|-
| [http://www.mikrocontroller.net/part/BAT54 BAT54(A/C/S)]
| 0,072
| sehr schnelle Kleinsignal-(Doppel-)Schottky-Diode
| 200mA
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.alldatasheet.com/view.jsp?Searchword=BAT54 D]
|-
| [http://www.mikrocontroller.net/part/SB120 SB120]..[http://www.mikrocontroller.net/part/SB160 SB160]
| 0,13
| Schottky-Diode
| 1A 20-60V
| R,[https://www.IT-WNS.de/ I]
| [http://www.alldatasheet.com/view.jsp?Searchword=SB140 D]
|-
| [http://www.mikrocontroller.net/part/1N5817 1N5817]..[http://www.mikrocontroller.net/part/1N5819 1N5819]
| 0,15
| Schottky-Diode, sehr ähnlich zu SB120-140
| 1A 20/30/40V
| R, D, C, [https://www.IT-WNS.de/ I]
| [http://www.alldatasheet.com/view.jsp?Searchword=1N5819 D]
|-
| [http://www.mikrocontroller.net/part/BA159 BA159]
| 0,051
| Standard-Diode
| HF 1A 1000V
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=BA159 D]
|-
| [http://www.mikrocontroller.net/part/BAV99 BAV99]
| 0,041
| Standard-Doppeldiode, SOT-23
| ESD-Schutz
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=BAV99 D]
|-
|}

==== Z-Dioden ====
Nahezu jeder Lieferant von Elektronikbauteilen hat [[Diode#Z-Diode|Z-Dioden]] im Sortiment. Meist gliedert sich dieses Angebot in die 0,5W und 1,3W-Typen. Für den Handapparat sind fertig gefüllte Sortierkästen eine gute Wahl. Sie enthalten 10-20 Stück jeder Spannung einer Leistungsklasse. Wer weniger braucht, dem seien einige Standardanwendungsfälle angeraten:
* Querregler für kleinste Leistungen, typ. Spannungen 3.3V, 5,1V, 9V, 12V
* Spannungsbegrenzung an MOSFET-Gates 10V
* Bereitstellung von Referenzspannungen 2,4V-15V (bis 10V in 0,3V-Schritten, darüber 1V-Schritte)
* Die Spannung von Z-Dioden unterhalb von 5V ist stark vom Strom abhängig und die Nennspannung wird je nach Typ bei unterschiedlichem Strom spezifiziert, so dass bei verschiedenen 3,3V Typen recht verschiedene Spannungen auftreten können

==== Suppressordioden ====
==== Leuchtdioden====
Die Auswahl an [[LED|Leuchtdioden]] übersteigt die 2000 Typen. Sie unterscheiden sich nicht nur in der Farbe, der Form und den Bauweisen, auch die Leuchtstärke und der dafür notwendige Strom sind Auswahlkriterien. Wie bei den Z-Dioden sind Sortimente im Fall von Unsicherheit die beste Wahl. Ansonsten sind:
* für Anzeigezwecke Leuchtstärken von 2-50mcd ausreichend, zumal die Abstrahlwinkel über 90° liegen.
* Bis 2000mcd sind bereits Schutzmaßnahmen notwendig, denn bei 30° Abstrahlwinkel ist es fürs Auge bereits gefährlich
* Mehr als 4000mcd sind schon sehr hell, selten sind die Abstrahlwinkel allerdings größer als 15°

RGB-LEDs gibt es in zwei Grundkonfigurationen. Die gemeinsame Anode (common anode) erlaubt die Open-Collector-Ansteuerung der einzelnen Farben per NPN-Transistor. Für die gemeinsame Kathode (common cathode) muss man dann einen PNP-Transistor einsetzen oder spezielle Anzeigentreiber. Letztere setzen zu einem wesentlichen Teil auf gemeinsame Kathode. Die Ansteuerung mit Logik-Ausgängen hängt davon ab, wieviel Strom der Ausgang verträgt (sink, common anode) oder liefert (source, common cathode).

Leistungs-LEDs, die 0,3A und mehr vertragen gehören nicht zu den Standardbauteilen, erfreuen sich aber großer Beliebtheit. Da sie grundsätzlich der Kühlung bedürfen und in SMD-Bauweise gefertigt werden, ist der Kauf auf fertigen sog. Star-Platinen (engl. Stern) empfehlenswert. Eine solche Platine lässt sich leicht auf größere Kühlkörper schrauben und bietet sehr gut lötbare Anschlussflächen.

Ein Handappart aus je 10 LEDs der Farben rot, grün, gelb und weiß, 5mm Durchmesser und ca. 30mcd, zzgl. 20 Widerstände 330 Ohm (1/4W) sind für 5V und das Steckbrett völlig ausreichend. Für die Unterstützung (warm)weißer Leistungs-LEDs (je ca. 90lm) müssen schon Typen mit >2000mcd (bevorzugt gelb oder orange) vorgesehen werden.

=== Instrumentenverstärker ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/INA128 INA128]
| 6,37 (F)
| Verstärkung über 1 Widerstand einstellbar
| Brückenverstärker , Datenerfassung
| F
| [http://focus.ti.com/lit/ds/symlink/ina128.pdf#search=%22ina128%22 PDF]
|-
| [http://www.mikrocontroller.net/part/INA326 INA326]
| ca. 3 (DK)
| Low Power, läuft an 3.3 oder 5 V
| Medizintechnik (EKG), Sensoren
| DK
| [http://www.ti.com/lit/gpn/ina326 PDF]
|-
| [http://www.mikrocontroller.net/part/AD620 AD620]
| ca. 8 (R)
| Standardtyp
| EKG, EEG, Brückenverstärker
| R, RS, DK
| [http://www.analog.com/UploadedFiles/Data_Sheets/37793330023930AD620_e.pdf PDF]
|-
|}

=== Operationsverstärker ===
==== Liste ====
Es sind die ''typical values'' bei ''25°C'' angegeben. Falls es selektierte Versionen gibt (z. B. LM358'''A''') ist der schlechtere Wert des Standardteils angegeben.

Bei den R2R output Werten immer die Last RL in Ohm mitangeben, ansonsten sind die Werte relativ sinnlos. Teilweise steht auch dabei für welche Versorgungsspannung dies gilt.
Vcc ist Versorgungs-Plus. Vee ist Versorgungs-Minus.

Bei der Stromaufnahme (supply current) ist der Strom pro IC angegeben. Weil es besser aussieht, ist es in den Datenblättern oft pro OPV angegeben und muss z. B. bei einem Quad noch mit vier multipliziert werden.

Der Preis ist für Einzelstücke angegeben und entspricht meistens dem bei Reichelt.

''' ''Siehe auch:'' [http://www.rn-wissen.de/index.php/Operationsverst%C3%A4rker#Liste_g.C3.A4ngiger_Typen_von_Operationsverst.C3.A4rkern RN - Liste gängiger Typen von Operationsverstärkern]'''

<center>Die Tabelle lässt sich mit einem Klick auf die Überschriften '''sortieren'''.</center>
{| {{Tabelle}} style="font-size:80%" class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! OPVs
! Unity- Gain in MHz
! Slew-Rate in V/µs
! Input Offset Spannung in mV
! Input Offset Strom
! Input Bias Strom
! R2R in
! R2R out @RL Vcc
! Strom- aufnahme in mA
! Bemerkung
! Daten- blatt
! Lieferant
! Preis (€)
|-
| [http://www.mikrocontroller.net/part/LM358 LM358] / [http://www.mikrocontroller.net/part/LM324 LM324]
| 2 / 4
| 1
| 0,5
| 3
| 5 nA
| 45 nA
| Vcc-2V Vee-0,1V
| Vcc-1,5V Vee+5mV @10kΩ 5V
| 0,8
| Standard-OP, Vcc=3V-30V, Isink=15mA Isource=30mA Isink-max=40mA
| [http://www.ti.com/lit/gpn/lm358 PDF(358)] / [http://www.ti.com/lit/gpn/lm324 PDF(324)]
| alle
| 0,19
|-
| [http://www.mikrocontroller.net/part/TL072 TL072]
| 2
| 3
| 13
| 3
| 5 pA
| 65 pA
| Vcc-0V Vee+3V
| Vcc-1,5V Vee+1,5V @10kΩ 30V
| 2,8
| Standard Audio, Low Noise/JFET Eingang, Quad-Version: TL074, single: TL071(mit Offsetkorr.)
| [http://focus.ti.com/lit/ds/symlink/tl072.pdf PDF]
| alle
| 0,17
|-
| [http://www.mikrocontroller.net/part/NE5532 NE5532]
| 2
| 10
| 9
| 0,5
| 10 nA
| 500 nA
|
| Vcc-2V Vee+2V @600Ω 30V
| 8
| Standard Audio OP, treibt 600Ω, Iout=35mA
| [http://focus.ti.com/lit/ds/symlink/ne5532.pdf PDF]
| alle
| 0,23
|-
| [http://www.mikrocontroller.net/part/MAX4238 MAX4238/4239]
| 1
| MAX4238: 1.0, MAX4239: 6.5
| MAX4238: 0.35, MAX4239: 1.6
| 0,0001
| 2 pA
| 1 pA
| Vcc+0.3V Vee-0.3V
| Vcc-4mV Vee+4mV @10kΩ / Vcc-35mV Vee+35mV @1kΩ
| 0.6 @Vcc=5.5V
| very low offset ("zero offset") 0.1µV, Rail2Rail, Vcc=2.7-5.5V, MAX4239: min. Gain x10
| [http://datasheets.maxim-ic.com/en/ds/MAX4238-MAX4239.pdf PDF]
| F, (R MAX4238)
| 2,55 (1,45)
|-
| [http://www.mikrocontroller.net/part/OPA333 OPA333]
| 1
| 0.350
| 0.16
| 0.002
| 140 pA
| 70 pA
| Vcc+0.1V Vee-0.1V
| Vcc-30mV Vee+30mV @10kΩ
| 0.017
| micro power, low offset 2µV, Rail2Rail, Vcc=1.8-5.5V, SOT23-5 SO-8, Dual:OPA2333
| [http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=opa333&fileType=pdf PDF]
| F
| 3,60
|-
| [http://www.mikrocontroller.net/part/OPA335 OPA335]
| 1
| 2
| 1.6
| 0.001
| 120 pA
| 70 pA
| Vcc-1.5V Vee-0.1V
| Vcc-15mV Vee+15mV @10kΩ, Vcc-1mV Vee+1mV @100kΩ
| 0.285
| low offset 1µV, Rail2Rail, Vcc=2.7-5.5V, SOT23-5 SO-8, Dual:OPA2335
| [http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=opa335&fileType=pdf PDF]
| F
| 3,50

|-
| [http://www.mikrocontroller.net/part/TL062 TL062]
| 2
| 1
| 3
| 3
| 5 pA
| 30 pA
|
|
| 0,4
| Low Power/JFET Eingang, veraltet
| [http://focus.ti.com/lit/ds/symlink/tl062.pdf PDF]
| alle
| 0,17
|-
| [http://www.mikrocontroller.net/part/TS912 TS912]
| 2
| 1 @5V
| 0,8 @5V
| 2-10
| 1 pA
| 1 pA
| Vcc+0,2V Vee-0,2V over the rail
| Vcc-0,05V Vee+0,04V @10kΩ 5V
| 0,4
| Standard Rail2Rail Typ, Vcc=2,7-16V, Iout=40mA, Quad: TS914
| [http://www.st.com/stonline/products/literature/ds/2325/ts912.pdf PDF]
| alle
| 0,80
|-
| [http://www.mikrocontroller.net/part/LMC6484 LMC6484]
| 4
| 1,5
| 0,9
| 3
| 2 pA
| 4 pA
| Vcc+0,2V Vee-0,2V over the rail
| Vcc-0,2V Vee+0,2V @2kΩ 5V
| 3
| Iout=16mA@5V Iout=28mA@15V
| [http://www.national.com/ds.cgi/LM/LMC6484.pdf PDF]
| R
| 2,35
|-
| [http://www.mikrocontroller.net/part/OPA2340 OPA2340]
| 2
| 5,5
| 6
| 0,150
| 1 pA
| 1 pA
| Vcc+0,5V Vee-0,5V over the rail
| Vcc-0,04V Vee+0,04V @2kΩ
| 1,5
| CMOS Vcc=2,5V - 5,5V
| [http://focus.ti.com/lit/ds/symlink/opa4340.pdf PDF]
| R
| 1,65
|-
| [http://www.mikrocontroller.net/part/LF356 LF356]
| 1
| 5
| 12
| 3
| 3 pA
| 30 pA
| Vcc'''+'''0,1V Vee+3V
| Vcc-2V Vee+2V @10kΩ 30V
| 5
| high bandwidth J-FET, Settling-Time = 1,5µs @0.01% error-voltage, Eingang knapp über Vcc,
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A200%252FLF355_LF356_LF357%2523STM.pdf; PDF]
| alle
| 0,50
|-
| [http://www.mikrocontroller.net/part/OP07 OP07]
| 1
| 0,6
| 0,3
| 0,030
| 0,4 nA
| 1 nA
| Vcc-1,5V Vee+1,5V
| Vcc-2,2V Vee+2,2V @2kΩ 15V
| 0,7 - 2,5
| geringer Offset <80µV je nach Hersteller
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=1;INDEX=0;FILENAME=A200%252FOP07%2523AD.pdf; PDF]
| alle
| 0,25
|-
| [http://www.mikrocontroller.net/part/LMC6062 LMC6062]
| 2
| 0,1
| 0,015
| 0,1
| 0,01 pA max:2pA
| 0,01 pA max:4pA
|
| Vcc-0,05V Vee+0,05V @25kΩ 5V
| 0,045
| Precision, Micropower, CMOS, Is~40µA (typ.), Iout=8mA
| [http://www.national.com/ds.cgi/LM/LMC6062.pdf PDF]
| R
| 2,05
|-
| [http://www.mikrocontroller.net/part/LM4250 LM4250]
| 1
| 0,3-0,01
| 1-0,001
| 3-5
| 3-10 nA
| 8-50 nA
| Vcc-0,6V Vee+0,6V
| Vcc-0,6V Vee+0,6V @10kΩ 3V
| 0,008 - 0,09
| Micropower, "programmierbar", Werte jeweils für Is=8µA und 90µA
| [http://www.national.com/ds.cgi/LM/LM4250.pdf PDF]
| R
| 0,98
|-
| [http://www.mikrocontroller.net/part/ICL7621 ICL7621]
| 2
| 0,5
| 0,15
| 15
| 30 pA
| 1 pA
| Vcc-0,3V Vee+0,3V unklar 
| Vcc-0,1V Vee+0,1V @100kΩ
| 0,2
| Micropower CMOS Vcc=2V - 16V
| [http://datasheets.maxim-ic.com/en/ds/ICL7611-ICL764X.pdf PDF]
| R
| 1,10
|-
| [http://www.mikrocontroller.net/part/ICL7611 ICL7611] / [http://www.mikrocontroller.net/part/ICL7612 ICL7612]
| 1
| 0,5
| 0,15
| 15
| 30 pA
| 1 pA
| Vcc-0,3V Vee+0,3V unklar 
| Vcc-0,1V Vee+0,1V @100kΩ
| 0,010 - 1
| gleich mit ICL7621, aber nur 1 OPV und dafür programmierbar: Is= 10µA, 100µA, 1mA
| [http://datasheets.maxim-ic.com/en/ds/ICL7611-ICL764X.pdf PDF]
| R
| 0,82
|-
| [http://www.mikrocontroller.net/part/LM13700 LM13700]
| 2
| 2
| 50
| 0,5
| 0,1 µA
| 0,4 µA
|
| Vcc-0,8V Vee+0,6V
| 2,6
| OTA - Steilheits-OP 50V/µs
| [http://www.national.com/ds.cgi/LM/LM13700.pdf PDF]
| R
| 0,90
|-

| [http://www.mikrocontroller.net/part/µA733 µA733]
| 1
| 1200*
|
|
| 6 µA
| 40 µA
|
| Vcc-3,5V Vee+3,5V @2kΩ
| 25
| Video OP, Vcc=12V, Isink=2mA; Gains of 10, 100, 400; Rin=8kΩ; VOutput offset=0,6V;
| [http://www.national.com/ds.cgi/LM/µA733 PDF]
| R
| 0,50
|-
| [http://www.mikrocontroller.net/part/NE592 NE592]
| 1
| 1200*
|
|
| 1 µA
| 9 µA
|
| Vcc-4V Vee+4V @2kΩ
| 20
| Video OP, Vcc=12V, Isink=15mA; Rin=4-30kΩ; VOutput offset=1,5V;
| [http://www.national.com/ds.cgi/LM/NE592 PDF]
| R, [https://www.IT-WNS.de/ I]
| 0,40
|-
| [http://www.mikrocontroller.net/part/LT1363 LT1363]
| 1
| 70
| 1000
| 1,5
| 120 nA
| 0,6 µA
| Vcc-1,6V Vee+1,8V
| Vcc-0,9V Vee+0,9V @500Ω 10V
| 7
| Steilheits OP, Vcc=5-15V, Isink/source=30-60mA; Rin=5MΩ*;
| [http://www.national.com/ds.cgi/LM/LT1363 PDF]
| R
| 3,80
|-
| [http://www.mikrocontroller.net/part/CA3140 CA3140]
| 1
| 4,5
| 9
| 5
| 0,5 pA
| 10 pA
| Vee-0,5V
| Vcc-2V Vee+0,6V @2kΩ 15V
| 4
| BIMOS-OP - kleiner Eingangsstrom, ideal für Single-Supply, Vcc-min=4V
| [http://www.intersil.com/data/fn/fn957.pdf PDF]
| R
| 0,47
|-
| [http://www.mikrocontroller.net/part/TCA0372 TCA0372]
| 2
| 1,1
| 1,3
| 1
| 10 nA
| 100 nA
| Vee to Vcc-1,0V
| Vcc-0,8V Vee+0,8V @0,1A 30V Vcc-1,3V Vee+1,3V @1A 24V
| 5
| Power-OPV, Thermal Shutdown, Io=1A Io(max)=1.5A
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A200%252FTCA0372%2523MOT.pdf; PDF]
| alle, R
| 0,70
|-
| [http://www.mikrocontroller.net/part/LA6510 LA6510]
| 2
|
| 0,15
| 2
| 10 nA
| 100 nA
| Vcc-2V Vee+0V
| Vcc-2V Vee+2V @33Ω 30V
| 12
| Power-OPV, current limiter pin, Imax=1A P=2,5W, Gehäuse:SIP10F
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A200%252FLA6510%2523SAN.pdf; PDF]
| R
| 0,80
|-
| [http://www.mikrocontroller.net/part/L272 L272]
| 2
| 0,35
| 1
| 15
| 50 nA
| 300 nA
|
| Vcc-1V Vee+0,3V @0,1A 24V Vcc-1,5V Vee+0,6V @0,5A 24V
| 8
| Power-OPV, Vcc=4V-28V, Io=0,7A P=1W, Thermal Shutdown @160°C
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A200%252FL272fai.pdf; PDF]
| R
| 0,70
|-
| [http://www.mikrocontroller.net/part/TLC272 TLC272]
| 2
| 1,7
| 2,9
| 1,1
| 0,1 pA
| 0,7 pA
| Vcc-0.8V Vee-0.3V
| Vcc-1.2V Vee+0V @10kΩ
| 5
| Precision OPV, für hochohmige Messanwendungen, Single: TLC271, Quad: TLC274, weniger Offset: TLC277
| [http://focus.ti.com/lit/ds/symlink/tlc272.pdf PDF]
| R, CSD
| 0,26
|-
| [http://www.mikrocontroller.net/part/MCP602 MCP602-I/P]
| 2
| 2,8
| 2,3
| 1
| 1 pA
| 1 pA
| Vcc-1,2V Vee-0,2V
| Vcc-0,1V Vee+0,1V @5kΩ
| 0,5
| Vcc=2,7V-5,5V Vout=20mA
| [http://www.chipcatalog.com/Doc/88306CED2FD891755A0736169A8D31C1.pdf PDF]
| R
| 0,55
|-
| [http://www.mikrocontroller.net/part/LM393 LM393]
| 2
|
|
| 1
| 5 nA
| 65 nA
| Vcc-2V Vee+0V
| Open- Collector
| 1,6
| Standard-Komparator, Isink=16mA, Vcc=2V - 36V, Response-Time=1,5µs
| [http://www.datasheetarchive.com/search.php?q=lm393 PDF]
| alle
| 0,10
|-
| [http://www.mikrocontroller.net/part/LM339 LM339]
| 4
|
|
| 1,4
| 2,3 nA
| 60 nA
|
| Open- Collector
| 1,1
| Standard-Komparator, Isink=16mA, Vcc=2V - 36V, Response-Time=1,5µs
| [http://www.datasheetarchive.com/search.php?q=lm339 PDF]
| alle
| 0,10
|-
| [http://www.mikrocontroller.net/part/TLC3702 TLC3702]
| 2
|
|
| 1,2
|
| 5pA
|
|
| 0,02
| Micropower-Komparator (20µA) PushPull Ausgang
| [http://www.datasheetarchive.com/search.php?q=tlc3702 PDF]
| F, C
| 0,80
|-


|}

Warum findet sich in obiger Liste kein [http://www.mikrocontroller.net/part/LM741 741], war er doch lange Zeit "der" OPV schlechthin? Nun, er wird allgemein als "veraltet" angesehen, da er aus den 60er Jahren stammt (1968 von Fairchild vorgestellt, etwa ab 1969 kommerziell erhältlich) und keine besonderen technischen Daten aufweist. Der immerhin etwa fünf Jahre jüngere 324 (von 1974) kostet häufig ein paar Cent weniger, enthält dafür aber vier statt einen OPV mit besseren Daten.

==== Empfehlungen ====
===== Lineare NF-Verstärker =====
Als besonders lineare Verstärker für Audiozwecke eignen sich u.a der LF356.

===== HF-taugliche Verstärker =====
Für HF-Anwendungen eigenen sich besonders:

[http://www.mikrocontroller.net/part/LT1222 LT1222]

===== Komparatoren =====
Komparatoren müssen schnell aber nicht so genau schalten. Dafür eigenen sich:

=== Spannungsregler ===
==== Linearregler ====
{| {{Tabelle}} class="wikitable sortable" id="linearregler"
|- bgcolor="#eeeeee"
! Bezeichnung Datenblatt
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
|-
| [http://www.mikrocontroller.net/part/LP2950 LP2950]
| 0,39 - 0,53
| Festspannungsregler Low-Dropout
| 3 - 5V 100mA, TO-92, <120µA Ruhestrom
| R, D
|-
| [http://www.mikrocontroller.net/part/LM2940 LM2940]
| 0,40
| Festspannungsregler Low-Dropout
| z. B. 5V, 1A(@0,5V drop), Verpolschutz, TO-220, SOT-223.
| R, D
|-
| [http://www.mikrocontroller.net/part/LM1117 LM1117]
| 0,65
| Festspannungsregler Low-Dropout (auch LT1117, NCP#, REG#, usw.)
| z. B. 3V3, 800mA(@1,1V drop), SOT-223. fixed 3V3 oder adjustable
| D, R, [https://www.IT-WNS.de/ I]
|-
| [http://www.mikrocontroller.net/part/LM317 LM317]
| 0,22
| Linearer einstellbarer Spannungsregler (LM337 für neg. Spannungen)
| max 40V -> 1,2 - 37V, max 1.5A, TO220
| alle
|-
| [http://www.mikrocontroller.net/part/MAX663 MAX663]
| 1,80
| Linearer, einstellbarer Spannungsregler
| sehr niedriger Eigenstromverbrauch
|
|-
| [http://www.mikrocontroller.net/part/LM7805 LM78xx]
| <1,00
| Festspannungregler (xx=05: 5V, xx=12: 12V ...)
|
| alle
|-
| [http://www.mikrocontroller.net/part/LM7905 LM79xx]
| <1,00
| Festspannungregler, negative Spannung (xx=05: -5V, xx=12: -12V ...)
|
| alle
|-
| [http://www.mikrocontroller.net/part/LF33 LF33]
| <1,00
| Festspannungregler
| +3,3V, TO-220, 1A
| R, [https://www.IT-WNS.de/ I]
|-
| [http://www.mikrocontroller.net/part/MCP1700 MCP1700]
| <1,00
| Festspannungregler, Low-Dropout, sehr niedriger Eigenstromverbrauch, siehe auch MCP1702/MCP1703, durch geringe PSRR eher nur für Batterieanwendung
| +3,3V u.a., TO-92, SOT-89, SOT-23, 200mA
| R, F, [https://www.IT-WNS.de/ I]
|-
| [http://www.mikrocontroller.net/part/LM2931 LM2931]
| ~0,30 - 0,40
| feste (5V; 3,3V) und variable (3..24V) Low-Dropout Spannungsregler (max. 100mA)
| TO-220, TO-92, SMD, Automotive, Iq=0,4mA
| R
|-
| [http://www.mikrocontroller.net/part/LM723 μA723/LM723]
| ~0,30
| einstellbar 2-37V
| Netzteile mit Strombegrenzung, Netzteile mit hohem Ausgangsstrom, Labornetzteile, DIP-14, SO-14
| alle

|}

Siehe auch:
* [http://www.national.com/an/AN/AN-1148.pdf AN-1148: Application Note 1148 Linear Regulators: Theory of Operation and Compensation] von National Semiconductor Corporation (PDF)

==== Schaltregler ====
{| {{Tabelle}} class="wikitable sortable" id="schaltregler"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/LM2576 LM2576, LM2575, LM2574]
| 0,90
| Step-Down, als ADJ (einstellbare Spannung) und als Festspannungsregler
| max 40V -> 1,2 - 37V, TO220-5 u.a., LM2576 bis 3A, LM2575 bis 1A, LM2574 bis 0,5A, als HV-Typen Vin bis 63V
| alle - Achtung: R liefert u.U. den nur zum LM2596 äquivalenten P3596
| [http://www.datasheetarchive.com/search.php?q=LM2576 PDF] - [http://www.mikrocontroller.net/topic/58094#450561 mit Funk-Entstördrossel FED100µ (Reichelt...) bis 3 A]
|-
| [[MC34063]]A
| 0,29
| Step-Up ~0,3A / Step-Down 0,7A / Inverter 0,2A-0,6A
| SO-8/DIP-8; Tool zum Berechnen auf [http://www.nomad.ee/micros/mc34063a/index.shtml www.nomad.ee]
| R, [https://www.IT-WNS.de/ I]
| [http://www.onsemi.com/pub/Collateral/MC34063A-D.PDF PDF], [http://www.mikrocontroller.net/articles/MC34063]
|-
| [http://www.mikrocontroller.net/part/PR4401 PR4401]
| 0,50
| Led-Treiber, Step-Up, Batteriebetrieb mit einer Zelle (bis 0,9 V)
| SO-23
| R, [http://www.ak-modul-bus.de/ AK Modul-Bus], [https://www.IT-WNS.de/ I]
| [http://www.prema.com/pdf/pr4401.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/LT1930 LT1930] und [http://www.mikrocontroller.net/part/LT1932 LT1932]
| ~3 €
| Leistungs-Led-Treiber, Step-Up
| SO-23
| R
| [http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1003,C1042,C1031,C1061,P1813]

|-
|}

==== Shuntregler/[[Spannungsreferenz]] ====
{| {{Tabelle}} class="wikitable sortable" id="schaltregler"
|- bgcolor="#eeeeee" style="text-align:center"
! Bezeichnung
! Preis [€]
! Spannung [V]
! Strom [mA]
! Fehler [%]
! Temperatur koeffizient typ/max [ppm/K]
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/TL431 TL431]
| 0,15
| 2,5-36
| 1-100
| 2
| 20/70
| Präzise Alternative zur Z-Diode; SO8; TO92
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=TL431 PDF]
|-
| [http://www.mikrocontroller.net/part/LT1021 LT1021]
| 5,00
| 5; 7; 10
| 10
| 1; 0,05
| 2/5
| Präzisionsreferenz, +/-10mA Ausgangsstrom
| C, R, DK
|[http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-17&file=DSA-321686.pdf&scan= PDF]
|-
| [http://www.mikrocontroller.net/part/LT1004 LT1004]
| 1,90
| 1,235; 2,5
| 0.01-20
| 0,8
| 20/50
| niedriger Stromverbrauch, ab 20 µA; 1,2V bessere Eigenschaften; TI =! LT
| R, [https://www.IT-WNS.de/ I]
|[http://www.datasheetarchive.com/search.php?q=LT1004 PDF]
|-
| [http://www.mikrocontroller.net/part/LT1009 LT1009]
| 1,95
| 2,5
| 1-10
| 0,2
| 20/30
| verbesserter Ersatz für LM336
| R
|[http://www.datasheetarchive.com/search.php?q=LT1009 PDF]
|-
| [http://www.mikrocontroller.net/part/LM336-2.5 LM336-2.5]
| 0,20
| 2,5; 5,0
| 0,6-10
| 4
| 70/230
| TO92; SO8; 1% erhältlich
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=LM336 PDF]
|-
| [http://www.mikrocontroller.net/part/LM385 LM385]
| 0,35
| 1,2V; 2,5
| 0,015-20
| 2
| 30/150
| Präzise Alternative zur Z-Diode; SO8; TO92
| C, R, DK
|[http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A200%252FLM385Z1%252C2%2523TEX.pdf; PDF]
|-
| LM 4041 CIDBZT
| 0,35
| 1,22V-10,0
| 0,000045-12
| 0,5
| 20/100
| Battery Powered Equipment
| elpro.org
|[http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CEYQFjAE&url=http%3A%2F%2Fwww.farnell.com%2Fdatasheets%2F36982.pdf&ei=MCbJU9ShJajy7Ab41YDIBw&usg=AFQjCNEhAH7BdMUd-YWQB1HRbdUNmvzA_Q&bvm=bv.71198958,d.ZGU]
|-
| [http://www.mikrocontroller.net/part/LT1029 LT1029]
| 2,20
| 5,0
| 0,6-10
| 1
| 8/40
| Bandgap TO92; 0,2% erhältlich
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=LT1029 PDF]
|-
| ADR36x
| 2,20
| 2,048; 2,5; 3; 3,3; 4,096; 5
| -1, +5
| 0,1
| 3/9
| Bandgap; SOT23
| DK, RS, FAR
|[http://www.datasheetarchive.com/search.php?q=ADR363 PDF]
|-
|}

Viele Spannungsreferenzen haben auch [http://www.maxim-ic.com/products/references/ Maxim] und [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=401&uiTemplateId=NODE_STRY_PGE_T TI] im Programm.

=== Stromquelle ===
==== Referenzstromquelle ====
{| {{Tabelle}} class="wikitable sortable" id="referenzstromquelle"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/LM334 LM334]
| 0,58 - 1,84
| Referenzstromquelle, 1µA...10mA, TO-92
| Referenzstromquelle/Temperatursensor
| R, C
| [http://www.national.com/ds/LM/LM134.pdf PDF]
|}

=== Timer ===
{| {{Tabelle}} class="wikitable sortable" id="can"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/NE555 555]
| 0,15
| Universeller Zeitgeber.
| Für alles, wirklich alles. CMOS-Versionen lassen sich aufgrund ihrer niedrigeren Betriebsspannung besser mit µCs verbinden.
| alle
| [http://www.google.de/search?q=555+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/DS1307 DS1307]
| 1,95
| 64 X 8 Serial Real Time Clock. Quarzuhr / Kalender Baustein mit serieller TWI-Schnittstelle.
| Uhrenfunktion, unabhängig vom µC, aber µC-Steuerbar. Batteriepufferbar (3V-Knopfzelle wie CR2032) um die Zeit bei ausgeschalteter Board-Betriebsspannung weiter zu zählen.
| D, R, [https://www.IT-WNS.de/ I]
| [http://www.google.de/search?q=DS1307 Google]
|-
| [http://www.mikrocontroller.net/part/PCF8583 PCF8583]
| 1,50
| I²C/TWI Real Time Clock, Calendar, SRAM, Alarm, Timer, Eventcounter
| Auf Basis eines SRAM-chips, deshalb kann ein großer Teil als SRAM genutzt werden (ca 240 bytes). Berechnet Datum (4 Jahre, Jahr 0 = Schaltjahr), Uhrzeit (12/24), Wochentag. ein 32-kHz-Uhrenquarz ist nötig, sonst als Uhr unbrauchbar da störempfindlich. Möglichkeit eines Interruptausganges bei voreingestellter Alarmzeit. Bemerkenswert einfaches Protokoll. Kann umgeschaltet werden in einen Timer-Modus (einfacher Counter mit bestimmter Timebase) oder Event-Counter-Modus (Eingangssignale zählen).
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=PCF8583]
|-
|}

=== Analogschalter und Multiplexer ===
Die DG2xx DG3xx DG4xx, teilweise auch DG5xx bezeichnen Analogschalter und Multiplexer die sich zum Industriestandard entwickelt haben. Es gibt sie von vielen Herstellern und zahlreichen Ausführungen in allen R(on) Bereichen und sind Pinkompatibel. Anstelle von "DGxxx" benutzen Hersteller für verbesserte/moderne Versionen ihre eigenen Präfixe wie "ADGxxx" von Analog Devices oder "MAXxxx" von Maxim. Für einfache Schalter werden häufig die letzten zwei Ziffern 01 bis 05 und 11-13 benutzt, 06/07/08/09 bezeichnet 16:1 8:1 und 4:1 Multiplexer in Single Ended und Differential Ended. Spannungsbereich geht bis +/-12 oder +/-15 V, die Steuereingänge haben zum Teil TTL-Kompatibilität, andernfalls einen Pin der den Logikpegel definiert (z. B. VCC).
{| {{Tabelle}} class="wikitable sortable" id="can"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/DG201 DG201]/[http://www.mikrocontroller.net/part/DG202 DG202]/[http://www.mikrocontroller.net/part/DG212 DG212]
| ~2-3€
| Vierfach Einzelschalter in SPST, SPDT,
| Zum µC-gesteuerten schalten von Analogsignalen, in Audio, Video, und Messschaltungen, in OP-Schaltungen für programmierbare Verstärkungen
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG202&action=Search]
|-
| [http://www.mikrocontroller.net/part/DG306 DG306]/[http://www.mikrocontroller.net/part/DG406 DG406]
| ~4-10€
| 16:1 Analog-Multiplexer
| Zum Multiplexen von Analogsignalen, Kanalauswahl für ADC-Messschaltungen.
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG306&action=Search]
|-
| [http://www.mikrocontroller.net/part/DG307 DG307]/[http://www.mikrocontroller.net/part/DG408 DG408]
| ~4-10€
| Zweifach 8:1 bzw Einfach 8:1 differential ended (8 Doppelkanäle)
| Zum Multiplexen von Analogsignalen, Kanalauswahl für ADC-Messschaltungen auch für differentielle Eingänge.
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG308&action=Search]
|-
|-
| 4051, z. B. [http://www.mikrocontroller.net/part/74HC4051 74HC4051]
| ab 25ct
| 1:8 Multiplexer, R_on <100Ω, auch 2:4, 1:16 usw
| Zum µC-gesteuerten schalten von Analogsignalen, in Audio, Video, und Messschaltungen, in OP-Schaltungen für programmierbare Verstärkungen
| verschiedende
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=74HC4051&action=Search]
|}

== Digital ==

=== CAN ===
{| {{Tabelle}} class="wikitable sortable" id="can"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/MCP2515 MCP2515]
| 2,55
| CAN 2.0B, [[SPI]]-Schnittstelle
|
| D,F,R,[https://www.IT-WNS.de/ I]
| [http://www.datasheetarchive.com/search.php?q= PDF]
|-
| [http://www.mikrocontroller.net/part/SJA1000 SJA1000]
| 4,55
| PellCAN 2.0B, 8 Bit parallele Schnittstelle
|
| F,R
|-
|}

=== Logik ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/74HC4050 74HC4050]
| 0,27
| z. B. 5V => 3V
| Pegelwandler unidirektional abwärts
| alle
| [http://www.datasheetarchive.com/search.php?q=74hc4050 PDF]
|-
| [http://www.mikrocontroller.net/part/HEF4104B HEF4104B]
| 0,77
| z. B. 5V => 12V
| Pegelwandler unidirektional aufwärts
| alle
| [http://www.datasheetarchive.com/search.php?q=HEF4104B PDF]
|-

|}

=== USB ===
{| {{Tabelle}} class="wikitable sortable" id="usb"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/FT232 FT232]
| 3,59
| USB <-> RS232 Wandler
| Zugriff über virtuellen COM Port
| D, R, [https://www.IT-WNS.de/ I]
| [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232BL_BQ.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/FT245 FT245]
| 4,79
| USB <-> Seriell Wandler mit paralleler Schnittstelle
| Zugriff über virtuellen COM Port
| D, R
| [http://www.datasheetarchive.com/search.php?q=ft245 PDF]
|-
| [http://www.mikrocontroller.net/part/TUSB3410 TUSB3410]
| 3,50
| USB <-> RS232 mit 8052 CPU
| Zugriff über virtuellen COM Port
| DK
| [http://focus.ti.com/docs/prod/folders/print/tusb3410.html PDF]
|-
| [http://www.mikrocontroller.net/part/MCP2200 MCP2200]
| 1,90
| USB <-> UART per fest-vorprogrammiertem PIC
| Zugriff über virtuellen COM Port
| R, RS, F, M, DK, [https://www.IT-WNS.de/ I]
| [http://ww1.microchip.com/downloads/en/DeviceDoc/22228B.pdf PDF]
|-
|}

=== GPS ===
{| {{Tabelle}} class="wikitable sortable" id="usb"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| NL-552ETTL (uBlox5)
| 25,43
| GPS-Empfänger
| Zugriff über TTL (NMEA Protokoll)
| www.mercateo.com
| [http://www.navilock.de/produkte/gruppen/13/Boards_und_Module/60721_NL-552ETTL_ublox5.html HTML]
|-
| NL-550ERS (uBlox5)
| 24,95
| GPS-Empfänger
| Zugriff über RS232 (NMEA Protokoll)
| www.mercateo.com
| [http://www.navilock.de/produkte/gruppen/13/Boards_und_Module/60418_NL-550ERS_ublox5.html HTML]
|-
| NL-551EUSB (uBlox5)
| 22,56
| GPS-Empfänger
| Zugriff über USB (NMEA Protokoll)
| www.mercateo.com
| [http://www.navilock.de/produkt/60419/pdf.html?sprache=de PDF]
|-
| EM-406A (Sirf III)
| um 35 Euro
| GPS-Empfänger mit 1PPS-Ausgang
| Zugriff über TTL (NMEA Protokoll)
|
| [http://www.navilock.de/produkte/G_60407/merkmale.html HTML]
|-
| CW25-TIM
| ca. 35 Euro (ab 10 Stk)
| GPS Empfänger mit zusätzlichen Frequenzausgang(programmierbar von 10Hz..30Mhz)
| Sehr interesant wenn man einen präzisen Takt braucht.(für Adwandler, Datenlogger usw)
| [http://www.navsync.com]
|}

=== Treiber ===
==== Diverse Treiber ====
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/ULN2003A ULN2003A]
| 0,29
| 7-fach Low-Side Treiber
| 50V/500mA
| R, D, [https://www.IT-WNS.de/ I]
| [http://www.datasheetarchive.com/search.php?q=ULN2003 PDF]
|-
| [http://www.mikrocontroller.net/part/ULN2803A ULN2803A]
| 0,31
| 8-fach Low-Side Treiber
| 50V/500mA
| alle
| [http://www.datasheetarchive.com/search.php?q=ULN2803 PDF]
|-
| [http://www.mikrocontroller.net/part/TPIC6B595 TPIC6B595]
| 1,00
| 8-fach Low-Side Treiber mit integriertem Schieberegister
| 45V/250mA
| F
| [http://www.datasheetarchive.com/search.php?q=TPIC6B595 PDF]
|-
| [http://www.mikrocontroller.net/part/UDN2981 UDN2981]
| 1,50
| 8-fach High-Side Treiber
| 50V/500mA
| R
| [http://www.datasheetarchive.com/search.php?q=UDN2981 PDF]
|-
| [http://www.mikrocontroller.net/part/ICL7667 ICL7667]
| 1
| Dual inverting MOSFET Treiber
| 18V, 20ns@1nF
| R
| [http://www.datasheetarchive.com/search.php?q=ICL7667 PDF]
|-
| [http://www.mikrocontroller.net/part/HCPL3120 HCPL3120]
| 3.70
| Optokoppler mit integriertem MOSFET-Treiber
| Schaltnetzteile, etc.
| C
| [http://www.datasheetarchive.com/search.php?q=HCPL3120 PDF]
|-
|-
| [http://www.mikrocontroller.net/part/SN75179B SN75179B]
| 0.36
| RS-485/422 Receiver/Transmitter, alter IC mit hohem Stromverbrauch (60mA!)
| Serielle Daten (z. B.UART) über weite Strecken
| R
| [http://www.datasheetarchive.com/search.php?q=SN75174 PDF]
|-
| [http://www.mikrocontroller.net/part/MAX485 MAX485]
| 1.50
| RS-485/422 Receiver/Transmitter, moderner CMOS IC mit geringem Stromverbrauch (0,3mA!)
| Serielle Daten (z. B.UART) über weite Strecken
| R
| [http://www.datasheetarchive.com/search.php?q=MAX485 PDF]
|-
| LTC1480
|
| RS-485 Transceiver
| Betriebsspannung 3,3V, "Ultralow Power"
| R, C u.a.
| [http://www.datasheetarchive.com/search.php?q=LTC1480 PDF]
|-
| MAX3232
|
| RS-232 Transceiver
| Betriebsspannung 3V bis 5,5V
| R, D, C, [https://www.IT-WNS.de/ I] u.a.
| [http://www.datasheetarchive.com/search.php?q=MAX3232 PDF]
|-

|}

==== 7-Segment LED-Treiber ====
{| {{Tabelle}} class="wikitable sortable" id="led"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/SAA1064 SAA1064]
| ~2€
| Vier-Stellen Treiber mit [[I2C|I²C]] ([[TWI]]) Bus
| Treibt bis zu vier 7-Segment (plus Dezimalpunkt) Stellen mit gemeinsamer Anode. Bis zu vier SAA1064 können an einem I²C-Bus betrieben werden. Damit kann man insgesamt 16 Stellen treiben.
| Reichelt
| [http://www.nxp.com/pip/SAA1064_CNV_2.html NXP]
|-
| [http://www.mikrocontroller.net/part/STLED316S STLED316S], [http://www.mikrocontroller.net/part/STLED316SMTR STLED316SMTR]
| ~2€
| Sechs-Stellen Treiber mit [[SPI]]-ähnlicher Busschnittstelle
| Sechs-Stellen Treiber, der zusätzlich noch ein 8x2 Tastaturdekoder enthält. Die Busschnittstelle ist [[SPI]]-ähnlich, MOSI und MISO liegen auf einem gemeinsamen PIN als DIN/DOUT.
| Mouser
| [http://www.st.com/stonline/products/literature/ds/14307/stled316s.pdf ST]
|-
| [http://www.mikrocontroller.net/part/ICM7218 ICM7218C]
| ~6€
| Acht-Stellen Treiber mit paralleler Busschnittstelle
| Alt, teuer, benötigt viele µC-Pins für die parallele Schnittstelle
| Reichelt
| [http://www.intersil.com/data/fn/FN3159.pdf Intersil]
|-
| [http://www.mikrocontroller.net/part/MAX7221 MAX7221]
| ~6€
| Acht-Stellen Treiber mit [[SPI]]-Schnittstelle
| Mit BCD-Dekoder, kann auch beliebige 8x8 LED-Matrix ansteuern
| Reichelt
| [http://datasheets.maxim-ic.com/en/ds/MAX7219-MAX7221.pdf Maxim]
|}

==== Punkt/Streifen (Dot/Bar) LED-Treiber ====
{| {{Tabelle}} class="wikitable sortable" id="bar"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/LM3914 LM3914]
| ~1,20 €
| 10-Stellen Balkenanzeigetreiber mit Analogeingang
| Lineare A/D-Wandlung
| Reichelt
| [http://www.national.com/pf/LM/LM3914.html National]
|-
| [http://www.mikrocontroller.net/part/LM3915 LM3915]
| ~1,40 €
| 10-Stellen Balkenanzeigetreiber mit Analogeingang
| Logarithmische A/D-Wandlung
| Reichelt
| [http://www.national.com/pf/LM/LM3915.html National]
|}

=== Analogschalter aus der 4000 Logikreihe ===
Die folgenden Schalter werden digital gesteuert, daher sind sie im Kapitel [[#Digital|Digital]] einsortiert. Sie basieren auf standard CMOS-Technologien, sind daher weit verbreitet, günstig, haben aber daher auch nur mäßige Eigenschaften und begrenzte Anwendungsbereiche. Analogschalter für Präzisionsanwendungen sind im Kapitel [[#Analog|Analog]]. Zum Schalten Analog- oder Digitalsignalen. Je nach Typ sind Analogsignale bis in den 100 MHz Bereich mit einer Schaltfrequenz bis mehrere 10 MHz möglich.

{| {{Tabelle}} class="wikitable sortable" id="can"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/CD4051 4051]
| 0,25
| Ein 8:1 Analogmultiplexer.
|
| alle
| [http://www.google.de/search?q=4051+datasheet Google]
|-
| [http://www.mikrocontroller.net/part/CD4052 4052]
| 0,11
| Zwei 4:1 Analogmultiplexer/-demultiplexer
|
| alle
| [http://www.google.de/search?q=4052+datasheet Google]
|-
| [http://www.mikrocontroller.net/part/CD4053 4053]
| 0,16
| Drei 2:1 Analogmultiplexer/-demultiplexer
|
| alle
| [http://www.google.de/search?q=4053+datasheet Google]
|-
| [http://www.mikrocontroller.net/part/CD4066 4066]
| 0,15
| Vier Analogschalter
|
| alle
| [http://www.datasheets.org.uk/pdf/347282.pdf 4066.pdf]
|-
| [http://www.mikrocontroller.net/part/CD4067 4067]
| 0,60
| Ein 16:1 Analogmultiplexer/-demultiplexer
|
| alle
| [http://www.google.de/search?q=4067+datasheet Google]
|-
|}

=== Galvanische Trennelemente ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/CNY17 CNY17]
| 0,28
| Optisch, Standardtyp
| 3,7kV 50-100kHz
| R,C
| [http://www.datasheetarchive.com/search.php?q=CNY17 PDF], [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A500%252FCNY17-I_CNY17-II_CNY17-III.pdf; PDF Temic]
|-
| [http://www.mikrocontroller.net/part/6N137 6N137]
| 0,49
| Optisch, Logikausgang (5V)
| sehr schnell 14MHz
| R,D,[https://www.IT-WNS.de/ I]
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=0;INDEX=0;FILENAME=A500%252F6N137.pdf; PDF]
|-
| ADUM240*
| 10
| Induktiv, 3V/5V Logik
| extrem schnell, EN90650, 5kV
| F
| [http://www.datasheetarchive.com/search.php?q=adum240 PDF]
|-
| ISO72*
| 1,25
| Kapazitiv, 3V/5V
| 6kV, bis zu 150MHz
| DK,F
| [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=897&uiTemplateId=NODE_STRY_PGE_T PDF]
|-
| PC817/827/837/847
| 0,3
| Optisch
| 8x7, x=Anzahl der Optokoppler
| C, R, [https://www.IT-WNS.de/ I]
| [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=897&uiTemplateId=NODE_STRY_PGE_T PDF]
|-
|}

=== Displays ===
Bei den Textdisplays eignet sich praktisch jedes [[HD44780]] konforme Display.
Praktisch jeder Elektronikversender hat eine Auswahl an verschiedenen Größen zu bieten.
Wer keinen besonderen Anspruch auf die Größe der Displays hat sollte sich bei Pollin und in Ebay umschauen.

=== Speicher ===

==== [[RAM]] ====

==== [[EEPROM]] ====

{| {{Tabelle}} class="wikitable sortable" id="EEPROMmemory"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| ST 24C01 BN6, ST 24C02 BN6, ST 24C256 BN6 (allgemein 24C## mit ## Größe in kbit)
| 0,14€ - 1,50€
| EEPROM Speicher mit seriellem (I2C) Interface, 1kbit bis 512 kbit Speicher. Viele verschiedene Hersteller.
| Speichern von Konfigurationsdaten
| R
| [http://www.datasheetarchive.com/search.php?q=24C PDF]
|-
|}

== Converter ==
=== ADC ===

{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Geschwindigkeit / Sps/s
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/ADC830 ADC830]
| 6
| 8-Bit-ADC, Differentiell, Parallel, (DIL-20)
| 8770
| C,R
| [http://www.datasheetarchive.com/search.php?q=adc830 PDF]
|-
|-
| [http://www.mikrocontroller.net/part/LTC2400 LTC2400CS8]
| 8,30
| 24-Bit-ADC, Single Ended, Seriell (SPI), (SO-8)
| ca. 6
| R
| [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1001,C1152,P1636,D1887]
|-
|-
| [http://www.mikrocontroller.net/part/LTC2440 LTC2440CGN]
| 8,40
| 24-Bit-ADC, Differentiell, Seriell (SPI), (SSOP-16)
| bis 3500
| R
| [http://www.datasheetarchive.com/search.php?q=LTC2440 PDF]
|-
|-
| CS5381
| 37,50
| 24 Bit Stereo-Audio-ADC (SOIC-24)
| bis 192k
|
| [http://www.cirrus.com/en/products/cs5381.html Seite]
|-
|-
| ADS830
| 6,10
| 8 Bit ADC Parallel (SSOP-20)
| bis 60M
| R
| [http://www.datasheetcatalog.com/datasheets_pdf/A/D/S/8/ADS830.shtml PDF]
|-
|-
| [http://www.mikrocontroller.net/part/MCP3204 MCP3204]
| 2,65
| 12-Bit-SAR-ADC, Single Ended, 4 Kanäle mit MUX, Seriell (SPI), (DIL-14/SO-14)
| bis 100k
| C,R
| [http://ww1.microchip.com/downloads/en/DeviceDoc/21298c.pdf PDF]
|-
|}

=== DAC ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/DAC08 DAC08]
| 0,90
| 8-Bit DAC mit parallelem Businterface.
| Alt, preiswert. Benötigt viele µC Pins (min. 8, paralleler Bus) und eine doppelte Spannungsversorgung. Langsamere Version: 0808.
| alle
| [http://www.google.de/search?q=DAC08+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/AD7524 AD7524]
| 3,00
| 8-Bit DAC mit parallelem Businterface
| Benötigt viele µC Pins. Single-Supply (5V bis 15V).
| alle
| [http://www.google.de/search?q=7524+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/TDA8444 TDA8444]
| 1,20
| Achtfach 6-Bit DAC mit seriellem TWI-Businterface. Bezahlbarer sechsfach-DAC, allerdings mit geringer Auflösung.
| Dort wo µC gesteuert viele Ausgangskanäle mit geringer, ungenauer Auflösung benötigt werden.
| R
| [http://www.google.de/search?q=TDA8444+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/PCF8591 PCF8591]
| 2,50
| 8-Bit DAC, 8-Bit ADC mit seriellem TWI-Businterface.
| Z.B. in Regelkreisen wo sowohl ein DAC, als auch ein ADC benötigt wird.
| R
| [http://www.google.de/search?q=PFC8591+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/TDA8702 TDA8702]
| 2,50
| 8-Bit Video DAC mit parallelem Businterface und Clock-Eingang.
| Schnelle Wandlung bis 30 MHz. Benötigt viele µC Pins.
| R
| [http://www.google.de/search?q=TDA8702+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/LTC1661 LTC1661]
| 2,45
| Dual 10-bit DAC mit seriellem 3-Leitungs-Businterface.
| Guter Kompromiss aus Preis und Leistung. (Achtung, Micro-SO8-Gehäuse)
| F, C (Suchfunktion weigert sich manchmal ihn im Conrad-Shop zu finden), R
| [http://www.google.de/search?q=LTC1661+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/LTC1257 LTC1257]
| 6,20
| 12-bit DAC mit kaskadierbarem seriellen 3-Leitungs-Businterface.
| Genauer µC-steuerbarer DAC.
| C, F, R
| [http://www.google.de/search?q=LTC1257+Datasheet Google]
|-
| [http://www.mikrocontroller.net/part/LTC1456 LTC1456]
| 10,-
| 12-bit DAC mit kaskadierbarem seriellen 3-Leitungs-Businterface.
| Genauer µC-steuerbarer DAC.
| C
| [http://www.google.de/search?q=LTC1456+Datasheet Google]
|-
| MCP4922
| 2,25
| 2Kanal 12-bit DAC mit SPI-Interface
| Genauer µC-steuerbarer DAC von Microchip.
| R
| [http://ww1.microchip.com/downloads/en/devicedoc/21897a.pdf Datenblatt]
|-
|}

== Sensoren (aktiv) ==
=== [[Temperatursensor|Temperatur]] ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/LM75 LM75]
| 1,75
| Temperatursensor mit I²C (TWI) Bus Interface (3.3V und 5V Version) (SMD)
| D, R, [https://www.IT-WNS.de/ I]
| [http://www.datasheetarchive.com/search.php?q=LM75 PDF]
|-
| [http://www.mikrocontroller.net/part/DS1621 DS1621]
| ~5
| Temperatursensor mit I²C (TWI) Bus Interface (wie LM75, kein SMD)
| C, D
|
|-
| [http://www.mikrocontroller.net/part/DS18B20 DS18B20]
| 2,95
| Temperatursensor mit 1-Wire Interface
| D, R, [https://www.IT-WNS.de/ I]
| [http://www.datasheetarchive.com/search.php?q=DS18B20 PDF]
|-
| [http://www.mikrocontroller.net/part/LM35 LM35]
| 1,19
| Analoger Temperatursensor
| D, R
| [http://www.datasheetarchive.com/search.php?q=LM35 PDF]
|-
| [http://www.mikrocontroller.net/part/LM335 LM335]
| 0,87
| Analoger Temperatursensor
| R
| [http://www.datasheetarchive.com/search.php?q=LM335 PDF]
|-
| [http://www.mikrocontroller.net/part/TSIC306 TSIC306]
| 6
| Digitaler Temperatursensor (auch analog oder ratiometrisch)
| R,C
| [http://www.datasheetarchive.com/search.php?q=TSIC306 PDF]
|-
|-
| [http://www.mikrocontroller.net/part/TSIC506 TSIC506]
| 6
| Digitaler Temperatursensor (fertig kalibriert bis zu 0,1K zwischen 0-45°C)
| F
| [http://www.zmd.de/pdf/ZMD%20TSic%20Data%20Sheet%20V3%207.pdf PDF]
|-
|}

Wenn man z. B. einen Übertemperaturschutz bauen will, bei der es nur eine Schaltschwelle gibt, dann empfiehlt sich die Verwendung eines NTCs. Dessen Kennlinie ist gegenüber den Kennlinien von z. B. LM335 dahingehend im Vorteil, dass eine geringe Temperaturänderung besser messbar ist. Eine detailliertere Übersicht findet sich im Artikel [[Temperatursensor]]en, andere Sensoren sind in der [[:Category:Sensorik|Kategorie Sensorik]] zu finden.

= Passive Bauelemente =
== Sensoren (passiv)==
=== Licht ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
|-
| [http://www.mikrocontroller.net/part/BPX65 BPX65]
| 4,25
| Fotodiode 10µA, 350-1000nm
| schnelle Lichtmessungen (bis MHz Bereich), großer Wellenlängenbereich
| R
|-
| [http://www.mikrocontroller.net/part/BPW34 BPW34]
| 0,59
| Fotodiode 80µA, 400-1100nm
| großer Wellenlängenbereich, Low Cost model, große Verfügbarkeit
| R
|-
| [http://www.mikrocontroller.net/part/BPW21 BPW21]
| 5,25
| Fotodiode 10µA, 550nm
| Lichtspektrum des menschlichen Auges
| R
|-
|}

=== [[Temperatursensor|Temperatur]] ===
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| [http://www.mikrocontroller.net/part/KTY81 KTY81]
| ~0,50
| nichtlinear(*), bis 150°C
| in μC Schaltungen
| R, D
| [http://www.semiconductors.philips.com/acrobat/datasheets/KTY84_SERIES_5.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/KTY84 KTY84]
| 0,72
| nichtlinear(*), bis 300°C
| in μC Schaltungen
| R
| [http://www.datasheetcatalog.org/datasheet2/e/0l2lc3p1dl8e5dgghsfh2oee43py.pdf PDF]
|-
| [http://www.mikrocontroller.net/part/PT100 Pt100] / [http://www.mikrocontroller.net/part/PT1000 Pt1000]
| ab 3,00
| lineare Kennlinie
| analoge Messschaltungen
| F C R
|
|-
|}

(*) Verschaltet man den Sensor als Spannungsteiler (Abgriff an den ADC), so erhält man dadurch eine meist ausreichende Linearisierung!

== Widerstände ==
Mit einem Widerstandssortiment, welches die E12-Werte enthält, kann man normalerweise nicht falsch liegen. Denn früher oder später benötigt man jeden Widerstandswert der E12-Reihe einmal. Für einen Einstieg eignen sich die Sortimente vom Pollin. Auch ein Blick in Ebay kann sich lohnen, um ein Einstiegssortiment zu bekommen. Wer Schaltungen an Netzspannung entwickelt, sollte auf die ''Operation Voltage'' achten, denn nicht alle Typen weisen die nötige Spannungsfestigkeit auf. Als Daumenregel gilt: ½-Watt-Widerstände oder größer passen immer, zwei bis drei in Reihe geschaltete ¼-Watt-Widerständen tun es auch.

== Kondensatoren ==
{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 100nF Keramik
| ~0.05
|
| [[Kondensator#Entkoppelkondensator | Abblockkondensator]] zwischen VCC und GND vor allem bei Digital-ICs
| alle
| [http://www.datasheetarchive.com/search.php?q= PDF]
|-
| 100nF Keramik SMD 0603
| ~0.01 (bei 100 Stück)
| SMD 0603
| [[Kondensator#Entkoppelkondensator | Abblockkondensator]] zwischen VCC und GND vor allem bei Digital-ICs
| D
| [http://www.google.de/search?num=100&hl=de&q=datasheet+0603+chip-capacitors+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-
|}

= Mechanische Bauelemente =

== Taster / Schalter ==

== Steckverbinder ==

{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| WSL 10G
| 0,07
| Wannenstecker, 10-polig, gerade, Raster 2,54 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| R, alle
| -
|-
| PFL 10
| 0,09
| Pfostenleiste, 10-polig, Schneidklemmtechnik, Raster 2,54 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| R,alle
| -
|-
| AWG 28-10G
| 0,70€/m
| Flachbandkabel, 10-polig, 3 Meter, Raster 1,27 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| R,alle
| -
|-
| D-SUB BU 09FB
| 0,50
| D-Sub 9-polig auf 10-polig Pfostenleiste mit Flachbandkabel
| Anschluss für serielle Schnittstelle am PC
| R
| -
|-
| KKxx025C
| 0,35 - 1,20
| Flachkabel-IC-Sockelverbinder, xx-polig (08, 14, 16, 18, 20, 28 erhältlich)
| Übergang von Leiterplatte auf Steckbrett
| R
| -
|-
| Anreihklemmen
| 0,30
| Reihenklemme/Anreihklemme (verschieden Typen, für Lochraster: Raster 5.08)
| Anschluss der Spannungsversorung, leistungsstarke Verbraucher
| alle
| -
|-
|
| 0,30
| Hohlstecker/DC-Stecker
| siehe englische Wikipedia [http://en.wikipedia.org/wiki/Coaxial_power_connector Coaxial power connector]
| -
| -
|-
|}

= Lieferanten =

'''Lokale Lieferanten: [[Lokale Anbieter]]'''
 
Allgemeine Lieferantenliste: [[Elektronikversender]] 
Metallteile/Mechanik Lieferantenliste: [[Eisenwarenversender]] 

{| {{Tabelle}} class="wikitable sortable" id="opamps"
|- bgcolor="#eeeeee"
! Kürzel
! Name
! Webseite
! Kommentar
|-
|B
|Bürklin
|[http://www.buerklin.de www.buerklin.de]
|Ladengeschäft in München
|-
|C
|Conrad
|[http://www.conrad.de www.conrad.de]
|Gigantisches Sortiment, aber sehr hohe Preise. Nur zu empfehlen, wenn die benötigten Teile nirgendwo anders aufzutreiben sind. Trotzdem kann man auch hier gelegentlich ein Schnäppchen machen. Filialen haben nicht alle Katalogartikel auf Lager
|-
|D
|CSD-Electronics
|[http://www.csd-electronics.de www.csd-electronics.de]
|Kleiner Shop mit überschaubarem Sortiment und akzeptablen Preisen. Ladengeschäft in Bonn
|-
|DK
|Digikey
|[http://de.digikey.com www.de.digikey.com]
|Mindestbestellmenge von 65€, sonst 18€ Versandkosten
|-
|F
|Farnell
|[http://www.farnell.de www.farnell.de]
|Versand nur Firmen & Studenten. Farnell-Zwischenhändler für Privatkunden: HBE-Shop [http://www.hbe-shop.de] (wenn Ware im Shop nicht gelistet, einfach Farnell-Bestellnummer eingeben)
|-
|I
|IT-WNS
|[http://www.it-wns.de www.it-wns.de]
|Kein Mindestbestellwert, geringe Versandkosten ab 1,90;
|-
|M
|Meilhaus
|[http://www.meilhaus.de www.meilhaus.de]
|Nur gewerbliche Kunden
|-
|P
|Pollin
|[http://www.pollin.de www.pollin.de]
|Hier finden sich viele Schnäppchen und Industrierestposten
|-
|U
|Mouser
|[http://www.mouser.com www.mouser.com]
| 20€ Versand, ab 65€ Versandkostenfrei. Großes Sortiment und meist die niedrigsten Preise wenn man größere Stückzahlen benötigt.
|-
|R
|Reichelt
|[http://www.reichelt.de www.reichelt.de]
| Mindestbestellmenge von 10€, sonst Zuschlag von 3€, 5,60€ Versand, großes Sortiment und meist gute Preise
|-
|}

[[Kategorie:Bauteile| ]]
[[Kategorie:Lieferanten]]
[[Kategorie:Liste mit Bauteilen]]

AVR-Tutorial: Stack

2014-07-15T08:19:59Z

Prx:

"[[Stack]]" bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da nahezu alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-Tutorial: Stack

2014-07-15T08:06:11Z

Prx: Indirekte Sprünge veraltet

"[[Stack]]" bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-Tutorial: Stack

2014-07-15T08:01:50Z

Prx:

"[[Stack]]" bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-Tutorial: Stack

2014-07-15T07:59:42Z

Prx: IN statt MOV

"[[Stack]]" bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung irrtümlich angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

Feuchtesensor

2014-03-12T09:35:46Z

Prx: /* Micromaus gibts nicht mehr */

Feuchtigkeitssensoren bzw. Feuchtesensoren arbeiten meist nach dem Prinzip eines feuchtigkeitsabhängigen Kondensators. 

==Typen==

===Dallas/Maxim DS1923===
Eigentlich ein Temperatur-& Feuchtelogger, aber auch nur als Sensor verwendbar. 
Edelstahl-1wire-iButton mit Lithiumzelle 
Gibt es nicht mehr als Sample, kostet etwa 50 Euro bei www.spezial.de. 
Hygrochron Temperature/Humidity Logger iButton with 8KB Data-Log Memory 
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4379/t/al

===Philips H1 2322 691 90001===
vom Reichelt (Datenblatt dort downloaden): 
jetzt von vishay hergestellt: http://www.vishay.com/docs/29001/23226919.pdf 
Applikation von Valvo dazu:
http://docs.poulter.de/Elektronik/Sensoren/Luftfeuchtesensor%20VALVO.pdf (link down)
FEUCHTESENSOR Sensor für Feuchtigkeit € 10.00 
Feuchtesensor zur Messung und Regelung der relativen Luftfeuchte 
Kapazität: 122pF +/-15%
Empf.(Frel=43%): 0,4pF/%Frel 
Meßfrequenz: 1kHz...1MHz
Meßbereich: 10%...90% 
Top: 0°C...+85°C
Vmax: 15V 
Weitere Informationen zu diesem Artikel finden Sie in den Datenblättern

Auswerten z. B. mit einem Oszillator muss man selbst!

===KM33 von Innovative Computer===
ab € 43,00 
Schuricht 115-245057 
vermutlich auch nur ein variabler Kondensator

===HIH-3610, HIH3610===
von Honeywell (sehr linear, aber über € 23,00) 
analoger Ausgang 0..4V 
Versionen:
* -001 RM 2,54 unkalibriert
* -002 RM 1,27 unkalibriert
* -003 RM 2,54 kalibriert
* -004 RM 1,27 kalibriert
Nachtrag: sind abgekündigt, Nachfolger: 
HIH-4000-001, HIH4000-001 und HIH-4000-003, HIH4000-003 

Mittlerweile ist der HIH-5030/31 aktuell. (Stand: Sep. 2009)

http://catalog.sensing.honeywell.com/ss.asp?FAM=humiditymoisture 
Für den Sensor HIH-3605 gibt es eine Applikation, in der der Sensor an den 1-wire Bus von Dallas angeschlossen wird. Der Sensor läßt sich so mit einer verdrillten Leitung betreiben und auslesen. 
http://www.sensorsmag.com/sensors/humidity-moisture/a-1-wire-humidity-sensor-1080

===H25K5A===
von Sencera (<4€ bei CSD) 
Variabler Widerstand bei Wechselspannung. 
Bereich 0..+60°C, 20..90%RH. Achtung: auch Lagerung nur bis 90%RH 
Temperaturkompensierte Messung über Spannungsteiler mit handelsüblichem NTC.
 

===HS1101===
von Humirel (~14€ bei CSD) 
Variable Kapazität, 164..200pF. 
Temperaturbereich -40..+100°C. 
Temperaturkompensierter Oszillator mit CMOS-Timer 555 im Datasheet.

===HYT371===
von Hygrosens (~11€ bei Reichelt) 
Temperaturbereich -40..+100°C. 
Genauigkeit 3% rF, 0.4°C 
Interface I2C 
Meßprinzip kapazitiv 
Es gibt diverse weitere Sensoren, die Dokumentation ist allerdings bei allen sehr schlecht bzw. steht in separaten Dokumenten unter [http://www.hygrosens.com/produkte/sensorelemente/digitale-feuchtesensoren.html Doku]. 
Für Parallelbetrieb mehrerer Sensoren läßt sich die I2C Adresse im EEPROM ändern (Beitrag: [http://www.mikrocontroller.net/topic/222242#2234294 I2C Adresse ändern]).
sieht auch: HYT Serie von [http://www.hygrosens.com/produkte/sensorelemente/digitale-feuchtesensoren.html Hygrosens Instruments Web-Seiten]

===INSED===
* HIH3602A Feuchtigkeit und Temperatur (ab € 79,00) bei RS-Components
* HIH3602C Feuchtigkeit und Temperatur (ab € 82,00) bei RS-Components

Bezugsquellen: 
INSED GmbH + Co KG Sensoren für die Industrie Kronenstr 10 70794 Filderstadt 0711-9972758 Fax 9972762 
IBA GmbH Ingenieurbüro für Sensorik
Am Sandborn 14 63500 Seligenstadt 06182 95980 
Schuricht, RS-Components, Farnell 

===www.vaisala.be===
* 17204HM-humichip- mit Temp-Sensor KTY85-110 (special selection), analog 0..1V 
* 17205HM ohne Temp-Sensor analog 0..1V 

Datenblatt fand ich nicht auf deren Homepage, aber im Forum: 
http://www.mikrocontroller.net/forum/read-1-15717.html#48616 

Vermutlich verkaufen sie lieber fertige Module: 
http://www.vaisala.com/businessareas/instruments/products/humidity 
http://www.vaisala.com/businessareas/instruments/products/humidity/modules/oemmodules

===Sensirion===
Von [http://www.sensirion.com Sensirion] gibt es eine ganze Reihe kombinierter Feuchte- und Temperatursensoren mit digitaler Schnittstelle.
* Sensoren mit digitaler 2-Draht Schnittstelle (nicht kompatibel zu I2C): SHT10, SHT11, SHT15, SHT71, SHT75
* Sensoren mit I2C-Schnittstelle: SHT21, SHT25
* Eval-Kits: EK-H4 EK-H5 (für SHT1x, 2x, 7x)

Siehe hierzu auch:
* [http://pic-projekte.de/phpBB3/viewtopic.php?f=39&t=94 Assembler Ansteuerung]

===Silicon Labs===
Von [http://www.silabs.com Silicon Labs] gibt es einen kombinierten Feuchte- Temperatursensor mit I2C. Temperaturbereich -45 °C - 85 °C, Feuchte 0% bis 100%, [http://www.silabs.com/products/sensors/humidity-sensors/Pages/Si7005.aspx Si7005]
Bezugsquelle: SiLabs direkt bzw. über Mouser

===E+E Elektronik===

[http://www.epluse.com www.epluse.com]

Von E+E Elektronik gibt es einige Sensoren für verschiedene Anwendungsbereiche und Montagearten:

*HC1000 High End Feuchtesensor für hochpräzise Anwendung
*HC201 Sensor für Standardanwendungen

Erhältlich bei Distrelec HC1000 [https://www.distrelec.at/feuchtesensor/e-e-elektronik/hc1000-0-100/241104] und HC201 [https://www.distrelec.at/feuchtesensor/e-e-elektronik/hc201/245000]

*HCT01 kombinierter Feuchte- und Temperatursensor im SMD Gehäuse mit Schutzbeschichtung; Datenblatt [http://www.epluse.com/fileadmin/data/product/hct01/Datenblatt_HCT01.pdf]

Module

*Gut geschützes Modul EE04 [https://www.distrelec.at/feuchte-temperatur-messumformer/e-e-elektronik/ee04-ftb4a7-ha010305/245002]

*Kleiner Messumformer für Temperatur und Feuchte EE06 [https://www.distrelec.at/feuchte-temperatur-messumformer/e-e-elektronik/ee06-ft1a1/245284]

===Hoperf===
HH10D Humidity sensor
*C-F Wandler mit Kalibrierdaten im EEPROM [http://www.hoperf.com/sensor/app/HH10D.htm]

==Informationen==

* Applikationnote [http://www.sensirion.com/images/getFile?id=91 #91 (PDF)] und [http://www.sensirion.com/images/getFile?id=95 #95 (C-Quellcode)] des Herstellers
* [http://www.mikrocontroller.net/topic/48590#372123 C-Bibliothek] von Timo Dittmar im Forum
* [http://www.mikrocontroller.net/topic/145736 C-Bibliothek] in der Codesammlung
* Fertige Ansteuerung durch AVR ATMega in [http://www.ethersex.de/index.php/SHT Ethersex]

Bezugsquellen u.a.:
* http://www.driesen-kern.de/ und CSD (SHT11, 20€)
* [http://www.tme.eu/de/katalog/#id_category%3D100525%26cleanParameters%3D1%26path%3D%3B100124%3B100249%3B100525 TME]
* [http://www.csd-electronics.de/de/index.htm CSD] (Klick: ICs >> Sensoren >> Feuchtigkeit)

==Übersicht==

{| class="wikitable sortable" id="tabelleabc"
|+ '''tabellarische Übersicht 11/2013'''
|-
! Bauteil || Hersteller || Schnittstelle || Temperatur inkl.
|-
|DS1923 || Maxim || digital || ja
|-
|2381 691 90001 || Vishay || analog || nein
|-
|P14 || ISTAG || analog || nein
|-
|MK 33 || ISTAG || analog || nein
|-
|HYT-271 || ISTAG || I2C || ja
|-
|HYT-221 || ISTAG || I2C || ja
|-
|HYT-939 || ISTAG || I2C || ja
|-
|HIH-6000 series || Honeywell || I2C/SPI || ja
|-
|HIH-4000 series || Honeywell || analog || nein
|-
|HIH-1000 series || Honeywell || analog || nein
|-
|H25K5A || Sencera || analog || nein
|-
|818 || Sencera || analog || nein
|-
|H23K5A || Sencera || analog || nein
|-
|H12K5 || Sencera || analog || nein
|-
|HTS2030SMD || Measurement Specialties || analog || ja
|-
|HTU21D || Measurement Specialties || I2C || ja
|-
|HS1101LF || Measurement Specialties || analog || nein
|-
|KFS140-D || B+B Thermo-Technik || analog || nein
|-
|KFS33LC || B+B Thermo-Technik || analog || nein
|-
|SHT10 || Sensirion || digital || ja
|-
|SHT11 || Sensirion || digital || ja
|-
|SHT15 || Sensirion || digital || ja
|-
|SHT20 || Sensirion || I2C || ja
|-
|SHT21 || Sensirion || I2C || ja
|-
|SHT25 || Sensirion || I2C || ja
|-
|SHT71 || Sensirion || digital || ja
|-
|SHT75 || Sensirion || digital || ja
|-
|Si7005-B || Silicon Labs || digital || ja
|-
|HCT01 || E+E Elektronik || analog || nein
|-
|HC109 || E+E Elektronik || analog || nein
|-
|HC201 || E+E Elektronik || analog || nein
|-
|HC103M2 || E+E Elektronik || analog || nein
|-
|AM2321 || Aosong || I2C || ja
|-
|DHT11 || Aosong || I2C || ja
|-
|AM2305 || Aosong || I2C || ja
|-
|AM2301 || Aosong || I2C || ja
|}

[[Kategorie:Sensorik]]

ARM Bitbanding

2014-02-21T20:32:35Z

Prx: /* Wortbreite */

= Hintergrund =

Eine RISC Architektur wie die der ARM Prozessoren besitzt oft keine
Befehle, um einzelne Bits im Speicher zu manipulieren. Um ein
einzelnes Bit in einem Peripherieregister zu setzen ist daher eine Folge
mehrerer Befehle erforderlich, wie beispielsweise

<syntaxhighlight lang="avrasm">
ldr r0, =0x40012C0C
ldrh r1, [r0]
orr r1, #1<<9
strh r1, [r0]
</syntaxhighlight>
oder in C formuliert
<syntaxhighlight lang="c">
uint16_t temp = TIM1.DIER;
temp |= 1<<9;
TIM1.DIER = temp;
</syntaxhighlight>

Wenn eine solche Befehlssequenz im Hauptprogramm steht und in einem
Interrupt Handler ein anderes Bit des gleichen Peripherieregisters verändert
wird, dann kann es vorkommen, dass der Handler zwischen dem Load- und
dem Store-Befehl dieser Sequenz ausgeführt wird. In diesem Fall geht
die Änderung im Handler mit dem Store-Befehl verloren, der seinen Wert
aus dem Zustand vor dem Aufruf des Handlers ableitet.

Nun kann man natürlich die Befehlssequenz dagegen absichern, indem man
sie mit abgeschalteten Interrupts ausführt. Das ist aber recht
umständlich und verlängert zudem die Reaktionszeit von Interrupts.

ARM Controller mit den Cores Cortex-M3 und -M4 sowie auch manche
Cortex M0+ besitzen jedoch die Fähigkeit, einzelne Bits im RAM und im
Peripheriebereich direkt adressieren zu können. Dazu existiert für den
Peripheriebereich 0x40000000-0x400FFFFF ein weiterer Adressbereich
0x42000000-0x43FFFFFF und für den RAM-Bereich 0x20000000-0x200FFFFF
der Bereich 0x22000000-0x23FFFFFF. Das sogenannte '''Bitbanding'''.

= Arbeitsweise =

In der Bitbanding-Region wird aus den Adressbits 5..24 die Byteadresse
abgeleitet, indem diese Bits um 5 Bits nach rechts verschoben zur
Basisadresse der normalen Region addiert werden. Die Adressbits 2..4
geben die Bitnummer im Byte an. Die Adressbits 0..1 besitzen keine
Funktion und sollten 0 enthalten.

Ladebefehle in einer Bitbanding-Region laden den Wert 1, wenn das
adressierte Bit gesetzt ist, sonst 0. Speicherbefehle speichern Bit 0
des Wertes ins adressierte Bit.

[[Datei:Bitbanding1.png|Adressierung]]

Dadurch wird die obige Sequenz nun zu:

<syntaxhighlight lang="avrasm">
ldr r0, =0x422581A4
mov r1, #1
strh r1, [r0]
</syntaxhighlight>
oder in C
<syntaxhighlight lang="c">
*(volatile uint16_t *)0x422581A4 = 1;
</syntaxhighlight>

Das skizzierte Problem mit Interrupt-Handlern kann hier nicht mehr
auftreten, da die Bitmodifikation als ununterbrechbarer Teil des
Store-Befehls ausgeführt wird.

= Zu beachten =

== Interner Ablauf ==

Es handelt sich bei einer Bitmodifikation weiterhin um eine Abfolge von drei getrennten Operationen:
* Wert aus dem RAM/Peripherieregister laden,
* Bit setzen,
* Wert wieder speichern.
Nur wird diese Sequenz vom Core im Store-Befehl ausgeführt.
Die Bitbanding-Operation ist also nicht exakt äquivalent zu speziellen
Peripherieregistern mit Setzen/Löschen Funktion, wie sie insbesondere
bei GPIO Ports nicht selten zu finden sind. Diese speziellen Register
führen wirklich nur eine Bitoperation durch, während es sich beim
Bitbanding technisch um Operationen auf das gesamte Register handelt.

Siehe: [http://www.mikrocontroller.net/topic/267654 Wo Bitbanding nicht funktioniert]

== Wortbreite ==

Der Core verwendet bei den Bitbanding-Operationen intern die
Zugriffsbreite genau so, wie sie im Befehl angegeben wird. Ports die
nur wortweise angesprochen werden dürfen, müssen also auch beim
Bitbanding wortweise angesprochen werden. Halbwort- oder Bytebefehle
sind dann nicht zulässig.

== Aliasing ==

Der C Compiler weiss nicht, dass es sich bei den verschiedenen
Adressen für die normalen Daten und deren Bitbanding-Adressen in
Wirklichkeit um die gleiche Speicherstelle handelt. Es kann also
sogenanntes Aliasing auftreten.

Damit der Optimizer des Compilers keinen Strich durch die Rechnung
macht sollten alle Daten, die per Bitbanding angesprochen werden, als
"volatile" deklariert werden. Das gilt sowohl für die Daten selbst,
als auch für deren Spiegelbereich in der Bitbanding-Region.

Dies betrifft in der Praxis hauptsächlich Bitbanding im RAM-Bereich, da
die Peripherieregister ohnehin als "volatile" deklariert sind.

= Makros =

Um die Adressrechnung vom Bitbanding zu vereinfachen wird man
sinnvollerweise Makros einsetzen. Wer C++ verwendet kann natürlich
auch Templates nutzen.

==GCC==

Beim GNU Compiler kann man für den Peripheriebereich beispielsweise diese Makros verwenden, die auf den Definitionen und der Konvention von ARM CMSIS aufsetzen und Besonderheiten des GNU Compilers nutzen:

===Direkte Adressierung===

<syntaxhighlight lang="c">
// Access bitbanded peripheral register by direct address.
#define BBPeriphBit(perReg, bit) (*(__typeof__(perReg)*) ((PERIPH_BB_BASE + (((unsigned)&(perReg) - PERIPH_BASE) << 5) + ((bit) << 2))))
#define BBPeriphMask(perReg, mask) BBPeriphBit(perReg, BBitOfMask(mask))
#define BBitOfMask(mask) (31 - __builtin_clz(mask))
</syntaxhighlight>

Damit lassen sich direkt adressierte Peripherieregister ansprechen:
<syntaxhighlight lang="c">
BBPeriphBit(TIM1->DIER, 9) = 1;
</syntaxhighlight>

Das Makro BBPeriphMask erwartet keine Bitnummer, sondern eine
Bitmaske, da die Definitionen in den Include-Files der Hersteller die
Bits u.U. nur als Maske zur Verfügung stellen. Die Umrechnung einer konstanten
Maske in eine Bitnummer erfolgt durch den Compiler.

Die Adressrechnung erfolgt bei konstanten Adressen durch den Compiler. Über einen Pointer adressierte Register sollten so nicht verwendet werden, jedenfalls nicht wenn man über diesen Pointer mehrere Zugriffe in der Funktion durchführt, da dann die Adressrechnung zur Laufzeit erfolgt und man sehr von der Intelligenz des Optimierers abhängt.

===Indirekte Adressierung===

<syntaxhighlight lang="c">
// Convert regular base address of a peripheral to bitbanded base address.
// perPtr: base address of peripheral, typed as pointer to peripheral_TypeDef
#define BBaseOfPeriph(perPtr) ((__typeof__(*(perPtr))*) (PERIPH_BB_BASE + (((unsigned)(perPtr) - PERIPH_BASE) << 5)))

// Access bitbanded peripheral register by bitbanded base address and register offset.
// perBB: bitbanded base address of peripheral, typed as pointer to peripheral_TypeDef
// member: member name of peripheral_TypeDef
#define BBOffset(perBB, member) (__builtin_offsetof(__typeof__(*(perBB)), member) << 5)
#define BBasedBit(perBB, member, bit) (*(__typeof__((perBB)->member)*) (((unsigned)(perBB) + BBOffset(perBB, member) + ((bit) << 2))))
#define BBasedMask(perBB, member, mask) BBasedBit(perBB, member, BBitOfMask(mask))
</syntaxhighlight>

Beispiel:

<syntaxhighlight lang="c">
extern TIM_TypeDef *timer;
TIM_TypeDef *timer_bbptr = BBaseOfPeriph(timer);
BBasedMask(timer_bbptr, DIER, TIM_DIER_CC1DE) = 1;
</syntaxhighlight>

Die Adressrechnung erfolgt hier zur Laufzeit in BBaseOfPeriph(). Bei konstanter Bitnummer erfolgt die Berechnung des Offsets relativ zum Pointer durch den Compiler, beim Zugriff entsteht dann also kein Zusatzaufwand. Der Bitbanding-Pointer timer_bbptr lässt sich für alle Register des Timers verwenden.

===Portierung auf andere Compiler===

Es wird der Maschinenbefehl CLZ (Count Leading Zeroes) verwendet, um eine Bitmaske in eine Bitnummer zu übersetzen. Alternativ kann dies auch per ?: Kaskade realisiert werden, nur übersetzt sich dies bei nicht-konstanter Maske in hässlich viel Code. GCC berechnet bei konstanter Maske die CLZ Operation bereits selbst.

Mit __typeof__ wird erreicht, dass die Zugriffe automatisch mit der richtigen Breite durchgeführt werden. Ein in Halbwortbreite deklariertes Register wird auch mit Halbwortbefehlen angesprochen.

Das Konstrukt __builtin_offsetof existiert auch als offsetof.

[[Kategorie:ARM]]

ARM Bitbanding

2014-02-21T20:27:12Z

Prx: /* Portierung auf andere Compiler */

= Hintergrund =

Eine RISC Architektur wie die der ARM Prozessoren besitzt oft keine
Befehle, um einzelne Bits im Speicher zu manipulieren. Um ein
einzelnes Bit in einem Peripherieregister zu setzen ist daher eine Folge
mehrerer Befehle erforderlich, wie beispielsweise

<syntaxhighlight lang="avrasm">
ldr r0, =0x40012C0C
ldrh r1, [r0]
orr r1, #1<<9
strh r1, [r0]
</syntaxhighlight>
oder in C formuliert
<syntaxhighlight lang="c">
uint16_t temp = TIM1.DIER;
temp |= 1<<9;
TIM1.DIER = temp;
</syntaxhighlight>

Wenn eine solche Befehlssequenz im Hauptprogramm steht und in einem
Interrupt Handler ein anderes Bit des gleichen Peripherieregisters verändert
wird, dann kann es vorkommen, dass der Handler zwischen dem Load- und
dem Store-Befehl dieser Sequenz ausgeführt wird. In diesem Fall geht
die Änderung im Handler mit dem Store-Befehl verloren, der seinen Wert
aus dem Zustand vor dem Aufruf des Handlers ableitet.

Nun kann man natürlich die Befehlssequenz dagegen absichern, indem man
sie mit abgeschalteten Interrupts ausführt. Das ist aber recht
umständlich und verlängert zudem die Reaktionszeit von Interrupts.

ARM Controller mit den Cores Cortex-M3 und -M4 sowie auch manche
Cortex M0+ besitzen jedoch die Fähigkeit, einzelne Bits im RAM und im
Peripheriebereich direkt adressieren zu können. Dazu existiert für den
Peripheriebereich 0x40000000-0x400FFFFF ein weiterer Adressbereich
0x42000000-0x43FFFFFF und für den RAM-Bereich 0x20000000-0x200FFFFF
der Bereich 0x22000000-0x23FFFFFF. Das sogenannte '''Bitbanding'''.

= Arbeitsweise =

In der Bitbanding-Region wird aus den Adressbits 5..24 die Byteadresse
abgeleitet, indem diese Bits um 5 Bits nach rechts verschoben zur
Basisadresse der normalen Region addiert werden. Die Adressbits 2..4
geben die Bitnummer im Byte an. Die Adressbits 0..1 besitzen keine
Funktion und sollten 0 enthalten.

Ladebefehle in einer Bitbanding-Region laden den Wert 1, wenn das
adressierte Bit gesetzt ist, sonst 0. Speicherbefehle speichern Bit 0
des Wertes ins adressierte Bit.

[[Datei:Bitbanding1.png|Adressierung]]

Dadurch wird die obige Sequenz nun zu:

<syntaxhighlight lang="avrasm">
ldr r0, =0x422581A4
mov r1, #1
strh r1, [r0]
</syntaxhighlight>
oder in C
<syntaxhighlight lang="c">
*(volatile uint16_t *)0x422581A4 = 1;
</syntaxhighlight>

Das skizzierte Problem mit Interrupt-Handlern kann hier nicht mehr
auftreten, da die Bitmodifikation als ununterbrechbarer Teil des
Store-Befehls ausgeführt wird.

= Zu beachten =

== Interner Ablauf ==

Es handelt sich bei einer Bitmodifikation weiterhin um eine Abfolge von drei getrennten Operationen:
* Wert aus dem RAM/Peripherieregister laden,
* Bit setzen,
* Wert wieder speichern.
Nur wird diese Sequenz vom Core im Store-Befehl ausgeführt.
Die Bitbanding-Operation ist also nicht exakt äquivalent zu speziellen
Peripherieregistern mit Setzen/Löschen Funktion, wie sie insbesondere
bei GPIO Ports nicht selten zu finden sind. Diese speziellen Register
führen wirklich nur eine Bitoperation durch, während es sich beim
Bitbanding technisch um Operationen auf das gesamte Register handelt.

Siehe: [http://www.mikrocontroller.net/topic/267654 Wo Bitbanding nicht funktioniert]

== Wortbreite ==

Der Core verwendet bei den Bitbanding-Operationen intern die
Zugriffsbreite genau so, wie sie im Befehl angegeben wird. Ports die
nur nur wortweise angesprochen werden dürfen, müssen also auch beim
Bitbanding wortweise angesprochen werden. Halbwort- oder Bytebefehle
sind dann nicht zulässig.

== Aliasing ==

Der C Compiler weiss nicht, dass es sich bei den verschiedenen
Adressen für die normalen Daten und deren Bitbanding-Adressen in
Wirklichkeit um die gleiche Speicherstelle handelt. Es kann also
sogenanntes Aliasing auftreten.

Damit der Optimizer des Compilers keinen Strich durch die Rechnung
macht sollten alle Daten, die per Bitbanding angesprochen werden, als
"volatile" deklariert werden. Das gilt sowohl für die Daten selbst,
als auch für deren Spiegelbereich in der Bitbanding-Region.

Dies betrifft in der Praxis hauptsächlich Bitbanding im RAM-Bereich, da
die Peripherieregister ohnehin als "volatile" deklariert sind.

= Makros =

Um die Adressrechnung vom Bitbanding zu vereinfachen wird man
sinnvollerweise Makros einsetzen. Wer C++ verwendet kann natürlich
auch Templates nutzen.

==GCC==

Beim GNU Compiler kann man für den Peripheriebereich beispielsweise diese Makros verwenden, die auf den Definitionen und der Konvention von ARM CMSIS aufsetzen und Besonderheiten des GNU Compilers nutzen:

===Direkte Adressierung===

<syntaxhighlight lang="c">
// Access bitbanded peripheral register by direct address.
#define BBPeriphBit(perReg, bit) (*(__typeof__(perReg)*) ((PERIPH_BB_BASE + (((unsigned)&(perReg) - PERIPH_BASE) << 5) + ((bit) << 2))))
#define BBPeriphMask(perReg, mask) BBPeriphBit(perReg, BBitOfMask(mask))
#define BBitOfMask(mask) (31 - __builtin_clz(mask))
</syntaxhighlight>

Damit lassen sich direkt adressierte Peripherieregister ansprechen:
<syntaxhighlight lang="c">
BBPeriphBit(TIM1->DIER, 9) = 1;
</syntaxhighlight>

Das Makro BBPeriphMask erwartet keine Bitnummer, sondern eine
Bitmaske, da die Definitionen in den Include-Files der Hersteller die
Bits u.U. nur als Maske zur Verfügung stellen. Die Umrechnung einer konstanten
Maske in eine Bitnummer erfolgt durch den Compiler.

Die Adressrechnung erfolgt bei konstanten Adressen durch den Compiler. Über einen Pointer adressierte Register sollten so nicht verwendet werden, jedenfalls nicht wenn man über diesen Pointer mehrere Zugriffe in der Funktion durchführt, da dann die Adressrechnung zur Laufzeit erfolgt und man sehr von der Intelligenz des Optimierers abhängt.

===Indirekte Adressierung===

<syntaxhighlight lang="c">
// Convert regular base address of a peripheral to bitbanded base address.
// perPtr: base address of peripheral, typed as pointer to peripheral_TypeDef
#define BBaseOfPeriph(perPtr) ((__typeof__(*(perPtr))*) (PERIPH_BB_BASE + (((unsigned)(perPtr) - PERIPH_BASE) << 5)))

// Access bitbanded peripheral register by bitbanded base address and register offset.
// perBB: bitbanded base address of peripheral, typed as pointer to peripheral_TypeDef
// member: member name of peripheral_TypeDef
#define BBOffset(perBB, member) (__builtin_offsetof(__typeof__(*(perBB)), member) << 5)
#define BBasedBit(perBB, member, bit) (*(__typeof__((perBB)->member)*) (((unsigned)(perBB) + BBOffset(perBB, member) + ((bit) << 2))))
#define BBasedMask(perBB, member, mask) BBasedBit(perBB, member, BBitOfMask(mask))
</syntaxhighlight>

Beispiel:

<syntaxhighlight lang="c">
extern TIM_TypeDef *timer;
TIM_TypeDef *timer_bbptr = BBaseOfPeriph(timer);
BBasedMask(timer_bbptr, DIER, TIM_DIER_CC1DE) = 1;
</syntaxhighlight>

Die Adressrechnung erfolgt hier zur Laufzeit in BBaseOfPeriph(). Bei konstanter Bitnummer erfolgt die Berechnung des Offsets relativ zum Pointer durch den Compiler, beim Zugriff entsteht dann also kein Zusatzaufwand. Der Bitbanding-Pointer timer_bbptr lässt sich für alle Register des Timers verwenden.

===Portierung auf andere Compiler===

Es wird der Maschinenbefehl CLZ (Count Leading Zeroes) verwendet, um eine Bitmaske in eine Bitnummer zu übersetzen. Alternativ kann dies auch per ?: Kaskade realisiert werden, nur übersetzt sich dies bei nicht-konstanter Maske in hässlich viel Code. GCC berechnet bei konstanter Maske die CLZ Operation bereits selbst.

Mit __typeof__ wird erreicht, dass die Zugriffe automatisch mit der richtigen Breite durchgeführt werden. Ein in Halbwortbreite deklariertes Register wird auch mit Halbwortbefehlen angesprochen.

Das Konstrukt __builtin_offsetof existiert auch als offsetof.

[[Kategorie:ARM]]

C-Präprozessor

2013-12-09T09:01:49Z

Prx: /* #if, #ifdef */

Der erste Verarbeitungsschritt bei der Kompilierung eines [[C]]/[[C++]]-Programmes erfolgt durch den '''Präprozessor'''. Dieser verändert den Quelltext, den die späteren Verarbeitungsphasen erhalten, in folgender Hinsicht:
* Einbeziehen zusätzlicher Dateien ([[Include-Files]])
* Ersetzen von (parametrisierbaren) [[Makro]]s
* Entfernen einzelner Abschnitte (= bedingte Kompilierung)

Im Grunde kann man sich den Präprozessor als eine Art Texteditor vorstellen, der die Anweisungen, was er zu tun hat, dem Text entnimmt, den er bearbeitet. In jedem Texteditor gibt es zb. die Funktion 'Suchen und Ersetzen'. Auch im Präprozessor gibt es sie, nur heißt sie dort #define. Alle Anweisungen an den Präprozessor beginnen grundsätzlich damit, daß das Zeichen '#' das erste Zeichen in einer Textzeile darstellt. Und umgekehrt: Ist das erste Zeichen in einer Textzeile ein '#', so handelt es sich um eine Präprozessor-Anweisung.

==#include==
Die #include weist den Präprozessor an, den Inhalt der angegebenen Datei anstelle der #include Anweisung einzusetzen. Weiter passiert nichts. Bei der Angabe des Dateinamens der einzusetzenden Datei gibt es 2 Formen
<syntaxhighlight lang="c">
#include "Datei1.xyz"
#include <Datei2.abc>
</syntaxhighlight>
Der Unterschied zwischen beiden Formen besteht rein im Aufsuchpfad, den der Präprozessor benutzt, um die Datei zu finden. Per Konvention wird die < >-Form benutzt, um systemweite Includes durchzuführen. Alle mit dem Compiler mitgelieferten Header Files sind zb. solche systemweite-Includes. Bei der Installation des Compilers wurde im System hinterlassen, auf welchem Pfad sie gefunden werden können. Durch Verwendung der < >-Form wird dem Präprozessor mitgeteilt, dass diese damals vereinbarten Pfadangaben zur Aufsuche dieser Datei benutzt werden soll.

==#define==
Mittels #define wird eine Textersetzung vereinbart.
<syntaxhighlight lang="c">
#define ABC xyz
</syntaxhighlight>
weist den Präprozessor an, im weiteren Quelltext alle Vorkommen von 'ABC' durch den Text 'xyz' zu ersetzen. Der Präprozessor macht dies überall, solange
* es sich an der zu ersetzenden Stelle um keinen String handelt. Mit obigem #define würde also in "Dies ist ABC" keine Textersetzung stattfinden.
* er den Ursprungstext als 'Wort' im Sinne eines C-Wortes handelt. Mit obigem #define würde also in cdABCef = 5; keine Textersetzung stattfinden.

Wichtig ist: Der Präprozessor führt eine reine Textersetzung durch! Ob sich durch diese Ersetzung eine Logikänderung im Programm ergibt, interessiert den Präprozessor nicht.

<syntaxhighlight lang="c">
#define NR 5

int Werte[NR];

...

for( i = 0; i < NR; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

Bevor der eigentliche Compiler den Quelltext zu Gesicht bekommt, wird er zunächst vom Präprozessor bearbeitet. Dieser führt die Textersetzung durch, indem er alle Vorkommen von NR durch den Text 5 ersetzt. Erst dieses Ergebnis

<syntaxhighlight lang="c">
int Werte[5];

...

for( i = 0; i < 5; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

wird dann dem eigentlichen Compiler zur Übersetzung vorgelegt. In diesem Beispiel hat man durch den Einsatz des Präprozessors erreicht, dass die Anzahl der Arrayelemente immer mit dem Maximalwert in der for-Schleife übereinstimmt. Ein Fehler, dass beispielweise die Arraygröße verändert wird, ohne das die for-Schleife angepasst würde, ist durch den Einsatz des Präprozessors wirkungsvoll verhindert worden.

Aber auch hier wieder: Der Präprozessors macht nur eine Textersetzung! Für den Präprozessors ist es völlig unerheblich, ob sich dadurch die Logik des Programms aus Sicht des Programmierers verändert
<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*PART;
</syntaxhighlight>
In diesem Beispiel mag es schon so sein, dass der Programmierer im Sinn hatte, den Ausdruck 4 mal 8 berechnen zu lassen, wobei sich die 8 durch eine Addition von 3 und 5 ergeben. Das interessiert aber den Präprozessor nicht. Der macht eine reine textuelle Ersetzung, indem er den Text 'PART' durch den Text '3+5' austauscht, wodurch dieses Ergebnis entsteht

<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*3+5;
</syntaxhighlight>
Dies ist aber etwas anderes, nämlich '(4*3)+5', also ursprünglich beabsichtigt war, nämlich '4*(3+5)'.

Schlussfolgerung: Es ist bei komplexeren Makros nicht ungewöhnlich, dass sich in Makros relativ viele Klammern wiederfinden, deren Zweck gerade für einen Neuling nicht auf den ersten Blick zu durchschauen ist.
<syntaxhighlight lang="c">
#define PART (3+5)

...
x = PART;
y = 4*PART;
</syntaxhighlight>
Während die Klammern im Makro bei der Zuweisung an x keine Funktion erfüllen (aber auch nicht störend sind), sind sie bei der Zuweisung an y lebenswichtig um der ganzen Anweisung nach der Textersetzung die beabsichtigte Bedeutung zu geben.

==#define für eine Codesequenz==

Wird ein #define nicht für einen Ausdruck verwendet, sondern für eine Codesequenz wie in
<syntaxhighlight lang="c">
#define F(n) { a = n; b = n; }
</syntaxhighlight>
dann entsteht ein Problem bei
<syntaxhighlight lang="c">
if (...) F(1); else F(2);
</syntaxhighlight>
da hier für den Compiler letztlich
<syntaxhighlight lang="c">
if (...) { ... }; else { ... };
</syntaxhighlight>
stehen bleibt, und damit ein überzähliges Semikolon vor dem else. Nun kann man dies natürlich mit
<syntaxhighlight lang="c">
if (...) { F(1); } else { F(2); }
</syntaxhighlight>
oder
<syntaxhighlight lang="c">
if (...) F(1) else F(2)
</syntaxhighlight>
abhandeln. Gelegentlich findet man deshalb aber auch seltsam anmutende Definitionen wie
<syntaxhighlight lang="c">
#define F(n) do{ a = n; b = n; }while(0)
</syntaxhighlight>

==#if, #ifdef==

Die Statements #if und #elsif sind die einzigen Präprozessor-Statements, in denen er selbst Berechnungen durchführt. In allen anderen Fällen findet eine reine Textersetzung statt und es rechnet erst der Compiler oder der Prozessor. Da der Präprozessor aber nach eigenen Regeln rechnet, wird Code wie
<syntaxhighlight lang="c">
#define N (1000000*1000000)
#if N==1000000000000
printf("%Ld\n", (long long)N);
#endif
</syntaxhighlight>
oft zur Ausgabe von -727379968 führen. Wenn der Präprozessor mit 64 Bits rechnet und der Compiler mit 32 Bits.

==mögliche Probleme beim Einsatz des Präprozessors==
Eine am C-Präprozessor häufig geäußerte Kritik ist, dass er (nahezu) ohne Berücksichtigung der eigentlichen Sprachsyntax arbeitet ("The C-Preprocessor doesn't know about C"). Die Tatsache, dass Makros beispielsweise auf der Basis von Textersatz arbeiten, kann zu Überaschungen führen. So wird in
<syntaxhighlight lang="c">
#define cub(a) a*a*a
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
in x nicht etwa der Wert 125 (5 hoch 3) stehen, sondern der Wert 13, da nach Ersetzen des Makros der folgende Quelltext kompiliert wird ...
<syntaxhighlight lang="c">
x = y+1*y+1*y+1;
</syntaxhighlight>
... und durch die arithmetischen Vorrangregeln, wird dieser Ausdruck so ausgewertet:

<syntaxhighlight lang="c">
x = y + (1*y) + (1*y) + 1;
</syntaxhighlight>

Deshalb sollte man jeden Parameter eines Makros bei jeder Verwendung klammern. Damit werden viele Probleme mit Makros gelöst und man erhält für obiges Beispiel folgende Form und damit auch eine korrekte Berechnung:
<syntaxhighlight lang="c">
#define cub(a) ((a)*(a)*(a))
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
Ein weiteres Problem besteht jedoch, wenn ein Makro-Parameter im Ersatztext doppelt verwendet wird:
<syntaxhighlight lang="c">
#define max(a, b) ((a>b) ? (a) : (b))
...
int x, y;
...
x = max(y, 10); /* OK */
x = max(++y, 10); /* ?? */
</syntaxhighlight>
Im zweiten Fall wird die Variable ''y'' u.U. ''zweimal'' inkrementiert - was ohne Kenntnis der Makro-Definition keineswegs offensichtlich ist (''max'' könnte auch eine echte Funktion sein).

Die Tatsache, dass der C-Präprozessor die Syntax von C/C++ nicht wirklich berücksichtigt, ist allerdings auch nützlich. So lassen sich mit dem C-Präprozessor Datentypen parametrisieren, um systematische Programmteile zu vereinfachen:
<syntaxhighlight lang="c">
/* GSAWP:
generiert Funktionsdefinition zum Vertauschen des Inhalts von zwei Variablen
*/
#define GSWAP(n, T)s\
void n(T *xp, T *yp) { T tmp = *xp; *xp = *yp; *yp = tmp; }
...
GSWAP(iswap, int)
GSWAP(dswap, double)
GSWAP(swap_s, struct s)
...
int a, b;
double c, d;
struct s e, f;
...
iswap(&a, &b);
dswap(&c, &d);
swap_s(&e. &f);
</syntaxhighlight>

Viele typische Anwendungsfälle des Präprozessors lassen sich allerdings bereits mit Standard-C-Bordmitteln erfolgreich erschlagen:
* Statt ''#define'' besser mit ''const'' vereinbarte Variablen benutzen. Bei jedem besseren Compiler ergeben sich dank Optimierung keinerlei Nachteile.
* ''enum'' für Konstantenfelder benutzen. Dabei sollte man allerdings sauber casten, da ''enum''-Werte in der Regel als ''int'' interpretiert werden.
* Neuere Versionen des GCC unterstützen ''inline'', wodurch Makros für Einzeiler überflüssig werden.

In [[C++]] wurden ergänzend zum C-Präprozessor weitere Mechanismen eingeführt. So erlauben [[Templates (C++)|Templates]] generische Programmierung, womit viele der "Makro-Tricks" wie die obigen überflüssig werden.

[[Kategorie:C]]

STM32F10x Standard Peripherals Library

2013-12-08T12:46:06Z

Prx: GPIO_ToggleBits

=Allgemeines=

Die ''STM32F10x Standard Peripherals Library'' ist eine umfangreiche komfortable C-Bibliothek, die den Zugriff auf alle Funktionen der '''STM32F10x''' Familie erlaubt. Dabei ist für die verschiedenen Peripheriekomponenten jeweils ein eigenes Modul verfügbar.

Die Bibliothek kann hier bei ST kostenlos heruntergeladen werden.
Dazu auf der [http://www.st.com/web/en/home.html ST-Webseite]:
* Oben den Punkt Support wählen
* Auf der linken Seite "Tools and Software" anklicken
* Nun links nochmals "Software" auswählen
* Danach den Unterpunkt "MCU Software" wählen
* Nun die richtige MCU-Familie, also "STM32 MCUs Software" selektieren
* Es erscheint eine Tabelle mit vielen Packages für die zahlreichen Demoboards und verschiedene Bibliotheken (USB, Ethernet, etc.)
* Die STM32F10x Standard Peripherals Library ist hier als "STSW-STM32054" bezeichnet
* Nach der Auswahl kann diese über den Download-Button in einem *.zip-Archiv heruntergeladen werden

Alternativ ist hier ein [http://www.st.com/st-web-ui/static/active/en/st_prod_software_internet/resource/technical/software/firmware/stsw-stm32054.zip Direktlink].
In dem Archiv ist die ‎STM32F10x Standard Peripherals Library. Zu jeder Peripherie gibt es diverse Beispiele und eine Beschreibung als CHM Datei "stm32f10x_stdperiph_lib_um.chm".

Bevor Ihr lange sucht, die USB-Schnittstelle ist nicht in der ''STM32F10x Standard Peripherals Library'' enthalten. Die hierfür verfügbare Firmware sowie Beispielcode befindet sich in der [[STM32_USB-FS-Device_Lib]]

===Hinweise===
Die notwendigen Informationen, um die Funktionen der Standard Peripherals Library zu verstehen, muss man sich leider aus verschiedenen Quellen zusammensuchen. Daher soll mit diesem Artikel versucht werden, deren Benutzung für die verschiedenen Peripheriekomponenten zu erläutern.

Leider beziehen sich die von ST gelieferten Beispiele sehr auf die von ST verfügbaren Evalboards und der Code wimmelt von #defines, so dass man sich erst mühsam durchhangeln muss um zu verstehen, was da eigentlich passiert. Dies geht zwar durch die gute Verlinkung in der Hilfsdatei ganz gut, erschwert aber den Einstieg unnötig.

In diesem Artikel soll daher die Anwendung ''bare bones'' ähnlich den Beispielen in den AVR Datenblättern erfolgen.
Wo nötig, werden die zum Verständnis relevanten Ausschnitte des Reference Manual [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf RM0008] in den Artikel kopiert.

'''(Bevor hier die Copyright Discussion entbrennt: Das Landgericht München hat 1996 festgestellt, dass die Beschreibung von elektronischen Schaltungen nicht dem Urheberrecht unterliegen. Außerdem sollte ST sehr daran gelegen sein mehr Entwickler für Ihre µC zu begeistern.)'''

=== Dokumentationen ===

Um mit der Library zu arbeiten sind folgende Dokumentationen empfehlenswert:

* RM0008 Reference Manual zum STM32F10xxx Controller
Beschreibung und Registerdoku der Peripherie (GPIO, Timer ...)
* PM0056 STM32F10xxx Cortex-M3 programming manual
Cortex-M3 eigene Peripherie (wichtig zb. NVIC)
* Datasheet des verwendeten µC Types (zb. STM32F103xC/D/E)
Pinout des µC und alternative Verwendbarkeit der PINs

Download from [[http://www.st.com/internet/mcu/class/1734.jsp Documents and files for STM32F family]]

=== Die ST Standard Peripheral Lib in CrossWorks ===
Aufgrund mehrfacher Anfragen, hier ein Archiv, das meine Arbeitsumgebung [[Bild:CrossWorks_StandardLib_Setup.zip]] mit zwei Crossworks Projekten (ARM_LED_TEST und ARM_USB_Test) enthält. Einfach alles in ein Verzeichnis entpacken und schon sollte es Laufen.

=== Einführungsbeispiel Blinking LED ===

Einführungsbeispiel [[STM32 LEDBlinken AtollicTrueStudio]]

=== Die Idee hinter der STM32 Standard Peripherals Library ===

So stellt sich ARM und ST-Microelectronics die Library vor.

[[Datei:Stm32_std_peripherial_library_idee.JPG]]

=Clocks - Der Herzschlag unseres Mikrocontrollers=

[[Datei:stm32_aufbau.jpg|thumb|Interner Aufbau eines [[STM32F103]]]]
Unser Mikrocontroller hat viele interne Takte. Diese müssen unbedingt konfiguriert werden. Dazu verwenden wir die RCC (Reset and Clock Control). Dazu gibt es Funktionen in der ST-Library. Welche Takte an welchen Bussen liegen, siehst du im Bild.

Die Controller verfügen über zwei getrennte Datenbusse für die langsameren Teile der Periphierie. Den APB1 und den APB2. Diese sind wiederum über Brücken am Systembus angeschlossen. Das wären in diesem Fall die AHB1 und AHB2. Man muss beachten, dass der APB1 "nur" mit maximal 36MHz getaktet werden darf, der APB2 hingegen mit 72MHz.

'''Wichtig!''' Alle unsere Peripherie Teile, die wir verwenden möchten, '''müssen mit einem Takt versorgt werden,''' bevor man sie verwenden kann. Bei Nichtbeachten führt dies häufig zu langer Fehlersuche.

Der [[STM32]] wird normalerweise mit einem Quarz von 4-16MHz versorgt. Aus diesem wird dann mittels der internen PLL der eigentliche Takt gebildet (bis 72MHz).
Jeder benötigte Takt wird vom Haupttakt abgeleitet. Die Controller verfügen auch über interne RC-Oszillatoren (typischerweise ein 8 MHz RC-Oszillator mit einer Genauigkeit von 1 % sowie einem 40 kHz RC-Oszillator). Zumindest der interne 8 MHz-Oszillator ist für die meisten Anwendungen genau genug. Für z.B. USB oder CAN mit Taktraten > 100 kbit/s ist er aber '''nicht''' genau genug. Der interne 40 kHz-Oszillator hingegen ist '''sehr''' ungenau (zwischen 30 und 60 kHz).

Hardwaretechnisch sollte darauf geachtet werden, dass bei Verwendung eines externen Quarzes dieser eine Frequenz von 8 MHz besitzt.
Die gesamten Defines in der Library beziehen sich darauf. Ansonsten ist eine Anpassung der PLL Multiplikatoren in der Datei "system_stm32f10x.c" nötig.

==Taktquelle auswählen==

Nach dem Reset wird automatisch '''immer''' der interne HSI-Takt genutzt, um einen definierten Zustand zu haben (also der interne 8 MHz RC-Oszillator). Das ist z.B. erforderlich, damit der integrierte Bootloader mit einer bekannten Frequenz versorgt wird (sofern dieser über die Boot-Pins überhaupt gewünscht ist).
Zum Glück gibt es ein automatisches Sicherheitsfeature, sodass man die aktuelle Taktquelle des Controllers nicht abschalten kann, da der Controller sonst einfach stehen bleiben würde!
===HSI - Highspeed Internal Oscillator===
Man kann den internen Oszillator nach dem Reset umkonfigurieren. [Hier fehlt noch etwas]

Zum Ein- und Ausschalten der HSI-Taktquelle verwendet man '''RCC_HSICmd()'''. Als Parameter werden entweder '''ENABLE''' oder '''DISABLE''' erwartet.
<syntaxhighlight lang="c">
RCC_HSICmd(ENABLE); //Aktiviert den internen Highspeed Oszillator.
</syntaxhighlight>

==Takte Reseten==
Nach dem Reset befindet sich die gesamte Taktkonfiguration in einem definierten Zustand. Macht man später irgendwelche Änderungen an der Taktkonfiguration kann es sinnvoll sein, vorher alle Takte auf ihre Standardwerte zurückzusetzen. Dies schafft wieder eine definierte zentrale Taktkonfiguration. Man muß sich nicht überlegen, wo man noch was zuvor eingestellt hat. Hat man allerdings schon z.B. irgendwelche Peripheriemodule konfiguriert, muß man natürlich aufpassen, welche Folgen die zentrale Taktänderung hier haben kann!
Nach '''RCC_DeInit()''' sind alle Takte resettet. Übergeben wird nichts!
<syntaxhighlight lang="c">
RCC_DeInit(); //Setzt alle Takte auf deren Ursprungsszustand zurück.
</syntaxhighlight>

===HSE - Highspeed External Oscillator (Quarz)===
Es kann auch eine externe Taktquelle ausgewählt werden. Um dem Controller dies mitzuteilen, gibt es die Funktion '''RCC_HSEConfig()'''. Als Parameter erwartet sie einen der folgenden Werte: '''RCC_HSE_OFF''', '''RCC_HSE_ON''' oder '''RCC_HSE_Bypass'''.

Die Ersten sind selbsterklärend. Wenn man der Funktion jedoch '''RCC_HSE_Bypass''' übergibt, so erwartet der Controller am OSC_IN Pin ein Taktsignal. Dieses darf bis zu 25MHz schnell sein und kann Rechteck, Sinus oder Dreieck Spannung mit einem Duty Cycle von 50% sein.
<syntaxhighlight lang="c">
RCC_HSEConfig(RCC_HSE_ON); //Aktiviert den Externen Highspeed Oszillator (Quarz).
</syntaxhighlight>

=GPIOS - Wie greife ich auf einzelne Pins zur Ein/Ausgabe zu=
===Grundlagen===

Unser Mikrocontroller hat ja einige Beinchen, diese können wir als Eingänge sowie als Ausgänge verwenden.
Dazu müssen wir unserem Käfer jedoch erst sagen welcher Pin was machen soll. Wie dies geht wird hier beschrieben.

Der STM32F10x verfügt zur Manipulation der IO-Pins über ein sehr raffiniertes Feature, das es erlaubt Bits für die IO-Pins zu setzen / löschen ohne vorher deren aktuellen Zustand auslesen zu müssen (üblicherweise Read-Modify-Write). Dadurch ist gewährleistet, dass beim Setzen/Löschen von Bits kein Interrupt dies stören kann.

'''Each of the general-purpose I/O ports has two 32-bit configuration registers (GPIOx_CRL, GPIOx_CRH), two 32-bit data registers (GPIOx_IDR, GPIOx_ODR), a 32-bit set/reset register (GPIOx_BSRR), a 16-bit reset register (GPIOx_BRR) and a 32-bit locking register (GPIOx_LCKR).'''

'''Each I/O port bit is freely programmable, however the I/O port registers have to be accessed as 32-bit words (half-word or byte accesses are not allowed). The purpose of the GPIOx_BSRR and GPIOx_BRR registers is to allow atomic read/modify accesses to any of the GPIO registers. This way, there is no risk that an IRQ occurs between the read and the modify access.'''

Auf die '''BRR''' und '''BSRR''' register greift man über die entsprechenden GPIO-Port zu.

Hierzu existieren in <syntaxhighlight lang="c">\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x\stm32f10x.h</syntaxhighlight> folgende Definition:

<syntaxhighlight lang="c">
typedef struct
{
__IO uint32_t CRL;
__IO uint32_t CRH;
__IO uint32_t IDR;
__IO uint32_t ODR;
__IO uint32_t BSRR;
__IO uint32_t BRR;
__IO uint32_t LCKR;
} GPIO_TypeDef;
</syntaxhighlight>

Pointer auf die entsprechenden GPIO-Ports sind hier ebenfalls definiert:

<syntaxhighlight lang="c">
#define GPIOA ((GPIO_TypeDef *) GPIOA_BASE)
#define GPIOB ((GPIO_TypeDef *) GPIOB_BASE)
#define GPIOC ((GPIO_TypeDef *) GPIOC_BASE)
#define GPIOD ((GPIO_TypeDef *) GPIOD_BASE)
#define GPIOE ((GPIO_TypeDef *) GPIOE_BASE)
#define GPIOF ((GPIO_TypeDef *) GPIOF_BASE)
#define GPIOG ((GPIO_TypeDef *) GPIOG_BASE)
</syntaxhighlight>
Welche GPIO-Ports tatsächlich verfügbar sind ist abhängig vom verwendeten Controller!

In stm32f10x_gpio.h sind darüber hinaus Definitionen für alle Pins vorhanden:

<syntaxhighlight lang="c">
#define GPIO_Pin_0 ((uint16_t)0x0001) /*!< Pin 0 selected */
#define GPIO_Pin_1 ((uint16_t)0x0002) /*!< Pin 1 selected */
#define GPIO_Pin_2 ((uint16_t)0x0004) /*!< Pin 2 selected */
#define GPIO_Pin_3 ((uint16_t)0x0008) /*!< Pin 3 selected */
#define GPIO_Pin_4 ((uint16_t)0x0010) /*!< Pin 4 selected */
#define GPIO_Pin_5 ((uint16_t)0x0020) /*!< Pin 5 selected */
#define GPIO_Pin_6 ((uint16_t)0x0040) /*!< Pin 6 selected */
#define GPIO_Pin_7 ((uint16_t)0x0080) /*!< Pin 7 selected */
#define GPIO_Pin_8 ((uint16_t)0x0100) /*!< Pin 8 selected */
#define GPIO_Pin_9 ((uint16_t)0x0200) /*!< Pin 9 selected */
#define GPIO_Pin_10 ((uint16_t)0x0400) /*!< Pin 10 selected */
#define GPIO_Pin_11 ((uint16_t)0x0800) /*!< Pin 11 selected */
#define GPIO_Pin_12 ((uint16_t)0x1000) /*!< Pin 12 selected */
#define GPIO_Pin_13 ((uint16_t)0x2000) /*!< Pin 13 selected */
#define GPIO_Pin_14 ((uint16_t)0x4000) /*!< Pin 14 selected */
#define GPIO_Pin_15 ((uint16_t)0x8000) /*!< Pin 15 selected */
#define GPIO_Pin_All ((uint16_t)0xFFFF) /*!< All pins selected */
</syntaxhighlight>

Will man also von Hand auf die Bits dieser Register zugreifen, so ist das denkbar einfach:
<syntaxhighlight lang="c">
GPIOC->BSRR = GPIO_Pin_13;
</syntaxhighlight>
setzt das Bit für Pin 13 im Port C.
<syntaxhighlight lang="c">
GPIOC->BRR = GPIO_Pin_13;
</syntaxhighlight>
oder
<syntaxhighlight lang="c">
GPIOC->BSRR = GPIO_Pin_13 << 16;
</syntaxhighlight>
löscht dieses Bit wieder. Mit
<syntaxhighlight lang="c">
GPIOC->BSRR = (0x00F0 << 16) | ((data << 4) & 0x00F0);
</syntaxhighlight>
kann man die Pins 4..7 auf einen beliebigen Wert setzen, ohne die übrigen Pins zu beeinflussen. Die oberen 16 Bits des geschriebenen Wertes definieren die betroffenen Pins, die unteren 16 Bits den Wert. In der ''Standard Peripheral Library'' ist keine Funktion enthalten, die diese Fähigkeit des Ports unterstützt.

Die äquivalente Operation über das ODR ist nicht atomar und somit in Verbindung mit Interrupts problematisch.

Die ''Standard Peripheral Library'' stellt für dies Zugriffe allerdings auch komfortablere und vor allem sprechendere Funktionen zur verfügen, die weiter unten erklärt werden.

===Initialisierung===

'''WICHTIG: Bevor man Pins eines GPIO-Ports benutzen kann, muss man die Clock des entsprechenden Ports mit der Funktion ''RCC_APB2PeriphClockCmd'' aktivieren , da diese nach einem Reset immer ausgeschaltet ist. Dies ist ein sehr beliebter Fehler beim Arbeiten mit Ports. Mehr dazu bei [[STM32F10x Standard Peripherals Library#Clocks - Der Herzschlag unseres Mikrocontroller|Clocks]]'''

Bevor man einen Pin benutzen kann, muss dieser Initialisiert werden.

Die Funktion '''GPIO_Init()''' ermöglicht es einen oder mehere Pins auf einmal zu konfigurieren. Hierzu muss eine struct ausgefüllt und GPIO_Init übergeben werden:

<syntaxhighlight lang="c">
typedef struct
{
u16 GPIO_Pin;
GPIOSpeed_TypeDef GPIO_Speed;
GPIOMode_TypeDef GPIO_Mode;
}GPIO_InitTypeDef;
</syntaxhighlight>

Definieren müssen wir dieses zuvor jedoch auch. Dies geschieht mit

<syntaxhighlight lang="c">
GPIO_InitTypeDef GPIO_InitStructure;
</syntaxhighlight>

Danach können wir bequem auf die einzelnen Einträge aus der Struct zugreifen.
Der nachfolgende Code zeigt eine Beispielkonfiguration.

<syntaxhighlight lang="c">
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All;
</syntaxhighlight>
 
'''GPIO_Speed''' definiert die maximale Änderungsrate des Pins. Das ist aber keine harte Grenze, sondern verändert die Charakteristik des Pintreibers. Eine niedrigere Grenzfrequenz reduziert die Flankensteilheit und damit Leitungsreflexionen.
Mögliche Werte für GPIO_Speed
{| border="1" cellspacing="0" cellpadding="5" style="border-collapse:collapse;"
|''' Wert''' ||''' Bedeutung''
|-
| GPIO_Speed_2MHz || 2MHz / 125ns
|-
| GPIO_Speed_10MHz || 10MHz / 25ns
|-
| GPIO_Speed_50MHz || 30-50MHz / 5-12ns
|}

 
'''GPIO_Mode''' konfiguriert den Port oder den Port Pin.
Mögliche Werte für GPIO_Mode
{| border="1" cellspacing="0" cellpadding="5" style="border-collapse:collapse;"
|''' Wert''' ||''' Beschreibung'''
|-
| GPIO_Mode_Out_PP || Der Pin wird als Ausgang im Push Pull Modus konfiguriert. Dies bedeutet, der Ausgang kann sowohl positive als auch negative Ströme liefern
|-
| GPIO_Mode_Out_OD || Der Pin wird als Ausgang im Open Drain Modus konfiguriert.
|-
| GPIO_Mode_IN_FLOATING || Der Pin wird als Eingang im Floating modus konfiguriert. Dies bedeutet, das der Pin kein Niveau hat. Er "schwebt"
|-
| GPIO_Mode_AIN || Der Pin wird als analoger Eingang konfiguriert
|-
| GPIO_Mode_IPD || Der Pin wird als Eingang konfiguriert mit internem Pull Down Widerstand
|-
| GPIO_Mode_IPU || Der Pin wird als Eingang konfiguriert mit internem Pull Up Widerstand
|-
| GPIO_Mode_AF_OD || Der Pin wird mit Alternativer Funktion (SPI, I2C..) konfiguriert im Open Drain Modus
|-
| GPIO_Mode_AF_PP || Der Pin wird mit Alternativer Funktion (SPI, I2C..) konfiguriert im Push Pull Modus
|}
 

'''GPIO_Pin''' definiert den Pin welcher konfiguriert werden soll.

Um den zu konfigurierenden Pin anzugeben, genügt es '''GPIO_Pin_X''' zu schreiben.
Wobei "X" durch die entsprechende Pinnummer zu ersetzen ist.
 Es können auch mehrere Pins gleichzeitig konfiguriert werden.
Dazu wird einfach logische ODER verknüfung verwendet ( | )
Möchte man den gesamten Port konfigurieren, so genügt es wenn man '''GPIO_Pin_All''' angibt.

Hier ein Beispiel mit mehreren Pins

<syntaxhighlight lang="c">
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_7
</syntaxhighlight>
 

'''GPIO_Init()'''

Nachdem wir nun alle relevanten Parameter gesetzt haben, müssen wir den Port nur noch mit '''GPIO_Init()''' initialisieren.

<syntaxhighlight lang="c">
void GPIO_Init(GPIO_TypeDef* GPIOx, GPIO_InitTypeDef* GPIO_InitStruct)
</syntaxhighlight>

''GPIOx'' ist der Pointer auf den den zu initialisierenden Port. Wobei x einfach mit dem entsprechenden Buchstaben zu ersetzen ist.

''GPIO_InitStruct'' ist der Pointer auf die soeben von uns ausgefüllte struct.

Ein Beispiel für GPIOA
<syntaxhighlight lang="c">
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); // Clock des Ports einschalten

GPIO_InitTypeDef GPIO_InitStructure;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_7

GPIO_Init(GPIOA, &GPIO_InitStructure);
</syntaxhighlight>

===Etwas auf den Port ausgeben===

Um etwas an einem GPIO auszugeben, gibt es drei Möglichkeiten (Funktionen).
Entweder man schreibt den gesamten Port oder nur ein einzelnes Bit.
Die STMs bieten eine Bitbanding-Funktion, die in [[ARM Bitbanding]] genauer erklärt ist.

'''Funktion 1'''

Die erste Funktion lautet '''GPIO_SetBits()''' und '''GPIO_ResetBits()'''
Erster Parameter ist der GPIO Port, der zweite ist der Pin oder eine Kombination daraus. Kombinationen sind wieder logisch zu verknüpfen mit ODER ( | )

<syntaxhighlight lang="c">
GPIO_SetBits(GPIOA,GPIO_Pin_1 | GPIO_Pin_5); //Setzt die Bits 1 und 5 am GPIOA auf high

GPIO_ResetBits(GPIOA,GPIO_Pin_2 | GPIO_Pin_9); //Setzt die Bits 2 und 9 am GPIOA auf low
</syntaxhighlight>

In neueren Versionen der Lib existiert auch eine Funktion GPIO_ToggleBits. Die ist allerdings Stand 2013 nicht atomar implementiert. Das kann im Zusammenspiel mit Interrupts zu sporadischen Überraschungen führen.

'''Funktion 2'''

Die zweite Funktion lautet '''GPIO_WriteBit()''' Diese Funktion kann sowohl einen oder mehrere Pins setzen als auch löschen. Erster Parameter ist der GPIO Port, der zweite ist der Pin oder eine Kombination daraus, und der dritte sagt aus, ob gesetzt oder gelöscht wird! Kombinationen sind auch hier logisch zu verknüpfen mit ODER ( | ).

<syntaxhighlight lang="c">
GPIO_WriteBit(GPIOA, GPIO_Pin_1 | GPIO_Pin_5, Bit_SET); //Setzt die Bits 1 und 5 am GPIOA auf high

GPIO_WriteBit(GPIOA, GPIO_Pin_2 | GPIO_Pin_9, Bit_RESET); //Setzt die Bits 2 und 9 am GPIOA auf low
</syntaxhighlight>

'''Funktion 3'''

Die dritte und somit letzte Funktion lautet '''GPIO_Write()'''. Diese Funktion beschreibt den gesamten Port! Erster Parameter ist der GPIO Port, der zweite ist der an dem Port auszugebende Wert. '''Wichtig!''' Hier wird der ganze Port mit einem 16 bit Wert beschrieben. Viel leserlicher als mit magic numbers im Hex-Format zu arbeiten, sind natürlich auch hier die defines: GPIO_Pin_1 | GPIO_Pin_5

<syntaxhighlight lang="c">
GPIO_Write(GPIOA,0x0011); //Setzt die Bits 1 und 5 am GPIOA auf high
GPIO_Write(GPIOA, GPIO_Pin_1 | GPIO_Pin_5); // Geht natürlich auch und ist verständlicher

GPIO_ResetBits(GPIOA,0x0102); //Setzt die Bits 2 und 9 am GPIOA auf low
</syntaxhighlight>

===Pin Sperren===

Der [[STM32]] bietet die Möglichkeit, einen Pin zu sperren. Ist ein Pin gesperrt, so kann dessen Zustand (High / Low) '''bis zu einem Reset''' nicht mehr geändert werden! Wie wir es nun gewohnt sind, hat ST dafür eine eigene Funktion geschrieben. Diese lautet '''GPIO_PinLockConfig()'''. Erster Parameter ist der Port, der zweite sind die Pins, welche man sperren möchte. Diese kann man wieder mit der ODER Verknüpfung kombinieren.

<syntaxhighlight lang="c">
GPIO_PinLockConfig(GPIOA,GPIO_Pin_1 | GPIO_Pin_5); //Sperrt die Pins bis zu einem Reset
</syntaxhighlight>

===Eingänge einlesen===

Um Daten in den [[STM32]] einzulesen, gibt es wieder ein paar ST Funktionen. Diese möchten wir hier vorstellen. Die dafür verwendbaren Funktionen sind: '''GPIO_ReadInputDataBit()''' sowie '''GPIO_ReadInputData()'''. Erster Parameter ist der Port, der zweite sind die Pins, die man einlesen möchte. Bei '''GPIO_ReadInputData()''' wird jedoch nur der Port übergeben, da diese Funktion den '''gesamten''' Port zurück liefert! Hier wird der tatsächliche logische Pegel am Pin eingelesen!

<syntaxhighlight lang="c">
uint8_t ucStatus = 0;

ucStatus = GPIO_ReadInputDataBit(GPIOA,GPIO_Pin_5); //Speichert den Zustand von Pin5 am GPIOA in die 8-bit-Variable ucStatus
//(uint8_t ist die kleinstmögliche, eigenständige Variable für dieses eine Bit)
</syntaxhighlight>

<syntaxhighlight lang="c">
uint16_t uiPort = 0;

uiPort = GPIO_ReadInputData(GPIOA); //Speichert den Zustand von GPIOA in die 16-bit-Variable uiPort
</syntaxhighlight>

===Ausgänge einlesen===

Man hat ja häufig das Problem, dass man gerne nachsehen möchte, was man denn gerade am Ausgang ausgibt. Dazu kann man den Ausgang wie ein Eingang einlesen. Die dafür verwendbaren Funktionen sind: '''GPIO_ReadOutputDataBit()''' sowie '''GPIO_ReadOutputData()'''. Erster Parameter ist der Port, der zweite sind die Pins, welche man auslesen möchte. Bei '''GPIO_ReadOutputData()''' wird jedoch nur der Port übergeben, da diese Funktion den '''gesamten''' Port zurück liefert!Hier wird '''nicht''' der tatsächliche logische Pegel am Pin eingelesen, sondern was im Ausgangsregister eingestellt wurde (also eigentlich anliegen sollte)! Diese beiden Werte können sich auf Grund externer Einflüsse aber unterscheiden!!!

<syntaxhighlight lang="c">
uint8_t ucStatus = 0;

ucStatus = GPIO_ReadOutputDataBit(GPIOA,GPIO_Pin_5); //Speichert den Zustand von Pin5 am GPIOA in die 8-bit-Variable ucStatus
//(uint8_t ist die kleinstmögliche, eigenständige Variable für dieses eine Bit)
</syntaxhighlight>

<syntaxhighlight lang="c">
uint16_t uiPort = 0;

uiPort = GPIO_ReadOutputData(GPIOA); //Speichert den Zustand von GPIOA in die 16-bit-Variable uiPort
</syntaxhighlight>

===Deinitialisieren von Ports===

Es gibt auch die Möglichkeit, den Port zu deinitialisieren. Dann wird er mit seinen Standardwerten konfiguriert. Die Funktion dazu lautet '''GPIO_DeInit()'''. Erster und einziger Parameter ist der Port, den man deinitialisieren möchte.

<syntaxhighlight lang="c">
GPIO_DeInit(GPIOA); //Setzt den GPIOA auf seine Standardwerte zurück
</syntaxhighlight>

= Weblinks, Foren, Communities =

* [http://www.mikrocontroller.net/topic/175840 Diskussion zum Artikel]
* [http://www.libopencm3.org libopencm3] -- Eine Open-Source Alternative (GPL, Version 3 oder höher) zur ST Library
* Artikel [[STM32]]

[[Kategorie:STM32]]

C-Präprozessor

2013-11-26T11:15:41Z

Prx:

Der erste Verarbeitungsschritt bei der Kompilierung eines [[C]]/[[C++]]-Programmes erfolgt durch den '''Präprozessor'''. Dieser verändert den Quelltext, den die späteren Verarbeitungsphasen erhalten, in folgender Hinsicht:
* Einbeziehen zusätzlicher Dateien ([[Include-Files]])
* Ersetzen von (parametrisierbaren) [[Makro]]s
* Entfernen einzelner Abschnitte (= bedingte Kompilierung)

Im Grunde kann man sich den Präprozessor als eine Art Texteditor vorstellen, der die Anweisungen, was er zu tun hat, dem Text entnimmt, den er bearbeitet. In jedem Texteditor gibt es zb. die Funktion 'Suchen und Ersetzen'. Auch im Präprozessor gibt es sie, nur heißt sie dort #define. Alle Anweisungen an den Präprozessor beginnen grundsätzlich damit, daß das Zeichen '#' das erste Zeichen in einer Textzeile darstellt. Und umgekehrt: Ist das erste Zeichen in einer Textzeile ein '#', so handelt es sich um eine Präprozessor-Anweisung.

==#include==
Die #include weist den Präprozessor an, den Inhalt der angegebenen Datei anstelle der #include Anweisung einzusetzen. Weiter passiert nichts. Bei der Angabe des Dateinamens der einzusetzenden Datei gibt es 2 Formen
<syntaxhighlight lang="c">
#include "Datei1.xyz"
#include <Datei2.abc>
</syntaxhighlight>
Der Unterschied zwischen beiden Formen besteht rein im Aufsuchpfad, den der Präprozessor benutzt, um die Datei zu finden. Per Konvention wird die < >-Form benutzt, um systemweite Includes durchzuführen. Alle mit dem Compiler mitgelieferten Header Files sind zb. solche systemweite-Includes. Bei der Installation des Compilers wurde im System hinterlassen, auf welchem Pfad sie gefunden werden können. Durch Verwendung der < >-Form wird dem Präprozessor mitgeteilt, dass diese damals vereinbarten Pfadangaben zur Aufsuche dieser Datei benutzt werden soll.

==#define==
Mittels #define wird eine Textersetzung vereinbart.
<syntaxhighlight lang="c">
#define ABC xyz
</syntaxhighlight>
weist den Präprozessor an, im weiteren Quelltext alle Vorkommen von 'ABC' durch den Text 'xyz' zu ersetzen. Der Präprozessor macht dies überall, solange
* es sich an der zu ersetzenden Stelle um keinen String handelt. Mit obigem #define würde also in "Dies ist ABC" keine Textersetzung stattfinden.
* er den Ursprungstext als 'Wort' im Sinne eines C-Wortes handelt. Mit obigem #define würde also in cdABCef = 5; keine Textersetzung stattfinden.

Wichtig ist: Der Präprozessor führt eine reine Textersetzung durch! Ob sich durch diese Ersetzung eine Logikänderung im Programm ergibt, interessiert den Präprozessor nicht.

<syntaxhighlight lang="c">
#define NR 5

int Werte[NR];

...

for( i = 0; i < NR; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

Bevor der eigentliche Compiler den Quelltext zu Gesicht bekommt, wird er zunächst vom Präprozessor bearbeitet. Dieser führt die Textersetzung durch, indem er alle Vorkommen von NR durch den Text 5 ersetzt. Erst dieses Ergebnis

<syntaxhighlight lang="c">
int Werte[5];

...

for( i = 0; i < 5; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

wird dann dem eigentlichen Compiler zur Übersetzung vorgelegt. In diesem Beispiel hat man durch den Einsatz des Präprozessors erreicht, dass die Anzahl der Arrayelemente immer mit dem Maximalwert in der for-Schleife übereinstimmt. Ein Fehler, dass beispielweise die Arraygröße verändert wird, ohne das die for-Schleife angepasst würde, ist durch den Einsatz des Präprozessors wirkungsvoll verhindert worden.

Aber auch hier wieder: Der Präprozessors macht nur eine Textersetzung! Für den Präprozessors ist es völlig unerheblich, ob sich dadurch die Logik des Programms aus Sicht des Programmierers verändert
<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*PART;
</syntaxhighlight>
In diesem Beispiel mag es schon so sein, dass der Programmierer im Sinn hatte, den Ausdruck 4 mal 8 berechnen zu lassen, wobei sich die 8 durch eine Addition von 3 und 5 ergeben. Das interessiert aber den Präprozessor nicht. Der macht eine reine textuelle Ersetzung, indem er den Text 'PART' durch den Text '3+5' austauscht, wodurch dieses Ergebnis entsteht

<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*3+5;
</syntaxhighlight>
Dies ist aber etwas anderes, nämlich '(4*3)+5', also ursprünglich beabsichtigt war, nämlich '4*(3+5)'.

Schlussfolgerung: Es ist bei komplexeren Makros nicht ungewöhnlich, dass sich in Makros relativ viele Klammern wiederfinden, deren Zweck gerade für einen Neuling nicht auf den ersten Blick zu durchschauen ist.
<syntaxhighlight lang="c">
#define PART (3+5)

...
x = PART;
y = 4*PART;
</syntaxhighlight>
Während die Klammern im Makro bei der Zuweisung an x keine Funktion erfüllen (aber auch nicht störend sind), sind sie bei der Zuweisung an y lebenswichtig um der ganzen Anweisung nach der Textersetzung die beabsichtigte Bedeutung zu geben.

==#define für eine Codesequenz==

Wird ein #define nicht für einen Ausdruck verwendet, sondern für eine Codesequenz wie in
<syntaxhighlight lang="c">
#define F(n) { a = n; b = n; }
</syntaxhighlight>
dann entsteht ein Problem bei
<syntaxhighlight lang="c">
if (...) F(1); else F(2);
</syntaxhighlight>
da hier für den Compiler letztlich
<syntaxhighlight lang="c">
if (...) { ... }; else { ... };
</syntaxhighlight>
stehen bleibt, und damit ein überzähliges Semikolon vor dem else. Nun kann man dies natürlich mit
<syntaxhighlight lang="c">
if (...) { F(1); } else { F(2); }
</syntaxhighlight>
oder
<syntaxhighlight lang="c">
if (...) F(1) else F(2)
</syntaxhighlight>
abhandeln. Gelegentlich findet man deshalb aber auch seltsam anmutende Definitionen wie
<syntaxhighlight lang="c">
#define F(n) do{ a = n; b = n; }while(0)
</syntaxhighlight>

==#if, #ifdef==

==mögliche Probleme beim Einsatz des Präprozessors==
Eine am C-Präprozessor häufig geäußerte Kritik ist, dass er (nahezu) ohne Berücksichtigung der eigentlichen Sprachsyntax arbeitet ("The C-Preprocessor doesn't know about C"). Die Tatsache, dass Makros beispielsweise auf der Basis von Textersatz arbeiten, kann zu Überaschungen führen. So wird in
<syntaxhighlight lang="c">
#define cub(a) a*a*a
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
in x nicht etwa der Wert 125 (5 hoch 3) stehen, sondern der Wert 13, da nach Ersetzen des Makros der folgende Quelltext kompiliert wird ...
<syntaxhighlight lang="c">
x = y+1*y+1*y+1;
</syntaxhighlight>
... und durch die arithmetischen Vorrangregeln, wird dieser Ausdruck so ausgewertet:

<syntaxhighlight lang="c">
x = y + (1*y) + (1*y) + 1;
</syntaxhighlight>

Deshalb sollte man jeden Parameter eines Makros bei jeder Verwendung klammern. Damit werden viele Probleme mit Makros gelöst und man erhält für obiges Beispiel folgende Form und damit auch eine korrekte Berechnung:
<syntaxhighlight lang="c">
#define cub(a) ((a)*(a)*(a))
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
Ein weiteres Problem besteht jedoch, wenn ein Makro-Parameter im Ersatztext doppelt verwendet wird:
<syntaxhighlight lang="c">
#define max(a, b) ((a>b) ? (a) : (b))
...
int x, y;
...
x = max(y, 10); /* OK */
x = max(++y, 10); /* ?? */
</syntaxhighlight>
Im zweiten Fall wird die Variable ''y'' u.U. ''zweimal'' inkrementiert - was ohne Kenntnis der Makro-Definition keineswegs offensichtlich ist (''max'' könnte auch eine echte Funktion sein).

Die Tatsache, dass der C-Präprozessor die Syntax von C/C++ nicht wirklich berücksichtigt, ist allerdings auch nützlich. So lassen sich mit dem C-Präprozessor Datentypen parametrisieren, um systematische Programmteile zu vereinfachen:
<syntaxhighlight lang="c">
/* GSAWP:
generiert Funktionsdefinition zum Vertauschen des Inhalts von zwei Variablen
*/
#define GSWAP(n, T)s\
void n(T *xp, T *yp) { T tmp = *xp; *xp = *yp; *yp = tmp; }
...
GSWAP(iswap, int)
GSWAP(dswap, double)
GSWAP(swap_s, struct s)
...
int a, b;
double c, d;
struct s e, f;
...
iswap(&a, &b);
dswap(&c, &d);
swap_s(&e. &f);
</syntaxhighlight>

Viele typische Anwendungsfälle des Präprozessors lassen sich allerdings bereits mit Standard-C-Bordmitteln erfolgreich erschlagen:
* Statt ''#define'' besser mit ''const'' vereinbarte Variablen benutzen. Bei jedem besseren Compiler ergeben sich dank Optimierung keinerlei Nachteile.
* ''enum'' für Konstantenfelder benutzen. Dabei sollte man allerdings sauber casten, da ''enum''-Werte in der Regel als ''int'' interpretiert werden.
* Neuere Versionen des GCC unterstützen ''inline'', wodurch Makros für Einzeiler überflüssig werden.

In [[C++]] wurden ergänzend zum C-Präprozessor weitere Mechanismen eingeführt. So erlauben [[Templates (C++)|Templates]] generische Programmierung, womit viele der "Makro-Tricks" wie die obigen überflüssig werden.

[[Kategorie:C]]

C-Präprozessor

2013-11-26T11:13:10Z

Prx: Codesequenz

Der erste Verarbeitungsschritt bei der Kompilierung eines [[C]]/[[C++]]-Programmes erfolgt durch den '''Präprozessor'''. Dieser verändert den Quelltext, den die späteren Verarbeitungsphasen erhalten, in folgender Hinsicht:
* Einbeziehen zusätzlicher Dateien ([[Include-Files]])
* Ersetzen von (parametrisierbaren) [[Makro]]s
* Entfernen einzelner Abschnitte (= bedingte Kompilierung)

Im Grunde kann man sich den Präprozessor als eine Art Texteditor vorstellen, der die Anweisungen, was er zu tun hat, dem Text entnimmt, den er bearbeitet. In jedem Texteditor gibt es zb. die Funktion 'Suchen und Ersetzen'. Auch im Präprozessor gibt es sie, nur heißt sie dort #define. Alle Anweisungen an den Präprozessor beginnen grundsätzlich damit, daß das Zeichen '#' das erste Zeichen in einer Textzeile darstellt. Und umgekehrt: Ist das erste Zeichen in einer Textzeile ein '#', so handelt es sich um eine Präprozessor-Anweisung.

==#include==
Die #include weist den Präprozessor an, den Inhalt der angegebenen Datei anstelle der #include Anweisung einzusetzen. Weiter passiert nichts. Bei der Angabe des Dateinamens der einzusetzenden Datei gibt es 2 Formen
<syntaxhighlight lang="c">
#include "Datei1.xyz"
#include <Datei2.abc>
</syntaxhighlight>
Der Unterschied zwischen beiden Formen besteht rein im Aufsuchpfad, den der Präprozessor benutzt, um die Datei zu finden. Per Konvention wird die < >-Form benutzt, um systemweite Includes durchzuführen. Alle mit dem Compiler mitgelieferten Header Files sind zb. solche systemweite-Includes. Bei der Installation des Compilers wurde im System hinterlassen, auf welchem Pfad sie gefunden werden können. Durch Verwendung der < >-Form wird dem Präprozessor mitgeteilt, dass diese damals vereinbarten Pfadangaben zur Aufsuche dieser Datei benutzt werden soll.

==#define==
Mittels #define wird eine Textersetzung vereinbart.
<syntaxhighlight lang="c">
#define ABC xyz
</syntaxhighlight>
weist den Präprozessor an, im weiteren Quelltext alle Vorkommen von 'ABC' durch den Text 'xyz' zu ersetzen. Der Präprozessor macht dies überall, solange
* es sich an der zu ersetzenden Stelle um keinen String handelt. Mit obigem #define würde also in "Dies ist ABC" keine Textersetzung stattfinden.
* er den Ursprungstext als 'Wort' im Sinne eines C-Wortes handelt. Mit obigem #define würde also in cdABCef = 5; keine Textersetzung stattfinden.

Wichtig ist: Der Präprozessor führt eine reine Textersetzung durch! Ob sich durch diese Ersetzung eine Logikänderung im Programm ergibt, interessiert den Präprozessor nicht.

<syntaxhighlight lang="c">
#define NR 5

int Werte[NR];

...

for( i = 0; i < NR; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

Bevor der eigentliche Compiler den Quelltext zu Gesicht bekommt, wird er zunächst vom Präprozessor bearbeitet. Dieser führt die Textersetzung durch, indem er alle Vorkommen von NR durch den Text 5 ersetzt. Erst dieses Ergebnis

<syntaxhighlight lang="c">
int Werte[5];

...

for( i = 0; i < 5; i++ )
printf( "%d", Werte[i] );
</syntaxhighlight>

wird dann dem eigentlichen Compiler zur Übersetzung vorgelegt. In diesem Beispiel hat man durch den Einsatz des Präprozessors erreicht, dass die Anzahl der Arrayelemente immer mit dem Maximalwert in der for-Schleife übereinstimmt. Ein Fehler, dass beispielweise die Arraygröße verändert wird, ohne das die for-Schleife angepasst würde, ist durch den Einsatz des Präprozessors wirkungsvoll verhindert worden.

Aber auch hier wieder: Der Präprozessors macht nur eine Textersetzung! Für den Präprozessors ist es völlig unerheblich, ob sich dadurch die Logik des Programms aus Sicht des Programmierers verändert
<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*PART;
</syntaxhighlight>
In diesem Beispiel mag es schon so sein, dass der Programmierer im Sinn hatte, den Ausdruck 4 mal 8 berechnen zu lassen, wobei sich die 8 durch eine Addition von 3 und 5 ergeben. Das interessiert aber den Präprozessor nicht. Der macht eine reine textuelle Ersetzung, indem er den Text 'PART' durch den Text '3+5' austauscht, wodurch dieses Ergebnis entsteht

<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*3+5;
</syntaxhighlight>
Dies ist aber etwas anderes, nämlich '(4*3)+5', also ursprünglich beabsichtigt war, nämlich '4*(3+5)'.

Schlussfolgerung: Es ist bei komplexeren Makros nicht ungewöhnlich, dass sich in Makros relativ viele Klammern wiederfinden, deren Zweck gerade für einen Neuling nicht auf den ersten Blick zu durchschauen ist.
<syntaxhighlight lang="c">
#define PART (3+5)

...
x = PART;
y = 4*PART;
</syntaxhighlight>
Während die Klammern im Makro bei der Zuweisung an x keine Funktion erfüllen (aber auch nicht störend sind), sind sie bei der Zuweisung an y lebenswichtig um der ganzen Anweisung nach der Textersetzung die beabsichtigte Bedeutung zu geben.

==#define für eine Codesequenz==

Wird ein #define nicht für einen Ausdruck verwendet, sondern für eine Codesequenz wie in
<syntaxhighlight lang="c">
#define F(n) { a = n; b = n; }
</syntaxhighlight>
dann entsteht ein Problem bei
<syntaxhighlight lang="c">
if (...) F(1); else F(2);
</syntaxhighlight>
da hier für den Compiler letztlich
<syntaxhighlight lang="c">
if (...) { ... }; else { ... };
</syntaxhighlight>
stehen bleibt, und damit ein überzähliges Semikolon vor dem else. Nun kann man dies natürlich mit
<syntaxhighlight lang="c">
if (...) { F(1); } else { F(2); }
</syntaxhighlight>
abhandeln. Gelegentlich findet man deshalb aber auch seltsam anmutende Definitionen wie
<syntaxhighlight lang="c">
#define F(n) do{ a = n; b = n; }while(0)
</syntaxhighlight>

==#if, #ifdef==

==mögliche Probleme beim Einsatz des Präprozessors==
Eine am C-Präprozessor häufig geäußerte Kritik ist, dass er (nahezu) ohne Berücksichtigung der eigentlichen Sprachsyntax arbeitet ("The C-Preprocessor doesn't know about C"). Die Tatsache, dass Makros beispielsweise auf der Basis von Textersatz arbeiten, kann zu Überaschungen führen. So wird in
<syntaxhighlight lang="c">
#define cub(a) a*a*a
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
in x nicht etwa der Wert 125 (5 hoch 3) stehen, sondern der Wert 13, da nach Ersetzen des Makros der folgende Quelltext kompiliert wird ...
<syntaxhighlight lang="c">
x = y+1*y+1*y+1;
</syntaxhighlight>
... und durch die arithmetischen Vorrangregeln, wird dieser Ausdruck so ausgewertet:

<syntaxhighlight lang="c">
x = y + (1*y) + (1*y) + 1;
</syntaxhighlight>

Deshalb sollte man jeden Parameter eines Makros bei jeder Verwendung klammern. Damit werden viele Probleme mit Makros gelöst und man erhält für obiges Beispiel folgende Form und damit auch eine korrekte Berechnung:
<syntaxhighlight lang="c">
#define cub(a) ((a)*(a)*(a))
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
Ein weiteres Problem besteht jedoch, wenn ein Makro-Parameter im Ersatztext doppelt verwendet wird:
<syntaxhighlight lang="c">
#define max(a, b) ((a>b) ? (a) : (b))
...
int x, y;
...
x = max(y, 10); /* OK */
x = max(++y, 10); /* ?? */
</syntaxhighlight>
Im zweiten Fall wird die Variable ''y'' u.U. ''zweimal'' inkrementiert - was ohne Kenntnis der Makro-Definition keineswegs offensichtlich ist (''max'' könnte auch eine echte Funktion sein).

Die Tatsache, dass der C-Präprozessor die Syntax von C/C++ nicht wirklich berücksichtigt, ist allerdings auch nützlich. So lassen sich mit dem C-Präprozessor Datentypen parametrisieren, um systematische Programmteile zu vereinfachen:
<syntaxhighlight lang="c">
/* GSAWP:
generiert Funktionsdefinition zum Vertauschen des Inhalts von zwei Variablen
*/
#define GSWAP(n, T)s\
void n(T *xp, T *yp) { T tmp = *xp; *xp = *yp; *yp = tmp; }
...
GSWAP(iswap, int)
GSWAP(dswap, double)
GSWAP(swap_s, struct s)
...
int a, b;
double c, d;
struct s e, f;
...
iswap(&a, &b);
dswap(&c, &d);
swap_s(&e. &f);
</syntaxhighlight>

Viele typische Anwendungsfälle des Präprozessors lassen sich allerdings bereits mit Standard-C-Bordmitteln erfolgreich erschlagen:
* Statt ''#define'' besser mit ''const'' vereinbarte Variablen benutzen. Bei jedem besseren Compiler ergeben sich dank Optimierung keinerlei Nachteile.
* ''enum'' für Konstantenfelder benutzen. Dabei sollte man allerdings sauber casten, da ''enum''-Werte in der Regel als ''int'' interpretiert werden.
* Neuere Versionen des GCC unterstützen ''inline'', wodurch Makros für Einzeiler überflüssig werden.

In [[C++]] wurden ergänzend zum C-Präprozessor weitere Mechanismen eingeführt. So erlauben [[Templates (C++)|Templates]] generische Programmierung, womit viele der "Makro-Tricks" wie die obigen überflüssig werden.

[[Kategorie:C]]

STM32

2013-10-24T20:31:29Z

Prx: /* Hardware */

STM32 ist ein Mikrocontroller-Familie von [http://www.st.com/mcu/inchtml-pages-stm32.html ST] mit einer 32-Bit [http://www.arm.com/products/processors/cortex-m/index.php ARM Cortex-M0/M3/M4] CPU. Diese Architektur ist speziell für den Einsatz in Microcontrollern neu entwickelt und löst damit die bisherigen ARM7-basierten Controller weitestgehend ab. Den STM32 gibt es von ST in unzähligen Varianten mit variabler Peripherie und verschiedenen Gehäusegrößen und -formen. Durch die geringe Chipfläche des Cores ist es ST möglich, eine 32 Bit-CPU für weniger als 1 € anzubieten.

[[Bild:stm32F103xc.png|thumb|right|340px|Blockdiagramm STM32F103xC/D/E]]

== STM32-Familien ==

Bisher gibt es sieben STM32-Familien:
* [http://www.st.com/internet/mcu/subclass/1588.jsp STM32F0]
** Cortex M0
** Mikrocontroller zum Einstieg
** Bis 48MHz
* [http://www.st.com/internet/mcu/subclass/1169.jsp STM32F1]
** Cortex M3
** Bis 72MHz
**Verschiedene Unterfamilien:
*** Connectivity line
*** Performance line
*** USB Access line
*** Access Line
*** Value line
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1575 STM32F2]
** Cortex M3
** Bis 120MHz
** Wie die STM32F1 Serie, Camera-Interface, 32-Bit Timer, Crypto-Engine...
* [http://www.st.com/internet/mcu/subclass/1605.jsp STM32F3]
** Cortex M4F
** DSP und FPU
** Bis 72MHz
** Fast 12-bit 5 MSPS and precise 16-bit sigma-delta ADCs
** Touch sensing controller (TSC)
* [http://www.st.com/internet/mcu/subclass/1521.jsp STM32F4]
** Cortex M4F
** DSP und FPU
** Bis 180MHz
** Bis zu 2MB Flash
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1295 STM32L1]
** Cortex M3
** Low Power
** mit LCD Treiber
** Bis 32MHz
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1581 STM32W]
** Cortex M3
** BIS 24MHz
** RF-MCU
[http://www.st.com/internet/mcu/class/1734.jsp Hier eine Übersicht zum Auswählen eines STM32Fxxx]

===Features===
* Cortex-M0 / Cortex-M3 / Cortex-M4F Kern (mit FPU)
* 16KB ... 2MB [[Flash-ROM]]
* 4KB ... 256KB [[Speicher#SRAM|SRAM]]
* 4KB [[Speicher#EEPROM|EEPROM]] (STM32L)
* SDRAM-Controller bei den [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806 STM32F42xxx und STM32F43xxx], bis 512 MByte externer SDRAM addressierbar
* 512 one-time programmable Bytes(STM32F2/4)
* [[IC-Gehäuseformen | Gehäuse]] 36 ... 216 Pins als QFN, LQFP und BGA
* Derzeit sind über '''250''' STM32 Derivate/Varianten verfügbar
* Bis 72MHz CPU-Takt, bis 120MHz beim STM32F2xx, bis 168/180 MHz beim STM32F4xx, wobei eine spezielle prefetch-hardware bis 120/168 MHz eine Geschwindigkeit erzielen soll, die 0 Wait-States entspricht. Der CPU-Takt wird über einen Multiplikator aus dem internen RC-Takt oder einem externen Quarz-Takt abgeleitet.
* Externes Businterface (nur bei Gehäusen ab 100 Pin und nur bei STM32F4, STM32F2 und STM32F1 Performance line)
* LCD Treiber für 8x40 Punkte (nicht beim STM32F2xx)
* TFT Treiber bei STM32F429 / STM32F439
* Spannungsbereich 1,65 ... 3,6V, nur eine Betriebsspannung nötig
* Temperaturbereich bis 125 °C
* Bis zu 140 IOs, viele davon [[Pegelwandler|5V-tolerant]]
* Interner, kalibrierter RC-Oszillator mit 8MHz (16MHz bei STM32F2/F4xx)
* Externer Quarz
* Real Time Clock mit eigenem Quarz und separater Stromversorgung
* Bis zu 16 [[Timer]], je Timer bis zu 4 IC/OC/PWM Ausgänge. Davon 2x Motion Control Timer (bei STM32F103xF/G)
* Systick Counter
* Bis zu 3 12-Bit [[AD-Wandler]] mit insgesamt 24 AD-Eingängen, integrierter [[Temperatursensor]], Referenzspannung Vrefint und VBatt Spannungsmessung (STM32F4xx)
* Bis zu 2 12-Bit [[DA-Wandler]] (bis zu 3 beim STM32F3xx)
* Bis zu 2 [[DMA]] Controller mit bis zu 12 Kanälen (16 beim STM32F2/4xx)
* Bis zu 2x [[I2C|I²C]]
* Bis zu 5x [[UART|USART]] mit LIN, IrDA und Modem Control (bis zu 8 beim STM32F2/F4xx)
* Bis zu 3x [[SPI]] (bis zu 6 beim STM32F4xx)
* Bis zu 2x [[I2S|I²S]]
* Bis zu 2x [[CAN#STMicroelectronics STM32 (Cortex M3/M4)|CAN]]
* Hardware [[CRC]] Unit, bei der STM32F3xx Serie mit einem einstellbaren Polynom
* Unique device ID register (96 Bits)
* RNG - Random Number Generator (STM32F2/4xx)
* Cryptographic Processor (CRYP) (STM32F2/4xx)
* Hash Processor (HASH) (STM32F2/4xx)
* Kamera-Interface (DCMI) (STM32F2/4xx)
* [[USB]] 2.0 Full Speed / OTG
* [[USB]] 2.0 Hi Speed OTG mit extra PHY-Chip (STM32F2/4xx)
* SDIO Interface (z.B. SD-Card Reader)
* Ethernet
* Watchdog mit Window-Mode
* Jedes Peripheriemodul ist separat einschaltbar, wodurch sich erheblich [[Ultra low power|Strom sparen]] lässt
* [[JTAG]] und SWD (Serial Wire Debug) Interface
* Bis zu 6 Hardware-Breakpoints für Debuggen
* und vieles mehr . . .

== Struktur der Dokumentation: ==
Die Dokumentation der STM32 ist zwar umfangreicher und komplexer z.B. die der [[AVR]], enthält aber dennoch alle nötigen Informationen. Sie teilt sich auf in mehrere Dokumente.
Als Beispiel der Dokumentation soll stellvertretend der [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164486 STM32F103RC] genannt werden. Die Seite von ST beinhaltet alle nötigen Informationen passend zu diesem Prozessor.

Diese Dokumente von ST beschreiben den Controller:

* Im [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00191185.pdf STM32F103xC/D/E Datasheet] sind die speziellen Eigenschaften einer bestimmten Modellreihe beschrieben und die exakten Daten und Pinouts aufgeführt, sowie die Zuordnung Chipname - Flash/RAM-Größe. Die Peripheriemodule werden nur aufgeführt, nicht detailliert beschrieben.
* Im [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00171190.pdf Reference Manual (RM0008)] sind alle Peripheriemodule der jeweiligen STM32-Controllerfamilie im Detail beschrieben.
* Das [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0403c/index.html ARMv7M Architecture Reference Manual] beschreibt detailliert den Prozessorkern, wie das Exception Model, die CPU Instruktionen inklusive Encoding, etc.
* Das [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/CD00228163.pdf STM32 Cortex-M3 Programming Manual] ist eine Zusammenfassung des ARMv7M Architecture Reference Manual bezogen auf die STM32.
* Wer nicht die ST Firmware-Library verwendet, der benötigt zusätzlich das [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/CD00283419.pdf Flash Programming Manual] für die Betriebsart des Flash-ROMs, d.h. die frequenzabhängige Konfiguration der Waitstates.

Zusätzlich sollten auch die [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00197763.pdf Errata Sheets] beachtet werden. Empfohlen sei auch die Appnote "[http://www.st.com/web/en/resource/technical/document/application_note/CD00164185.pdf AN2586 Getting started with STM32F10xxx hardware development]".
Die jeweiligen Dokumentations-PDFs sind auf der Produktseite von ST eines jeden Mikrocontrollers verlinkt.

== Hardware Zugriffs-Libraries ==
=== CMSIS ===

Die CMSIS (ARM® '''C'''ortex™ '''M'''icrocontroller '''S'''oftware '''I'''nterface '''S'''tandard) ist eine Library von ARM für den Zugriff auf die herstellerübergreifenden Funktionen des ARM-Cores. Hierzu gehört bei den Cortex-M4F-Cores auch die DSP und Floating-Point Funktionalität. Weiterhin existieren eine Zahl von Helferfunktionen für den NVIC, den Sys-Tick-Counter, sowie eine SystemInit-Funktion, welche sich um die PLL kümmert.

Im Rahmen des CMSIS-Standards ([http://www.onARM.com www.onARM.com]) wurden die Headerdateien standardisiert, der Zugriff auf die Register erfolgt per '''Peripheral->Register'''. Die CMSIS C-Dateien bzw. Header enthalten auch Anpassungen für die verschiedenen Compiler. Die Portierung eines Real-Time-Betriebsystems sollte unter Verwendung der CMSIS, für Chips der verschiedenen Hersteller, stark vereinfacht möglich sein (z.B. einheitliche Adressen für Core-Hardware/Sys-Tick-Counter).

Die CMSIS ist im Download der ‎STM32 Standard Peripheral Library enthalten. Die Compiler-Hersteller liefern eine jeweils zur ihrer Tool-Version passende bzw. geprüfte Library (incl. CMSIS) aus. Diese Libs können, gegenüber den Downloads beim Chip-Hersteller, auch ältere Version beinhalten.

=== ‎STM32 Standard Peripheral Library ===

ST bietet für jede Controller Familie eine umfangreiche zur CMSIS passende Peripherie-Bibliothek. Alle Funktionen um die Peripherie zu benutzen sind gekapselt in einfache Strukturen und Funktionsaufrufe. Somit muss man sich nicht selbst um die Peripherie-Register kümmern. Diese Library und ihre Dokumentation setzen das grundlegende Verständnis der Funktion des jeweiligen Peripheriemoduls voraus, wie es die o.a. Referenz und diverse Appnotes vermitteln. Die Library beinhaltet außerdem für fast jede Peripherie mehrere Beispiele.
Für die USB Schnittstelle gibt es noch eine extra Library, genauso wie für Ethernet.

Auf der "Design Resources" Seite der Produktseite von ST eines jeden STM32 Mikrocontrollers kann die Library für den jeweiligen Controller heruntergeladen werden, z.B. [http://www.st.com/web/en/catalog/tools/PF257890 hier] für den o.g. STM32F103RC.

== Programmierung ==
Zur Programmierung der STM32 gibt es verschiedene Möglichkeiten, sowohl kommerzielle proprietäre als auch mit Freier Software.

Der GCC (in seinen verschiedenen Binärdistributionen) ist der einzige ARM Compiler der [http://de.wikipedia.org/wiki/C%2B%2B11 C++11] unterstützt.

=== Freie Software/Freeware ===
==== Selber zusammenstellen ====
Man nehme...:
* Eine Entwicklungsumgebung nach Wahl:
** [http://www.eclipse.org Eclipse] mit [http://www.eclipse.org/cdt/ C/C++ Development Tooling] und [http://gnuarmeclipse.livius.net/blog/ GNU ARM Plug-in] (Bei Verwendung vom GCC-ARM-Embedded als Toolchain "Sourcery G++ Lite" auswählen, dieser sieht für eclipse gleich aus) (Linux, Windows)
** [http://netbeans.org/ Netbeans] mit [http://plugins.netbeans.org/plugin/37426/gdbserver GDBserver-Plugin] (Linux, Windows)
** [http://www.kdevelop.org/ KDevelop] (Linux)
** [http://www.geany.org/ Geany] (Linux, Windows)
** Oder ein einfacher Texteditor
* Einen C,C++ Compiler:
** Eine der [[ARM_GCC#GCC_Bin.C3.A4rdistributionen|GCC-Binärdistributionen]], siehe auch [[#GCC|GCC]] (je nach Distribution Linux, Windows)
* Programmiersoftware zum Flashen des Target:
** [http://openocd.sourceforge.net/ OpenOCD] unterstützt viele Debug/Programmier-Adapter (Linux, Windows)
** [https://github.com/texane/stlink Texane stlink] funktioniert gut mit den ST-Link Adaptern wie sie zB. auf den STM32 Discovery Boards zu finden sind (Linux)
** Turtelizer2 oder andere JTAG Programmieradapter
** Bei Verwendung eines Segger J-Link, den [http://www.segger.com/admin/uploads/productDocs/UM08005_JLinkGDBServer.pdf Segger GDB-Server] in Verbindung mit dem beim GCC mitgelieferten GDB (Linux, Windows)

==== Komplette IDE's ====
* [http://www.codesourcery.com/sgpp/lite_edition.html Codesourcery Lite Edition]
* [http://www.coocox.org/ Coocox Eclipse IDE] kostenlose IDE für STM32F0 / F1 / F4 Hilfreiche Infos gibt es im [http://www.mikrocontroller.net/topic/214719?goto=new#2228482 hier] und [http://www.mikrocontroller.net/topic/214719?goto=new#2229943 hier] Forum
* [http://emide.org/ emIDE] kostenlose IDE die mit dem Segger J-LINK funktioniert.
* [http://www.emblocks.org EmBlocks] kostenlose IDE, Code::Blocks basiert, unterstützt STM32 L1/F0/F1/F2/F3/F4/W, integrierter GDB Debugger, Jlink/ST-Link, System view (Peripherie Register anzeigen) beim Debuggen, Project Wizzard

=== Kommerzielle Umgebungen ===

* [http://www.keil.com/arm/mdk.asp Keil µVision] (Demo max. 32KB Code): Die sehr komfortable µVison IDE ist neben dem ARM Compiler per Menue auch für einen beliebigen GNU-Compiler konfigurierbar. Damit besteht das 32k-Limit nur noch für den integrierten Debugger / Simulator. µVison selbst kann kostenlos mit dem MDK-Evaluationkit heruntergeladen werden. [https://www.keil.com/arm/demo/eval/arm.htm#DOWNLOAD download]
* [http://www.iar.com/en/Products/IAR-Embedded-Workbench/ IAR-Embedded-Workbench] (Demo max. 32KB Code) [http://supp.iar.com/Download/SW/?item=EWARM-EVAL download]
* [http://www.isystem.com/products/itag winIDEAiTag] Keine Code Limitierung, GCC und Testwerkzeug beinhaltet. Läuft mit dem iTag Adapter.
* [http://www.raisonance.com Raisonance Ride7] (GCC Compiler, kostenlose Version auf Debugging von max. 32KB Code limitiert, keine Limitierung beim Complilieren)
* [http://www.atollic.com Atollic] (Lite Version (bis V2.3.0) ohne Code-Limit, auf GCC basierend. Die neueste Version ab V3 hat fast keine Beschränkungen mehr außer jetzt einen Code-Limit von 32kB. Außerdem werden jetzt die meisten ARM Familien unterstützt. )
* [http://www.rowley.co.uk/arm/ Rowley Crossworks] (Demo 30 Tage unbeschränkt, 150$ für nichtkommerzielle Nutzung, auf GCC basierend)
* [http://www.code-red-tech.com Code Red] (GCC basierend)
* [http://www.sisy.de/index.php?id=17&no_cache=1 SiSy ARM oder SiSy Micrcontroller++] (Demo verfügbar keine Gößenbegrenzung, basiert auf GNU-Compiler, grafische Programmierung mit UML möglich, integrierter Debugger)
* [http://www.comsytec.eu/epsdebugger.php EPS Debugger Plugin, für STM32 Development mit Code::Blocks]

=== Tutorials für diverse Tool-Kombinationen ===
[[STM32 Eclipse Installation|Windows,Linux, Eclipse + Yagarto/CodeSourcery + OpenOCD/ST-Link]]

* Windows
** Eclipse
*** [http://www.mikrocontroller.net/topic/216554 Windows, Eclipse, codesourcery, st-link ]
*** [http://www.firefly-power.de/ARM/debugging.html Eclipse Plugin "GDB Hardware Debugging" mit OpenOCD]
** Code::Blocks
*** [http://www.mikrocontroller.net/topic/265600 Windows, Code::Blocks, STM32F4]
** STM32 mit EmBlocks
*** [http://www.emblocks.org/web/downloads-main Download EmBlocks]
*** [https://www.youtube.com/watch?v=coHPJylnzC8 Video STM32 Project Wizzard in EmBlocks]
** Atollic TrueSTUDIO
*** [[STM32 LEDBlinken AtollicTrueStudio|Atollic TrueSTUDIO Installation + Demo]]
** MDK-ARM Lite mit Einstellungen für STM32F0/F4-Discovery Board
*** [https://www.keil.com/demo/eval/arm.htm KEIL MDK-ARM Download]
*** [https://www.youtube.com/watch?v=RXOOxby5nns&list=PL6-W3FoUyb48WFI5PQv3SDJj2G1t2FonV&index=1 Installations Video STM32F4 Discovery Board]
*** [https://www.youtube.com/watch?annotation_id=annotation_203294&feature=iv&index=4&list=PL6-W3FoUyb48WFI5PQv3SDJj2G1t2FonV&src_vid=sN4gDZ7H8gw&v=BeZcQjXxk9A Einstellungen STM32F0 Discovery Board Video]
** SiSy ARM, STM32
*** Download: [http://www.sisy.de/index.php?id=59 SiSy DEMO] kein Begrenzung der Codegröße
*** [http://www.youtube.com/watch?v=84Y3jYLWYpo Videobeispiel]
* Ubuntu
** [http://www.seng.de/downloads/HowTo_ToolChain_STM32_Ubuntu.pdf Ubuntu, eclipse, Code Sourcery, OpenOCD] ([http://www.seng.de/downloads/HowTo_ToolChain_STM32_Ubuntu.odt Das Gleiche im bearbeitbaren ODT-Format])
** [http://fun-tech.se/stm32/index.php Ubuntu, Selbstcompilierter GCC, STM32/Cortex-M3]
** [http://thetoolchain.com The ToolChain] - Automatisch installierende Entwicklungsumgebung mit eigenen und externen Treibern, Unterstützt QtCreator als IDE, Flexibel erweiterbar über Shellskripte

* [http://www.mikrocontroller.net/topic/214719 Tipps für Installation mit Eclipse]

===Programmieradapter===
* [http://www.segger.com/jlink-model-overview.html SEGGER J-LINK / J-TRACE] für u.a. alle ARM7/9/11, Cortex-M0/M1/M3/M4/A5/A8/A9/R4 als [http://www.segger.com/cms/j-link-edu.html NonComercial] J-LINK-EDU für ca. 60,- zu haben, läuft in µVision, IAR, GDB (Linux & Windows über einen eigenen [http://www.segger.com/admin/uploads/productDocs/UM08005_JLinkGDBServer.pdf GDB-Server]), Keil, ...
* Keil [http://www.keil.com/ulinkme/ ULINK-ME], [http://www.keil.com/arm/ulink2/ ULINK2], [http://www.keil.com/arm/ulinkpro/ ULINK pro]
* [http://www.st.com/internet/evalboard/product/219866.jsp ST-LINK], [http://www.st.com/internet/evalboard/product/251168.jsp ST-LINK/V2]
* Jedes STM32 Discovery board hat einen ST-Link für Programmierung/Debugging per SWD on-board, welcher auch für eigene STM32 Target Hardware benutzt werden kann (ca. 12,- bis 19,-€, je nach Typ).
* [http://www.raisonance.com/~rlink-debugger-programmer__microcontrollers__tool~tool__T018:4cn9ziz4bnx6.html Raisonance RLink]
* [http://www.amontec.com Amontec]
* [http://www.hjtag.com H-JTAG] Personal Edition für ca. 60,- zu haben, läuft mit ADS, SDT, IAR, Vision und RVDS
* [http://www.isystem.com/products/itag iTag] für 50.- bei Amazon zu bestellen, oder als Eigenbau version (offenes Design) läuft mit der freien winIDEAiTag version (siehe oben)

In der Regel haben die [[JTAG]] Adapter einen 20-Poligen Stecker, den man direkt auf die Demo-Boards, die auch einen 20-Poligen [[JTAG]]-Anschluss haben, einstecken kann. Die Pinbelegung ist genormt, siehe Artikel [[JTAG]]. Die Discovery-Boards haben keinen seperaten JTAG-Stecker, aber zumindest für das STM32F4 Discovery kann man sich leicht einen Adapter Pinheader->JTAG Stecker selber bauen.

Andere [[JTAG]] Adapter wie z.B. der ULink von Keil funktionieren nur mit dem Keil Compiler.

===Programmieradapter Open-Source===

* [https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-COOCOX/ ARM-JTAG-COOCOX], CoLinkEX Nachbau von Olimex, unterstützt JTAG sowie SWD
** [http://www.coocox.org/colinkEx.htm unterstützte uC]
** unterstütze IDEs: [http://www.keil.com/arm/mdk.asp Keil MDK-ARM 4.03] oder neuer, [http://www.iar.com/en/Products/IAR-Embedded-Workbench/ IAR Embedded Workbench 5.xx] oder neuer sowie die [http://www.coocox.org/CooCox_CoIDE.htm CooCox CoIDE]
* [https://www.olimex.com/Products/ARM/JTAG/ Olimex] ARM-USB-OCD (ca. 60.-, hat zusätzlich einen Spannungsausgen und einen COM Port)
* [http://www.oocdlink.com/ OOCDLink]
* [https://github.com/texane/stlink Stlink]
* [http://www.randomprojects.org/wiki/Floss-JTAG FLOSS-JTAG]
* [http://capitanio.org/mlink/ Linux Demo Code für die Discovery's ST-Link Programmierung]

Der Controller hat auch einen fest eingebauten Boot-Lader. Damit läßt er sich auch über eine gewöhnliche serielle Schnittstelle programmieren, ohne dass man einen JTAG-Adapter benötigt. Dies erfordert ggf. entsprechende Konfiguration über die BOOTx-Pins und/oder die Option-Bytes.

=== Demo-Projekte ===

* Einführung in die GPIO Programmierung der STM32F10x und STM32F30x Prozessoren am Beispiel des STM32F3 Discovery Boards und Vergleich zur AVR IO Registerstruktur [http://www.mikrocontroller.net/topic/300472#new]
* [[prog_bsp_timer_1_timer2|Programmbeispiel für die Verwendung von Timer2 zusammen mit dem Interrupt]]
* [http://www.firefly-power.de/ARM/printf.html Printf() debugging mit minimalem Aufwand]
* [[STM32_BLDC_Control_with_HALL_Sensor|Programmbeispiel für BLDC Motoransteuerung (Timer 1) mit HALLSensor (Timer 3)]]
* [[Cortex_M3_OCM3U]]
* Martin Thomas hat ein umfangreiches Projekt erstellt, in der die Eclipse Einstellungen enthalten sind:
** [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html "ChaN's FAT-Module with STM32 SPI"]
* [[STM32 USB-FS-Device Lib]]
* Modellbau-Sender auf STM32-Basis mit vielen Treibern [http://www.rcos.eu www.rcos.eu]
* Ausführliches [https://github.com/jkerdels/stm32edu Einstiegs-Tutorial] in Codeform für das [http://www.st.com/internet/evalboard/product/252419.jsp STM32F4 discovery board]
* [http://www.redacom.ch/keillab/ Schweizer Gondelbahnsteuerung über Webserver auf ETT STM32F ARM KIT Board in Keil RTOS] mit Webcam
* Die [http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/ Ethernut SVN Version] unterstützt inzwischen viele STM32 Typen, viele Devices und einige STM32 Demoboards

== Debug- und Trace-Interface (CoreSight™ Debug and Trace Technologie)==

Übersicht über beide Funktionalitäten und den Schnittstellen:
http://www.keil.com/support/man/docs/ulink2/ulink2_cs_core_sight.htm

Die Coresight-Debug-Architektur ermöglicht ein nicht-invasives Debugging, d.h. es können während des Betriebes (meistens) ohne Beeinflussung des Prozessors Daten vom Speicher gelesen und in selbigen geschrieben werden.

=== Debugger Funktionen ===

Der Debugger-Teil besitzt drei Funktionen:
* Run Control: z.B. Programm-Start, Stopp und Einzel-Schritte.
* (Program) Break Points: Ein Programm hält an, wenn der Programm Counter eine bestimmte Programm-Adresse erreicht.
** Die maximale Anzahl der gleichzeitig möglichen Break Points ist begrenzt (z.B. 6 bei einem STM32).
** Die Anzahl der Break Points ist nahezu unbegrenzt, wenn ein Debugger über den Memory Access (s.u.) sogenannte Flash Break Points unterstützt. Dabei wird ein geladenes Programm im Flash umprogrammiert, um den Debugger anzuhalten. Diese Funktionalität ist meistens ein kostenpflichtiges Zusatz-Feature des Debugger-Herstellers.
** Beinhaltet keine Data Watch Funktionalität, welche im Trace-Teil (DWT) realisiert wird.
* Memory Access: Lesen und Schreiben von Speicheradressen.
** Diese Funktionalität beinhaltet keine direkte Flash-Programmierung. Der Programmiervorgang für einen Flash ist herstellerspezifisch und muss von dem verwendeten Debugger unterstützt werden.

=== Trace Funktionen ===
Die Trace-Funktionalität wird in drei Funktionen aufgeteilt:
* ETM (Embedded Trace Macrocell): Optional, nicht jede CPU besitzt diese Hardware (Kostenfaktor, Austattung).
* ITM (Instrumentation Trace Macrocell): Über diesen Kanal kann ein vereinfachtes Trace des Core ermöglicht werden, sowie "printf-ähnlich" Daten über den ITM Channel 0 geschickt und im Debugger ausgegeben werden.
* DWT (Data Watchpoint & Trace Unit):
** Data Watch: 4 Access-Break-Points ( z.B. der Debugger bleibt stehen, wenn das Programm auf einen Speicher zugreift oder der Wert einer Variablen einen bestimmten Wert annimmt).
** Trace Unit: Programmverlauf (durch Lesen des Program Counters) und Interrupt Aufrufe verfolgen, sowie Zeitmessungen.

Einige der Trace-Funktionalitäten können über die JTAG-Schnittstelle angesprochen werden. Die schnelle Trace-Funktionalität (mit 4 bit Parallel-Port) steht nur mit der erweiterten DEBUG + ETM Schnittstelle zur Verfügung. Im Gegensatz zum Debugger-Teil (Run Control, Break Points und Memory Access) werden Trace-Funktionen nicht von allen Debuggern unterstützt. Debugger mit der vollen Trace-Funktionalität kosten deutlich mehr.

* Beispiele für Trace-Port-Aktivierungen für verschiedene Hersteller: http://www.keil.com/support/man/docs/jlink/jlink_capture_tracedata.htm

Die Aktivierung des parallelen Trace-Ports erfordert, je nach CPU Hersteller, zusätzliche Debugger-Makros für die Aktivierung und Port-Freischaltung. Zusätzlich sind die Schnittstellenauswahl und Einstellung (Frequenzen) im Entwicklungs-Tool (IDE) wichtig, um erfolgreich den Programm-Verlauf "tracen" zu können.

=== Debug und Trace-Schnittstellen ===
Als Debug Interface stehen zwei Varianten zur Auswahl:
* [[JTAG]]: Dafür sind mindestens 6 Steuerleitungen nötig. Unterstützt Device Chaining: Mehrere verbundene Geräte können mit einem Debugger/Programmer gleichzeitig angesteuert werden.
* SWD (Serial Wire Debug): Hier mindestens 2 Steuerleitungen (3 mit SWO, zzgl GND und 3,3V). Die SWD Schnittstelle ist in der Regel schneller und kann auch Funktionen aus dem Trace-Teil beinhalten (z.B. ITM, dafür wird der SWO-Pin benötigt). Device Chaining ist mit dieser Schnittstelle nicht möglich.

Standard-JTAG Steckerbelegungen:
http://www.keil.com/support/man/docs/ulink2/ulink2_hw_connectors.htm

=== Der 10polige JTAG-Stecker von mmvisual ===
mmvisual hat mit dieser Steckerbelegung die Standard JTAG Schnittstelle erweitert:

Ich habe diesen Part in den Artikel [http://www.mikrocontroller.net/articles/JTAG#Der_10-polige_JTAG_Stecker_von_mmvisual JTAG] verschoben.
Hinzu gekommen ist die Adapterplatine 10-Polig auf Standard JTAG 20 Polig mit TTL/V24 Wandler. [http://www.mikrocontroller.net/articles/JTAG#Die_Adapterplatine Siehe hier.]

== Hardware-Beschaltung ==

Der STM32 benötigt für den Betrieb nur (Minimalbeschaltung):

* VCC 2..3,3V (je nach Typ)
* AVCC 2..3,3V (sehr wichtig, der STM32 lässt sich ohne diese Spannung nicht programmieren)
* GND
* Reset Pin 100nF nach GND (ein Pull-Up Widerstand von ca. 40k ist intern vorhanden)
* [[#Bootmodi|Boot-Pins]]

ansonsten nur ein paar einzelne Cs 100nF an VCC/GND.

Um Programmieren zu können wird entweder noch die serielle Schnittstelle (Programmieren über den vorprogrammierten Bootloader) oder JTAG oder die SWD Schnittstelle benötigt.

=== Bootmodi ===
Unterschiedliche Bootmodi lassen sich mittels der PINs BOOT0 und BOOT1 auswählen . Siehe Application Note [https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf AN2606]. Ausser F1 besitzen neuere Familien ein SYSCFG_MEMR Register. In dieses Register kann man die gewünschten Boot0/1 Werte schreiben und nach einem Core-Reset (!= System_Reset) startet der Prozessor im gewünschten Mode. Eine Neu- bzw. Deinitialisierung der Peripherie empfiehlt sich!

==== Boot from FLASH ====
Startadresse wird von 0x08000004 geladen
BOOT0 Lo
BOOT1 X

==== Boot from SRAM ====
PC Startadresse wird an 0x200001E0 direkt angesprungen.
BOOT0 Hi
BOOT1 Hi
Da der interne FLASH der stm32f1x laut Datenblatt nur für 1000 Schreibvorgänge ausgelegt ist, kann mittels BOOT0 (High) und BOOT1 (High) auch aus dem zuvor mit dem Debugger (JTAG/SWD) beschriebenen SRAM booten.
Hierbei gilt zu beachten:
VTOR auf die NVIC Tabelle im SRAM vor dem auslösen des ersten Interrupts remappen.

Um ein vergleichbares Startverhalten zum FLASH zu erreichen, empfiehlt es sich,
0xF1E0F85F an 0x200001E0 zu schreiben. Diese implizite Ausführung von "ldr.w pc,
[pc, #-0x01E0]" beim Start erzwingt ein laden der Startadresse von 0x20000004.

==== Boot from SYSMEM (RS232, CAN und USB) ====
PC Startadresse wird von 0x1FFFF004 geladen
BOOT0 Hi
BOOT1 Lo
Auch ohne JTAG lässt sich ein STM32 programmieren (Bootloader-Aktivierung). Dabei stehen, je nach CPU-Typ, verschiedene Möglichkeiten zur Verfügung:
* RS-232 (bisher alle STMs)
* USB (nur in bestimmten MCUs mit entsprechender Bootloader-Version und PIN-Anzahl, z.B. STM32F105/107)
* CAN (wie USB nur in bestimmten MCUs)

3 zusätzliche Verbindungen müssen auf dem Board gepatcht werden. Für einen Test geht es auch mit Tastern für RESET und BOOT0. 
RESET=RTS (L-aktiv) 
BOOT0=DTR (H-aktiv) 
BOOT1=LOW 

Details sind hier im Forum: [http://www.mikrocontroller.net/topic/141711 STM32 Programmiertool]

== Bewertung ==
=== Vorteile ===

'''Vorteile gegenüber ARM7:'''

* Interrupt-Controller jetzt Teil des Prozessors (als Core Peripheral), die Vector Table ist jetzt eine echte Vektortabelle, keine Sprungliste wie bei ARM7. Durch Automatismen zwischen Core und NVIC (auto register save r0..r3, lr, sp, pc) bei Interrupt Entry wird eine deutlich schnellere Ausführungszeit bei Interrupts erreicht. Der Interrupt Code muss sich nicht mehr selbst um die Sicherung der o.g. Register kümmern und eine besondere Konfiguration der Handler im Compiler entfällt. Sind vor Beendigung einer ISR (d.h. Rücksprung zum User Code) weitere Interrupts pending, so werden diese ausgeführt, ohne dass eine komplette pop-push-sequenz der Register notwendig ist. Schön beschrieben ist es hier im [http://www.st.com/mcu/files/mcu/1221142709.pdf Insider's Guide] unter 2.4.5 / Seite 20.
* Thumb-2 Befehlssatz, deutlich schneller als Thumb-1 und ebenso kompakt
* Weniger Pins für Debugging benötigt durch SWD
* Mehr Hardware Breakpoints machen debuggen einfacher
* Software ist einfacher weil die Umschaltung zwischen ARM Mode und Thumb Mode wegfällt

'''Vorteile gegenüber LPC1700 und LPC1300:'''

* Flexiblere Gehäuseformen mit mehr Peripherie bei kleinen Gehäusen
* FW-Lib für alle STM32 gleich, alle AppNotes/Demos beziehen sich auf diese eine FW-Lib was die Entwicklung der eigenen Applikation sehr beschleunigt.
* Genauerer und flexiblerer ADC, insbesondere gegenüber LPC1300
* Flexiblere Varianten der Peripherie >> bei weniger einen deutlichen Preisvorteil
* ab 0,85 EUR (Stand 2010) Allerdings gibts den LPC1100 mit Cortex-M0 schon ab 0,65 $!

'''Vorteile gegenüber SAM3/4:'''

* Fast alle Pins sind 5-Volt tolerant.

'''Vorteile gegenüber anderen "Kleinen" wie z.B. PIC, Atmel usw.'''
* nahezu gleicher Preis bei Hobby Anwendungen
* 32 Bit ohne Umwege in Assembler rechenbar
* Schnelle direkte Offset-Adressierung ermöglich effizienten Zugriff auf Stack-Variablen, lokal gespeicherte Flash-Konstanten, struct/Array-Elemente
* Einfache einheitliche Adressierung des gesamten Adressraums, d.h. Pointer auf Peripherieregister, RAM & Flash können exakt gleich behandelt werden, keinerlei Banking/Umschalt-Mechanismen erforderlich auch bei großem Flash/RAM
* Interrupt-Prioritäten und Prioritätsgruppen
* Effiziente Pointerarithmetik da Registerbreite=Adressbreite
* bessere Peripherie wie USB, Ethernet, Vielzahl an Timern
* der ARM-Core hat eine höhere Taktfrequenz und kann gleichzeitig mehr in weniger Takten berechnen
* Hardware-Division, bei einigen FPU zur effizienten float-Berechnung
* Mit größerem Flash/RAM verfügbar
* Code kann direkt aus dem RAM ausgeführt werden, Speicherschutz und privilegierter Ausführungsmodus können "Kernel"- vor "Anwendungs"-Code schützen, somit wird das dynamische Nachladen von Anwendungen aus externem Speicher effizient & sicher möglich
* ... und weitere 1000 Punkte ...

=== Nachteile ===

'''Nachteil gegenüber LPC1700:'''
* STM32F1xx: nur 72 MHz statt 100 MHz (LPC1759: 120 MHz) Taktfrequenz; STM32F2xx hat diesen Nachteil nicht (ebenfalls 120MHz, STM32F4xx mit 168MHz) (Aber NXP hat schon 150MHz angekündigt)
* Der LPC1700 besitzt deutlich mehr Mechanismen, um die Auswirkung der Waitstates des Flash-ROMs auf Code- und Datenzugriffe zu reduzieren und das bedeutet mehr Performance bei gleicher Taktfrequenz. Beim STM32F2 entfällt dieser Nachteil wohl aufgrund des ART accelerators.
* Alle LPC1xxx haben 32 Bit Timer. Bei den STM32 haben das nur die STM32F2xx (2 Stück)
* I2S Einheit von ST hat keinen FIFO und im 24/32Bit Modus müssen 2x16Bit Halbwörter übertragen werden. Wobei allgemein bei neuen ARM Prozessoren die vorhandenen DMA-Kanäle (basierend auf eigenen BUS-Kanälen und Speicherzugriffen) FIFO in beliebiger Größe bedeutet.

'''Nachteil für Hobby-Anwender'''

* Nicht direkt "Steckbrettauglich", da kein DIL Gehäuse verfügbar. Der ebay-Shop dipmicro führt jedoch sehr günstige Lötadapter für Umsetzung von LQFP48 auf DIP48. QFP64 in 0.5mm Pinabstand und nicht 0.8mm wie AVR

* Viel Peripherie, Clocks müssen alle richtig eingestellt werden, ggf. Anpassung des Startup Codes usw.
** => Daher nicht besonders gut für Mikrcontroller Anfänger/Einsteiger geeignet.

'''

== Errata, Tipps und Tricks ==
=== Hardware ===
* AD-Wandler PA0: Im Errata steht, dass hier Fehler in der Wandlung entstehen könnten, also einen anderen Pin verwenden.
* CAN-Bus PD0/PD1: Remap geht erst ab der 100-Pin-Version. Steht im RM0008 unter 9.3.3.: "CAN1 alternate function remapping". Alle Infos von RM0008 9.3.x sind interessant
* CAN und USB sind bei der F1 Serie nur bei der "◦Connectivity-Line" gleichzeitig nutzbar. Siehe Datenblätter.
* Mit internem RC-Oszillator kann die CPU mit maximal 64MHz betrieben werden. Mit einem externen Quarz sind dann 72MHz möglich.
* Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden (bei STM32F1xx).
* Der Idle Interrupt vom Usart wird zwar ausgelöst, aber nicht vom entsprechenden Statusflag angezeigt
* Der DMA fängt beim aktivieren immer von vorn an zu zählen, auch wenn er nur kurz angehalten wurde
* STM32F2xx hat kein Flash Size Register, bei STM32F4xx ist zwar ein flash Size Register beschrieben, kollidiert aber in der Adresse mit einem anderen Register
* Derivate mit internem EEPROM und nur einer Speicherbank haben das "Feature" bei write/erase des Data-Flashes (EEPROM) einen kompletten stall der code execution zu verursachen (inkl. ISR's, DMA). Desgleichen bei write/erase des internen Flash (ISP-routinen, EEPROM-Emulation).
* Der I2C hat diverse Fehler, welche im Errata des jeweiligen Modells (z.B. [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00238166.pdf STM32F105xx and STM32F107xx Errata sheet] ) zu finden sind. Workarounds hierzu finden sich in der Application Note [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00209826.pdf AN2824]. Am Besten benutzt man jedoch die I2C Communication peripheral application library (CPAL) von ST ([http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF258336 STSW-STM32127])
* [http://blog.frankvh.com/category/stm32/ weitere undokummentierte Features]
* Interrupt-Flags in Statusregistern der diversen Peripherals wie der Timer müssen zu '''Beginn''' (bzw. möglichst weit vor dem Return) der ISR zurückgesetzt werden, da die ISR sonst eventuell 2x ausgeführt wird ([http://www.mikrocontroller.net/topic/312393#new Siehe Forum]).

=== Software ===
==== GCC ====
Um den GCC direkt zu verwenden (zB. mit selbstgebautem makefile), falls man das nicht von einer Entwicklungsumgebung machen lässt, siehe zunächst [[ARM GCC]]. STM32-spezifisches ist:
* Wird die [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] und ein Quarz verwendet, so muss noch per Präprozessor-Definition die Frequenz des Quarzes angegeben werden mittels z.B. -DHSE_VALUE=8000000 für 8MHz (wie auf dem STM32F4 Discovery).

===== Startupcode & Linkerscript =====
* Damit der compilierte Code an den richtigen Stellen im Controller landet (d.h. dem Flash) muss man dem Linker ein Linkerscript mitgeben. Dies geht per "-T ''pfad_zum_linkerscript.ld''" an den Linker-Befehl. Im Archiv der [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] befindet sich ein Beispiel-Linkerscript für die Atollic TrueSTUDIO IDE, dieses kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich das Script im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Project/STM32F4xx_StdPeriph_Templates/TrueSTUDIO/STM324x7I_EVAL/stm32_flash.ld" des Archives.
* Damit beim Starten die richtigen Initialisierungen vorgenommen werden (wie globale Variablen und bei C++ Konstruktoren globaler Objekt-Instanzen) muss als erstes ein Startupcode laufen, der dann die main()-Funktion aufruft. Der Startupcode ist meistens in Assembler geschrieben, C-Code ist aber auch möglich. Im Archiv der [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] befindet sich ein Beispiel-Startupcode für die Atollic TrueSTUDIO IDE, dieser kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich der Code in Assemblerform im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f40xx.s" des Archives. Der Assemblercode kann per arm-none-eabi-as (Flags s.o.) assemblisiert werden, die resultierende .o -Datei normal mitgelinkt.

Zusammen bieten die beiden Dateien der Anwendung ein Standard-C-Interface, d.h. man kann wie gewohnt globale Variablen verwenden und seinen Code in die main()-Funktion schreiben.

=== Tipps für Umsteiger von Atmel/PIC/8051 ===
* Prozessortakt hat unterschiedliche Taktquellen und eine PLL.
* Alle Peripheriemodule haben einen extra Clock, den man aktivieren muss.
* Wenn man z.B. einen UART benutzen möchte, so muss man den Clock vom UART, Alternate Function IO (AFIO) und dem GPIO-Port aktivieren.
* Ansonsten hat man nahezu doppelt so viele Möglichkeiten in den Peripheriemodulen.
* Interrupt-Flags müssen in der ISR selber gelöscht werden
* Forum zu [http://www.mikrocontroller.net/topic/175888 Interrupts vs. Events]

=== Errata vom STM32F4xx die nicht im Errata von ST stehen ===
* [http://www.mikrocontroller.net/topic/267439#2788478 Aktivieren von DMA], wenn mehr als 3 DMA Kanäle aktiviert werden, kann es sein dass die nicht alle korrekt bedient werden. Auch klappt der DMA mit dem FSMC nicht immer zuverlässig. [https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FWarning%20limit%20simultaneous%20DMAs%20to%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=811 siehe hier] [http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/ und hier]
* [http://www.mikrocontroller.net/topic/260637#2700761 Nerviger Bug in "stm32f4xx.h"] Änderung Struktur GPIO_TypeDef
* [http://www.mikrocontroller.net/topic/261690#2714754 Batterie wird leer gezogen], nur bei manchen Chips mit Rev. A
* [http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt Liste von Dokumentations-Fehlern]

== Bezugsquellen ==

=== Controller ===

Versandhäuser für Privatpersonen
* [http://www.reichelt.de/STM-Controller/2/index.html?;ACTION=2;LA=2;GROUPID=2950; Reichelt]
* [http://darisusgmbh.de/shop/index.php?cat=c2692_ARM-Cortex.html Darisus]
* [http://www.hbe-shop.de HBE (Farnell Programm für Private)]
* [http://www.sander-electronic.de/be00069.html Sander]
*[http://www.tme.eu/de/katalog/index.phtml#cleanParameters%3D1%26search%3DSTM32F10%26bf_szukaj%3D+ TME]
*[http://teske-electronics.de/index.php?cPath=3_9_53 Teske electronics]
*[http://de.rs-online.com/web/c/halbleiter/prozessoren-und-mikrocontroller/mikrocontroller/?sort-by=default&sort-order=default&applied-dimensions=4294417325&lastAttributeSelectedBlock=4294425895 RS-Online]

Gewerblich liefern natürlich viele wie EBV, Mouser, Farnell, Digikey usw...

=== Evaluation Boards ===

* [http://shop.embedded-projects.net/index.php?module=artikel&action=gruppe&id=14 Im Shop von Embedded Projects]
* [http://www.watterott.com/de/Boards-Kits/ARM/ARM-Cortex-M3 Cortex M3 bei Watterott]
* [http://www.raisonance.com/~primer-starter-kits__microcontrollers__tool~tool__T018:4enfvamuxbtp.html Primer und Primer2 von Raisonance]
* [http://www.sander-electronic.de/es0028.html Sander Electronic]
* [http://www.mikrocontroller.net/articles/MP32F103-Stick:_Ein_Mini-Mikrocontroller-Board_mit_USB_und_bis_zu_4MB_Datenspeicher Artikel im Wiki, ARM mit USB und 4MB Speicher]
* [http://www.futurlec.com/STM32_Development_Board.shtml Futurlec Evalboard, ebenso Header-Board]
* [http://www.propox.com/products/t_174.html Propox, Header-Boards für 103R und 103V sowie Trägerplatine dafür]
* [http://www.mikrocontroller.net/articles/Cortex_M3_OCM3U Cortex M3 Artikel im Wiki]
* [http://olimex.com/dev/index.html STM32 bei Olimex]
* [http://de.farnell.com/jsp/displayProduct.jsp?sku=1824325&action=view&CMP=GRHS-1000962 STM32Discovery bei Farnell] Mikrocontroller Board (STM32F100RBT6B) mit onboard USB-Programming Interface für ca. 12,50€
* [http://www.de.rs-online.com/web/p/products/7458434/ STM32Discovery bei RS-Components] 12,65 € +MwSt.
* [http://www.segor.de/#Q=STM32 VL DISCOVERY] STM32 Discovery bei Segor
* [http://www.watterott.com/de/STM32F4Discovery STM32F4DISCOVERY] STM32F4 Cortex M4 Controller mit JTAG-Debugger auf der Platine bei Watterott für 16,66EUR.
* [http://www.conrad.de/ce/de/product/443910/ STM32F4 Discovery Kit bei Conrad] 17,11 €
* [http://www.mcu-raisonance.com/~open4-development-platform__microcontrollers__tool~tool__T018:g65gu6ghg2n.html/ Open 4 oder auch genannt Evo-Primer]
* [http://www.wayengineer.com/index.php?main_page=index&cPath=50_66&page=1&sort=3a WayEngineer]
* [http://thinkembedded.ch/ST-STMicroelectronics:::24.html Im Thinkembedded Shop] in der Schweiz / DiscoveryF4, div. ETT und Olimex Boarde ab 20,18 CHF / 16,15 EUR (inkl. MwSt.) zzgl. Versandkosten
* [http://shop.myavr.de/ARM-Produktlinie/STM32F4-Discovery.htm?sp=article.sp.php&artID=200072 Im myAVR Shop] DiscoveryF4 mit möglichem Zubehör 16,45 EUR (inkl. MwSt.) zzgl. Versandkosten
* [http://www.keil.com/boards/cortexm.asp Keil/ARM Demoboards]
* [http://www.phytec.de Phytec]
* [http://shop.myavr.de/index.php?sp=artlist_kat.sp.php&katID=37 verschiedene ARM Produkte und Erweiterungen bei myAVR]

== Weblinks, Foren, Communities, Tutorials ==
* [http://www.mikrocontroller.net/topic/173753 Diskussion zum Artikel]
* [http://www.mikrocontroller.net/forum/mikrocontroller-elektronik?filter=ARM*+STM32*+Cortex* Suche im Forum]
* [https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/AllItems.aspx Forum auf der ST Homepage]
* [http://www.stm32circle.com/hom/index.php STM32 Community]
*[http://joe-c.de/pages/posts/einstieg_mikrocontroller_stm32f103_101.php Einstieg: STM32board mit Kamera (deutsch)]
* [http://www.ebv.com/fileadmin/products/Press_Print/Brochures/Product_Brochures/EBV_Cortex%20Collection_V2.pdf Übersicht der Cortex Prozessoren und deren Hersteller (nicht nur ST, von EBV)]
* [http://www.mikrocontroller.net/topic/258652 Tutorial]
* [http://diller-technologies.de/stm32_wide.html STM32 Tutorial in Deutsch von Diller Technologies]
* [http://mySTM32.de STM32 C und C++ Tutorial in Deutsch ]
* [http://mikrocontroller.bplaced.net STM32F4 Quellcode-Librarys und CooCox-Projekte in Deutsch ]

<references/>
[[Kategorie:ARM]]
[[Kategorie:STM32| ]]

Bitfelder

2013-10-12T08:27:17Z

Prx: Basistyp und Alignment

Beim Programmieren von Mikrocontrollern muss auf jedes Byte oder sogar auf
jedes Bit geachtet werden. Oft müssen wir in einer Variablen lediglich den
Zustand 0 oder 1 speichern. Wenn wir nun zur Speicherung eines einzelnen Wertes
den kleinsten bekannten Datentypen, nämlich <tt>unsigned char</tt>, nehmen, dann
verschwenden wir 7 Bits, da ein <tt>unsigned char</tt> 8 Bits breit ist.

Hier bietet uns die Programmiersprache C ein mächtiges Werkzeug an, mit dessen
Hilfe wir 8 Bits in eine einzelne Bytevariable zusammenfassen und (fast) wie
8 einzelne Variablen ansprechen können. Die Rede ist von sogenannten '''Bitfeldern'''. Diese werden als Strukturelemente definiert. Sehen wir uns dazu doch am besten gleich ein Beispiel an:

<syntaxhighlight lang="c">
struct {
unsigned bStatus_1:1; // 1 Bit für bStatus_1
unsigned bStatus_2:1; // 1 Bit für bStatus_2
unsigned bNochNBit:1; // Und hier noch mal ein Bit
unsigned b2Bits:2; // Dieses Feld ist 2 Bits breit
// All das hat in einer einzigen Byte-Variable Platz.
// die 3 verbleibenden Bits bleiben ungenutzt
} x;
</syntaxhighlight>

Der Zugriff auf ein solches Feld erfolgt nun, wie beim Strukturzugriff bekannt,
über den Punkt- oder den Dereferenzierungs-Operator:

<syntaxhighlight lang="c">
x.bStatus_1 = 1;
x.bStatus_2 = 0;
x.b2Bits = 3;
</syntaxhighlight>

Bitfelder sparen Platz im RAM, zu Lasten von Rechenzeit zum Zerlegen des Bytes in seine einzelnen bits. Besteht also kein triftiger Grund sollten nur Datentypen mit längen die Vielfache von 8bit sind verwendet werden, auch wenn nur ein Bitwert gespeichert werden soll.

Es kann sinnvoll sein, als Basistyp "unsigned char/short" statt "unsigned" zu wählen. Viele Plattformen behandeln ein als "unsigned" deklariertes Bitfeld hinsichtlich Aligment wie ein normales "unsigned". Ein Array aus der oben definierten Struct würde dann pro Element 2 oder 4 Bytes benötigen.

So wird im ARM ABI
<syntaxhighlight lang="c">struct { unsigned i:1; }</syntaxhighlight>
auf 4 Bytes aligned,
<syntaxhighlight lang="c">struct { unsigned char i:1; }</syntaxhighlight>
aber nicht.

[[Kategorie:C]]

Cortex-M3

2013-03-18T15:20:03Z

Prx: /* Bit-Band-Aliasing */

Ich fange mal mit der Seite zum [[ARM]] Cortex-M3 an.

== Unterschiede zu anderen ARM-Architekturen: ==

=== Statusregister ===

; Anwendungsprogrammstatusregister (Application Program Status)
::{| {{Tabelle}}
|+ '''APSR'''
! Bit 31 || Bit 30 || Bit 29 || Bit 28 || Bit 27
|-
| Negative || Zero || Carry || Overflow || Saturation
|}
: Bits für bedingte Ausführung
:: Negative Negatives Ergebnis bei letzter Operation
:: Zero Nullergebnis bei letzter Operation
:: Carry Übertrag bei letzter Operation
:: Overflow Überlauf bei letzter Operation
: Andere Bits
:: Saturation Anzeige eines Überlaufs oder Unterlaufs bei Befehlen mit Sättigung

; Ausführungsstatusregister (Execution Status)
::{| {{Tabelle}}
|+ '''EPSR'''
! Bit 26 - Bit 25 || Bit 24 || Bit 15 - Bit 10
|-
| ICI/IT || Thumb || ICI/IT
|}
: ICI/IT Interner Zwischenspeicher für den Prozessor für Wiederaufnahme eines Multiplen Befehles nach einer Exception oder für Zwischenspeicherung des IT-Befehls
: Thumb Thumbcode aktiv, im Falle des Cortex-M3 immer 1

; Ausnahmenstatusregister (Interrupt Program Status)
::{| {{Tabelle}}
|+ '''IPSR'''
! Bit 8 - 0
|-
| Exception number
|}
: Exceptionnumber Beinhaltet die Nummer der Unterbrechung die Auslöste (am sinnvollsten in einer Interrupt-Service-Routine nutzbar)

Zugriff auf APSR und IPSR erhält der Programmierer durch den MRS/MSR-Befehl, abhängig von den aktuellen Privilegien.
EPSR-Zugriffe über MRS/MSR sind möglich, werden im Falle von ICI/IT ignoriert und bei ungesetztem T-Bit folgt eine UsageFault-Exception.

=== Interrupte und Ausnahmen ===

FIQs werden nicht mehr unterstützt.

Der Cortex-M3 beinhaltet eine [[Interrupt]]verwaltung (Nested Vectored Interrupt Controler) ab Werk und räumt mit den unterschiedlichen Implementierungen unterschiedlicher Hersteller auf.
Die Interruptverwaltung ermöglicht eine priorisierte Verarbeitung von Interrupten.
Der Interruptcontroller stellt auch den Systemtick zur Verfügung.

==== Primäres Interruptbit ====

Die Primäres Interruptbit (PRIMASK) ist ein 1-Bit Register. Wenn es gesetzt ist werden nur NMI- und Hard-Fault-Ausnahmen einen Interrupt auslösen.

==== Fehler-Interruptbit ====

Die Fehler-Interruptbit (FAULTMASK) ist ebenfalls ein 1-Bit-Register. Wenn es gesetzt ist werden nur NMI-Ausnahmen einen Interrupt auslösen.

==== Basispriorität ====

Die Basispriorität (BASEPRI) ist bis zu 8 Bit breit und abhängig von den im Interrupt-Teil unterstützen Prioritäten. Alle Interrupt mit einer Priorität gleich oder kleiner der in BASEPRI eingestellten Priorität werden unterdrückt.

Zugriff auf PRIMASK,FAULTMASK und BASEPRI erhält der Programmierer durch den MRS und MSR-Befehl, abhängig von den aktuellen Privilegien.

==== Vektortabelle ====

Die Vektortabelle beinhaltet echte Sprungadressen.
Die erste Adresse in der Sprungtabelle ist der Stackpointer, der bei einem Reset geladen wird.
Die zweite Adresse ist die Resetadresse.

=== Control-Register ===

: Bit 0 Durch ein gesetztes Bit wird der Prozessor in Ausnahmen (Handle-Mode) im Privilegierten Modus laufen und außerhalb (Thread-Mode) im unprivilegierten Modus.
: Bit 1 Durch ein gesetztes Bit wird der Prozessor in Ausnahmen (Handle-Mode) Main Stack Pointer (MSP) benutzen und im unprivilegierten Modus den Program Stack Pointer (PSP). Andernfall benutzen beide Modis den Main Stack Pointer

Nach einem Reset ist der Cortex-M3 im Privilegierten Modus

=== Stack ===

Es gibt keine Schattenregister für bestimmte Betriebsmodi mehr.
Der Prozessor führt bei einem Interrupt ein automatisches Sichern des PC (R15), LR (R14), R12 und R0-R3 durch,
welche nach dem Zurückspringen automatisch wieder vom [[Stack]] geholt werden.
Der Prozessor hat zwei Stackregister (MSP und PSP), welche in Abhängigkeit von den Control-Registern je nach Betriebsmodus (Privilegierter Modus oder UserMode) im Registerraum eingeblendet werden.

=== Befehlssatz ===

Das Umschalten zwischen ARM-Codes und Thumb-Codes ist nicht möglich, es wird nur Thumb2 ausgeführt.

Es existieren Befehle für [[#Division|Division]] und [[#MAC-Opcodes|kombinierte Addition und Multiplikation]], [[#Sättigung|Befehle mit Sättigung]], [[#Bitreihenfolgenmanipulation|Befehle für Bitreihenfolgenmanipulation]], [[#IT-Opcode für Bedingte Ausführung|bedingte Ausführung]].

'''IT-Opcode''' Als Ausgleich zu den fehlenden Bedingungsflags des ARM-Codes existiert der [[#IT-Opcode für Bedingte Ausführung|Opcode IT]] (If-True).

=== Speicherbereich ===

Der Adressbereich ist wie bei einem 32-Bit System üblich 4 GiB groß.
Aufgeteilt ist es in mehrere fest definierte Teile:

::{| {{Tabelle}}
! Adressbereich || Verwendung
|-
| 0x00000000 – 0x1FFFFFFF || Code-Bereich
|-
| 0x20000000 – 0x3FFFFFFF || SRAM-Bereich
|-
| 0x40000000 – 0x5FFFFFFF || Geräte-I/O-Bereich
|-
| 0x60000000 – 0x9FFFFFFF || Externer Speicher
|-
| 0xA0000000 – 0xDFFFFFFF || Externe Geräte
|-
| 0xE0000000 – 0xE00FFFFF || Interner und externer Geräte-Bus
|-
| 0xE0100000 – 0xFFFFFFFF || Herstellerspezifischer Bereich
|}

Mit [[#Bit-Band-Aliasing|Bit-Band-Aliasing]] ist bitgenaue Speichermanipulation in bestimmten Speicherbereichen innerhalb eines Befehles möglich.

== Genauere Erläuterungen: ==

=== Befehle ===

==== IT-Opcode für Bedingte Ausführung ====

Diesem Opcode wird eine Bedingung (EQ, GT etc.) übergeben die für den ersten Befehl der folgt erfüllt sein muß.
Wenn die Bedingung nicht erfüllt ist, wird der Befehl übersprungen.
Ein IT-Block kann bis zu 4 Befehle beinhalten, wobei der erste Befehl der Kette immer wahr sein muß.
Die folgenden Befehle werden entsprechend der Angabe ihrer Bedingung, welche die Bedingung im IT-Befehl oder die gegenteilige Bedingung ist, ausgeführt oder übersprungen.

CMP R0,R1 ;Vergleich mit Aktualisierung der Statusbits
ITETE LT ;TRUE-ELSE-TRUE-ELSE LT
MOV[LT] R2,R0 ;TRUE Bedingung R0 LT R1
MOV[GE] R2,R1 ;ELSE Bedingung !(R0 LT R1)
MOV[LT] R3,R0 ;TRUE Bedingung R0 LT R1
MOV[GE] R3,R1 ;ELSE Bedingung !(R0 LT R1

Die in eckigen Klammern angegebenen Bedingungen sind der Lesbarkeit halber angegeben.
Ein bedingter Sprung kann im IT-Block angegeben werden mit der Besonderheit, daß er am Ende des Blocks stehen muß.

==== Division ====

Es existieren zwei 32-Bit-Divisionsbefehle. Beide Befehle speichern keinen Rest und sind auf 32-Bit als Divident begrenzt.

: SDIV Division mit Vorzeichen
: UDIV Division ohne Vorzeichen

SDIV/UDIV R0,R1,R2 führt zum Ergebnis in R0 aus der Division von R1 durch R2

==== Bitreihenfolgenmanipulation ====

Für Bitmanipulation stehen mehrere Befehle zur Verfügung:

: REV Die Byte-Anordnung wird umgedreht und bietet Konvertierung von zwischen Big- und Little-Endian innerhalb eines Befehles.
: REV16 Wechselt die Byte-Anordnung im Oberen und Unteren Wort.
: REVSH Konvertiert einen 16 Bit-Wert mit Byte-Anordnungswechsel und folgender Vorzeichenerweiterung in einen 32 Bit-Wert.
: RBIT Dreht die Bit-Anordnung um.
: BFC Löscht Bits ab einer Bit-Position über eine angegebene Länge.
: BFI Kopiert in das Zielregister die Bits des Quellregister ab der angegebenen Bit-Position über die angegebene Länge.
: SBFX Extrahiert die Bits ab einer angegebene Position über eine angegebene Länge in das Zielregister ab Bit 0 und erweitert es vorzeichenkorrekt.
: UBFX Extrahiert die Bits ab einer angegebene Position über eine angegebene Länge in das Zielregister ab Bit 0 und setzt die andere Bits auf 0.
: SXTB,SXTH Erweitert den Byte-Wert (SXTB) oder den Wort-Wert (SXTH) vorzeichenkorrekt auf 32 Bit. Optional kann vor der Korrektur ein ROR ausgeführt werden.
: UXTB,UXTH Erweitert den Byte-Wert (SXTB) oder den Wort-Wert (SXTH) vorzeichenlos auf 32 Bit. Optional kann vor der Korrektur ein ROR ausgeführt werden.

==== MAC-Opcodes ====

Kombinierte Multiplikations und Additionsbefehle sind:

: MLA Vorzeichenlose Multiplikation zweier 32 Bit-Werte und Addition der unteren 32 Bit des Ergebnisses der Multiplikation mit einem 32-Bit-Wert.
: MLS Vorzeichenlose Multiplikation zweier 32 Bit-Werte und Subtraktion eines 32-Bit-Wert von den unteren 32 Bit des Ergebnisses der Multiplikation.
: SMLAL Vorzeichenbehaftete Multiplikation zweier 32 Bit-Werte zu 64 Bit und folgendes Addieren eines 64 Bit-Wertes.
: UMLAL Vorzeichenlose Multiplikation zweier 32 Bit-Werte zu 64 Bit und folgendes Addieren eines 64 Bit-Wertes.

==== Sättigung ====

Zwei Befehle sind im Zusammenhang mit dem Q-Flag des APSR nutzbar:

Übersteigt der Wert die Bitgrenze n wird der Maximalwert geliefert, Unterschreitet der Wert den Minimalwert wird der Minimalwert geliefert, andernfalls wird der Wert selbst geliefert.
Bei Überschreiten einer einer Grenze wird das Q-Flag gesetzt.

: SSAT Sättigungskorrektur mit Vorzeichenbehafteten Werten.
:: Die Bitgrenze n ist von 1 bis 32
:: Der Minimalwert ist - 2 ^ (n - 1)
:: Der Maximalwert ist ( 2 ^ (n - 1) ) - 1
: USAT Sättigungskorrektur zu Vorzeichenlosen Werten.
:: Die Bitgrenze n ist von 0 bis 31
:: Der Minimalwert ist 0
:: Der Maximalwert ist ( 2 ^ n ) - 1

Ein optionales Arithmetisches oder Logisches Verschieben nach Rechts vor dem Abarbeiten ist möglich.

=== Speicherzugriff ===

==== Bit-Band-Aliasing ====

Der SRAM und der Gerätespeicher sind im für die ersten 32 MB als ''Bit-band-Alias'' definiert.

Unter ''Bit-Band-Alias'' versteht man einen Speicherbereich, der einen bitgenauen Zugriff auf einen Speicherbereich innerhalb eines Befehles zuläßt.
So ist es möglich ohne Deaktivierung von Unterbrechungsanforderungen und in einem Befehl ein Bit zu lesen oder ein Bit zu setzen.

z.B.
Der SRAM-Bereich von 0x20000000-0x200FFFFF kann durch 32-Bit-Zugriffe im Bereich von 0x22000000-0x23FFFFFF bitweise angesprochen werden:

* 0x22000000 entspricht dem Bit 0 von 0x20000000
* 0x22000004 entspricht dem Bit 1
* 0x22000008 Bit 2
* 0x22000020 entspricht dem Bit 0 von 0x20000001
* usw.
Bit-Band-Adresse = Bit-Band-Basis + (Byte-Offset × 32) + (Bit[0-7] × 4)
0x22000020 = 0x22000000 + 1 × 32 + 0 × 4

Beim Zugriff zählt nur das unterste Bit im schreibenden und lesenden Zugriff.

Ein Schreiben auf Adresse 0x22000008 mit einem Wert von 1 setzt das 2. Bit in 0x20000000 innerhalb eines Befehls und wird [[atomar]] ausgeführt.

Das Lesen von der Adresse 0x22000008 ergibt je nach Zustand des 2. Bits in 0x20000000 eine 1 oder eine 0 als Ergebnis.

Siehe [[ARM_Bitbanding]].

[[Kategorie:ARM]]

Diskussion:Plattformunabhängige Programmierung in C

2013-02-27T14:57:09Z

Prx: /* Was noch fehlt */

== Was noch fehlt ==

Bei einem Wettbewerbsartikel würde ich zumindest noch folgende Punkte erwarten:

* Verweise auf die entsprechende Kausel im Standard, so dass jeder Interessierte es genau nachlesen kann.
* Bessere Recherche: <tt>char</tt> ist nicht notwendig signed, sondern kann auch unsigned sein. Dies überlässt der C-Standard der Implementierung (ABI etc.)
* <tt>long long</tt> wird erst mit C99 eingeführt
* Ebenso <tt>stdint.h</tt> das zB <tt>uint8_t</tt> definiert — und im Artikel noch nichtmal erwähnt wird. Ditto für <tt>inttypes.h</tt>.
* signed und unsigned-Typen unterscheiden sich auch hinsichtlich des Überlaufverhaltens.
* −2''n''−1 als minimaler Wert für eine ''n''-Bit signed-Variable wird vom Standard '' nicht'' zugesichert. Ausnahmen sind zwar exotisch, sollten aber Erwähnung finden.
* Maximal- und Minimalwert erhält man z.B. per <tt>INT_MAX</tt> oder <tt>INT8_MIN</tt>.
* Wie sieht's mit portierbarer Ausgabe aus, etwa mit <tt>printf</tt> et al.?
* Was ist bei der Portierung von Arithmetik zu beachten? Was kann <tt>stdint.h</tt> leisten und was nicht? (Die Promotion-Rules werden z.B. ''nicht'' verändert).
* Was ist bei portabler Zeiger-Arithmetik zu beachten? Was ist mit <tt>sizeof (void*)</tt>, <tt>size_t</tt> und <tt>ptrdiff_t</tt> etc.?
* Wie ist mit Literalen umzugehen, etwa in <tt>x = 1 << y</tt>? Welche Möglichkeiten gibt es? Was ist der Unterschied zwischen UINT32_C und einem Cast?
* Wie sieht es mit Berechnungen im Präprozessor aus, etwa <tt>#if X != 1 << 16</tt>. Ist das portierbar? Welchen natürlichen Typ haben die Präprozessor-Literale?
* Was ist beim Serialisieren / Deserialisieren zu beachten? Bit-, Byte- und Word-Endianess.
* Wie ist mit unterschiedlichen Alignments umzugehen. Wieder fällt einem Serialisieren / Deserialisieren und Zeiger-Arithmetik ein.
* Bei Portierbarkeit kann auch das Thema "Bitfelder" nicht ausgespart werden, ebenso verdienen andere Datentypen wie <tt>float</tt> zumindest Erwähnung.
* Was tun, wenn kein C99 verfügbar ist, wie bei Microsoft-Compilern nicht unüblich?
* Was ist Für und Wider? Entwicklungszeit, Fehleranfälligkeit, Effizienz des erzeugten Codes, Leserlichkeit des Codes, etc.
* Welche Teile eines Programmes können als nicht-portierbar angesehen werden? (ISRs, Ausgabe (LCD, UART), ...), wie ist damit umzugehen, und wie sieht die Integration in den portierbaren Teil aus? Etwa in ein minimales Programm wie folgt, und zwar /ohne/ diese Quelle umzuschreiben und UART- oder LCD-Funktionen rein zu hacken?
#include <stdio.h>
#include <stdlib.h>

int main (void)
{
printf ("Hallo Welt!\n");

return EXIT_SUCCESS;
}

Diskussion:Plattformunabhängige Programmierung in C

2013-02-27T14:56:18Z

Prx: /* Was noch fehlt */

Diskussion:Lock-Free Algorithmen

2013-02-09T19:31:15Z

Prx:

Da LL/SC schon drin steht würde Transactional Memory auch gut reinpassen, zumindest eine Erwähnung des Prinzips. Gibts ja demnächst von Intel in Haswell. Dazu siehe:
http://www.realworldtech.com/haswell-tm/
http://www.realworldtech.com/haswell-tm-alt/
--[[Benutzer:Prx|Prx]] 19:31, 9. Feb. 2013 (UTC)

2012-05-24T07:29:55Z

Prx:

Der Abschnitt "Kritik" sollte meines Erachtens komplett wegfallen, da er zu stark verallgemeinert oder gar falsch ist:

* Es ist für den Programmierer unter Umständen sehr wohl sichtbar, weil er sich damit beschäftigen muss, wo z.B. Konstanten liegen (Flash oder RAM, z.B. auf AVRs)
* Das hat keinen zwingenden Einfluss auf die Geschwindigkeit der Speicherzugriffe.
* die x86 Prozessoren waren noch nie Harvard. Sie unterstützen allerdings sowohl memory mapped I/O sowie auch I/O über einen separaten Bus.

--[[Benutzer:Tomm|Tomm]] 20:50, 12. Apr. 2011 (UTC)

In der Kritik ging es mir vorrangig darum, in dieser Frage den Unterschied zwischen "Bus" und "Adressraum" zu beleuchten.

* Implementierungen werden leider oft bereits dann als vom Harvard Typ bezeichnet, wenn sie getrennte Befehls- und Datencaches besitzen, auch wenn sich beide im gleichen Adressraum befinden. 486 hatte einen gemeinsamen Cache, Pentium getrennte.

* Die x86 Prozessoren besitzen zwar einen getrennten I/O-Adressraum, aber keinen getrennten I/O-Bus.

* Der Programmierer muss sich nur dann mit Konstanten befassen, wenn die Konstanten in einem separaten Adressraum liegen. Ob der über einen gemeinsamen oder getrennten Bus angesprochen wird ist hingegen ohne Belang.

--[[Benutzer:Prx|Prx]] 07:26, 24. Mai 2012 (UTC)--