Mikrocontroller.net - Benutzerbeiträge [de]

Benutzer:Haku

2014-01-03T06:57:05Z

Haku:

<div style="border: 5px solid red; padding: 10px; text-align: center;">
<big>Dieser Benutzer ist hier nicht mehr aktiv.</big>
</div>

Es ist schade und ich habe mich lange gegen den Eindruck gewehrt, aber das Diskussionsniveau konvergiert in jüngster Zeit stramm hinfort.
Ich weiß besseres mit meiner Zeit anzufangen, als mich bei jeder sich bietenden Gelegenheit wieder von wie von uneinsichtigen Kindergartenkindern belehren und anpöbeln zu lassen, die nicht in der Lage sind, ein Datenblatt oder eine Anleitung zu lesen.

''Ja, aber...''
Nein. --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 07:57, 3. Jan. 2014 (CET)

----
Übrigens:

http://www.mikrocontroller.net/topic/99690
* Ich bin nicht in der Lage, mitzudenken.
* Ich behalte mein Supergesülze für mich.
* Ich kanns nicht lassen. (Pater Brown und Agathe übrigens auch nicht.)
* Ich bin ein Erbsenzähler.
* Ich ziehe alles sinnlos runter.
* Ich lenke von der eigentlichen Frage ab.
* Ich kann nicht lesen.
* Bitte sehr für die Ratschläge.
* Ich habs kapiert. Bitteschön, man hilft, wo man kann.
* Ich bin ein arroganter Schnösel.
* Bei mir tickt es nicht richtig.
* Ich stelle ziemlich unfreundliche Gegenfragen.
* Ich bin hier nicht der Nette.
* Ich habe garnix verstanden.
* Ich brauche eine Beschäftigung.
* Ich habe nicht den Hauch einer Ahnung.
* Bittesehr für den Link.
* Alles ist etwas zu viel für mich heute.
* Ich habe aber auch gar keine Ahnung, was ich hier deutlich beweise.
* Ich war heute noch nicht auf dem Klo.
* Ich mache Jupp die Rolle des Forentrolls streitig.
* Ich verweise auf nutzlose Links.
* Ich bin ein Übergott und haue jeden.
* Ich bin ein Superstar.
* Ich bin Mister Allwissend und belehre schwachsinnig alle von oben herab.
* SiMa ist dumm und klein.
* Ich moser andere Leute an, wenn ich mal was weiß.
* Ich bin einfach nur still.
* Ich pinsele Superregeln.
* Ich habe garnichts gelüftet, alles was ich mache, ist falsch.
* Ich stelle mich immer noch als allwissend dar. Und alles ist ein Kinderspiel, weil ihr alle zu doof und zu faul seit.
* Ich beleidige ständig alles und jeden.

http://www.mikrocontroller.net/topic/101931
* Ich tue immer ganz erhaben.
* Ich halt die Klappe.

http://www.mikrocontroller.net/topic/102386#892463
* Ich mach mal.

http://www.mikrocontroller.net/topic/104088#910584
* Ich bin ein möchtegern-Hilfssheriff.

http://www.mikrocontroller.net/topic/113723?reply_to=1025066#1025066
* Ich bin eine Katastrophe für mikrocontroller.net.

Kategorie:Löschkandidaten

2013-12-31T08:43:34Z

Haku: /* Löschantrag */ Vorlage

= Löschkandidaten =
Diese Kategorie enthält Seiten, die zur Löschung vorgeschlagen sind. Löschen einer Seite ist etwas anderes, als den Inhalt einer Seite zu entfernen und die dann leere Seite als neue Version zu speichern! Seiten können nur von Administratoren gelöscht werden.

== Löschantrag ==
Um eine Seite zur Löschung vorzuschlagen, lege sie in dieser Kategorie ab, indem du der Seite einen Verweis auf diese Kategorie hinzufügst:
<nowiki>
{{Vorlage:Löschen|Deine Begründung...}}
</nowiki>

== Löschen von Benutzerseiten ==
Seiten aus den Benutzernamensräumen (''Benutzer:Mustermann/Musterseite'') sollten nur vom Eigentümer des Namensraumes zur Löschung vorgeschlagen werden. Falls notwendig, sollte zunächst der Kontakt zu dem Benutzer gesucht werden (etwa über dessen Diskussionsseite, ''Benutzer Diskussion:Mustermann''), um die Löschung zu diskutieren.

== Löschdiskussion ==
Die Löschung von Artikeln sollte diskutiert werden. Dazu dient die [[Kategorie Diskussion:Löschkandidaten|Diskussionsseite]]. Vielleicht kann ein Artikel durch zum Beispiel durch inhaltliche Überarbeitung gerettet werden. Bitte lege zu jeder Löschdiskussion eine neue Überschrift auf der Diskussionsseite an und signiere deine Beiträge mit <nowiki>--~~~~</nowiki>.

Vorlage:Löschen

2013-12-31T08:43:06Z

Haku: Includeonly wg. Kategorie

<div style="border: 3px dashed red; padding: 5px;">
<div style="font: 32pt bold;">Löschkandidat</div>
Dieser Artikel wurde zur [[Kategorie:Löschkandidaten|Löschung]] vorgeschlagen.
Bitte beteilige dich an der [[Kategorie Diskussion:Löschkandidaten/{{FULLPAGENAME}}|Löschdiskussion]]!

<div style="border: 1px solid gray; padding: 3px; margin: 5px;">
Begründung: {{{1|Wunsch des Benutzers}}}
</div>
</div>
 

<includeonly>
[[Kategorie:Löschkandidaten]]
</includeonly>

Vorlage:Löschen

2013-12-31T08:41:54Z

Haku: Kategorie

Vorlage:Löschen

2013-12-31T08:41:25Z

Haku:

Vorlage:Löschen

2013-12-31T08:35:04Z

Haku:

<div style="border: 3px dashed red; padding: 5px;">
<h1>Löschkandidat</h1>
Dieser Artikel wurde zur [[Kategorie:Löschkandidaten|Löschung]] vorgeschlagen.
Bitte beteilige dich an der [[Kategorie Diskussion:Löschkandidaten/{{FULLPAGENAME}}|Löschdiskussion]]!

<div style="border: 1px solid gray; padding: 3px; margin: 5px;">
Begründung: {{{1|Wunsch des Benutzers}}}
</div>
</div>

Vorlage:Löschen

2013-12-31T08:32:52Z

Haku: Die Seite wurde neu angelegt: „<div style="border: 3px dashed red; padding: 5px;"> <h1>Löschkandidat</h1> Dieser Artikel wurde zur Löschung vorgeschlagen. Bi…“

Diskussion:STM32 für Einsteiger

2013-12-31T08:15:27Z

Haku: /* Speicher... */

= Speicher... =
RAM und I/O liegen bei den AVR im gleichen Adressbereich. --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 17:45, 30. Dez. 2013 (CET)

:Das ist wohl richtig. Sogar der Registersatz (32 Register à 8 Bit) liegt dort. --[[Benutzer:M-w|M-w]] ([[Benutzer Diskussion:M-w|Diskussion]]) 23:20, 30. Dez. 2013 (CET)

= Programm/Arbeitsspeicher =
Man sollte auch fairerweise unterscheiden zwischen 8Bit und größeren. Wenn man beim PIC z.B. hinschreibt, dass er 2MB Programmspeicher hat, dann sollte man erwähnen, dass es dann kein 8-Bit-PIC mehr ist. Denn die AVR32 können auch mehr als 256k... --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 09:15, 31. Dez. 2013 (CET)

Kategorie:Löschkandidaten

2013-12-30T19:03:07Z

Haku: Löschverfahren wie in anderen Wikis üblich

= Löschkandidaten =
Diese Kategorie enthält Seiten, die zur Löschung vorgeschlagen sind. Löschen einer Seite ist etwas anderes, als den Inhalt einer Seite zu entfernen und die dann leere Seite als neue Version zu speichern! Seiten können nur von Administratoren gelöscht werden.

== Löschantrag ==
Um eine Seite zur Löschung vorzuschlagen, lege sie in dieser Kategorie ab, indem du der Seite einen Verweis auf diese Kategorie hinzufügst:
<nowiki>
[[Kategorie:Löschkandidaten]]
</nowiki>

== Löschen von Benutzerseiten ==
Seiten aus den Benutzernamensräumen (''Benutzer:Mustermann/Musterseite'') sollten nur vom Eigentümer des Namensraumes zur Löschung vorgeschlagen werden. Falls notwendig, sollte zunächst der Kontakt zu dem Benutzer gesucht werden (etwa über dessen Diskussionsseite, ''Benutzer Diskussion:Mustermann''), um die Löschung zu diskutieren.

== Löschdiskussion ==
Die Löschung von Artikeln sollte diskutiert werden. Dazu dient die [[Kategorie Diskussion:Löschkandidaten|Diskussionsseite]]. Vielleicht kann ein Artikel durch zum Beispiel durch inhaltliche Überarbeitung gerettet werden. Bitte lege zu jeder Löschdiskussion eine neue Überschrift auf der Diskussionsseite an und signiere deine Beiträge mit <nowiki>--~~~~</nowiki>.

STM32 für Einsteiger

2013-12-30T16:48:29Z

Haku: /* Eigene Fähigkeiten und Wünsche */

Immer wiederkehrend hier im Forum "Mit welchem Mikrocontroller anfangen?". Es gibt eine große Auswahl und eben so viele Empfehlungen. In diesem Artikel soll zu erst geholfen werden ob ein STM32-Prozessor mit Cortex-M3/M4 Kern überhaupt der Richtige für den Start ist.
Nicht für jeden ist der STM32 zu empfehlen, denn die Anforderungen und Wünsche die man realisieren möchte, sowie die eigenen Fähigkeiten sind verschieden.

Es werden meist die Prozessoren AVR, PIC, Arduino, MSP430 und STM32 empfohlen. Seltener auch 8051, LPC und M16C. Alle haben Vorzüge und ebenso auch Nachteile.

= Eigene Fähigkeiten und Wünsche =

Dieser Artikel geht davon aus, dass bereits Elektronik Kenntnisse vorhanden sind. Wenn nicht dann sollte man erst einmal den Artikel "[[Absolute Beginner]]" durcharbeiten, sowie die anderen Artikel aus der Kategorie "[http://www.mikrocontroller.net/articles/Kategorie:Grundlagen Grundlagen]"

Zu erst einmal die Randbedingungen, mit der man sich selbst zu erst einmal einschätzen sollte:
{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Fähigkeit || Empfehlung [[STM32]] || Empfehlung [[AVR]] || Empfehlung PIC || Empfehlung [[MSP430]] || Empfehlung Arduino
|-
| Neueinsteiger, kaum Elektronikkenntnisse, noch nie programmiert || align="center"|O || align="center"|O [http://www.rn-wissen.de/index.php/AVR-Einstieg_leicht_gemacht] [http://www.avr-asm-tutorial.net/avr_de/] || align="center"|O [http://www.sprut.de/] || align="center"|O || align="center"|x
|-
| Wunsch ist SD-Card oder Grafik-Display || align="center"|x || align="center"|x || align="center"|x [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537999] [http://www.microchip.com/pagehandler/en-us/technology/graphics/] || align="center"|x || align="center"|x
|-
| Wunsch ist TCP/IP Netzwerk oder Kamera|| align="center"|x || align="center"|O || align="center"|x [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505&param=en535724] || align="center"|O || align="center"|O
|-
| Möchte die Erkenntnisse beruflich nutzen|| align="center"|x || align="center"|x || align="center"|x || align="center"|x || align="center"|-
|-
| Strom sparende Anwendungen|| align="center"|O || align="center"|x [http://www.atmel.com/technologies/lowpower/default.aspx] || align="center"|x [http://www.microchip.com/pagehandler/en-us/technology/xlp/] || align="center"|x || align="center"|-
|-
| Experimentieren mit Multithreading, RTOS, Schedulern || align="center"|x || align="center"|O [http://www.freertos.org/a00098.html] [http://www.femtoos.org/] || align="center"|O [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en531543&redirects=rtos] || align="center"|- || align="center"|-
|-
| Große, komplex strukturierte Programme || align="center"|x || align="center"|bedingt, z.B. XMega || align="center"|O || align="center"|O || align="center"|-
|-
| Sehr viel PWM mit komplexem Timing || align="center"|x || align="center"|bedingt, AT90Spwm || align="center"|O || align="center"|O || align="center"|-
|-
| Deutschsprachige Community || align="center"|O || align="center"|x || align="center"|O || align="center"|- || align="center"|x
|}
* x = ja
* O = Teilweise, Einschränkungen
* - = nicht empfohlen
* ? = Bitte ergänzen

Nur um nicht zu verwirren, auch wenn Teile "nicht empfohlen" sind, heißt dass nicht dass es mit dem Prozessor nicht geht, vielmehr dass es mehr Aufwand ist das zu realisieren oder mehr Einschränkungen hat.

= Unwichtige Randbedingungen =

Oftmals werden fälschlicherweise Argumente für oder gegen eine µC-Familie ausgesprochen, die in der Praxis '''zum Einstieg''' (bei konkreten Anwendungen kann das anders aussehen) eher unwichtig sind.

* Spannungsversorgung 3,3V / 5V
* 8 (z.B. [[AVR]]), 16 (z.B. [[MSP430]]) oder 32 (z.B. [[STM32]]) Bit
* Interrupt System mit mehr oder weniger Features
* Programmiersprache (Assembler, Basic, C, C++, Pascal)
* Assembler verstehen (Sollte nur theoretisch verstanden werden, ein Programm sollte in einer Hochsprache geschrieben sein)
* DIL Gehäuse - steckbretttauglich (STM32-Prozessoren gibt es auch fertig gelötet auf einem steckbretttauglichen Board zum zehnfachen Preis vergleichbarer DIL Mikrocontroller)
* Programmieradapter
* zu 90% reicht doch ein kleiner Prozessor ([[AVR]]/PIC) - und für die restlichen kann man immer noch einen großen nehmen. Warum also nicht gleich einen großen nehmen?

= Kosten =

Grobe Abschätzung was das alles denn kosten wird. Hier sind nur einige Beispiele gezeigt.

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Board || [[STM32]] || [[AVR]] || PIC18/24/32 || [[MSP430]] || Arduino
|-
| Demo-Board || align="center"|[http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419] 9..20€ (incl. Programmieradapter und Debugger) || align="center"|5..500€, z.B. Arduino || align="center"| [http://www.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=Starter%20Kits&mid=1&lmid=610 durchschnittlich 18€ .. 50€] || align="center"|[http://www.ti.com/tool/msp-exp430fr5739] ~35€ || align="center"|20€
|-
| Steckbrettaugliches Board || align="center"| s.o. oder [http://re.reworld.eu/de/produkte/s64dil-405/index.htm S64DIL-405] 30€ || align="center"|2-5€ als einzelner IC || align="center"|2-5€ als einzelner IC || align="center"|?? || align="center"|??
|-
| Programmieradapter mit Debugger || align="center"| s.o. oder z.B [http://www.segger.com/j-link-edu.html Segger J-LINK EDU] 50€ (sehr schnell und unterstützt viele Prozessoren) || align="center"|?? || align="center"|PICkit 3 30€ [http://www.microchipdirect.com/ProductSearch.aspx?keywords=PG164130] || align="center"|z.B. Dragon 50€ || align="center"|20€ (Man muss DebugWire aktivieren)
|}

Das Demo-Board sollte ein Board sein, nicht zu teuer, um die ersten Erfahrungen zu sammeln. Wenn einem der Prozessor gefällt, so kann man später immer noch mit einem zweiten Demo-Board, z.B. mit Display aufrüsten.

Wenn man gerne mit einem Steckbrett sich die Schaltung zusammen stecken möchte, so kann man entweder die benötigten Drähte am Demo-Board anlöten oder bei z.B. [[AVR]]/[[PIC]] Prozessoren gibt es Ausführungen im DIL Gehäuse, die direkt steckbar sind.

Ein Programmieradapter sollte unbedingt auch einen Debugger beinhalten. Denn für den Start ist es ungemein hilfreich zu sehen was im Prozessor gerade geschieht. Die JTAG-Adapter für einen [[STM32]] Prozessor sind alle Debugger-Tauglich. Für einen [[AVR]] oder [[PIC]] Prozessor gibt es auch oft reine Programmer (oft Selbstbau-Lösungen über die serielle oder parallele Schnittstelle) welche den Mikrocontroller nur beschreiben können. Sinvoller sind hingegen Debugger (bspw. PIC Kit 3 [http://www.microchipdirect.com/ProductSearch.aspx?keywords=PG164130] kompatibel zu allen PIC Mikrocontrollern), die die Ausführung eines Mikrocontrollers anhalten können um die aktuelle Position im Programmcode, Variableninhalt, Register, ... auszulesen bzw. zur Laufzeit zu ändern.

Der für den [[STM32]] empfohlene Segger J-LINK EDU ist zwar nicht der günstigste (z.B. auf einem STM32F4DISCOVERY Borad ist auch einer drauf den man für andere STM32 nutzen kann) aber eines der besten, mit sehr guten Software-Tools und nutzbar für alle Prozessoren mit ARM-Kern (ARM7/9/11/... Cortex-Mx). Niemals am Werkzeug sparen und man hat viel mehr Freude bei der Arbeit.

Der "Arduino" ist kein eigenständiger Prozessor, sondern ein fertiges Board mit einer "Arduino" Programmierumgebung (und einem AVR Prozessor), extra geschaffen für Einsteiger. Allerdings ist da der Lerneffekt viel geringer da man den Prozessor mit der Arduino-Software programmiert und nicht direkt die Register.

Ein [[PIC16]] ist ein älterer 8-Bit Mikrocontroller, der durch die [[PIC18]] Reihe abgelöst wurde. Werden komplexere Anforderungen in Zukunft an den Mikrocontroller gestellt (Audio, Grafik), so sollte zu den moderneren [[PIC24]] bzw. [[dsPIC]] (16-Bit) oder gar zu [[PIC32]] (32-Bit MIPS Prozessor) gegriffen werden, wobei letzterer von der Performance vergleichbar mit den STM32 ARM-basierten Mikrocontrollern ist.

= Programmierumgebungen=

Bei den Programmierumgebungen gibt es zu allen Prozessorfamilien kostenlose und Leistungsfähige Software

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! [[STM32]] || [[AVR]] || PIC || [[MSP430]] || Arduino
|-
| align="center"|[http://www.coocox.org/CooCox_CoIDE.htm CooCox] || align="center"|Atmel-Studio || align="center"|[http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPALB X] (IDE inklusive compiler) || align="center"|?? || align="center"|arduino 1.0.5
|}

natürlich gibt es noch viele weitere (für STM32 siehe [[STM32#Programmierung]]), es sollte jedoch nur die einfachsten kostenlose (und ohne Codebegrenzung) für den ersten Einstieg gezeigt werden.

= Dokumentation=

Bevor man sich für einen Prozessor entscheidet sollte man unbedingt deren Dokumentation mal zumindest überfliegen und auch deren Errata's lesen. Nicht dass man eine Anwendung erstellen möchte und stellt hinterher fest, dass genau dieser Teil so buggy ist das er nicht genutzt werden kann.

Beim [[STM32]] hat die Dokumentation doch recht viele Seiten, viel mehr als bei einem [[AVR]] oder PIC. Dabei ist vieles eher knapp beschrieben, man muss mehr suchen als z.B. bei den AVR-Dokus, um die gewünschten Informationen zu finden. Außerdem gibt es durchaus einige Unklarheiten und Fehler/Widersprüche. Schlussendlich ist es Geschmackssache mit welcher Doku von welchem Hersteller man sich besser zurecht findet.

Bei den PICs gibt es zu jedem Mikrocontroller ein Datenblatt das die wichtigsten Informationen für den alltäglichen Gebrauch enthält. Da bestimmte Peripherie (bspw. I2C, SPI, ... ) aber sehr komplex ist und innerhalb einer Familie (PIC16/18/24/32) sich identisch verhält, gibt es zu jeder Familie die sogenannten Family-Datasheets, welche alle Module im Detail beschreiben.

Parallel zur Dokumentation sollte man sich auch die Demo-Beispiele der Hersteller anschauen, dann wird vieles gleich verständlicher.

Eine Übersicht über die Funktionen gibt es im Artikel: [[STM32]]

= Die Arbeit mit dem STM32=

Zu erst einmal SOOO groß sind die Unterschiede zwischen den einzelnen Prozessoren nicht. Alle haben Ein-/Ausgänge und um mittels einem Port-Pin eine LED ansteuern zu können muss bei jedem Prozessor der Pin erst einmal parametriert werden, egal ob das jetzt ein STM32 oder ein AVR oder ein MSP430 ist. Nur hat man bei einem STM32 doch einige Funktionen mehr, z.B. zuschaltbarer Pull-Up oder Pull-Down Widerstand und spezielle Setz-Rücksetzregister, die andere Prozessoren nicht haben, jedoch das programmieren vereinfachen.
Der Haupt-Unterschied zu den anderen Prozessoren ist, dass der [[STM32]] so viele Peripherie-Module beherbergt, dass man die einzeln immer mit einem Clock aktivieren muss, denn damit lässt sich viel Strom sparen.

Und mal ganz ehrlich die Diskussion welcher µc einfacher zu konfigurieren ist, ist doch absoluter Unsinn. Der Weg ist immer der Gleiche:
*1. Blick ins Datenblatt welche Register für diese Funktion benötigt werden.
*2. Werte ermitteln die in die Register eingetragen werden.
*3. Werte ins Register schreiben. Da machte es GAR KEINEN UNTERSCHIED ob es ein [[AVR]], 8051/2, ARM,...... ist.

Stimmt schon es gibt Unterschiede. Die Register haben anderen Namen, andere Adressen, andere Bitbedeutungen,...
Aber es steht doch alles im Datenblatt. Und ob ich jetzt einen [[AVR]] oder einen ARM das erste mal vor mir liegen hab. Ich brauch in allen Fällen die oben beschriebenen Schritte.

Das Interruptsystem ist bei einem STM32 zusätzlich priorisiert, damit kann man festlegen welcher Interrupt vorrangig bearbeitet wird. Die Prioritätenvergabe ist auch kein Hexenwerk.

Zu allen Prozessoren liefern die jeweiligen Hersteller umfangreiche Demo-Codes und Libraries mit. Meist sind alle in C geschrieben, daher sollte auch die Programmiersprache C verwendet werden. Vor allem auch wenn man berufliche Absichten verfolgt.

Und wenn man einen STM32 kann, dann ist ein Umstieg auf einen LPC17xx (NXP) oder andere Hersteller überhaupt kein Problem, denn die bieten ebenfalls Prozessoren mit Cortex-M3 Kern und man kann diese mit der gleichen Programmierumgebung programmieren. Somit ist man nicht zwingend Herstellerabhängig.

Mit einem STM32 kann man als Hobby-Baster und Professionell nahezu alle Anwendungen realisieren. Der hat genügend RAM und FLASH Speicher und auch genügen Geschwindigkeit. Viele Gehäuse-Varianten um kleine bis hin zu größere Geräte zu erstellen. Viele Schnittstellen, sind im Artikel [[STM32]] beschrieben.

Der einzige Nachteil beim STM32: man muss etwas mehr lesen, da eine Peripherie doch viel mehr Funktionalität hat. Ansonsten kenne ich nicht wirklich einen Grund warum man als Neueinsteiger keinen STM32 nehmen sollte.

= Programmiersprachen =
* Wie bei vielen anderen Controllern wird beim STM32 auch hauptsächlich C und C++ verwendet. Kennen sollte man die Programmiersprache C schon, wenn man davon noch keine Ahnung hat dann sollte man erst mal mittels einem Tutorial auf einem PC ein Konsoleprogramm schreiben, sodass man es einigermaßen kennen lernt. Hier im Forum gibt es ebenfalls Artikel dazu. Zielt man auf die (spätere) Anwendung in der Industrie, sollte aufgrund der Verbreitung auf jeden Fall C (oder C++) gewählt werden; außerdem sind die meisten verfügbaren Libraries in C geschrieben.
* Assembler sollte man nur grob verstehen, Details wie ein Befehl arbeitet ist unwichtig. Selbst wenn man die Zyklen für einen Funktionsaufruf wissen will, so bietet der STM32 (Cortex-M3) einen Cycle-Counter den man auslesen kann; durch die komplexere Pipeline und Cache-Effekte sind die Laufzeiten allerdings nicht genau vorhersehbar. Wird zyklengenause Timing benötigt, sollten Timer verwendet werden - davon hat der STM32 genug.

Der 32bit-Adressraum, der RAM, Flash, I/O-Register vereinheitlicht ansprechen kann (im Gegensatz zu z.B. AVR) ist ideal für eine Verwendung durch Hochsprachen; bei Pointern muss keine zusätzliche Information verwaltet werden, in welche Art Speicher sie zeigen. Die Adresse gibt dies eindeutig an (es gibt nur '''eine''' Adresse 42, und nicht 2 wie bei es für Harvard-Architekturen eigentlich typisch ist (Programmspeicher und Datenspeicher, also z.B. Flash und RAM/IO) und die Hardware spricht automatisch den richtigen Speicher an. Die Möglichkeiten zur Offset-Adressierung, der Barrel-Shifter, Divsions-Einheit, die FPU (bei STM32F4), Interrupt-Modell etc. begünstigen ebenfalls die Erzeugung effizienteren Codes. Außerdem haben die STM32 einfach mehr "rohe Leistung", d.h. mehr Flash/RAM-Speicher und höhere Taktfrequenzen. 
 
'''Folgerung''': Die Programmierung in Hochsprachen ist '''bequemer als bei 8-Bittern''', denn man muss sich einfach weniger Gedanken machen, ob der Compiler ein Programm nun effizent umsetzen kann (kann man natürlich trotzdem machen, um noch mehr Leistung "herauszuquetschen", wenn man will).

= Weitere Randbedingungen für die Entscheidung=

Der wichtige Punkt, der oftmals auch vergessen wird: die Beschaffbarkeit. Wenn jemand einen Renesas M16C oder Fujitsu empfiehlt, dann sucht man erst mal und findet nur wenige vereinzelte die man privat kaufen kann.

Oder auch die Unterstützung im Internet - ist bei einigen Exoten spärlich. Dieses Forum bietet die beste Hilfe für [[AVR]], PIC, [[STM32]] und [[MSP430]].

Andere Prozessoren sind schon sehr alt, bzw. nicht mehr modern da deren Peripherie zum Teil doch recht eingeschränkte Funktionalität bietet. z.B. viele 8051 Typen oder PIC16. Die mögen für Mini-Anwenungen gut sein, aber wer will den schon gerne sich extra für eine Kleinanwendung mit einem kleinen µC auseinandersetzen, wenn er schon einen STM32 kennt, mit dem er alles machen kann (und sich bereits gute Funktionen geschrieben hat)?

Daher mein Resümee: wer nicht gerade auf den Kopf gefallen ist, der kann getrost mit einem STM32 starten. Ein [http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419?s_searchtype=keyword STM32F4DISCOVERY] Board kostet nur ca. 20 EUR - und mehr muss für den ersten Start nicht investiert werden - wenn es doch zu komplex sein sollte gibt es hier im Forum auch Hilfe oder man nimmt erst mal ein "Arduino". Jedenfalls sind diese 20 EUR wirklich keine große Investition.

= Weblinks, Foren, Communities, Tutorials =
* [[STM32]] Hauptartikel, [http://www.mikrocontroller.net/articles/STM32#Weblinks.2C_Foren.2C_Communities.2C_Tutorials dortige Linksammlung]
* [http://www.mikrocontroller.net/topic/319328 Diskussion zum Artikel]

<references/>
[[Kategorie:ARM]]
[[Kategorie:STM32| ]]

Diskussion:STM32 für Einsteiger

2013-12-30T16:45:26Z

Haku: Die Seite wurde neu angelegt: „= Speicher... = RAM und I/O liegen bei den AVR im gleichen Adressbereich. --~~~~“

= Speicher... =
RAM und I/O liegen bei den AVR im gleichen Adressbereich. --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 17:45, 30. Dez. 2013 (CET)

STM32 für Einsteiger

2013-12-30T16:45:04Z

Haku: Etwas ergänzt.

Immer wiederkehrend hier im Forum "Mit welchem Mikrocontroller anfangen?". Es gibt eine große Auswahl und eben so viele Empfehlungen. In diesem Artikel soll zu erst geholfen werden ob ein STM32-Prozessor mit Cortex-M3/M4 Kern überhaupt der Richtige für den Start ist.
Nicht für jeden ist der STM32 zu empfehlen, denn die Anforderungen und Wünsche die man realisieren möchte, sowie die eigenen Fähigkeiten sind verschieden.

Es werden meist die Prozessoren AVR, PIC, Arduino, MSP430 und STM32 empfohlen. Seltener auch 8051, LPC und M16C. Alle haben Vorzüge und ebenso auch Nachteile.

= Eigene Fähigkeiten und Wünsche =

Dieser Artikel geht davon aus, dass bereits Elektronik Kenntnisse vorhanden sind. Wenn nicht dann sollte man erst einmal den Artikel "[[Absolute Beginner]]" durcharbeiten, sowie die anderen Artikel aus der Kategorie "[http://www.mikrocontroller.net/articles/Kategorie:Grundlagen Grundlagen]"

Zu erst einmal die Randbedingungen, mit der man sich selbst zu erst einmal einschätzen sollte:
{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Fähigkeit || Empfehlung [[STM32]] || Empfehlung [[AVR]] || Empfehlung PIC || Empfehlung [[MSP430]] || Empfehlung Arduino
|-
| Neueinsteiger, kaum Elektronikkenntnisse, noch nie programmiert || align="center"|O || align="center"|O [http://www.rn-wissen.de/index.php/AVR-Einstieg_leicht_gemacht] [http://www.avr-asm-tutorial.net/avr_de/] || align="center"|O [http://www.sprut.de/] || align="center"|O || align="center"|x
|-
| Wunsch ist SD-Card oder Grafik-Display || align="center"|x || align="center"|x || align="center"|x [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537999] [http://www.microchip.com/pagehandler/en-us/technology/graphics/] || align="center"|x || align="center"|x
|-
| Wunsch ist TCP/IP Netzwerk oder Kamera|| align="center"|x || align="center"|O || align="center"|x [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505&param=en535724] || align="center"|O || align="center"|O
|-
| Möchte die Erkenntnisse beruflich nutzen|| align="center"|x || align="center"|x || align="center"|x || align="center"|x || align="center"|-
|-
| Strom sparende Anwendungen|| align="center"|O || align="center"|x [http://www.atmel.com/technologies/lowpower/default.aspx] || align="center"|x [http://www.microchip.com/pagehandler/en-us/technology/xlp/] || align="center"|x || align="center"|-
|-
| Experimentieren mit Multithreading, RTOS, Schedulern || align="center"|x || align="center"|O [http://www.freertos.org/a00098.html] [http://www.femtoos.org/] || align="center"|O [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en531543&redirects=rtos] || align="center"|- || align="center"|-
|-
| Große, komplex strukturierte Programme || align="center"|x || align="center"|- || align="center"|O || align="center"|O || align="center"|-
|-
| Sehr viel PWM mit komplexem Timing || align="center"|x || align="center"|- || align="center"|O || align="center"|O || align="center"|-
|-
| Deutschsprachige Community || align="center"|O || align="center"|x || align="center"|O || align="center"|- || align="center"|x
|}
* x = ja
* O = Teilweise, Einschränkungen
* - = nicht empfohlen
* ? = Bitte ergänzen

Nur um nicht zu verwirren, auch wenn Teile "nicht empfohlen" sind, heißt dass nicht dass es mit dem Prozessor nicht geht, vielmehr dass es mehr Aufwand ist das zu realisieren oder mehr Einschränkungen hat.

= Unwichtige Randbedingungen =

Oftmals werden fälschlicherweise Argumente für oder gegen eine µC-Familie ausgesprochen, die in der Praxis '''zum Einstieg''' (bei konkreten Anwendungen kann das anders aussehen) eher unwichtig sind.

* Spannungsversorgung 3,3V / 5V
* 8 (z.B. [[AVR]]), 16 (z.B. [[MSP430]]) oder 32 (z.B. [[STM32]]) Bit
* Interrupt System mit mehr oder weniger Features
* Programmiersprache (Assembler, Basic, C, C++, Pascal)
* Assembler verstehen (Sollte nur theoretisch verstanden werden, ein Programm sollte in einer Hochsprache geschrieben sein)
* DIL Gehäuse - steckbretttauglich (STM32-Prozessoren gibt es auch fertig gelötet auf einem steckbretttauglichen Board zum zehnfachen Preis vergleichbarer DIL Mikrocontroller)
* Programmieradapter
* zu 90% reicht doch ein kleiner Prozessor ([[AVR]]/PIC) - und für die restlichen kann man immer noch einen großen nehmen. Warum also nicht gleich einen großen nehmen?

= Kosten =

Grobe Abschätzung was das alles denn kosten wird. Hier sind nur einige Beispiele gezeigt.

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Board || [[STM32]] || [[AVR]] || PIC18/24/32 || [[MSP430]] || Arduino
|-
| Demo-Board || align="center"|[http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419] 9..20€ (incl. Programmieradapter und Debugger) || align="center"|5..500€, z.B. Arduino || align="center"| [http://www.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=Starter%20Kits&mid=1&lmid=610 durchschnittlich 18€ .. 50€] || align="center"|[http://www.ti.com/tool/msp-exp430fr5739] ~35€ || align="center"|20€
|-
| Steckbrettaugliches Board || align="center"| s.o. oder [http://re.reworld.eu/de/produkte/s64dil-405/index.htm S64DIL-405] 30€ || align="center"|2-5€ als einzelner IC || align="center"|2-5€ als einzelner IC || align="center"|?? || align="center"|??
|-
| Programmieradapter mit Debugger || align="center"| s.o. oder z.B [http://www.segger.com/j-link-edu.html Segger J-LINK EDU] 50€ (sehr schnell und unterstützt viele Prozessoren) || align="center"|?? || align="center"|PICkit 3 30€ [http://www.microchipdirect.com/ProductSearch.aspx?keywords=PG164130] || align="center"|z.B. Dragon 50€ || align="center"|20€ (Man muss DebugWire aktivieren)
|}

Das Demo-Board sollte ein Board sein, nicht zu teuer, um die ersten Erfahrungen zu sammeln. Wenn einem der Prozessor gefällt, so kann man später immer noch mit einem zweiten Demo-Board, z.B. mit Display aufrüsten.

Wenn man gerne mit einem Steckbrett sich die Schaltung zusammen stecken möchte, so kann man entweder die benötigten Drähte am Demo-Board anlöten oder bei z.B. [[AVR]]/[[PIC]] Prozessoren gibt es Ausführungen im DIL Gehäuse, die direkt steckbar sind.

Ein Programmieradapter sollte unbedingt auch einen Debugger beinhalten. Denn für den Start ist es ungemein hilfreich zu sehen was im Prozessor gerade geschieht. Die JTAG-Adapter für einen [[STM32]] Prozessor sind alle Debugger-Tauglich. Für einen [[AVR]] oder [[PIC]] Prozessor gibt es auch oft reine Programmer (oft Selbstbau-Lösungen über die serielle oder parallele Schnittstelle) welche den Mikrocontroller nur beschreiben können. Sinvoller sind hingegen Debugger (bspw. PIC Kit 3 [http://www.microchipdirect.com/ProductSearch.aspx?keywords=PG164130] kompatibel zu allen PIC Mikrocontrollern), die die Ausführung eines Mikrocontrollers anhalten können um die aktuelle Position im Programmcode, Variableninhalt, Register, ... auszulesen bzw. zur Laufzeit zu ändern.

Der für den [[STM32]] empfohlene Segger J-LINK EDU ist zwar nicht der günstigste (z.B. auf einem STM32F4DISCOVERY Borad ist auch einer drauf den man für andere STM32 nutzen kann) aber eines der besten, mit sehr guten Software-Tools und nutzbar für alle Prozessoren mit ARM-Kern (ARM7/9/11/... Cortex-Mx). Niemals am Werkzeug sparen und man hat viel mehr Freude bei der Arbeit.

Der "Arduino" ist kein eigenständiger Prozessor, sondern ein fertiges Board mit einer "Arduino" Programmierumgebung (und einem AVR Prozessor), extra geschaffen für Einsteiger. Allerdings ist da der Lerneffekt viel geringer da man den Prozessor mit der Arduino-Software programmiert und nicht direkt die Register.

Ein [[PIC16]] ist ein älterer 8-Bit Mikrocontroller, der durch die [[PIC18]] Reihe abgelöst wurde. Werden komplexere Anforderungen in Zukunft an den Mikrocontroller gestellt (Audio, Grafik), so sollte zu den moderneren [[PIC24]] bzw. [[dsPIC]] (16-Bit) oder gar zu [[PIC32]] (32-Bit MIPS Prozessor) gegriffen werden, wobei letzterer von der Performance vergleichbar mit den STM32 ARM-basierten Mikrocontrollern ist.

= Programmierumgebungen=

Bei den Programmierumgebungen gibt es zu allen Prozessorfamilien kostenlose und Leistungsfähige Software

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! [[STM32]] || [[AVR]] || PIC || [[MSP430]] || Arduino
|-
| align="center"|[http://www.coocox.org/CooCox_CoIDE.htm CooCox] || align="center"|Atmel-Studio || align="center"|[http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPALB X] (IDE inklusive compiler) || align="center"|?? || align="center"|arduino 1.0.5
|}

natürlich gibt es noch viele weitere (für STM32 siehe [[STM32#Programmierung]]), es sollte jedoch nur die einfachsten kostenlose (und ohne Codebegrenzung) für den ersten Einstieg gezeigt werden.

= Dokumentation=

Bevor man sich für einen Prozessor entscheidet sollte man unbedingt deren Dokumentation mal zumindest überfliegen und auch deren Errata's lesen. Nicht dass man eine Anwendung erstellen möchte und stellt hinterher fest, dass genau dieser Teil so buggy ist das er nicht genutzt werden kann.

Beim [[STM32]] hat die Dokumentation doch recht viele Seiten, viel mehr als bei einem [[AVR]] oder PIC. Dabei ist vieles eher knapp beschrieben, man muss mehr suchen als z.B. bei den AVR-Dokus, um die gewünschten Informationen zu finden. Außerdem gibt es durchaus einige Unklarheiten und Fehler/Widersprüche. Schlussendlich ist es Geschmackssache mit welcher Doku von welchem Hersteller man sich besser zurecht findet.

Bei den PICs gibt es zu jedem Mikrocontroller ein Datenblatt das die wichtigsten Informationen für den alltäglichen Gebrauch enthält. Da bestimmte Peripherie (bspw. I2C, SPI, ... ) aber sehr komplex ist und innerhalb einer Familie (PIC16/18/24/32) sich identisch verhält, gibt es zu jeder Familie die sogenannten Family-Datasheets, welche alle Module im Detail beschreiben.

Parallel zur Dokumentation sollte man sich auch die Demo-Beispiele der Hersteller anschauen, dann wird vieles gleich verständlicher.

Eine Übersicht über die Funktionen gibt es im Artikel: [[STM32]]

= Die Arbeit mit dem STM32=

Zu erst einmal SOOO groß sind die Unterschiede zwischen den einzelnen Prozessoren nicht. Alle haben Ein-/Ausgänge und um mittels einem Port-Pin eine LED ansteuern zu können muss bei jedem Prozessor der Pin erst einmal parametriert werden, egal ob das jetzt ein STM32 oder ein AVR oder ein MSP430 ist. Nur hat man bei einem STM32 doch einige Funktionen mehr, z.B. zuschaltbarer Pull-Up oder Pull-Down Widerstand und spezielle Setz-Rücksetzregister, die andere Prozessoren nicht haben, jedoch das programmieren vereinfachen.
Der Haupt-Unterschied zu den anderen Prozessoren ist, dass der [[STM32]] so viele Peripherie-Module beherbergt, dass man die einzeln immer mit einem Clock aktivieren muss, denn damit lässt sich viel Strom sparen.

Und mal ganz ehrlich die Diskussion welcher µc einfacher zu konfigurieren ist, ist doch absoluter Unsinn. Der Weg ist immer der Gleiche:
*1. Blick ins Datenblatt welche Register für diese Funktion benötigt werden.
*2. Werte ermitteln die in die Register eingetragen werden.
*3. Werte ins Register schreiben. Da machte es GAR KEINEN UNTERSCHIED ob es ein [[AVR]], 8051/2, ARM,...... ist.

Stimmt schon es gibt Unterschiede. Die Register haben anderen Namen, andere Adressen, andere Bitbedeutungen,...
Aber es steht doch alles im Datenblatt. Und ob ich jetzt einen [[AVR]] oder einen ARM das erste mal vor mir liegen hab. Ich brauch in allen Fällen die oben beschriebenen Schritte.

Das Interruptsystem ist bei einem STM32 zusätzlich priorisiert, damit kann man festlegen welcher Interrupt vorrangig bearbeitet wird. Die Prioritätenvergabe ist auch kein Hexenwerk.

Zu allen Prozessoren liefern die jeweiligen Hersteller umfangreiche Demo-Codes und Libraries mit. Meist sind alle in C geschrieben, daher sollte auch die Programmiersprache C verwendet werden. Vor allem auch wenn man berufliche Absichten verfolgt.

Und wenn man einen STM32 kann, dann ist ein Umstieg auf einen LPC17xx (NXP) oder andere Hersteller überhaupt kein Problem, denn die bieten ebenfalls Prozessoren mit Cortex-M3 Kern und man kann diese mit der gleichen Programmierumgebung programmieren. Somit ist man nicht zwingend Herstellerabhängig.

Mit einem STM32 kann man als Hobby-Baster und Professionell nahezu alle Anwendungen realisieren. Der hat genügend RAM und FLASH Speicher und auch genügen Geschwindigkeit. Viele Gehäuse-Varianten um kleine bis hin zu größere Geräte zu erstellen. Viele Schnittstellen, sind im Artikel [[STM32]] beschrieben.

Der einzige Nachteil beim STM32: man muss etwas mehr lesen, da eine Peripherie doch viel mehr Funktionalität hat. Ansonsten kenne ich nicht wirklich einen Grund warum man als Neueinsteiger keinen STM32 nehmen sollte.

= Programmiersprachen =
* Wie bei vielen anderen Controllern wird beim STM32 auch hauptsächlich C und C++ verwendet. Kennen sollte man die Programmiersprache C schon, wenn man davon noch keine Ahnung hat dann sollte man erst mal mittels einem Tutorial auf einem PC ein Konsoleprogramm schreiben, sodass man es einigermaßen kennen lernt. Hier im Forum gibt es ebenfalls Artikel dazu. Zielt man auf die (spätere) Anwendung in der Industrie, sollte aufgrund der Verbreitung auf jeden Fall C (oder C++) gewählt werden; außerdem sind die meisten verfügbaren Libraries in C geschrieben.
* Assembler sollte man nur grob verstehen, Details wie ein Befehl arbeitet ist unwichtig. Selbst wenn man die Zyklen für einen Funktionsaufruf wissen will, so bietet der STM32 (Cortex-M3) einen Cycle-Counter den man auslesen kann; durch die komplexere Pipeline und Cache-Effekte sind die Laufzeiten allerdings nicht genau vorhersehbar. Wird zyklengenause Timing benötigt, sollten Timer verwendet werden - davon hat der STM32 genug.

Der 32bit-Adressraum, der RAM, Flash, I/O-Register vereinheitlicht ansprechen kann (im Gegensatz zu z.B. AVR) ist ideal für eine Verwendung durch Hochsprachen; bei Pointern muss keine zusätzliche Information verwaltet werden, in welche Art Speicher sie zeigen. Die Adresse gibt dies eindeutig an (es gibt nur '''eine''' Adresse 42, und nicht 2 wie bei es für Harvard-Architekturen eigentlich typisch ist (Programmspeicher und Datenspeicher, also z.B. Flash und RAM/IO) und die Hardware spricht automatisch den richtigen Speicher an. Die Möglichkeiten zur Offset-Adressierung, der Barrel-Shifter, Divsions-Einheit, die FPU (bei STM32F4), Interrupt-Modell etc. begünstigen ebenfalls die Erzeugung effizienteren Codes. Außerdem haben die STM32 einfach mehr "rohe Leistung", d.h. mehr Flash/RAM-Speicher und höhere Taktfrequenzen. 
 
'''Folgerung''': Die Programmierung in Hochsprachen ist '''bequemer als bei 8-Bittern''', denn man muss sich einfach weniger Gedanken machen, ob der Compiler ein Programm nun effizent umsetzen kann (kann man natürlich trotzdem machen, um noch mehr Leistung "herauszuquetschen", wenn man will).

= Weitere Randbedingungen für die Entscheidung=

Der wichtige Punkt, der oftmals auch vergessen wird: die Beschaffbarkeit. Wenn jemand einen Renesas M16C oder Fujitsu empfiehlt, dann sucht man erst mal und findet nur wenige vereinzelte die man privat kaufen kann.

Oder auch die Unterstützung im Internet - ist bei einigen Exoten spärlich. Dieses Forum bietet die beste Hilfe für [[AVR]], PIC, [[STM32]] und [[MSP430]].

Andere Prozessoren sind schon sehr alt, bzw. nicht mehr modern da deren Peripherie zum Teil doch recht eingeschränkte Funktionalität bietet. z.B. viele 8051 Typen oder PIC16. Die mögen für Mini-Anwenungen gut sein, aber wer will den schon gerne sich extra für eine Kleinanwendung mit einem kleinen µC auseinandersetzen, wenn er schon einen STM32 kennt, mit dem er alles machen kann (und sich bereits gute Funktionen geschrieben hat)?

Daher mein Resümee: wer nicht gerade auf den Kopf gefallen ist, der kann getrost mit einem STM32 starten. Ein [http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419?s_searchtype=keyword STM32F4DISCOVERY] Board kostet nur ca. 20 EUR - und mehr muss für den ersten Start nicht investiert werden - wenn es doch zu komplex sein sollte gibt es hier im Forum auch Hilfe oder man nimmt erst mal ein "Arduino". Jedenfalls sind diese 20 EUR wirklich keine große Investition.

= Weblinks, Foren, Communities, Tutorials =
* [[STM32]] Hauptartikel, [http://www.mikrocontroller.net/articles/STM32#Weblinks.2C_Foren.2C_Communities.2C_Tutorials dortige Linksammlung]
* [http://www.mikrocontroller.net/topic/319328 Diskussion zum Artikel]

<references/>
[[Kategorie:ARM]]
[[Kategorie:STM32| ]]

Benutzer:Haku/Für:Assembler

2013-12-29T14:02:34Z

Haku: Die Seite wurde neu angelegt: „= Darum Assembler! = Ja, Assembler. Total altmodisch, umständlich und uncool. Es folgen einige Beispiele, weshalb ich persönlich der festen Überzeugung bin…“

= Darum Assembler! =
Ja, Assembler. Total altmodisch, umständlich und uncool.

Es folgen einige Beispiele, weshalb ich persönlich der festen Überzeugung bin, dass jeder, der ernsthaft mit Mikrocontrollern leben möchte, Assembler verstehen sollte.

== Befehlssatz ==
Gerade auf Mikroprozessoren hat man nicht beliebig viele Ressourcen und Rechenzeit, wie das mittlerweile auf jedem PC der Fall ist. Mit einer Hochsprache hat man schnell und elegant etwas programmiert, was für die Zielplattform aber völlig ungeeignet ist. Da hilft es, wenn man seinen Prozessor verstanden hat und sich in etwa vorstellen kann, welche Möglichkeiten der Compiler hat, um den Code zu übersetzen. Dazu muss man aber den Assembler verstanden haben.

Beispiele?

Auf dem AVR wird folgendes ziemlich umständlich:
<syntaxhighlight lang="c">
int schieben(int x, int d) {
return x << d;
}
</syntaxhighlight>

Oder, immer wieder gerne gesehen:
<syntaxhighlight lang="c">
#include <util/delay.h>
/* ... */
void warten(int sek) {
_delay_ms(1000 * sek);
}
</syntaxhighlight>

== Nebenläufigkeit ==
Richtig Spaß machen Mikroprozessoren erst mit Interrupts. Vorallem, wenn man dann Daten zwischen dem Hauptprogramm (''main-Schleife'') und den Interrupts austauscht. Man sollte dann wissen, was im Assembly passiert. Andernfalls handelt man sich jede Menge Unterhaltung ein, wenn es dann irgendwann zu ganz sporadischen (also auch ganz schlecht reproduzierbaren) Fehlern kommt.

Beispiel?

Dieses knallt auf dem AVR ''sehr sporadisch'':
<syntaxhighlight lang="c">
volatile int zaehler;
ISR(...) {
zaehler++;
}

int main() {
/* ... */
if (zaehler == 1000) {
/* Autsch */
}
}
</syntaxhighlight>

== Read-modify-write ==
Read-modify-write ist richtig schön im Zusammenspiel mit Interrupts.

Beispiel?

Folgendes funktioniert völlig unproblematisch und wackelt an zwei Pins eines ATmega128:
<syntaxhighlight lang="c">
volatile int zaehler;
ISR(/* ... */) {
static int flag = 0;

flag = !flag;
if (flag)
PORTE |= _BV(PE1);
else
PORTE &= ~_BV(PE1);
}

int main() {
for (;;) {
PORTE |= _BV(PE0);
PORTE &= ~_BV(PE0);
}
}
</syntaxhighlight>

Folgendes dagegen geht, wieder auf dem ATmega128, ''sehr sporadisch'' in die Hose:
<syntaxhighlight lang="c">
volatile int zaehler;
ISR(/* ... */) {
static int flag = 0;

flag = !flag;
if (flag)
PORTF |= _BV(PF1);
else
PORTF &= ~_BV(PF1);
}

int main() {
for (;;) {
PORTF |= _BV(PF0);
PORTF &= ~_BV(PF0);
}
}
</syntaxhighlight>

C-Präprozessor

2013-11-25T18:10:24Z

Haku: /* #define */ Inkrement

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.

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

Diskussion:Entprellung

2013-11-24T08:09:28Z

Haku: /* Wechselschalter ohne Flip-Flop ohne Schmitt-Trigger? */

== dat Bildchen ==

Warum muß das "Prellen" einer Taste eigentlich immer als sauberer Rechteck dargestellt werden? Meiner Meinung nach verwirrt das unsichere Neulinge. -- [[Benutzer:Guido|Guido]] 10:44, 9. Jul 2005 (CEST)

Für die Auswertung in der Logik ist ja das Wechselspiel zwischen Nullen und Einsen so wie dargestellt das Problem. Trotzdem hast du natürlich recht, als das die Ursache, also die Spannung am Schalter ganz anderes aussehen kann, bspw. langsames Ansteigen an Nicht-Schmitt-Trigger-Eingängen. Ich unterstütze deine Bemühungen, neue Bildchen einzufügen ;-) --[[Benutzer:Yahp|Yahp]] 13:19, 9. Jul 2005 (CEST)

Unkreativ und lustlos, aber vielleicht schon mal was, bis jemand mal mit einem Speicheroszi einen Originalpreller abschießen kann:

[[Bild:Entprellen1a.png]]

-- [[Benutzer:Guido|Guido]] 17:19, 9. Jul 2005 (CEST)

:Hallo Guido, ich bin für das Einbinden des Bildes im Artikel. Gegenstimmen? Nein. Gut, machen wir es so :-) --[[Benutzer:Yahp|Yahp]] 01:13, 11. Jul 2005 (CEST)

:: Werde das nachholen! [[Spezial:Beiträge/0:0:0:FFFF:87:166:185:17|0:0:0:FFFF:87:166:185:17]] 16:20, 19. Jan. 2013 (UTC)

:: Ich finde das Bild sehr verwirrend. Das blaue ist die Spannung vor dem RC ? Das ist aber genau ein Komparator ohne Hyterese

== Fehler in Quellcode? ==
<c>
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 );
}
</c>

-> Fehlt da nicht ein sei()?

-- [http://www.reintechnisch.de Winfried Mueller] 18.02.07

sei() wird in der aufgerufenen get_key_press() als deren Seiteneffekt ausgeführt und braucht an dieser Stelle nicht zusätzlich gemacht zu werden. Zu solchen Seiteneffekten siehe auch [[AVR-GCC-Tutorial#Interrupts mit dem AVR GCC Compiler (WinAVR)]]. [[Benutzer:Stefan|Stefan]] 13:31, 12. Jun 2007 (CEST)

== Neue Funktion "Warteschleifenvariante mit Maske und Pointer" ==

Guten Tag

Ich habe eine Funktion zum Entprellen eingefügt. Diese ist recht schnell (bei 0815-Tastern etwa 1-3ms) und man kann alle Pins eines Ports gleichzeitig verarbeiten.

Ich habe diese Funktion jetzt etwa ein halbes Jahr im Einsatz und habe nur in Ausnahmefällen noch ein Prellen auf meinen Schaltern.

Grüsse

Christian Riggenbach

== Komfortroutine ==
Die Komfortroutine hat inzwischen einen Haufen Fehler. Im Original sind diese noch nicht vorhanden:
[http://www.mikrocontroller.net/attachment/highlight/16197]
Werde mich bei Gelegenheit mal dranmachen. [[Benutzer:Esko|Esko]] 21:37, 12. Nov. 2008 (CET)

== Entprellroutine nach Peter Danegger ==

Im Text hatte sich ein Fehler eingeschlichen. Die gezeigte Routine betreibt keine 4-fach Abtastung, sondern 2-fach Abtastung. Dieser Beitrag klärt die Verwechslung auf:
[http://www.mikrocontroller.net/topic/6490#962294]

Soweit ich das im Forum gesehen hab, wurde für die Entprellung bei Peter Danegger nicht nachgefragt, ob er mit einer Veröffentlichung im Wiki einverstanden ist. (Im Gegensatz zur Zeit ohne RTC.) Das sollte man zumindest noch nachholen, denke ich. --[[Benutzer:80.108.115.184|80.108.115.184]] 19:15, 25. Apr 2005 (CEST)sym

: Sollte wohl erledgt sein!

== Millerentprellung ==
Ich habe das eben eingesetzt. Gefunden auf der Millerwebseite.

== Wechselschalter ohne Flip-Flop ohne Schmitt-Trigger? ==

In dem Abschnitt "Wechselschalter ohne Flip-Flop" wird ein Wechselschalter mit einem einfachen Tiefpass entprellt. In dem Abschnitt "Einfacher Taster" wird explizit darauf hingewiesen, dass dem Tiefpass ein Schmitt-Trigger folgen muss. Muss dieser nicht auch in der Schaltung mit Wechselschalter verwendet werden?
: Ratsam ist das, ja. Insbesondere, wenn man damit CMOS ansteuern möchte. Denn hinter dem RC-Glied entsteht eben die typische Lade-/Entladekurve. --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 09:09, 24. Nov. 2013 (CET)

Diskussion:Schnelle 32Bit-Integer Sinusberechnung

2013-10-29T18:02:35Z

Haku: /* Kommentar des Autors */

== Fragen und Probleme mit dem Code ==

Mit dem aktuellen Code ergeben sich einige Probleme:

* Je nach Plattform ist int lediglich 16 Bits breit: Der C-Standard garantiert mindestens 16 Bits für int, mehr jedoch nicht. Lösund wäre die Verwendung von stdin.h von C99 und Vermeidung von Überläufen wie sie momentan auftreten.
* Falls die Architektur nicht über Divisionsbefehle verfügt (Beispiel: [[AVR]]), ist die Berechnung keineswegs als "schnell" zu bezeichnen.
* Die angegebene Genauigkeit von 0.1% entspricht 10 Binärstellen. Es stellt sich die Frage, warum dafür überhaupt 32-Bit Arithmetik verwendet wird.
* Die Eingabe erfolgt in Grad, es sind also nur 91 Eingaben (0°...90°) möglich falls man sich auf den ersten Quadranten beschränkt. Dies erfordert eine Rundung der Eingabe auf ganze Grade, was einen Rundungsfehler von bis zu pi/360 bedingt. Dies entspricht einer Genauigkeit von nur 7 Binärstellen, was schneller, einfacher und kürzer durch eine 91 Byte große Lookup-Table bewerkstelligt werden kann.

--[[Benutzer:Gjlayde|Gjlayde]] ([[Benutzer Diskussion:Gjlayde|Diskussion]]) 11:15, 28. Okt. 2013 (CET)

== Optimierung ==
Wenn man 16 Stützstellen nimmt, kann die /10 Division durch eine Schiebeoperation optimiert werden.

: Es verbleiben aber immer noch Divisionen bzw. Modulo durch 360 und 90. --[[Benutzer:Gjlayde|Gjlayde]] ([[Benutzer Diskussion:Gjlayde|Diskussion]]) 13:59, 28. Okt. 2013 (CET)
:: Ginge mit INT und Abziehen direkter und einfacher. [[Spezial:Beiträge/87.166.187.53|87.166.187.53]] 21:05, 28. Okt. 2013 (CET)

:: Wenn nicht rad, dann könnte man anstatt in einer 360° Welt auch gleich in einer 256 oder 1024 Einheiten-Welt arbeiten. 07:02, 29. Okt. 2013 (CET)

== Kommentar des Autors ==

Zugegeben, ich arbeite nur noch mit 32Bit-Arm Controllern und habe nicht über eine 8Bit Optimierung oder die Reduktion von Divisionen nachgedacht. Da gibt es sicher noch ein paar Optimierungsmöglichkeiten. Wichtig war mir, das Verständnis für einen so einfachen Algorithmus mit nur 188Byte code (CortexM4) zu erzeugen.

'''Vorschlag:''' Optimiert das doch für 8Bit und mit Bitschift-Divisionen und wir bieten das als zusätzlichen Download mit an.

MPetschke

: Das ist ziemlich witzlos, weil schon jede Lookup-Tabelle für 8 Bit (256 Stützstellen) kleiner sein dürfte, als irgendwelche Berechnungen... --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 11:27, 29. Okt. 2013 (CET)

: 256 Stützstellen sind garantiert größer als der vorliegende code. MPetschke

:: Vertu dich da mal nicht. Ist immerhin ein 8-Bitter ohne Hardware-Dividierer. Und dann ist die Rechenzeit noch nicht berücksichtigt. Schon allein die Ganzzahl-Divisionsroutine frisst etwa 80 Bytes. Dazu kommen die je zehn Stützstellen für Sinus und Cosinus mit insgesamt 40 Bytes. Die Routine selbst braucht nochmals 192 Bytes. Macht insgesamt also rund 300 Bytes, bei starker Optimierung (-O2, avr-gcc 4.7.2). Spart bei ganzzahligen Winkeln also eigentlich quasi fast nichts und braucht noch viel mehr Rechenzeit als eine Tabelle mit 360 Einträgen. --[[Benutzer:Haku|Haku]] ([[Benutzer Diskussion:Haku|Diskussion]]) 19:02, 29. Okt. 2013 (CET)

Diskussion:Schnelle 32Bit-Integer Sinusberechnung

2013-10-29T10:27:05Z

Haku: /* Kommentar des Autors */

Eagle-Wishlist

2013-10-23T09:47:13Z

Haku: erledigte Punkte aufgesammelt

Auf dieser Seite können Wünsche zur Erweiterung der Funktionen des Leiterplatten CAD Programms Cadsoft EAGLE eingetragen werden. Es ist keine offizelle Wunschliste von Cadsoft und es ist nicht bekannt, ob Cadsoft-Mitarbeiter diese Seite regelmässig sichten. Cadsoft sollte sicherheitshalber regelmäßig angeschrieben werden, damit diese Liste nicht in Vergessenheit gerät.

Damit sich die beliebtesten Wünsche herauskristallisieren, macht jeder einfach einen virtuellen Strich dahinter: | (Windows: ALT-GR Taste und < Taste drücken, Mac OS X: Alt-Taste und 7 Taste drücken). Alle fünf Striche (|||||) bitte immer ein Leerzeichen einfügen.

Neue Wünsche einfügen darf und soll natürlich auch jeder. Einfach ganz viele Striche auf einmal hinter einem Wunsch einzufügen ist zwecklos. Das erkennt man in der History, und es gibt viele Leute, die diese Seite überwachen...

Ja, die Einleitung ist von der Reichelt-Wishlist geklaut. Existenzberechtigung für diese Seite: Farnell will Eagle verbessern. Siehe [http://de.farnell.com/jsp/bespoke/bespoke2.jsp?ICID=i-7706-00001001&bespokepage=farnell/de/design-link/cadsoft.jsp]

== Programmfunktionen ==

=== Control Panel ===

* In Bibliothek: Bei Klick auf ein Device soll das Fenster an der aktuellen Position stehenbleiben ||
* In Bibliothek: Bildposition vom Symbol und Package soll fixed sein (mitscrollen), bei großen Device-Kollektionen vorteilhaft ||
* Möglichkeit, für unterschiedliche Programmversionen auch unterschiedliche Projektverzeichnisse zu verwenden. |
* Backupdateien in Unterverzeichnisse packen ||||| |||
* Raster-/Grid-Größe für X und Y Achse getrennt angeben |
* Möglichkeit einbauen um alle Bibliotheken INKL. Unterverzeichnisse zuladen.

=== Schaltplan-Editor ===
* Bibliotheken aus dem Download Bereich in die Releases mit aufnehmen ||||| || | 8
* Richtungsabhängige Labels: (3erlei) verschiedene Labels mit denen zusätzlich zum Netznamen die Signalrichtung (Eingang, Ausgang, Bidirektional) visualisiert werden kann ||||| ||||| | 11
* Farbige XREFs → Das Netz dazu in der gleichen Farbe ||||| 5
* Eigenen 'Lagerbestand' mitverwalten, sodass beim Zeichnen von Plänen direkt nur Lagerteile verbaut werden (nützlich bei diesen ganzen SMD-Varianten) ||||| |||| 9
* "hierarchisches Design" von identisch aufgebauten Unterbaugruppen, sprich Subcomponenten mit definierten Input/Output-Signalen aus z.B. einer speziellen hierarchy.lib. Diese kann dann ja im gleichen Verzeichnis wieder als Schematic abgelegt werden. Mit dazugehöriger Board-Datei läßt sich dann auch das Layout clonen. ||||| ||||| ||||| || 17
* Drucken: neue Option "Automatisch drehen", um bei mehrseitigen Plänen mit wechselnder Seitenorientierung automatisch auszurichten ||||| 5
* Tastatur-/Maus-Bedienkonzept: z.B. Move, Copy etc. alle auf Tasten der linken Tastaturhälfte (bzw. auf der rechten für Linkshänder) und zwar ohne Ctrl/Shift etc. so daß man zügig arbeiten kann, ohne ständig mit der Maus umschalten zu müssen. ||||| |||| 9
* Der relative, beliebig setzbare Ursprung sollte vom absoluten zu unterscheiden sein (andere Farbe...) ||| 3
* Bauteilwerte direkt im ADD-Befehl festlegbar machen (-> Standardbauteile im Textmenü) ||| 3
* Der "Gruppenauswahlrahmen" sollte sich bei gedrückter Maustaste immer aufziehen lassen, nicht erst nach Druck auf Group. (Im Board auch) ||||| | 6
* Ein markiertes Bauteil/e sollte sich einfach mit Druck auf ENTF löschen lassen. |||| 4

=== Board-Editor ===
* MOVE mit einstellbaren Freiheitsgraden. Beispielsweise, um parallel (nur horizontal/vertikal) oder diagonal zu verschieben | 1
* Mathematik-Funktionen in Eingabefeldern (+ plus, - minus, * mal, / geteilt und () Klammern) z.B.: 375mil+(13,6mm/2) || 2
* Kacheln-Funktion im Drucken Dialog ||||| ||||| | 11
* Netznamen in verlegten Leiterbahnen einblenden<ref>Wird z. B. im AltiumDesigner so gemacht. Abstand und Größe der Beschriftung erfolgt je nach Zoom-Stufe.</ref> ||||| ||||| 10
* Die Auswahl von Bauteilen sperren, die mit dem aktuellen Werkzeug nicht bearbeitet können<ref>Wenn zB eine Leiterbahn durch einen Bauteilmittelpunkt läuft und man mit Ripup auf den Mittelpunkt klickt, will man natürlich die Leiterbahn auflösen. Ripup lässt sich ja nicht auf Bauteile anwenden. Warum muss man also mit linker Maustaste wählen, auf was man Ripup anwenden will?</ref> ||||| || 7
* Routing mit Walkaround/Push/Hug&Push Funktionen (Hindernisse automatisch umrouten beim FollowMe) ||||| || 7
* Parameter eines Objektes (Via, Track,..) per Doppelklick-Option bearbeitbar ||||| ||||| ||||| 15
* Thermal Vias für unterschiedliche Gehäuse einzeln anpassbar machen ||||| 5
* Padstack frei definierbar || 2
* Direkte Implementierung von EAGLE 3D ||||| ||||| ||||| ||||| ||||| ||| 28
* Messung der Leiterbahnlänge <ref>Die Messung der Länge einer Leiterbahn sollte zwischen zwei beliebigen Segmenten möglich sein. Man könnte dafür Start- und Endsegment markieren.</ref> ||||| ||||| ||||| ||||| ||||| ||||| 30
* Weitere Standardgeometrien (Spiralen, Heaxagon u.ä.) ||||| ||||| || 12
* Andere Farben für Versorgungsspannungen definierbar machen ||||| ||||| |||| ||| 18
* Impedanzkontrolle von Leiterbahnen ||||| ||||| ||||| ||||| || 22
* Board im Editor drehen (90°-Schritte) und Umdrehen (Oberseite/Unterseite) ||||| ||||| ||||| || 17
* Kopieren von Leiterbahnen/Gruppen ||||| ||||| | 11
* Online (Echtzeit) DRC ||||| ||||| ||||| 15
* Direkte Integration von Teardrops bzw SnowMans ||||| | 6
* Chamfered edge (Anfasungen bei T-Leiterbahnverbindungen) | 1
* selektives Ratsnest (nicht mit dem Bauteil verbundene Luftlinien beim Plazieren ausblenden) ||||| || 7
* dynamisches Ratsnest (Luftlinien des Bauteils beim Plazieren zum nächstgelegenen Pin verbinden) ||||| ||||| ||||| | 16
* Benannte Gruppen in Editor und Schaltplan z. B. analog1 oder power zum einfachen plazieren || 2
* Dxf Drag and Drop Mechanische Teile direkt in eagle boards und libs ziehen | 1
* Parametrische Library-Erstellung über Textfile | 1
* Iges / Step Export. 3D Darstellung für Mcad exportieren |||| 4
* 3DScanner Import. Da eine fertige Leiterplatte die Lageinformationen aller Bauteile hat, wird über einen 3D-Scanner die Höheninformationen der Bauteile eingelesen und in die Bibliothek übertragen. || 2
* Direkte, einfache Nutzung von Layout- und Schaltplanmodulen | 1
* Im Layouteditor Bauteile konsistent platzieren sowie kopieren können || 2
* DRC: Bestückungsdruck auf PADs, SMDs oder VIAs ||| 3
* DRC: Warnung / Meldung über nicht geroutete Netze / bestehende Luftlinien ||||| ||||| ||||| ||||| 20
* Layer werden sofort aktiviert/deaktiviert ohne erst "Übernehmen" anklicken zu müssen ||||| |||| 9
* Wert von "Alle Packages anzeigen" im change technology-Dialog merken | 1
* Busse werden automatisch umbenannt falls Nets umbenannt werden ||| 3
* Unrouted Layer nur für aktivertes Bauteil (oder Bereich) anzeigen lassen | 1
* Schrift-Ausrichtung: alle vier Richtungen zulassen, anstatt nur nach rechts oder oben. Dafür Ausrichtungen links/zentriert/rechts zulassen || 2
* unsplit-Funktion: einen Knick aus einem Wire löschen (z.B. als Shift-optimize) ||||| ||||| 10
* Busse (oder mehrere parallele Leitungen gleichzeitig) verlegen (wo es Sinn macht) ||||| | 6
* "clonen" von Leiterbahnen-Routings von einer Baugruppe zu einer anderen ||||| 5
* Ausblenden von Bauelementen im Layouteditor. Beispielsweise nach einer bestimmten Buchse Stecker Kombination im Schaltplan. Wäre hilfreich um Bauelemente im Gehäuse darzustelle | 1
* "Lochrastermodus" um noch einfacher Pläne für Lochrasterplatinen zu erstellen ||||| 5
* Symmetrierfunktion, um Bauteile automatisch symmetrisch um eine Achse oder Punkt anordnen zu können || 2
* automatische Platzierung von Bauteilen im Board ||||| ||| 8
* Der relative, beliebig setzbare Ursprung sollte vom absoluten zu unterscheiden sein (ander Farbe...) ||| 3
* Offset Routing - Gleichzeitiges verlegen von paralell verlaufenden Leiterbahnen |1
* Polygone gegen Verschieben schützen können (lock) || 2
* In Bauteilinfo die zugehörige Schaltplanseitennummer anzeigen || 2
* In Bauteilinfo die auch das DEVICE anzeigen (wie im Schaltplan) | 1
* Beim DRC einen Hinweis geben, wenn der Fehler durch Netzklassenregeln bedingt ist || 2
* Über Rechtsklickmenü eine ausgewählte Gruppe ins Raster setzen | 1
* die Airwires zeigen auf das Zentrum eines SMD Pads, das meist nicht auf dem raster liegt. Besser währe, wenn ein Bereich innerhalb des Pads als zulässiges Airwire-Ziel akzeptiert wird. Oft sind kleine Leiterbahnschnippsel übrig, mit denen man kämpfen muss. Pad ist eigentlich kontaktiert, aber man hat das zentrum wieder nicht getroffen. || 2
* invertierter Text einfach über Textbefehl einfügen zu können | 1

=== Autorouter ===

* Ausführungen des Autorouters zurücksetzen (z. B. mit Ctrl + Z) ||||| ||||| ||||| ||||| ||||| || 27
* Autorouter um Autoplacer von nicht gelockten Bauteilen ergänzen ||||| | 6

=== Bibiliotheks-Editor ===

* Alle Packages zentral speichern, zB in ref-packages. Andere Libs laden dann von da das Package und verbinden das mit ihren Symbols ||||| ||||| ||||| |||| 19
* Verschiedene Symbole für ein Bauteil (Auswählbar im Schaltplaneditor) ||||| 5
* Möglichkeit Symbole einzeln zu kopieren und nicht nur als Device inkl. allen Varianten/ Packages ||||| 5
* Pin-Namen und Nummern per Smash-Befehl verschiebbar und drehbar ||| 3
* Pin-Namen und Nummern auch in Schriftgröße einstellbar || 2
* Bibliotheken ausblenden oder Favoritenliste | 1
* Pin-Namen im Symbol mit auswählbaren Alternativen versehen (bei MCUs teilweise 8fach belegt) ||| 3
* Bauteile im Device als optional kennzeichnen, damit z.B. für MCUs unterschiedliche Packages als Varianten ausgewählt werden können | 1

== Preispolitik/Sonstiges ==
* Funktionsumfang der Non-Profit Version auf Schaltplan+Board mit 2 Layern reduzieren (Autorouter und 2 Innenlagen fallen weg), dafür max. Leiterplattengröße auf Doppel-Euro erhöhen. Besser noch 320cm2 in beliebigem Format. ||||| ||||| ||||| ||||| ||||| ||||| 30
* Kostenlose Studentenversion ||||| ||||| ||||| ||||| ||||| 25
* max. Leiterplattengröße der Light-Version auf 160x100mm erhöhen. Dafür den Autorouter weglassen. ||||| ||||| ||||| ||||| ||||| || 27
* Light Version auf 2 Signal + 2 Power Lagen anheben. 2 Lagen ist nicht mehr Zeitgemäß ||||| ||||| 10
* Generell eine ordentlicher strukturierte Bibliothek. Beispielsweise Widerstandsgehäuse in unterschiedlichen Rastern ("lange Beinchen"), einheitliches Bezeichnungsschema usw. ||||| ||||| | 11
* Bibliotheken mit Sammlungen der Bestände verschiedener Lieferanten (Reichelt, Segor, Farnell) ||||| ||||| 10

== Erledigte Punkte ==
* Mehrzeilige Texte (Mehrzeilige Texte sind ab Version 6.3 möglich) |||| 4
* Neben Ckeckbox "Smds" neue Checkbox "bedrahtet", sodass diese ausgeschaltet werden können, wenn nur mit SMDs gearbeitet wird (wurde nun in die Suchfunktion übernommen) ||||| |||| 9
* Meanderstrukturen für Leiterbahnlängenausgleich ||||| ||| 8
* Standardbauteile oder Makros in "Schnellzugriff" (Symbolleiste) für den Schnellzugriff (Mit dem ''MENU''-Befehl lässt sich eine Symbolleiste erzeugen, deren Knöpfe wiederum mit beliebigen Befehlen belegt werden können, einschließlich ''ADD'' --[[Benutzer:Haku|Haku]] 08:47, 21. Feb. 2010 (UTC)) oder ''RUN''/''SCRIPT'' für Makros. |||
* 2-3 frei definierbare Layerauswahlen, die sofort per Klick bzw. Shortcut übernommen und angezeigt werden (Es gibt die ALIAS-Option für den DISPLAY-Befehl. Shortcut dann wieder mit MENU oder direkt in den Einstellungen eine Tastenkombination festlegen) || 2
* Auswahlmenü beim Kopieren von Bauteilen, damit nur einzelne Packages (z. B. nur SO16) kopiert werden können und nicht zusätzlich alle anderen Varianten (z. B. DIL16, TSSOP16, usw.) (spätestens ab 6.5.0) |||| 4
* Zusätzliches Flag für Bauteile (Bestückt / Unbestückt), damit Bestückungsvarianten erstellt werden können (Bestückungsvarianten, spätestens ab 6.5.0 verfügbar) ||||| 5
* Einem Pin im Symbol können mehrere Pins eines Packages zugewiesen werden ||||| ||| 8 - gibt es ab 6.xx
* Polygone (mit Pad-Namen) zulassen für PAD-Sonderformen ||||| ||| 8 - gibt es indirekt ab 6.x
* Aktualisierung der Programmdateien statt jedes mal im neuen Ordner zu installieren <ref>''Nichts'' anderes passiert bei Installation im ''gleichen'' Ordner. Lesen lernen... → Diskussion --[[Benutzer:Hownottobeseen|Hownottobeseen]]</ref> ||||| | 6
* Abstandsmessung (Wie in Sprint-Layout: Mit Maustaste auf Startpunk klicken, gedrückt halten und zum Endpunkt ziehen. Länge und Winkel der Strecke werden in Echtzeit angezeigt.) (Dazu benutzt man en MARK-Befehl, um den Startpunkt zu setzen. Dann werden Winkel, Abstand und x/y-Offset in Echtzeit angezeigt) ||||| ||||| ||||| ||||| ||| 23
* Suche im Bauteilkatalog nach Lieferanten-Artikelnummer (sofern gepflegt) (spätestens ab 6.5.0 kann man nach Attributen und Attributwerten suchen) ||| 3
* Routen von LVDS-Leitungspaaren (Mäander) ||||| ||||| 10

== Anmerkungen ==
Diskussion im Forum: http://www.mikrocontroller.net/topic/169171

<references/>

[[Kategorie:Eagle]]

FET

2013-10-21T11:56:12Z

Haku: /* Linearbetrieb von MOSFETs */ Trench-Fets

Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]

Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet

Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.

== FET-Typen ==

FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transitor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp. Im weiteren Artikel wird nur mehr der "selbstsperrende" MOSFET betrachtet.

{| class="wikitable"
|+ '''Typen von Feldeffekttransistoren  '''
|-
! Typ || N-Kanal || P-Kanal
|- valign="top"
| JFET || [[bild:JFET-N.png|center]]
* drittgrößte Gruppe
* bislang nur für kleine Leistungen verfügbar
* JFETs mit hoher Leistung sind im Kommen
* Eingangsstufen von OPVs
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich
* als einfache [[Konstantstromquelle]] geeignet
| [[bild:JFET-P.png|center]]
* selten
|- valign="top"
| MOSFET Anreicherungstyp || [[bild:MOS-EN.png|center]]
* größte Gruppe
* sehr viele Typen erhältlich
| [[bild:MOS-EP.png|center]]
* zweitgrößte Gruppe
* bei gleicher Geometrie etwas schlechter als ein N-Kanal Typ
|- valign="top"
| MOSFET Verarmungstyp || [[bild:MOS-DN.png|center]]
* selten
| [[bild:MOS-DP.png|center]]
* sehr selten
|}

=== Vorteile des FET ===

* Meist niedrigere Verluste als bei Bipolartransistoren.
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört, im Gegensatz zum BJT.

=== Nachteile des FET ===

* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]].
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.
* Empfindlicher gegen ESD am Gate als BJT
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.

=== Erklärung der wichtigsten Datenblattwerte ===

{| class="wikitable"
|-
! '''Parameter''' || '''Symbol''' || '''Wert''' (Beispiel)|| '''Erklärung'''
|-
| Drain Source (Breakdown) Voltage || V(BR)_DSS oder V_DS || 75V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source
|-
| Continuous Drain current || I_D(on) || 55A @125°C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur
|-
| Pulsed Drain Current || ID_pulse oder I_CD(on) || 240A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)
|-
| Repetetive Avalanche Energy || t_sc || 280mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z. B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen
|-
| Drain-Source ON Resistance || R_DS_ON || 0,01Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A
|-
| Drain-Source ON Resistance || R_DS_on || 0,021Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A
|-
| Thermal Resistance (junction-case) || R_th_JC || 0,8K/W || Thermischer Widerstand im Transistor vom eigentlichen Chip im Inneren (junction) bis zur Rückseite des Transistorgehäuses (case)
|-
| Gate-Source Threshold Voltage || V_GS(th) || 2,0-4,5V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum
|-
| Turn-on Delay || t_d(on) || 40ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom
|-
| Rise Time || t_r || 200ns || Anstiegszeit des Transistorstromes am Drain
|-
| Turn-off Delay || t_d(off) || 120ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom
|-
| Fall Time || t_f || 60ns || Abfallzeit des Transistorstromes am Drain
|}

Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedungungen (Gatewiderstand, Treiberspannung, etc.) und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. Achtung: Die Tabelle ist nur für eine Temperatur von 25° C gültig !!

Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET '''minimal''' leitfähig wird, je nach Datenblatt bei 100-250µA Drainstrom. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typisch 1:2 zwischen Minimum und Maximum. Im praktischen Betrieb muss man mindestens das Doppelte anlegen, um den MOSFET voll aufzusteuern. Wer es solide machen will nimmt dabei typisch 10-15V für einen Standardtypen und 3-5V für einen Logic Level Mosfet, dabei '''immer''' den Wert aus dem Datenblatt beachten, welcher unter <math>R_{DS-ON}</math> als Messbedingung angegeben ist. Deshalb braucht man bei 5V Ansteuerung einen Typen, der '''sicher''' bei typ. 4,5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht.

{| class="wikitable"
|+ ''' Parasitäre Diode des FETs '''
|-
! '''Parameter''' || '''Symbol''' || '''Value''' (Beispiel)|| '''Erklärung'''
|-
| Continuous Current (Diode) || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs
|-
| Forward Voltage (Diode)|| V_SD || 1,0..1,3V || Spannungsfall an der parasitären Diode
|-
| Reverse Recovery Time || t_rr || 80..120ns || Zeit, die die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode.
|-
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt.
|}

==== SOA Diagramm ====

SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagrmm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN.

[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]

Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.

(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).

{{Clear}}

== Haupttypen und Gatespannungslevel ==

===Unterschied N-Kanal / P-Kanal FET===

Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.

Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.

Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z. B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.

Beim P-Kanal FET muss die Gatespannung negativ gegenüber Source sein. Eine typische Anwendung ist z. B. ein '''High-Side Schalter''': Source an z. B. 400V, Drain an die Last, Ansteuerung des P-Kanal FETs mit 388V also 12V UNTER dem Sourcepotential.

Natürlich kann ein High-Side Schalter auch mit einem N-Kanal FET realisiert werden, was in diesem Fall eine zusätzliche Spannungsquelle bedeutet, denn der FET wird dann mit 412V eingeschaltet. Beim P-Kanal FET ist diese zusätzliche Spannungsquelle nicht erforderlich.

'''Weblinks'''
* [http://www.eetimes.com/General/DisplayPrintViewContent?contentItemId=4009943 A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com
* [http://www.eetimes.com/General/DisplayPrintViewContent?contentItemId=4009944 A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix

===Unterschied Logic-Level / "Normal"-Level===

Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.

== Beispiel zur Bauteiledimensionierung ==

=== Spannungsfestigkeit ===

Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein.

Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak
addiert sich auf die aktuelle Versorgungsspannung.

Überschlagsrechnung als Beispiel:
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V

Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist.

=== Stromtragfähigkeit ===

In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren.
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !).
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs parallelgeschaltet werden.

=== Verlustleistung ===

Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.

{| class="wikitable"
|+ '''Beispiel'''
|-
! Parameter || Symbol ||Wert
|-
| Betriebsspannung || UN || 70 V
|-
| Nennstrom || IN || 30 A
|-
| Drain-Source Widerstand bei einer Chiptemperatur von 125°C und einer Gatespannung von 10V || RDSon || 17 mΩ
|-
| on-Zeit || ton || 150 µs
|-
| Schaltfrequenz || ƒschalt || 5 kHz, (T = 200µs)
|-
| Einschaltzeit (risetime) || tr || 500 ns
|-
| Ausschaltzeit (falltime) || tƒ || 800 ns
|-
|}

==== Leitungsverluste ====

Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleitung.

<math>
P_\text{ON}
= I_\mathrm{N}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}
= 30A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W
</math>

==== Schaltverluste ====

Vereinfachter Ansatz.

Einschalten:

:<math>\begin{align}
P_\mathrm{SW_r}
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W
\end{align}</math>

Ausschalten:

:<math>\begin{align}
P_\mathrm{SW_f}
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W
\end{align}</math>

Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.
:<math>\begin{align}
P_{SW_f} = f_{schalt} \cdot E_{ON}
\end{align}</math>
:<math>\begin{align}
P_{SW_r} = f_{schalt} \cdot E_{OFF}
\end{align}</math>

Die Gesamtverlustleistung beträgt also in etwa 15W.

Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z. B.:
* Kühlkörper mit einem R_th von 0,2K/W
* max. Umgebungstemperatur +60°C
* R_th "junction-case" des FETs 0,8K/W
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W
* R_th gesamt: 3,0K/W 
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!

Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken.

Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.

==Treiberleistung==

Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei einigen wenigen Leistungs-FET muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#Mosfet-Treiber|Mosfet-Treiber]] Verwendung.
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert.
Daher berechnet sich die Treiberleistung wie folgt:

:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{iss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math>

1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.

:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math>

2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.

:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math>

Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.

Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.

== Low- und High-Side ==

Definition LS- und HS:

;Low-Side: Schalter, der FET schaltet eine Last gegen GND – auch als LS-Schalter bezeichnet.
;High-Side: Schalter, der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.

Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.

== Linearbetrieb von MOSFETs ==

Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.

Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen.

Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching).

Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.

Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Die kennzeichnet die die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.

== Siehe auch ==

* [[Leistungselektronik]]
* [[Mosfet-Übersicht]]
* [[IGBT]]
* [[TRIAC]]
* [[Kühlkörper]]
* [[Zwischenkreiskapazität]]
* [[Treiber]]
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb

== Weblinks ==

* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)

[[Category:Bauteile]] [[Kategorie:Leistungselektronik]]

Diskussion:Richtiges Designen von Platinenlayouts

2012-11-09T19:06:56Z

Haku: Neuer Abschnitt /* HF */

Hoi! Ich würde vorschlagen, den Artikeltitel umzudrehen. --[[Benutzer:Yahp|Yahp]] 00:26, 17. Dez 2005 (CET)

----

Letzthin gab's mal einen Thread, der deutlich machte, warum 100nF||10nF wenig sinnvoll ist.

Es gibt eine Stelle mit diesem Text, reicht das? [[Benutzer:Stefan|Stefan]] 14:44, 7. Feb. 2008 (CET)

''Niemals unterschiedliche große Abblock-Kondensatoren parallel schaltet, z.B. 10nF und 100nF. Es entstehen durch die parasitären Elemente Resonanzstellen, die genau das gegenteil des gewünschten erzeugen!''

_niemals_ ist auch nicht ganz richtig. gerade bei hf-schaltungen sieht man oft 100nF || ~22pF als hf-block.

----

== HF ==

Bevor der Käse nun nocheinmal kommt: Bitte [http://www.mikrocontroller.net/wikisoftware/index.php?title=Wellenwiderstand#90.C2.B0_Ecken_in_Leiterbahnen _erst_ dieses lesen], dann verstehen, und dann ergänzen oder begründet ändern. --[[Benutzer:Haku|Haku]] 19:06, 9. Nov. 2012 (UTC)

Richtiges Designen von Platinenlayouts

2012-11-09T19:04:46Z

Haku: Änderung 69076 von 87.176.246.224 (Diskussion) wurde rückgängig gemacht. Ist gut jetzt, siehe Diskussion!

Beim Erstellen von Platinenlayouts muss man vieles beachten. Dieser Artikel zählt auf, was man machen sollte (Dos), und was man keinesfalls machen sollte (Don'ts).

== Gutes Platinenlayout (Dos) ==

* Berechne vor dem Zeichnen, welche Ströme über die Leiterbahn fließen werden und bestimme anhand dessen ihre Breite. Faustformel: 0,35mm können mit einem Ampere belastet werden. Weiteres siehe unter [[Leiterbahnbreite]].
* Halte die Leiterplatte klein und kompakt. Jeder Leiterzug wirkt wie eine Antenne, welche Störungen aussendet oder empfängt. Je länger um so intensiver. Zumindest auf der Eingangsseite.
* Nutze die Flächen zwischen den Leiterzügen und verbinde sie mit Masse (Polygone). So kann man Strahlung von außen abschirmen und Abstrahlung minimieren. Vermeide aber freie Kupferflächen, die nicht an GND angeschlossen sind.
* Geize nicht mit Blockkondensatoren. Für jeden VCC-Pin o.ä. ist mindestens ein 100nF Kondensator, bei schnelleren Sachen evtl. ein kleinerer (z. B. 10nF) einzusetzen. Ausserdem kann es meist notwendig sein, pro IC noch zusätzlich einen 10µF Kondensator und eine Ferritperle (engl. bead) zur Entkopplung von Vcc zu spendieren.
* Digitale und analoge Signale getrennt routen und nur in einem Punkt verbinden. Und zwar idealerweise am [[AD-Wandler]], wenn dieser vorhanden ist, sonst in der Nähe des Spannungsreglers. Eine Massefläche für analoge und digitale Schaltungsteile sollte durchgängig sein, getrennte Masseflächen sind nur in sehr seltenen Fällen sinnvoll.
* Nutze die Anschlüsse der bedrahteten Bauelemente für Durchkontaktierungen.
* Wenn es sich nicht vermeiden lässt 230V (400V) Netzspannung auf die Platine zu führen, so trenne die Bereiche der Kleinspannung und Netzspannung deutlich voneinander und mit vieeel Platz. Dabei unterscheidet man zwischen Luft- und Kriechstrecken. Eine Kriechstrecke ist die Strecke auf der Oberfläche einer Leiterplatte oder eines Bauteils. Die Luftstrecke ist sozusagen die kürzeste Verbindung zwischen den beiden Potentialen. Die Luft- und Kriechstrecken betragen zwischen 3 und 8 mm. Der notwendige Abstand hängt von der Gefährdung ab, siehe auch [[Leiterbahnabstände]].
* Mögichst sternförmige Verbindungen für Masse und Versorgungsspannungen bei Schaltungen mit hohen Strömen und empfindliche Analogschaltungen

== Schlechtes Platinenlayout (Don'ts) ==

* Analoge und digitale Schaltungsteile direkt ohne Filter aus der gleichen Stromquelle versorgen.
* Digitale Signalleitungen in unmittelbarer Nachbarschaft analoger Signale.
* Zu wenig Abstand zwischen Leiterplattenrand und Leiterzügen.
* 90° oder spitze Winkel beim Routen von Leiterbahnen. Entgegen der weit verbreiteten Annahme hat das nur sehr wenig Auswirkungen auf die HF-Eigenschaften. Es sind mehr mechanische (Ablösung von Ecken) und ästhetische Gründe (Aussehen, Packungsdichte der Leitungen). Mehr dazu im Artikel [[Wellenwiderstand#Leitungsf.C3.BChrung_und_Layout | Wellenwiderstand]].
* Durchkontaktierungen auf SMD-Pads. Beim maschinellen Löten läuft das Flussmittel bzw. das Lötzinn in die Bohrung. Die Fehlerhäufigkeit steigt.
* Durchkontaktierungen von beiden Seiten mit Stopplack verschließen. Es könnte Feuchtigkeit darin zurückbleiben und beim Löten der Stopplack abplatzen

== Vorgehen bei der Layouterstellung ==
* Umrisse festlegen
* Befestigungsbohrungen festlegen, dabei ausreichend Platz für Schraubenköpfe und Werkzeuge freihalten (Sperrflächen)
* Steckverbinder platzieren
* Bauteile platzieren, dabei möglichst zusammengehörige Bauteil nebeneinander platzieren. Die Verbindungen (Luftlinien, engl. air wires) möglichst kurz und kreuzungsarm halten.
* Stromversorgung der ICs layouten
* Kritische Signale layouten wie Takte, Sensoreingänge etc.
* Restliche Signale layouten
* Masseflächen füllen.
** Masseflächen können eine Schaltung deutlich verbessern, wenn sie richtig benutzt werden. Sie können aber auch genau das Gegenteil bewirken, wenn sie als automatisches Wundermittel betrachtet werden.
** Die Masserverbindung aller ICs muss zunächst direkt layoutet werden.
** Erst wenn die Masse komplett layoutet ist, kann man die Massefläche auffüllen. Damit verhindert man, dass vielleicht ein IC nur über eine sehr dünne Verbindung angeschlossen wird, welche man in der Masserfläche übersieht.
** Masseflächen sind nur dann wirklich wirksam, wenn sie möglichst durchgängig sind. Wenn sie durch viele Leitungen zerschnitten werden, sinkt ihre Wirksamkeit massiv und sie können sich zu einem EMV-Problem entwickeln (Abstrahung von Energie, Streifen- und Schlitzantennen)

== Siehe auch ==

*[http://www.mikrocontroller.net/forum/read-6-178710.html#254235 Forumsbeitrag]: Regeln beim Platinenentwurf
* [http://www.mikrocontroller.net/topic/93602#804338 Forumsbeitrag]: Vorschlag für Lötpads bei Hobbyeinsteigerplatinen
* [[EMV]]
* [[Eagle im Hobbybereich]]

==Links==
* [http://www.ilfa.de/download/C/pb-id=wd7c584f8c9d73e6df32d52cabe12bcbbba8624a4eci8/453/Design-Optimierung.pdf Optimierung von Layouts]
*[http://www.ilfa.de/de/_design/index.html?a-Common_menu-n_Selected=6&button-CurrentMenuTree-setmenutree=&a-Common_storyOutput-n_SearchNodeId=6&button-Common_storyOutput-find_story=&uypb-id=wd7c584f8c9d73e6df32d52cabe12bcbbba8624a4eci8 Weitere Dokumente zum Thema professionelle Platinenherstellung]
* [http://www.analog.com/library/analogDialogue/Anniversary/12.html Grounding (Again)], Ask The Applications Engineer - 12, Fa. Analog Devices, (englisch)

* [http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=115 Designing a Better PCB] von Sparkfun (engl.)
* [http://www.hottconsultants.com/tips.html Tech Tips] von Henry Ott (engl.)
* [http://www.ultracad.com/articles/90deg.pdf Messung] von verschiedenen Winkeln von Leiterbahnen mit 17ps TDR, keinerlei Unterschiede!

[[Category:Platinen]]
[[Kategorie:Schaltplaneditoren]]

VHDL

2012-10-16T16:16:14Z

Haku: /* If außerhalb eines Prozesses? */

== VHDL als Sprache ==

VHDL ist eine kombinierte Sprache: Sie enthält wie die typischen Programmiersprachen auch, eine Reihe von Konstrukten und Befehlen, die Abläufe und zeitliches Verhalten bescheiben, sowie ferner auch Elemente, die Strukturen und Zusammenhänge definieren. Diese werden genutzt, um das Verhalten der Schaltung zu definieren. Wesentlich ist dabei die funktionelle Abhängigkeit der Ausgänge von Schaltungsmoduln von ihren Eingängen, sowie der Zusammenhang der Eingänge der Module mit den Ausgängen anderer Module. Diese können jeweils direkt oder über FlipFlops verknüpft werden, wodurch die Informationsweitergabe erst im nächsten Takt erfolgt. Mit dieser grundsätlzichen Topologie sind quasi alle wichtigen Grundfunktionen digitaler Schaltungen darstellbar. Letztlich wird das Verhalten der Chipausgänge in Abhängigkeit der Chipeingänge definiert und dabei alle erdenklichen Zustände, in denen sich die Teilschaltungen befinden können, vollumfänglich beschrieben.

Wichtig ist bei VHDL das Verständnis, dass alle ausdrücklichen, zeitlichen Abläufe lediglich während der Simulation so vollzogen werden, wie sie anhand üblicher Regeln der Softwaretechnologie erwartet werden. Bei der Synthese hingegen, bleiben einige zeitliche Konstrukte und Zusammenhänge unberücksichtigt und nur die Strukturen selbst werden in die Schaltung übernommen. Damit ist z.B. die Anordnung des Codes in einem Modul aber auch die Ordnung der Prozesse und Reihenfolge von Signalzuweisungen weitgehend unerheblich.

=== Simulation ===

Bei der Simulation wird der Code in klassischer Weise kompiliert und ausgeführt. Die Anordnung von Codezeilen kann dabei ebenso relevant sein, wie die zeitliche Steuerung von Modulen, die bestimmte Abhängigkeiten von einzelnen Signalen haben. In dieser Funktion wird VHDL hauptsächlich zum Schreiben von Testbenches und Modellen verwendet. Näheres dazu im Artikel [[VHDL Testbench]].

=== Synthese ===

Bei der Synthese wird die Beschreibung von einer Synthesesoftware in eine Netzliste umgesetzt. Der grundlegende Unterschied zur Verwendung von VHDL als Simulationsprache besteht darin, dass man nicht beliebigen Code schreiben kann, sondern sich an bestimmte Strukturen halten muss, die der Synthesizer kennt und in Hardware umsetzen kann. Schleifen z.B. werden zur Compilezeit ausgeführt, um Matritzen, Vektoren oder redundante Strukturen zu beschreiben und besitzen keine zeitliche Relevanz zur Ausführungszeit.

Wie diese Strukturen im allgemeinen aussehen, ist weiter unten beschrieben, Details erfährt man in der Dokumentation der Software, z. B. dem [http://toolbox.xilinx.com/docsan/xilinx9/books/docs/xst/xst.pdf XST User Guide].

==== Grundregeln für synthetisierbaren VHDL-Code ====

Folgende Grundregeln sollten vor allem Anfänger auf jeden Fall einhalten:

* Es darf nur zwei Arten von Prozessen geben:
*# Rein kombinatorische Prozesse (keine Zustandsspeicher):
*#* Alle Signale die im Prozess gelesen werden in die sensitivity list eintragen
*#* Jedes Ausgangssignal muss in jedem if-Zweig einen von sich selbst verschiedenen Wert zugewiesen bekommen, damit keine [[Latch]]es entstehen (mein_signal <= mein_signal; ist unzulässig!)
*#* Keine Taktflankenabfrage
*# Rein getaktete Prozesse (Flip-Flops als Zustandsspeicher):
*#* Nur Clk und asynchroner Reset in die sensitivity list
*#* Maximal ein [[Reset für FPGA/CPLD | Reset]]
*#* Nur eine Taktflankenabfrage (rising_edge)
* Möglichst nur ein einziger Takt im gesamten Design, nur steigende ODER fallende Taktflanke auswerten. Um eine Flanke eines anderen Signals zu erkennen, siehe [[VHDL Flankenerkennung]].
* Keine Takte herunter teilen, stattdessen [[Taktung FPGA/CPLD#Clock Enable|Clock Enable]] verwenden.
* Kein "after", "wait for" o.ä. verwenden, das ist nicht synthetisierbar
* Keine shared variables verwenden
* Variablen nur dann verwenden, wenn man genau verstanden hat, was der Unterschied zu einem Signal ist und sich das Problem nicht auch mit Signalen lösen lässt
* Kein IEEE.STD_LOGIC_(UN)SIGNED verwenden, sondern IEEE.NUMERIC_STD (siehe [[Rechnen in VHDL]])

==FAQ==
===<code>CLK='1' and CLK'event</code> oder <code>rising_edge()</code>?===
'''Frage:'''
Bei der Beschreibung von FlipFlops werden je nach Buch/Programmierer zwei unterschiedliche Konstrukte benutzt:

Variante 1 (klassisch):

<vhdl>
process(clk)
begin
if clk = '1' and clk'event then
--snip
end if;
end process;
</vhdl>
und Variante 2:

<vhdl>
process(clk)
begin
if rising_edge(clk) then
--snip
end if;
end process;
</vhdl>

Welche ist zu empfehlen?

'''Antwort:'''
Kurz gesagt bei der Synthese gibt es keine Unterschiede, in der Simulation kleine. Verwende die besser lesbare Variante. Die mit ''rising_edge()'' (bzw. ''falling_edge()'') gilt allgemein als die bessere (Lesbarkeit und Simulationsgenauigkeit).

Wer es genau wissen will: Die klassische Variante ist nur korrekt für Signale die nur die Werte '1' und '0' annehmen können. Bei Signalen vom Typ std_logic (der Standardtyp für Signale) werden Flanken erkannt, die tatsächlich keine sind.
Zum Beispiel beim Treiben eines PullUps ('H' -> '1' keine tatsächliche Flanke aber für ''clk = '1' and clk'event'') oder beim Simulationsstart ohne Initialisierungswert für die Signale ('U' -> '1').(Signale mit Initialisierungswert werden so deklariert: ''signal a: std_logic := '0'; '').
Die Funktionen ''rising_edge()'' und ''falling_edge()'' konvertieren den std_logic Wert vor dem Vergleich auf '1' bzw. '0' und simulieren so keine Flanke wo in der echten Hardware auch keine ist.

* http://www.mikrocontroller.net/forum/read-9-391894.html

===Synchroner oder asynchroner Reset===
Folgende Regeln gelten bei der Überlegung, ob man einen ansynchronen Reset verwenden sollte:

* In FPGAs führt die Nutzung von Resetfunktionen in aller Regel zu einem erhöhten Resourcenverbrauch. Mitunter werden Taktnetze belegt.

* Asynchrone Resets bedürfen besonderer Behandlung, damit die negative RST-Taktflanke nicht genau zur Clk-Flanke kommt, da dies zu inkonsitenten Startbedingungen der FFs im FPGA führen kann.

* Viele FPGAs können per Init-Kommando in VHDL initialisiert werden und benötigen zum Anlaufen gar keinen (Re)set - weder synchron noch aysnchron.

* Oft benötigen FPGAs aus Betriebssicherheitsgründen einen synchronen Reset inmitten des Betriebs durch eine Instanz wie einen Controller, wenn ein Fehler detektiert wurde. In diesen Fällen ist ein asynchroner Reset unnötig.

* asynchrone Resets sollten nur an von einander unabhängigen Punkten der Schaltungselektronik angewendet werden, wie z.B. an verschiedenen Chips, wo man ohnehin keine totale Synchronität unterstellt und Massnahmen zum sicheren Anlaufen aller Schaltungsteile ergreifen muss.

* asynchrone Resets müssen in jeder einzelnen domain getrennt eingetaktet werden, um sie sicher in synchrone Resets zu überführen

* Innerhalb eines FPGAs sollten asnchrones Resets an z.B. PLLs geführt werden, damit deren Reset nicht von einer zweiten PLL abhängig ist.

* Sollen FPGAs in ASICs übersetzt werden und dort unbedingt ein asynchroner Reset verwendet werden müssen, können asynchrone Resets bedingt compilierbar eingebaut werden, sodass sie im FPGA nicht zwangsläufig aktiv sein müssen

==== Standardresetpfad in FPGAs ====

Ein probates und meistens sehr gut funktionierendes Design sieht folgendermassen aus:

* externer asynchroner Reset vom IO-PAD (bei nReset über Inverter) direkt im Top-Level an die Master-PLL / bzw den Haupt-DCM, genannt "PLL1"

* Die "PLL1" generiert neben den Takten ein LOCKED-Signal, das in invertierter Form als Reset für diese domain benutzt wird. Aus dem aynchronen Reset wird dadurch mittels des LOCK-Signals ein interner, synchroner Reset

* Dieser interne Reset wird in jeder einzelnen Teildomain dieser PLL zweimmal einsynchronisiert, um lokale Reset-Signale zu erzeugen. Damit werden die Auswirkungen metastabiler Zustände verhindert, die bei der negativen Resetflanke entstehen könnten, falls die Taktflanken der erzeugten PLL-Takte genau auf dieser Flanke liegen

* Der interne Reset der "PLL1" versorgt zudem auch alle weiteren PLLs der anderen Domains, die sich ihren lokalen Reset auf dieselbe Weise generieren. Der in der domain der PLL1 synchrone reset wirkt bei diesen PLLs quasi asynchron.

Damit wird sichergestellt dass alle PLLs einen eigenen Reset bekommen und sie danach definitiv anlaufen. Es ist nun wichtig, dass beachtet wird, dass der exakte Zeitpunkt der Resets der unterschiedlichen domains unbekannt ist. Daher müssen die locked-signale dieser domains gfs wieder einsynchronsiert werden, damit in der Master-Domain bekannt ist, wenn alle Teilschaltungen angelaufen sind und das Design "starten" kann.

Bei kritischen Applikationen muss gegebenenfalls auch noch dafür gesorgt werden, dass in der Phase zwischen Start des FPGAs und Arbeiten aller PLLs alle FPGA-Ausgänge auf einem passenden Pegel gehalten werden.

===Wann und warum verwendet man Variablen?===

* Variablen sind als Zwischenergebnisse / Synonyme für aus Kombinatorik gewonnene Werte / Signale zu verstehen. Sie erhalten jeweils "sofort" nach der Zuweisung ihren neuen Wert, der direkt an anderer Stelle genutzt werden kann - so, als läge eine direkte Verdrahtung vor. Die Nutzung von Variablen entkoppelt somit jegliche Berechung von den zeitlichen Randbedingungen, speziell dem Takt. Damit ist es möglich, komplexe Architekturen und Modellverhalten innerhalb von Simulationen ohne einen Zeitverlust zu berechnen, siehe Beispiele unten.

* Signale erhalten ihren neu zugewiesenen Wert dagegen erst nach dem vollständigen Abarbeiten eines Prozesses, praktisch nach einem Delta-Delay oder nach einer spezifizierten Zeit. Sie repräsentieren eine physikalische Signalkette mit tatsächlichem Datenfluss. Während Variablen daher in einem Prozess gleich weiterverwendet werden können, sind Signale faktisch erst mit dem nächsten Takt aktuell (das Delta-Delay führt dazu, dass der Wert für diesen Durchlauf noch nicht gilt, der nächste Durchlauf des getakteten Prozesses passiert dann erst einen Clockcycle später.

* Bei asynchronen Prozessen wird der Prozess bei der Verwendung von Signalen dann nochmals gestartet ... (oder so oft, so viele voneinander abhängige Signalzuweisungen drin sind), bei Variablen wird er in einem Durchlauf berechnet (Simulationszeit!).

* Die Benutzung von Variablen gegenüber Signalen hat mitunter Vorteile im Bereich der Ausführungszeit bei Simulationen, wenn umfangreiche Berechnungen nötig sind, die ansonsten mit Vektoren durchgeführt werden müssten.

Beispiele:

==== Beispiel 1 ====

<vhdl>
-- Nutzung von Signalen
-- die letzte Anweisung ist gültig und überschreibt alle vorhergehenden Anweisungen

-- steht real in der Signaldefinition über begin
signal a: std_logic;

process(clk)
begin
if rising_edge(clk) then
a <= a and b;
a <= a and c;
end if;
end process;

-- Ergebnis: a <= a and c, die Zeile zuvor wird ignoriert
</vhdl>

<vhdl>
-- Nutzung von Variablen
-- Aufeinanderfolgende Anweisungen werden sofort logisch wirksam und in die neue Anweisung einbezogen, die Anweisungen werden somit verkettet

process(clk)
variable a: std_logic;
begin
if rising_edge(clk) then
a := a and b;
a := a and c;
end if;
end process;

-- Ergebnis: a <= a and b and c, Verkettung der Anweisung wie in normalen Programmiersprachen
</vhdl>

* Es kann recht unübersichtlich werden, wenn man eine komplexe Berechnung hat und diese mit vielen Klammerebenen verschachtelt direkt in der Signalzuweisung beschreibt. Hier kann es besser sein, den Wert "nach und nach" über Variablen "zusammenzubauen" und erst am Schluss auf ein Signal zuzuweisen.

* Manchmal möchte man gemeinsame Teilausdrücke vorab berechnen, z. B.
<vhdl>
Var1 := A + B;
Var2 := C + D;
Var3 := E + F;
Result1 <= Var1 - Var2;
Result2 <= Var1 - Var3;
</vhdl>
ist i.d.R. besser als
<vhdl>
Result1 <= (A + B) - (C + D);
Result2 <= (A + B) - (E + F);
</vhdl>
Wenns komplexer wird, ist es auch einfacher, daran was zu ändern.

* Verschiedenen Synthesetools können manchmal mehr, manchmal weniger gut optimieren. So kann man z. B. durch das Zusammenfassen eines Teilausdruckes eine bessere Optimierung erreichen (Stichwort Resource-Sharing). Z.B.:
<vhdl>
if (opcode = add) then
res <= a+b;
else -- opcode = sub
res <= a-b;
end if;
</vhdl>
oder
<vhdl>
if (opcode = add) then
var1 := b;
else
var1 := -b;
end if;
res <= a+var1;
</vhdl>

Im ersten Fall wird ggf. ein Addierer und ein Subtrahierer (noch'n Addierer) eingebaut und das Ergebniss gemultiplext, im zweiten Fall wird eventuell nur ein Addierer eingebaut und der b-Eingang des Addierers gemultiplext. Sind a und b beispielsweise 32-Bit-Vektoren, dann macht das HW-mäßig schon was aus.
Gute Synthesetools sollten dies aber mittlerweile automatisch machen, so das in beiden Fällen dasselbe rauskommt (war nicht immer so). (BTW, ich selber tendiere normalerweise zur ersten Variante, da besser lesbar - und man die HW-Implementierung nicht notwendigerweise vorwegnehmen soll, aber da hat jeder seine eigene Meinung zu ...)

==== Beispiel 2 ====
Bei Analogen Filtern ist es oft notwendig, iterative Schleifen zu verwenden, um die Ergebnisse zu erlangen. Nur die Verwendung von Variablen und Loops gestattet es, komplexe Rechenergebnisse von "analoger" Reaktionsgeschwindigkeit vom Simulator zu erlangen, ohne Simulationszeit oder gar Takte vergehen zu lassen.

==== Geschwindigkeit ====
Simulatoren rechnen i.d.R. mit Variablen schneller, als mit Signalen. Hat man also viele Prozesse mit Signalen vs. Variablen in einem großen Design, dann kann das schon was ausmachen ... Siehe auch oben bei asynchronen Prozessen, die mit Signalen ggf. wesentlich öfters durchlaufen werden. Auch wenn also ein System mit Signalen abzubilden ist, so empfiehlt sich der Einsatz von Variablen mitunter dennoch.

Ausnahme: I.d.R. sind nur auf Signalen und getakteten Prozessen basierende Modelle voll und leicht synthesierbar. Soll z. B. ein Modell in einem [[HIL]] System getestet werden, ist die Verwendung von Signalen mit entsprechender Berücksichtigung des timing angezeigt.

==== Anfängerprobleme ====
Anfänger meinen oft, die unmittelbare Zuweisung eines Werts an eine Variable im Prozess gewinnbringend nutzen zu können. So werden dann ausgiebig Variablen verwendet, und eines der Hauptprobleme von Variablen übersehen: sie können nicht in der Sensitivliste eines Prozesses aufgeführt werden. Von diesem Nebeneffekt sind insbesondere ''speichernde'' Variablen betroffen. Im Beitrag
http://www.mikrocontroller.net/topic/117630 sind dort ein paar Beispiele aufgeführt. 
Das Hauptproblem an diesem Verhalten ist, dass die (fehlerfreie) Simulation nicht mehr zum Syntheseergebnis (das ebenfalls fehlerfrei und ohne Warnungen erzeugt wurde) passt.

=== Kodierschaltungen ===
Kodierschaltungen (Coder) sind Schaltungen mit einem mehrstelligen Ein- und Ausgang. In der Schaltung werden keine FF oder andere Speicher benutzt. Ein typisches Beispiel ist die Wandlung einer Binärzahl in eine Binär Codierte Dezimalzahl. Eine sehr übersichtliche Schreibweise benutzt ein Konstanten-Feld.

Vor- und Nachteile verschiedener VHDL-Varianten einen Coder zu beschreiben werden [[TTL74185|hier]] besprochen.

===If außerhalb eines Prozesses?===
If-Bedinungen sind außerhalb eines Prozesses nicht möglich.
Lösung:
<vhdl>
vector_or <= '0' when oder_vector = X"0000" else '1';
</vhdl>
Dies nennt der Fachmann bedingte Zuweisung (conditional assignment), es ist eine der ''nebenläufigen'' Anweisungen von VHDL. Daneben gibt es zu ähnlichem Zweck eine select-Anweisung:
<vhdl>
with vector select
bit_pos <= "00" when "0001",
"01" when "0010",
"10" when "0100",
"11" when "1000",
"00" when others;
</vhdl>

Für sperrige Fälle, die sich partout nicht lesbar und/oder elegant mittels dieser nebenläufigen Zuweisungen formulieren lassen, bietet sich entweder ein kombinatorischer Prozess an oder man verpackt die Zuweisung in eine Funktion. In beiden Fällen kann man dann den Ergebnisvektor schrittweise mit if-Abfragen zusammenbauen.

=== Alle Leitungen auf "0000.." bzw "1111..." setzen? ===

Auf null setzen:
<vhdl>
count <= (others => '0');
</vhdl>

Auf eins setzen:
<vhdl>
count <= (others => '1');
</vhdl>

===Vergleich eines std_logic_vector mit einer Konstanten===

Um einen std_logic_vector auf "00000..." oder "1111..." zu vergleichen, kann die (others => '0') Schreibweise nicht verwendet werden, weil die Vektorbreite dabei nicht definiert ist. Hier muss also ein Bereich angegeben werden:
<vhdl>
if VECTOR = (15 downto 0=>'0') then..
</vhdl>
oder
<vhdl>
if VECTOR = (VECTOR'range=>'0') then...
</vhdl>
Diese Schreibweise gilt universell für alle Libs.

Werte ungleich "000.." und "1111..." müssen bei Verwendung der NUMERIC_STD.ALL etwas aufwendiger umgewandelt werden (hier der Wert 77):
<vhdl>
if VECTOR = std_logic_vector(to_unsigned(77,VECTOR'length)) then...
</vhdl>

Wird die herstellerabhängige Synopsis-Lib STD_LOGIC_UNSIGNED.ALL verwendet, kann auch einfach so geschrieben werden:
<vhdl>
if VECTOR = 0 then...
</vhdl>
Genauso einfach geht ein Vergleich auf z. B. den Wert 77:
<vhdl>
if VECTOR = 77 then...
</vhdl>

===Report von std_logic_vector===

Report kann nur Strings verarbeiten, deswegen muss ein std_logic_vector in einen String verwandelt werden:
<vhdl>
report integer'image(to_integer(unsigned(rdata)));
</vhdl>

===parallel -> seriell: Schieberegister oder Multiplexer?===
* http://www.mikrocontroller.net/topic/78556

==Links==

===Kurzreferenzen===
* http://www.tcnj.edu/~hernande/r/VHDL_QRC__01.pdf - VHDL Quick Reference Card
* http://www.lrr.in.tum.de/~acher/tgi/uebung/VHDL-Buch.pdf
* http://www.mikrocontroller.net/attachment/21066/VHDL_Coding_eng.pdf - Design Rules & Coding Style

===Online-Bücher===
http://de.wikibooks.org/wiki/VHDL

====Deutsch====
* [http://www.nt-nv.fh-koeln.de/Labor/VhdlEasy/index.html VHDL easy] - deutschsprachige VHDL-Einführung von der FH Köln
* [http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/202594 Schaltungsdesign mit VHDL] - komplettes Buch als PDF
* [http://tams-www.informatik.uni-hamburg.de/vhdl/doc/kurzanleitung/vhdl.pdf VHDL Kurzanleitung] - Umfangreiches Buch der Uni Hamburg, deutschsprachig, ca. 110 Seiten
* [http://www.informatik.uni-ulm.de/ni/Lehre/SS03/ProSemFPGA/VHDL-Grundlagen.pdf VHDL Grundlagen] 15 Seiten Grundlagen, Universität Ulm
* [http://wwwlrh.fh-bielefeld.de/vhdl_vor/VHDL_VOR.htm Schaltungs-Synthese mit VHDL] eine Einfuehrung
* [http://www.vhdl-online.de/tutorial/ VHDL Tutorial] - umfangreiches Tutorial zu VHDL
* [http://de.wikibooks.org/wiki/VHDL VHDL - Wiki - Buch] VHDL Syntax mit vielen Beispielen. Da es sich um ein Wiki steht jede Woche mehr (korrigierter) Inhalt zur Verfügung.

====English====
* [http://tams-www.informatik.uni-hamburg.de/vhdl/ Hamburg VHDL archive]
* [http://www.ti.informatik.uni-frankfurt.de/Docs/cook/ VHDL Cookbook] - komplettes Buch
* [http://www.fpga4fun.com/VHDLTips.html VHDL Tips and Tricks]
* [http://www.doulos.com/knowhow/vhdl_designers_guide/ The Designer's Guide to VHDL]
* [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] - viele Beispiele mit Testbenches

[[Category:FPGA und Co]]
[[Category:Programmiersprachen]]
[[Kategorie:VHDL| ]]

Kühlkörper

2012-08-12T08:56:25Z

Haku: Montage

== Einleitung ==

Ein Kühlkörper (engl. ''heat sink'') wird benötigt, wenn die Verlustleistung von elektronischen Bauteilen einen bestimmten Wert übersteigt. Der Kühlkörper hat dabei die Aufgabe, die entstehende Wärme möglichst gut auf eine große Fläche zu verteilen, um sie dann an die Umgebung abzugeben.

[[bild: Rippenkuehlkoerper.png | thumb | 300px| Rippenkühlkörper, Schnittdarstellung]]

Das grundlegende Prinzip sieht man an jedem Rippenkühlkörper. An der Stelle, wo das Kühlobjekt angeschraubt/gepresst ist, ist ein dicker "Klumpen" Material, der erstmal die Wärme auf eine etwas größere Fläche verteilen soll. Bei CPU-Lüftern ist dort teilweise Kupfer eingepresst, weil das noch besser als Aluminium Wärme leitet (engl. heat spreader, Wärmespreizer). Danach folgen viele, nach aussen dünner werdende Rippen. In der Mitte noch dick, dort muss die Wärme ja verlustarm durchgeleitet werden, aussen dünn, dort ist fast alle Wärme schon abgegeben. Ein guter Kühlkörper hat eine möglichst große Oberfläche bei möglichst kleiner Masse. Viele Kühlkörper werden aus preiswerten [http://de.wikipedia.org/wiki/Strangpressen Strangpressprofilen] hergestellt.

== Wärmewiderstand ==

Die wichtigste Kennzahl eines Kühlkörpers ist der Wärmewiderstand. Er gibt an, um wie viel Kelvin sich die Temperatur zwischen Wärmequelle und Umgebung unterscheidet, wenn eine bestimmte Wärmeleistung abgeführt werden muss. Die Einheit ist K/W, Kelvin pro Watt. (Hinweis: Oft wird die Einheit °C/W angegeben, das ist allerdings nicht ganz korrekt. Temperaturdifferenzen werden in Kelvin angegeben). Je niedriger der Wärmewiderstand, umso besser der Kühlkörper, weil er die gleiche Wärmeleistung mit einem kleineren Temperaturunterschied abführen kann. Dadurch bleibt das Bauteil kühler, was der Lebensdauer und Funktionssicherheit zu Gute kommt.

Allgemein gilt die Formel

<math>\Delta T = P_t \cdot R_t</math>

*<math>\Delta T</math> - Temperaturdifferenz zwischen Wärmequelle und Umgebung in K
*<math>P_t</math> - Wärmeleistung in W
*<math>R_t</math> - Wärmewiderstand in K/W

== Berechnung des Wärmewiderstands ==

Für einen Kühlkörper ist der Wärmewiderstand im Datenblatt angegeben. Diesen rein aus dem Aufbau zu berechnen ist sehr schwierig, auch das Messen ist nicht so einfach. Was man jedoch berechnen kann und muss ist der Wärmewiderstand eines Gesamtaufbaus, d.h. Bauteil + Kühlkörper. Dazu muss man im Wesentlichen zwei Fälle unterscheiden.

=== Bauteil ohne Kühlkörper ===

Ohne Kühlkörper kann ein Bauteil seine Wärme über zwei Wege abgeben. Über das Gehäuse direkt an die Luft (Abstrahlung oder Konvektion) oder über die Anschlüsse auf die Platine (Wärmeleitung). Dies alles findet parallel statt, aber je nach Gehäusetyp und Platinengestaltung ist die Verteilung auf die Kühlwege verschieden. Transistoren im Metallgehäuse (z. B. TO-3) oder mit Metallfahne (z. B. TO220) können recht viel Wärme über das Gehäuse abgeben. Leistungsdioden im Plastikgehäuse hingegen können den Großteil der Wärme nur über die Anschlüsse abgeben. Deshalb sollten diese möglichst kurz sein, und auf der Platine an dicke Leiterbahnen oder gar Kupferflächen angeschlossen werden. Ähnliches gilt für leistungsverstärkte DIL- oder SOIC-[[IC-Gehäuseformen | Gehäuse]], welche oft für [[H-Brücken_Übersicht | Leistungstreiber]] oder [[FET | MOSFETs]] verwendet werden. In diesen Fällen sollten die Pins direkt an Kupferflächen '''ohne''' Wärmefallen (Thermals) angeschlossen werden, auch wenn dadurch das [[Löten]] erschwert wird.

Für die meisten Bauteile ist im Datenblatt der Wärmewiderstand zwischen dem eigentlichen Chip (engl. "junction") und der Umgebung (engl. "ambient") angegeben. Damit kann man direkt in die oben genannte Formel gehen und die Temperaturdifferenz ausrechnen. Die Temperatur der Sperrschicht errechnet sich einfach aus der maximalen Umgebungstemperatur (meist Luft) und dem errechneten Temperaturunterschied.

=== Bauteil mit Kühlkörper ===

Will man mit einem IC größere Verlustleistungen umsetzen (Linearer Spannungsregler, [[Transistor]], etc.] muss meist ein Kühlkörper her. Die jeweiligen Gehäuse besitzen dazu meist eine Kühlfahne, an die man den Kühlkörper anschrauben kann. Bei anderen gibt es Klemmen, die den Kühlkörper fest klemmen. Hier gibt es einiges zu beachten. Der Kühlkörper darf nicht zu schwach angeschraubt werden, sonst ist der Wärmewiderstand zwischen Gehäuse und Kühlkörper zu gross. Er darf aber auch nicht zu stark angeschraubt/angepresst werden, um das Gehäuse nicht zu deformieren. Wichtig ist der Übergang zwischen IC und Kühlkörper. Hier muss bei größeren Leistungen (>5W) Wärmeleitpaste verwendet werden. Ihre Aufgabe ist es, die Luft zwischen den Oberflächen zu verdrängen, welche sich in den mikroskopischen Unebenheiten befindet und den Wärmewiderstand '''deutlich''' erhöht. Dabei sollte die Schicht sehr dünn sein, denn die Wärmeleitpaste ist im Vergleich zu Aluminium oder Kupfer ein schlechter Wärmeleiter, allerdings deutlich besser als Luft.

{| class="wikitable" style="text-align:center"
|-
! Material || Wärmeleitfähigkeit [W/(m*K)]
|-
| Luft || 0,026
|-
| Wärmeleitpaste || 4-10
|-
| Aluminium || 221
|-
| Kupfer || 370
|}

'''Beispiel'''

Das oft verwendete TO220 Gehäuse hat ca. 1cm^2 Kühlfläche. Wird ein Kühlkörper ohne Wärmeleitpaste aufgeschraubt und entsteht dabei ein angenommener Luftspalt von 10µm, hat dieser einen Wärmewiderstand von ca. 4K/W! Mit Wärmeleitpaste sind es rein rechnerisch nur 1/150tel, also etwa 0,026 K/W. Real muss man jedoch eher mit 0,5-1K/W rechnen.

Für die Berechnung des gesamten Wärmewiderstandes müssen hier drei Widerstände in Reihe betrachtet werden. Der Erste ist im Datenblatt zwischen Chip und Gehäuse angeben (engl. junction to case). Danach kommt der Übergang Gehäuse-Kühlkörper. Dieser ist von der Oberflächengüte und der Wärmeleitpaste abhängig und kann nur abgeschätzt werden. Ein TO220 Gehäuse mit dünner Schicht Wärmeleitpaste hat hier ca. 0,5-1K/W. Zum Schluss muss noch der Wärmewiderstand des Kühlkörpers addiert werden, dieser ist im Datenblatt angegeben. Vorsicht, bei größeren Kühlkörpern mit großen Rippen ist die Einbaulage wichtig, damit der Luftstrom frei strömen und gut kühlen kann (freie Konvektion, warme Luft strömt nach oben und kalte strömt unten nach). Die drei Wärmewiderstände werden addiert und über die oben angegebene Formel der Gesamtwärmewiderstand und damit die Temperaturerhöhung der Sperrschicht berechnet.

Wird eine Schaltung in einem Gehäuse eingesetzt, muss man dafür sorgen dass die warme Luft abgeführt wird, vor allem in Kunststoffgehäusen. Ansonsten gibt es einen Wärmestau und die Temperatur steigt deutlich!

=== Zwangskühlung ===

Natürlich muss der Kühlkörper die Wärme auch abführen können. Was aber, wenn der für den Wärmeabtransport benötigte Kühlkörper mechanisch nicht ins Gehäuse paßt?
Hier kommen die Lüfter zum Einsatz, das Ganze nennt sich dann Zwangskühlung.

Durch den Einsatz eines Lüfters lässt sich die der Wärmewiderstand des Kühlkörpers etwa um den Faktor 4 verbessern, bzw. der Kühlkörper lässt sich in der Größe ungefähr um den Faktor 7..8 reduzieren. Dies sind jedoch nur Richtwerte für den ersten Entwurf, eine Prüfung durch Messung ist unbedingt erforderlich. Der Effekt beruht darauf, daß mittels eines Lüfters wesentlich mehr Luft wesentlich schneller am Kühlkörper vorbeiströmen kann, und dabei mehr Wärme bei gleicher Temperaturerhöhung aufnehmen kann.

Beim Einsatz eines Lüfters ist auch daran zu denken, daß sowohl die Ansaugöffnung als auch der Kühlkörper verschmutzen und regelmäßig gereinigt werden müssen. Weiterhin erzeugt ein Lüfter natürlich auch Lärm. Je kleiner der Lüfter und je größer die benötigte Luftlieferleistung, umso lauter wird der Lüfter. Umgekehrt kann man aber mit einem großen, eher langsam laufenden Lüfter den Geräuschpegel stark absenken. Und letztendlich kann ein Lüfter auch kaputt gehen, womit die Kühlung deutlich verschlechtert wird und das Bauteil überhitzt. Hier empfiehlt sich bei wertvolleren Objekten eine Lüfterüberwachung, wie sie seit längerem bei PCs eingesetzt wird.

==== Physikalischer Hintergrund der Zwangskühlung mit Luft ====

Luft hat eine Wärmekapazität von ungefähr 1kJ/kg/K was bedeutet, daß für die Erwärmung von 1kg Luft um 1K eine Energiemenge von 1kJ = 1000Ws erforderlich ist. D.h. für den kontinuierlichen Abtransport von 100W Wärme werden mindestens 100g Luft pro Sekunde benötigt, wenn man diese nur um 1K erwärmen will.
Um also 100W von einem Kühlkörper abzuführen, der sich hier im Beispiel um 8K erwärmen darf, sind 100W / 8K = 12,5g Luft pro Sekunde erforderlich. Ein Gramm Luft hat ein Volumen von etwa 0,77l, d.h. bei 12,5 g muss der Lüfter 9,6 l/s bzw. 34,5 m^3/h liefern, die dann auch durch den gesamten Kühlkörper geblasen werden müssen.

== Die Platine als Kühlkörper ==

Bei kleineren Leistungen (< 5W) kann man auch die Platine als Kühlkörper benutzten. Dabei muss jedoch die Wärme vom Bauteil möglichst schnell auf eine größere Fläche verteilt werden. Dazu nutzt man große Kupferflächen direkt am Bauteil. Diese werden teilweise beidseitig angebracht. Die Wärme muss man dann jedoch mit vielen Vias von der einen Seite, auf der das Bauteil sitzt, auf die andere geleitet werden. Diese Vias heißen thermische Vias, da sie nicht als elektrische Verbindung sondern als Wärmeleiter dienen. Das funktioniert deshalb so gut, weil die Vias innen mit Kupfer beschichtet sind, welches die Wärme wesentlich besser leitet als das Material der Leiterplatte (FR2, FR4).
Verfügt ein SMD-Bauteil über eine sogenannte "Heatslug" oder thermal pad auf der Unterseite, muss dieses zur Wärmeableitung unbedingt angelötet werden. Dies ist mit einem normalen Lötkolben möglich, wenn die Platine an dieser Stelle mehrere Durchkontaktierungen mit einem Durchmesser von ca. 1,5mm aufweist. Durch diese Durchkontaktierungen kann genug Lötzinn auf die andere Seite fließen um diese Fläche mit der Platine zu verlöten.

Mit modernen Technologien ist es auch möglich, deutlich größere Wärmeleistungen von der Platine abzuführen. Dazu werden z. B. Platinen mit Aluminium- oder Kupferkern oder auf einen Metallträger laminierte PCBs benutzt (IMS = '''I'''nsulated '''M'''etal '''S'''ubstrat). Diese kommen z. B. bei Hochleistungs-[[LED]]s zum Einsatz. Für Hobbyzwecke sind sie aber noch wesentlich zu teuer, vor allem bei Einzelstücken.

== Peltierelement ==

Ein [http://de.wikipedia.org/wiki/Peltier-Element Peltierelement] arbeitet nach dem [http://de.wikipedia.org/wiki/Thermoelektrizit%C3%A4t#Peltier-Effekt Peltier-Effekt]. Dabei wird in einem Halbleiter durch Stromfluss eine Seite des Elements kalt, die andere heiß. Damit kann man ein kleines Objekt beliebig kühlen oder heizen. Allerdings sind Peltierelemente nur in eher kleinen Abmessungen und Leistung verfügbar (bis einige Dutzend Watt) und deren Effizienz ist auch nicht sonderlich hoch. Die allgemeine Auffassung, die könnten Wärme einfach verschwinden lassen ist falsch. Denn die heiße Seite muss klassisch gekühlt werden, je nach Temperaturunterschied mit mehr als der doppelten Kühlleistung als auf der kalten Seite an Wärme abgeführt wird.

== Heatpipe ==

Eine [http://de.wikipedia.org/wiki/Heatpipe Heatpipe],auf deutsch Wärmerohr genannt, ist ein Rohr, welches mit einer leicht verdampfenden Flüssigkeit gefüllt ist. Wird ein Ende erhitzt, verdampft die Flüssigkeit und nimmt dabei sehr viel Wärme auf. Der Dampf steigt im Rohr ans andere Ende, kondensiert dort und gibt dabei seine Wärme wieder ab.

Heatpipes werden auch als Wärmesuperleiter bezeichnet, weil sie Wärme 100-10.000 mal besser leiten als ein massiver Kupferstab mit gleichen Abmessungen.

Auch hier muss gesagt werden, dass eine Heatpipe allein '''kein''' Kühlsystem ist, denn die Seite, auf der das Wärmetransportmedium wieder kondensiert muss auch wieder klassisch gekühlt werden. Der grosse Vorteil ist die Abführung großer Wärmemengen auf engstem Raum, wie z. B. bei CPUs in Laptops.

== Flüssigkühlung ==

Im PC-Bereich ist es unter einigen Enthusiasten verbreitet, den Rechner entweder zu übertakten, um eine höhere Leistung zu erzielen oder super leise zu machen, um angenehmer arbeiten oder spielen zu können. In beiden Fällen muss eine große Wärmemenge abgeführt werden. Dabei wird die sehr hohe Wärmekapazität von Wasser genutzt, um auf kleinem Raum die Wärme von CPU, GPU, Festplatten etc. abzuführen. Aber auch hier ist zu beachten, dass am Ende einer Flüssigkühlung praktisch immer ein klassicher Wärmetauscher steht, welcher die Wärme an die Umgebung Luft abgibt. Dieser kann sich aber deutlich weiter entfernt vom zu kühlenden Objekt befinden als ein einfacher, direkt montierter Kühlkörper.

Bei der Verwendung von Wasser statt Luft als Kühlmedium reduziert sich die Durchflußmasse in etwa um den Faktor 4,2, da die Wärmekapazität von Wasser bei ca. 4,182 kJ/kg/K liegt. Da Wasser aber auch eine deutlich höhere Dichte als Luft besitzt (Wasser = 1g/cm³; Luft = 1,3mg/cm³) kommt noch der Faktor von ~770 dazu, woraus sich ein Gesamtfaktor für das Durchflußvolumen von ~3230 ergibt.

D.h. die Durchflußmenge in unserem oben genannten Beispiel (100W) sinkt auf ca. 2,9 ml/s bzw. 10,7 l/h.

Vorteile
*Abtransport großer Wärmemengen auf kleinstem Raum
*nahezu lautlos

Nachteile
*höherer Aufwand und Kosten
*Gefahr durch auslaufendes Kühlmittel

Im Bereich der Leistungselektronik wird Flüssigkühlung eingesetzt, im Hobbybereich nahezu nicht.

== Bauteilmontage auf dem Kühlkörper ==
Die Montage der klassischen Halbleitergehäuse nach TO220 und ähnlichen gestaltet sich augenscheinlich simpel: Die Kühlfahne hat ein Loch. Da ist es doch sehr verlockend, das Bauteil mit einer Schraube durch ebendieses Loch auf dem Kühlkörper zu befestigen...

Bei fachgerechter Ausführung spricht auch wenig gegen diese Montageweise; dazu gehört dann zum Beispiel das richtige Anzugsmoment für die Schraube. Zu lose und zwischen Bauteilgehäuse und wärmeabführender Oberfläche entsteht ein Luftspalt. Ein Wärmeleitpad oder Wärmeleitpaste schaffen zwar Abhilfe, aber die Wärmeleitfähigkeit dieser Stoffe liegt um Größenordnungen unter der von dem Aluminium des Kühlkörpers und der Kühlfahne. Ein vorhandenes Wärmeleitpad wird mitunter auch nicht weit genug zusammengedrückt, sodass auch (wie gehabt, abseits der ohnehin bescheidenen Leitfähigkeit) noch Optimierung möglich wäre. Nämlich durch festeres Anziehen der Schraube.
Zu fest aber und die Kühlfahne wölbt sich minimal. Dabei hebt der Bauteilkörper von der Oberfläche des Kühlkörpers ab und es entsteht wieder ein Spalt. Ungünstigerweise aber liegt der ''Heat-Spot'', also der Usprung des Wärmeflusses (Silizium-Chip) genau dort...

[[Datei: kuehlkoerper-montage.jpeg | thumb | 300px | Montagebeispiel]] Weitaus einfacher zu handhaben ist folgende Montageweise: Die Bauteile werden, ungeachtet der Montagebohrung, lose auf den Kühlkörper gelegt. Falls notwending natürlich mit Isolierstoff dazwischen und in jedem Fall hauchdünn mit einem Wärmeleitmittel bestrichen. Über die Bauteile wird dann ein Aluminiumprofil gelegt und erst dieses wird -- weiterhin mit einer Schraube pro Bauteil -- auf den Kühlkörper gespannt.
Abgesehen davon, dass so auch SMD-Bauteile (IPAK!) auf einem Kühlkörper Platz finden, entsteht Druck genau über dem Hot-Spot.

== Weitere Hinweise ==

*Große Hochlastwiderstände mit Keramikgehäuse werden im Normalbetrieb recht heiß (200..350°C). Diese Temperaturen sollten nicht auf die Platine kommen, denn das macht das Material nicht lange mit. Hier muss genau das Gegenteil von dem gemacht werden, was weiter oben für Bauteile ohne Kühlkörper empfohlen wurde. Die Anschlüsse müssen möglichst lang sein, damit wenig Wärme über sie abgegeben werden kann. Die Kühlung erfolgt nahezu nur über den Keramikkörper.
* Ein TO220 Gehäuse kann ca. 1W ohne Kühlkörper abgeben.
* Bei der Dimensionierung des Kühlkörpers sollte man sich nicht an der maximal zulässigen Sperrschichttemperatur orientieren, sondern möglichst um 10..50K kühler bleiben. Das verbessert die Funktionssicherheit und vor allem die Lebensdauer erheblich!
* Merksatz über den dicken Daumen: Pro 10 Grad Temperaturerhöhung halbiert sich die Lebenserwartung eines Bauteils. (Arrheniusgesetz, RGT-Regel, 10-Grad-Gesetz)
* Temperaturzyklen verkürzen die Lebensdauer von Schaltungen erheblich
* Meist sind mehrere kleine Kühlkkörper deutlich kleiner und billiger als ein Großer.

== Links ==

* [[Treiber]]

== Weblinks ==

* [http://sound.westhost.com/heatsinks.htm The Design of Heatsinks]. Eine ausführliche Seite zum Thema Kühlkörper, englisch
* [http://ludens.cl/Electron/Thermal.html Noch eine gute Seite, englisch]
* [http://wiki.oliverbetz.de/owiki.php/FormelSammlung Universelle Formelsammlung mit kurzen Erklärungen]
* [http://www.thermoconsult.de/01_TechInfo/Physik.pdf Grundlagen zur Kühlung, inhaltlich gut, Formatierung eher mies]
* [http://tangentsoft.net/elec/diy-hs.html DIY Heat Sinks]
* [http://www.fischerelektronik.de/ Kühlkörper bei Fischer Elektronik]
* [http://www.leiton.de/leiterplatten_teaser_alu.html Leiterplatten mit Alukern bei Leiton]
*[http://www.mikrocontroller.net/topic/84303 Guter Beitrag im Forum mit einer Beispielrechnung]

[[Kategorie:Bauteile]]
[[Kategorie:Leistungselektronik]]
[[Category:Grundlagen]]

Datei:Kuehlkoerper-montage.jpeg

2012-08-12T08:56:03Z

Haku: Montagebeispiel mit IPAK

Montagebeispiel mit IPAK

Elektronikversender

2012-06-24T09:43:49Z

Haku: /* TME (Transfer Multisort Elektronik) */

Die Vor- und Nachteile von verschiedenen Elektronik-Versand-Händlern werden relativ häufig im Forum diskutiert. Diese Diskussionen führen nicht selten zu weitestgehend gleichen Ergebnissen. In diesem Artikel sollen daher die Argumente, die für oder gegen einen bestimmten Elektronik-Versender sprechen, zusammengetragen werden. Sobald diese Liste einigermaßen vollständig ist, würde dies sicher einige Diskussions-Threads und/oder Flame-Wars überflüssig machen.

Diese Liste erhebt keinerlei Anspruch auf Vollständigkeit, d.h. wenn ihr einen Versender kennt, der hier noch nicht aufgeführt ist, dann nennt wenigstens die URL und den Namen. Den Rest können auch andere besorgen, die den Versender ebenfalls kennen!

Bitte ergänzt nur allgemeine Sachen (z. B. "liefert immer vollständig", "günstig" oder "große Auswahl"), aber nicht Sachen wie "mein ATMega 128 hatte verbogene Beine"! Bitte auch die alphabetische Sortierung beibehalten!

'''Diese Seite kann nur von angemeldeten Benutzern bearbeitet werden!'''

__TOC__

== Liste der Versender ==

=== AATiS ===
Homepage: http://www.aatis.de

* Arbeitskreis Amateurfunk und Technik in der Schule e.V.
* Bausätze speziell auch für Elektronik-Anfänger, Schüler
* Literatur, Seminare für Lehrer

=== Actron ===
Homepage: http://www.actron.de

* '''kein''' Online-Shop!
* alphanumerische LCDs und Graphikdisplays in großer Auswahl, auch mit Touchscreens
* für gewerbliche Kunden: etwas verhandeln schadet nie
* bei kleinen Stückzahlen nicht ganz billig
* liefern sehr schnell und stets zuverlässig

=== Adapterprofi ===
Homepage: http://www.adapterprofi.de

* Bauteile, Gehäuse, Netzteile
* Viele unterschiedliche HF-Adapter
* Seite aktuell nicht erreichbar (10.12.2011)

=== AK Modul Bus Computer GmbH ===
Homepage: http://www.ak-modul-bus.com/stat/produkte.html

* Interfaces, Messmodule, Funktionsmodelle, Experimentiersysteme
* Entwicklungssysteme, Baugruppen, Elektor, Zubehör, Bauelemente
* Software, Lernpakete, Bücher, Sonderposten

=== Allpax ===
Homepage: http://www.allpax.de

* Liefert auch an Privathaushalte
* Keine Elektronik an sich, aber ggf. nützliches Zubehör: Größeres, übersichtliches Sortiment an ESD-Beuteln und -Folien, offen und mit Zippverschluss, Pink Poly und Metallisiert (High Shield). Preislich über Farnell, dafür findet man sofort, was man sucht...
* außerdem Ultraschallreiniger, Waagen und Folienschweißgeräte, sowie viel Fachfremdes
* Versandkosten: 8,33€ nach Deutschland, diverse EU-Länder 17,85€, Schweiz 34,51€; Versandkostenfrei in D ab 178,50€
* Gewährt scheinbar auch Privatkunden die Zahlung per Rechnung; bei Bankeinzug 2% Rabatt, bei Vorkasse und Abholung 3%

=== AME-Engineering ===
Homepage: http://www.ame-engineering.de

* Hochfrequenz-Spezialitäten, Amateurfunk

=== Amidon ===
Homepage: http://www.amidon.de

* Sehr großes Sortiment, vorallem für seltene Bauteile, z. B. Dioden

=== Andy's Funkladen ===
Homepage: http://www.andyfunk.de

* Alles für Amateur- und CB-Funk
* Bauteile und Gehäuse

=== Anvilex ===
Homepage: http://shop.anvilex.com/index.html

* Liefert sehr günstige Break-Out Boards für diverse Packages
* Hat einige einfache und günstige Programmer auch für FPGAs etc

=== Atlantis Shop 24 ===
Homepage: http://www.atlantis-shop24.de

* Elektronik nur ein kleiner Teil des Angebotes. Ansonsten eher Drogerie bzw. Haushaltsbedarf

=== Atzert-Elektronik Versand ===
Homepage: http://www.atzert-elektronik.de

Früher ''EFB-Electronic Versand'', davor ''MEGAKICK Electronic Stores''.

* Mindestens schon der dritte Name und die dritte Webseite für den Endkunden-Versand von [[Elektronikversender#ETT|ETT]]. ETT liefert sonst nur an gewerbliche Kunden.
* Ladengeschäfte in Bielefeld, Braunschweig, Bremen, Hamburg und Berlin.
* Die Preise schwanken im Vergleich zu anderen Anbietern, welche ebenfalls ETT-importierte Produkte führen, mal nach oben, mal nach unten.

=== Bassenberg Elektronik ===
Homepage: http://www.bassenberg.de

* Ladengeschäfte in Braunschweig und Neumünster
* Beschafft auch nicht mehr gelistete und abgekündigte Bauteile
* Liefert auch an Privat

=== Batronix ===
Homepage: http://www.batronix.com
* Grosses Sortiment an Geräten
* Bausätze für Microcontroller-Applikationen
* Liefert auch an Privat

=== BAZ Spezialantennen ===
Homepage: http://www.spezialantennen.de

* Antennen für Amateurfunk, ISM, WLAN usw.

=== bed - elektronik ===
Homepage: http://www.bed-elektronik.de

* Restposten aktive und passive Bauelemente
* sehr günstige Preise
* alles ab Lager lieferbar
* Versand an Privat
* ab 60 EUR versandkostenfrei

=== Bfi-Optilas ===
Homepage: http://www.bfioptilas.de

* Kein Onlineshop
* spezialisierter Distributor für Hochfrequenzhalbleiter und Optik

=== BG-Electronics.de ===
Homepage: http://www.bg-electronics.de

* Online Shop für aktive und passive elektronische Bauelememte
* günstige Preise
* alle Artikel ab Lager lieferbar, daher kurze Wartezeiten
* weltweiter Versand
* zahlreiche Mengenrabatte
* viele Ersatzteile aus dem Audio-, CarHiFi und TV-Bereich

=== B & M electronics ===
Homepage: http://www.bmelectronics.de

* Bauteile, Platinen und Baugruppen für Amateurfunk

=== Box73 ===
Homepage: http://www.box73.de

Onlineshop des Funkamateur.

* Bauteile, Bausätze, Literatur aus dem Amateurfunkbereich
* Preise sind O.K.
* Bestellungen werden nur Di und Do bearbeitet
* Ab 50 EUR bei Bankeinzug portofrei.

=== Bürklin OHG ===
Homepage: http://www.buerklin.com

* große Auswahl, hohe Verfügbarkeit
* sehr schneller Versand
* Ladengeschäft in Oberhaching (südlicher Landkreis München)
* <s>nur an gewerbliche Abnehmer (lt. AGB), private Abnehmer können dennoch im Ladengeschäft einkaufen Angeblich versendet Bürklin seit November 2010 auch an Privatpersonen. Allerdings verlangt Bürklin weiterhin in Adressformularen die Eingabe eines Firmennamens Geben Sie einen Wert in das Feld "Firma" ein. Daher ist diese Information eher mit Vorsicht zu genießen.</s> Mittlerweile muss man auch keinen Firmennamen mehr eingeben. Die AGB wurde ebenfalls angepasst.
* 35 EUR Mindestbestellwert (incl. MwSt), darunter 7 EUR Bearbeitungskosten

=== CBsoft, s.r.o. (ltd.) ===
*Homepage: http://www.jjtubes.eu/
* Firma in der Slowakei
* Verkauft Röhren der Firma JJ
* englischsprachig
* Zahlungsmöglichkeiten in € mit Paypal und Kreditkarte

=== chiptrade.com ===
siehe [[#SE Spezial-Electronic AG|SE Spezial-Electronic AG]]

=== ConeleK Electronic ===
Homepage: http://www.conelek.com

* Sehr kleines Bauteileangebot (Röhren, Röhrensockel)
* Elektronik-Laborbedarf, insbesondere Nachfüllpackungen mit Steckbrett-Drahtbrücken
* Werkzeug für Elektronik
* Stromversorgungen
* Versand an Privat
* Versandkosten bis 25kg, Vorkasse 5,90€ (Stand 04/2008)

=== Conrad ===
Homepage: http://www.conrad.de und http://www.business.conrad.de

* großes Angebot (für Bauteile den "Business"-Katalog beachten, der Hauptkatalog ist dahingehend etwas "dünn") (Anm.: Bauteile, die nur im Business-Katalog aufgeführt sind, sind in Ladengeschäften nur über Sonderbestellung zu bekommen, d.h. dort in aller Regel nicht vorrätig.)
* Positiv: Wirklich jedes Bauteil kann einzeln gekauft werden und wird nicht in dämlichen Verpackungseinheiten verkauft, so wie es bei den meisten anderen Elektronik-Lieferanten der Fall ist. Dies ist vor Allem für den Prototypenbau sehr hilfreich.
* relativ teuer jedoch bis zu 10% Rabatt für Schulen (bei genügend Umsatz)
* 21 Ladengeschäfte in Deutschland, fünf in Österreich
* positiv: Bei Business-Kunden wird der Rechnungsbetrag erst nach 14 Tagen abgebucht.
* haben einen (teuren) 24 Std. Lieferservice für Notfälle - Conrad garantiert aber nicht 100%ig für die Einhaltung der 24 Stunden. Bei Nichteinhaltung gibt es kein Geld zurück.
* Verfügbarkeit in Filialen kann Online überprüft werden.
* Verfügbarkeit in Filialen kann über zentale Rufnummer erfragt werden. Abholung bestellter Ware in Filialen möglich, aber trotzdem gleiche Versandkosten.


=== csd-electronics ===
Homepage: [http://www.csd-electronics.de csd-electronics.de]

* ATMEL, ICs, Passive und Mechanische Bauteile, Platinen- und Lötzubehör, u.a.
* ca. 4000 Bauteile lagernd
* günstig
* Mengenrabatte für fast jedes Produkt
* Versand innerhalb Deutschlands:
* DPD: 3,75€ (ab 50 EUR versandkostenfrei)
* DHL: 4,50€ (ab 100 EUR versandkostenfrei)
* Versand EU-weit ab 5,95 EUR
* kein Mindestbestellwert
* schnelle Lieferung, sofern die Artikel auf Lager sind, versandkostenfreie Nachlieferung
* Bauelemente, die nicht im Shop angeboten werden, können auf Anfrage beschafft werden.
* Zahlung per Vorkasse (2% Skonto), PayPal, Nachnahme. 1 EUR Aufschlag bei PayPal-Zahlung
* Zahlung per Bankabbuchung, Kreditkarte oder Rechnung nur für Stammkunden (ab 4 bis 5 Bestellung), Für Institute/Firmen direkt auf Rechnung möglich
* haben ein Forum, in dem man sich zu Sammelbestellungen organisieren kann und auch allgemeine Fragen stellen kann -zur Zeit (05/2008) offline-

=== dad24 ===
Homepage, Shop: http://dad24.eu
E-Bay Shop: http://stores.ebay.de/Shop-dad24

* Unterschiedliche Preise in den beiden Shops
* Kleiner, nicht sonderlich schöner Onlineshop (dad24.eu)
* Kleines Angebot. Lupenleuchten, Lötstationen, Labornetzgeräte, Messgeräte, etc. aus dem unteren Preissegment
* Jede Woche eine neue "Kategorie der Woche" auf dad24.eu. Produkte aus der Kategorie werden erst im Warenkorb mit einem Rabatt angezeigt, der auch gewährt wird.

=== Darisus ===
Homepage: http://www.darisus.de

* kompetente Beratung
* liefert sehr zuverlässig, in Notfällen auch Express
* Versand innerhalb Deutschlands ab 4,50 EUR
* Hat auch eine gute Auswahl an CPLDs und einige FPGAs diverser Hersteller

=== Daschke LTD ===
PDF-Katalog (Achtung, grosse Datei): http://www.daschke-ltd.de/Catalog/

* Prompte Antwort und Hilfe via info ät obige adresse
* Bezahlung per Paypal und Rechnung möglich. Ist auch Ebay-Händler.
* sehr faire Preise für Bauteile und Versand
* Führt eine Vielzahl an unüblichen Steckern und Buchsen
* Nicht verfügbare Bauteile wurden proaktiv nachbestellt, trotz geringer Bestellmenge. Prima!

=== DES - Der Elektroniker-Shop ===
Homepage: http://www.DerElektronikerShop.de

* Bauteile
* Bauteilsätze der [http://www.DieElektronikerseite.de Elektronikerseite]
* Verkauf des BasicBeetle und Zubehör von [http://www.DieProjektseite.de der Projektseite]
* Ständig wachsendes Angebot
* Auch einige SMD-Bauteile verfügbar
* Kein Mindestbestellwert
* Versandkosten ab 3,50 EUR (Österreich/Europa ab 4,00 Eur)
* Versand auch nach Österreich (Europa auf Anfrage)
* Zahlung per Vorkasse
* Lieferzeit 1-3 Tage bei Verfügbarkeit
* PrePaid-Konto möglich
* Lieferungen auch an Privat

=== Digi-Key ===
(tlw.) deutsche Homepage: http://de.digikey.com

* optisch nicht besonders ansprechende, aber durchaus sehr funktionelle Website
* beheimatet in den USA, ein Logistikbüro gibt es in den Niederlanden
* kostenloser Versand ab 65€, darunter 18€ Versandkosten
* macht merkwürdige Plausibilitäts-Checks: wenn man privat über ihrem Dollar Limit (z.B. 400 Dollar bestellt) kommt sofort die Rückfrage nach Firmenname und Firmenadresse
* Rückfragen nach dem Verwendungszweck kommen ebenfalls schon bei der Bestellung bei bestimmten Bauteilen die der Exportkontrolle unterliegen
* Versand direkt aus den USA, dafür sehr flott mit UPS Express (in rund zwei bis drei Tagen da)
* riesiges Angebot, gewissermaßen ein Distributor der auch Kleinmengen an Privatpersonen liefert, entscheidend ist, dass der Hersteller des Produkts geführt wird
* kein anderer Anbieter, bietet so viele verschiedene passive Bauteile in kleinen Stückzahlen, z. B. SMD Widerstände in Bauform 01005 bis 2512 meist in verschiedenen Toleranzklassen und von verschiedenen Herstellern
* alle Bauteile mit Herstellerangabe, Digikey kauft ausschließlich direkt vom Hersteller
* Preise sind auf der deutschen Website in Euro inklusive etwaigem Zoll angegeben, allerdings ohne Mehrwertsteuer, die korrekt abgerechnet wird (d.h. man zahlt bei Versand nach Österreich 20% Mwst., nach Deutschland m.W.n. 19%)
* Meistens deutlich teurer als Reichelt, doch häufig die beste Anlaufstelle für Privatkunden wenn es um Spezialbauteile geht, und der Hersteller sich im Programm von Digikey befindet

* Zu beachten ist auch noch folgendes, um unliebsame zusatzkosten zu vermeiden: http://www.mikrocontroller.net/topic/90943#new. ''Anmerkung dazu: Digikey hat wohl zum 1.4.2011 den Versand umgestellt und importiert nun selbst. Zusatzkosten durch Verzollung sollten dann nicht mehr anfallen.''

=== Display Electronics ===

Homepage: http://www.distel.co.uk

* In England
* Webseite = Augenkrebs
* Online-Shop versteckt hinter dem Search-Button auf der Homepage
* Restposten aller Art
* Mindestbestellwert 10 GBP

=== eHaJo ===
Homepage: http://www.eHaJo.de

* Bausätze
* Lötübungen
* AVR-ISP-Stick

=== Eisch-Kafka-Electronic ===
Homepage: http://www.eisch-electronic.de

* Hochfrequenz Bausätze und Bauteile für Amateurfunk

=== EleConT ===
Homepage: http://www.elecont.de/shop/

* Carrierboards für gebräuchliche AVR

=== Electropuces ===
Homepage: http://perso.wanadoo.fr/electropuces/

* Gebrauchte Messgeräte aus Nantes, Frankreich (teilweise engl. Menü)

=== Electronic Search ===

Homepage: http://www.electronic-search.de

* Keine Mindestbestellmenge
* Verkauf auch an Privat/Bastler
* Fast alle Preise im Online-Shop nur "auf Anfrage", und nicht im Shop angegeben.

=== electronicpool Rheinstetten ===
Homepage: http://www.electronicpool.de

* abgekündigte oder schwer beschaffbare elektronische Bauteile

=== Elektronikladen ===
Homepage: http://www.elektronikladen.de

* Spezialist für Mikrokontroller
* Entwicklungssysteme, keine Einzelbauteile
* entsprechende Literatur und Software
* "Kein Verkauf an Endverbraucher i.S.d. §13 BGB"

=== Elektronik-Kompendium ===
Homepage: http://www.elektronik-kompendium.de

* Bausätze diverser Schaltungen (mit Anleitung und Funktionsbeschreibung)
* erspart lästiges Suchen in anderen Shops
* kurze Lieferzeiten
* günstiger Versand

=== Elk Tronic ===
Homepage: http://www.elk-tronic.de

* kleines Lieferprogramm Adapterplatinen (SMD -> 2,54mm-Raster) und Programmieradapter
* günstige Preise und Versandspesen

=== Elko-Verkauf ===
Homepage: http://www.elko-verkauf.de

* Nur Low-ESR-Elkos
* Elko-Sets für ein Gerät

=== Ellmitron ===
Homepage: http://www.ellmitron.de/
Katalog: http://www.ellmitron.de/katalog.pdf

Lehrmittel, Kleinbausätze vor allem für Schüler, Experimentierkästen

=== Elpro Darmstadt ===
Homepage: http://www.elpro.org

* Kein Mindestbestellwert, aber hohe Versandkosten für kleine Bestellungen. Stand September 2008:
** Bis 15€: 9,95€ Versandkosten
** Von €15 bis €75: 5,95€ Versandkosten
** Von €75 bis €200: 4,49€ Versandkosten
** Ab €200: Versandkostenfrei
* Große Auswahl an Mikrocontrollern
* Sehr große Auswahl an Schaltnetzteilen von Meanwell (geschlossen, offen, auf PCB lötbar, DIN-Schiene)
* Merkwürdig zu bedienende Shopsoftware, ständig klappt was auf und zu und wird irgendwas nachgeladen. Braucht JavaScript
* Keine AGBs online. Da Preisangaben ohne MwSt. richtet sich das Angebot vermutlich nicht an Endverbraucher (werden aber beliefert)
* Bearbeitungszeit (bis Warenausgang) 2-3 Tage.
* Versand bisher mit DHL
* gute bis sehr gute Verpackung

=== Eltrix ===
Homepage: http://eltrix.de/Starteltrix.htm

* Verbrauchsmaterial, Tipps und Tricks fürs Leiterplattenherstellen und Löten

=== ELV ===
Homepage: http://www.elv.de

* nicht sehr große Auswahl an Einzelteilen
* riesiges Angebot an Zubehör für Hobbyisten
* viele z.T. pfiffige Eigenentwicklungen, Bausätze (auch zum Download auf der Website verfügbar)
* sonst Sortiment ähnlich Conrad, nicht billig
* im Allgemeinen nicht billig, merkwürdigerweise sind manche Artikel aber die günstigsten auf dem Markt
* mühsamer Onlinekatalog
* Immer mal wieder Fehllieferungen und Wartezeiten (zumindest in die Schweiz). Service erreichte in 3 Fällen nicht das inserierte Niveau.
* Versandkosten innerhalb Deutschland 4,5€, ab 150€ Bestellwert versandkostenfrei
* nicht abwählbare Versandversicherung, die 0,85% des Bestellwertes kostet



=== ETT - Electronic Toys Trading ===
Homepage: http://www.ett-online.de

* Großhandel nur für Gewerbekunden.
* Zweitshop [[Elektronikversender#Atzert-Elektronik_Versand|Atzert-Elektronik Versand]] (früher EFB-Electronic Versand, davor Megakick Electronic-Stores) für Endkunden.
* Ladengeschäft in Braunschweig für jedermann. Weitere Atzert Ladengeschäfte in Bielefeld, Bremen, Hamburg und Berlin.
* Eigentümer der Marken McCHECK®, McPower®, McVoice® und anderer, unter denen ETT importierte Messgeräte, Labornetzteile, usw. an Großkunden und Händler vertreibt. Diese sind unter oben genannten Marken dann in vielen Shops anderer Firmen für Endkunden zu finden, nicht nur bei Atzert. Preisvergleiche lohnen.

=== Ettinger GmbH ===
Homepage: http://www.ettinger.de

* Für gewerbliche Kunden
* Mechanische Komponenten (Gehäuse, Abstandshalter, Drehknöpfe, usw.)
* LEDs
* Gewöhnungsbedürftiger Online-Shop

=== EVE ===
Homepage: http://www.eve.de

* Zitat aus den AGBs:
::''"Zu Bestellungen im Rahmen des Online-Handels sind nur durch uns autorisierte, d. h. zugelassene Käufer berechtigt. Wir gewähren nach erfolgreicher Zertifizierung – ohne hierzu verpflichtet zu sein – dem jeweiligen Käufer das nicht übertragbare, nicht exklusive Recht im Rahmen des Online-Handels Bestellungen uns gegenüber “auszubringen”."''

:Dies darf man wohl getrost als Hinweis ansehen, dass Endverbraucher als Kunden nicht gewünscht sind.
* Versandhaus für elektronische Artikel in Emsdetten
* machen auch Kabelkonfektion
* Pb-freie Artikel markiert

=== Farnell ===
Homepage: http://de.farnell.com

* liefert nur an gewerbliche Abnehmer, Ausnahme sind Studenten und HTL-Schüler (Österreich, Farnell.at). Nachweis wird verlangt (Gewerbeschein oder Immatrikulation).
* Lieferungen an Privat:
:* Schweiz: Farnell Schweiz beliefert auch Privatkunden.
:* Deutschland: Über den Reseller [[#HBE_-_Heinz_B.C3.BCchner_Elektronik.2C_Messtechnik.2C_med._Elektronik_e.K.|HBE]] kann man Produkte aus dem Farnell-Sortiment zu bestellen.
:* Österreich: [[#Technik-Welt / Industrieshop.at|Technik-Welt / Industrieshop.at]]
* große Auswahl
* 12% Rabatt für Studenten und Lehreinrichtungen
* sehr schneller Versand, Ware ist in 99% aller Fälle am nächsten Tag da (UPS), fehlende Positionen werden relativ rasch versandkostenfrei nachgeliefert
* Versandkosten: Bestellung bis 49,99€: 7,95€; 50,- bis 149,99€: 5,95€; ab EUR 150,- versandkostenfrei
* hat nach eigenen Aussagen umfangreichstes Sortiment an RoHS-konformen Bauteilen mit Suchfunktion im WWW
* leistungsfähige parametrische Suchfunktion / teils aber völlig nutzlos, da den Artikeln massenweise Tags fehlen, weswegen die Suchergebnisse unnötig eingeschränkt werden
* Datenblätter für die meisten Bauteile online
* Internetpräsenz fällt nachts oft aus (Hinweis auf angebliche geplante Wartungsarbeiten)
* Sortierfunktion wird bei der Suche ständig zurückgesetzt, im Warenkorb ist überhaupt keine sinnvolle Sortierung möglich
* Eigenwillige Preispolitik: Einiges sehr günstig, Anderes total überteuert

=== Fibra-Brandt Zweibrücken ===
Homepage: http://www.fibra-brandt.com

* lagert tausende veraltete und schwer zu findende elektronische Bauteile
* Halbleiter, IC's, Transistoren, Spulen und Kondensatoren.
* Sonderbeschaffung von abgekündigten Halbleitern.

=== Fischer DK2FD ===
Homepage: http://www.dfe-online.de

* Baugruppen für Hochfrequenzmesstechnik und Amateurfunk

=== Funkamateur Online-Shop ===

Siehe [[Elektronikversender#Box73]]

=== Futurelec ===
Homepage: http://www.futurlec.com

* günstiger Versender aus Übersee
* viele Stamp-Boards
* LED Matrix-Module

=== Future Electronics ===
Homepage: http://de.futureelectronics.com

* große Auswahl an Teilen
* Versand auch an Privatpersonen
* Preisangaben ohne MwSt.
* Zahlung nur mit Kreditkarte
* Versandkosten 7,14€ (Brutto)
* Versand aus den USA mit FedEx, Lieferzeit meist unter 5AT
* Verzollung usw. wird von FutureElectronics gemacht, keine Nachzahlungen etc.

=== Geist Electronic-Versand GmbH ===
Homepage: http://www.geist-electronic.de

* Liefern Bauteile für Elektor-Projekte
* D-78054 Villingen-Schwenningen
* Versandkosten: 5.40€

=== Giga-Tech ===
Homepage: http://www.giga-tech.de

* Spezialitäten für Hochfrequenz / Amateurfunk
* 68542 Heddesheim

=== Grummes Elektronik ===
Homepage: http://www.grummes.de

* Elektronikversender /CNC-Fräsmaschinen / Schrittmotorsteuerungen / Bauteile
* Homepage nicht aufrufbar (10.12.2011)

=== Glyn (GLYNshop) ===
Homepage: https://www.glynshop.com/erp/welcome.do

* "B2B Shop" = nicht für Privatkunden
* Microcontroller, Evaluation Boards, TFT-Displays, LC-Displays, Memory Cards u.a.

=== guloshop.de ===
Homepage: http://guloshop.de

* kleiner Shop, konzentriert sich auf Standard-AVRs im DIP-Gehäuse, ist dabei aber meist der billigste Versender in Deutschland
* ATtiny, ATmega, Breakout-Boards, Programmer, Adapterkabel, IC-Fassungen
* AVR mit geflashtem Arduino-Bootloader
* äußerst niedrige Preise
* liefert schnell und zuverlässig, jedoch nur gegen Vorkasse
* kein Mindestbestellwert, Versandkosten für kleine Bestellungen: 2,40 EUR

=== H-Tronic ===
Homepage: http://www.h-tronic.eu/index.php

* Online-Shop einer Entwicklungsfirma, in dem neben Baugruppen und Geräten auch einige Bauelemente und Elektronikzubehör angeboten werden
* kleines Angebot

=== Hallmanns Elektronik ===
Homepage: http://www.hallmanns.com 
Adresse: Bruno Hallmanns, Weierstraße 41, 52349 Düren

* Elektronikhändler mit Ladenlokal und Versand
* Ladentypisches Sortiment (Bauteile, Geräte, PC, Funk, Hifi...)

=== Hari Seligenstadt ===
Homepage: http://www.hari-ham.com

* Bausätze, Ringkerne, Geräte für Amateurfunk

=== HBE - Heinz Büchner Elektronik, Messtechnik, med. Elektronik e.K. ===
Homepage: http://www.hbe-shop.de/katalog/

* Bezeichnet sich als ''[[#Farnell|Farnell]] Fachhändler'', bei dem nichtgewerbliche Kunden aus dem Farnell-Sortiment bestellen können.
* Preise für Farnell-Produkte normalerweise Farnell Netto-Preis + MwSt.
* Mindestbestellwert 25,- € (netto), Mindermengenzuschlag 5,- € (Stand 06/2010)
* Versandkosten 4,75 € (netto), ab 75,- € (netto) versandkostenfrei (Stand 06/2010)

=== Heho-Elektronik ===
Homepage: http://www.heho-elektronik.de
* Halbleiter / Bauteile, Sortimente, Handy - Akkus, VELLEMAN - Bausätze
* Aktuelles Angebot, Ladegeräte / Akkuladegeräte, Blei - Akkus
* Spannungswandler, Audio / Video / USB - Kabel, Netzwerk - Kabel
* 1-2 Arbeitstage für Waren ab Lager
* Porto + Verpackung pauschal Euro 4,50
* Mindestbestellwert von € 10,00

=== Hinkel ===
Homepage: http://www.hinkel-elektronik.de

* Von der Webseite "Unser Angebot richtet sich an Schulen, Behörden, Handel, Handwerk und Industrie."
* Batterien
* Knopfzellen, spezielle KZH, die man sonst lang sucht, findet man hier
* Mindestbestellwert von 20€
* Standardversand innerhalb Deutschlands 5,80€

=== HN Electronic Components GmbH & Co. KG / Netzteilshop ===
Homepage gewerbliche Kunden: http://www.hn-electronic.de/homed/framed.html 
Homepage Endkunden: http://www.netzteilshop.com/hnshop.html

* Netzteile aller Art
* Lieferung an Endkunden nur per UPS Nachnahme.
* Mindestbestellmenge für Endkunden 25 €

=== HW-Electronics ===
Homepage: http://www.hw-electronics.de 
Homepage EU: http://hw-electronics.eu/

* Tauch- und Sprühätzanlagen
* Entwicklungsgeräte
* Belichtungsgeräte, Materialsätze zum Selbstbau von Belichtungsgeräten

=== ID-Elektronik ===
Homepage: http://www.id-elektronik.de

* Amateurfunk-Baugruppen

=== IT-WNS ===
Homepage: http://www.it-wns.de

* "Bauteile, Platinen, Bausätze" insbesondere mit ATMEGA und ENC28J60
* Bausätze zu Projekten aus dem Forum, z. B. USBprog, ChipBasic, Mikro-Webserver, Transistortester u.v.a.m.
* Atmega32/644 Experimentiersystem als Bausatz mit vielen Zusatzmodul-Bausätzen
* SD-Slots, RFID, Bluetooth-Module, AVR Mikrocontroller uvam.
* Bauelemente, die nicht im Shop angeboten werden, können auf Anfrage (Kontaktformular) beschafft werden
* günstige Preise und Versandkosten ab 1,90EUR, kein Mindestbestellwert
* schneller Versand, sofern die Artikel auf Lager sind, versandkostenfreie Nachlieferung

=== Kabelscheune ===
Homepage: http://www.kabelscheune.de

* "Direktversand von Elektromaterial und Multimediaprodukten"

=== Kelemen ===
Homepage: http://www.kelemenantennen.de/Kelemen-Shop/

* Messgeräte, Antennen und Zubehör für den Amateurfunk

=== Kessler ===
Homepage: http://www.kessler-elektronik.de

* im Preis-Leistungsverhältnis mit Reichelt zu vergleichen (sprich: günstig)
* Sortiment kleiner als Reichelt und mit gewissen Abweichungen (z. B. andere FPGA und RAMs)
* oft lange Lieferzeiten
* Versandkosten innerhalb Deutschlands 4,95€ bei Bankeinzug und 6,90€ bei Nachnahme plus Nachnahmegebühren
* Der Download-Katalog ist von 2002! Online aktueller

=== Klein-Electronic ===
Homepage: http://www.klein-electronic.de

* Baugruppen zur Video- und 2,4GHz-Sendetechnik

=== Konni-Antennen ===
Homepage: http://www.konni-antennen.de

* Antennen für TV, Amateurfunk
* Zubehör, Einzelteile
* sehr netter kompetenter Service

=== Köditz Nachrichtentechnik ===
Homepage: http://www.koeditz-nachrichtentechnik.de

* Baugruppen und Bauteile für Amateurfunk und TV-Satellitenempfang

=== Kuhne DB6NT ===
Homepage: http://www.kuhne-electronic.de

* Baugruppen und Bausätze für Mikrowellenamateure

=== LEDSEE Electronics ===
Homepage: http://www.ledsee.com

* LEDs, LCDs, diverses
* Lieferung direkt aus China, daher sehr günstig und lange Lieferzeiten

=== LED Microtechnics LTD ===
Homepage: http://www.ledmeile.de

* "LED Shop und Lampentechnik"

=== LED-Tech LED-Shop ===
Homepage: http://www.led-tech.de

* viele verschiedene LEDs zu sehr guten (meist den günstigsten) Preisen
* vor allem auf High-Power-LEDs spezialisiert
* viele verschiedene Treiber für High-Power-LEDs
* kostenloser Versand
* haben ein eigenes, sehr umfangreiches Forum

=== Lieske Elektronik ===
Homepage: http://www.lieske-elektronik.de

* liefert nur an Geschäftskunden

=== LUMITRONIX LEDs-Shop ===
Homepage: http://www.leds.de

* alles rund um LEDs (auch Zubehör und Lektüre)
* neben Standard-LEDs auch SMD- und SuperFlux-LEDs

=== Marsch Elektronik, M. Schlimper ===
Homepage: http://www.marsch-elektronik.de

* Online Shop für aktive und passive Bauelemente
* Versandkosten ab Euro 1,60
* kein Mindestbestellwert
* bietet auch Einsteigersortimente und Widerstandsortimente (auch SMD)
* liefert nur innerhalb Deutschlands
* nicht gelistete Artikel können angefragt werden und werden meist auch beschafft

=== Mauritz Communication & Electronics ===
Homepage: http://www.mauritz-shop.eu

* Online Shop für HF-Stecker und Kabel
* bietet HF-Stecker/Buchsen und Koaxkabel an
* große Auswahl, auch exotische Teile
* Kabelkonfektionierung nach Wunsch
* vernünftige Preise
* liefert nach Rücksprache auch weltweit
* Keine Mindestbestellwert, aber 5 € Aufschlag unter 15 €
* Versand bis 40 kg pauschal 5,95 € per GLS innerhalb DE
* schneller Versand
* Paypal oder Vorkasse

=== Mein-Daarle ===
Homepage: http://www.mein-st-arnual.de/shop/saarbruecken/artikellisteL.html

* Teileliste eines "Händlers aus Saarbrücken" (wahrscheinl.: Frank Skowronek ESS Elektronik Service), "bis sein Onlineshop ans Netz gehen kann"
* derzeit (4/2011) kein Onlineshop, Kontakt über Formular

=== Micromaus ===
Homepage: http://www.micromaus.de

* Sensoren
* Mikrokontroller
* kein Mindestbestellwert

=== Microcontroller-Starterkits ===
Homepage: http://www.microcontroller-starterkits.de

* Bauteile: CAN, Ethernet, Mikrokontroller AVR und ARM, Linearregler 1,8V 3,3V 5V in SOT223
* Leerplatinen, Bausätze
* günstig
* Abholung in Hattingen möglich
* Versandkosten innerhalb Deutschlands ab 2,50€
* keine Kreditkartenzahlung möglich

=== Mikrocontroller.net ===
Homepage: http://shop.mikrocontroller.net

* Starterkits, Development Boards und Zubehör für AVR, AVR32, ARM und MSP430

=== Mira Nürnberg ===
Homepage: http://www.mira-electronic.de

* SMD-Bauteile, SMD-Sortimentboxen
* Verkauf und Preisangaben nur für Gewerbetreibende

=== Karl Müller EME Messtechnik ===
Homepage: http://www.eme-hf-technik.de

* Hochfrequenz-Messtechnik, HF-Komponenten

=== Mouser ===
Homepage: http://de.mouser.com

* Liefert an Privat
* Zügige Lieferung mit FedEx aus den USA
* Keine Halbleiter von Linear, National und Analog

=== MS-Elektronik ===
Homepage: http://www.ms-elektronik.info

* Liefert an Privat
* Zügige Lieferung
* Gute Qualität
* Viel in Richtung Audio
* Große Auswahl an Elkos -> kleine Preise
* kein allzu großes Sortiment

=== Mütron ===
Homepage: http://www.muetronshop.de

* Keine Privatkunden

=== myAVR Shop ===
Hompage http://shop.myavr.de

* Kleine Auswahl, aber die angebotene Ware ist sehr preiswert (meist preiswerter als bei Reichelt)
* Zügige Lieferung (1-2 Werktage)
* Diverse Zahlungsmöglichkeiten: Rechnung, Vorkasse, Lastschrift, Kreditkarte, PayPal
* Kein Mindestbestellwert
* Sehr günstige Versandkosten ab 1,95 Eur
* Mengenrabatt ab 10 gleichen Artikeln

=== Neuhold-Elektronik ===
Homepage: http://www.neuhold-elektronik.at 
Shop: http://www.neuhold-elektronik.at/catshop/default.php?language=de

* preiswerte Schnäppchen
* regelmäßig aktualisierte Angebotsliste herunterladbar
* Ab 60,- EUR versandkostenfrei in Österreich

=== Octamex ===
Homepage: http://www.octamex.de

* Leiterplattenchemie (Entwickler, Ätzmittel, CRC-Sprays)
* Chemisch Zinn
* Lötstopp-Laminat, Tentingresist, Bestückungsdruck
* Bungard Basismaterial in 0,5mm 1,0mm 1,5mm Dicke und 18µm, 35µm, 70µm Kupfer
* Bungard Alucorex für 19" Frontplatten
* Bungard Cotherm, Alukernbasismaterial
* Funkmodule 434MHz, 868MHz, 2.4GHz
* Löttechnik und Zubehör
* Gehäuse aller Art
* Messgeräte und Labornetzteile
* aktive, passive u. mechanische Bauelemente (Widerstände, Kondensatoren, Transistoren, Logik-ICs etc.)
* kein Mindestbestellwert
* Lieferung auch ins Ausland
* Versandkosten ab 4,50EUR
* Liefert nur gegen Vorkasse, ausser für Bestandskunden, die schon häufig bestellt haben
* Zahlung mit EC-Pay oder Kreditkarte nur gegen Aufschlag (bis zu 5%)

=== Online Batterien ===
Homepage: http://www.online-batterien.de

* Allerlei günstige Batterien & Akkus vieler Marken
* z. B. '''40 Stk.''' DURACELL PLUS LR6 AA 11,59€ (Jan 2010)
* Beleuchtungsartikel
* USV
* Versand ab 3,90€

=== Oppermann ===
Homepage: http://www.oppermann-electronic.de

* Restposten, auch HF Bauteile
* auch Privatkunden
* Lieferung nach üblicher Zeit

=== PCB-Soldering ===

Homepage, Online-Shop: http://www.pcb-soldering.co.uk
eBay: http://www.allendale-stores.co.uk
Firmen-Homepage: http://www.allendale-elec.co.uk

* [http://www.aoyue.com/en/products.asp Aoyue] Lötstationen und preiswertes Zubehör (Lötspitzen) für diese. Bei Aoyue-Zubehör bessere Preise (Stand 10/2008) als [[#WilTec_Wildanger_Technik_GmbH|WilTec]]
* Schnelle Lieferung
* Dank [http://www.zoll.de/b0_zoll_und_steuern/a0_zoelle/a1_grundlage_zollrecht/b0_zollgebiet/index.html EU Binnenmarkt] nur britische Mehrwertsteuer (VAT), kein Zoll, keine [http://www.zoll.de/b0_zoll_und_steuern/a3_einfuhrumsatzsteuer/index.html Einfuhrumsatzsteuer] fällig.
* Zwei von drei E-Mails wurden nicht beantwortet
* Versandart wurde eigenmächtig von "Standard" auf teureres "Signed for" (Einschreiben) geändert

=== Pollin Electronic ===
Homepage: http://www.pollin.de

* Günstige Restposten aller Art (z. B. "250 g verschiedene ICs" u.dgl.)
* Produktkategorien:
** Computer und Zubehör
** Telefone und Zubehör
** Antennentechnik
** HiFi/Car-HiFi/Video/TV
** Stromversorgung
** Lichttechnik
** Messtechnik / Uhren
** Haustechnik
** Werkstatt
** Bauelemente
** KFZ- und Zweirad
** Motoren
** Bausätze
** Fundgrube
* Produkte teils schnell ausverkauft
* Qualität schwankend. Man kann gute Schnäppchen machen aber auch reinfallen. Umtausch ist dann aber problemlos.
* Es wird öfters von sorgloser Verpackung berichtet, trotz Verpackungspauschale von 0,85 % des Warenwerts (empfindliche und schwere Produkte besser nicht zusammen bestellen). Reklamationen bei Beschädigungen werden freundlich behandelt.
* Lieferzeit i.d.r. 2-3 Werktage / knappe Woche bei neuer Sonderliste
* Ladengeschäft in 85104 Pförring
* Versandkosten innerhalb Deutschlands 4,50 € (ab 150€ versandkostenfrei); dazu 0,85 % Verpackungspauschale
* Zahlung per Nachnahme (+2,50 €) oder Bankeinzug (keine Kreditkarte, keine Überweisung)

=== proma / Isel ===
Homepage: http://www.proma-technologie.com/deutsch/rundum_l/proma_fs_1.html

* fotobeschichtete Leiterplatten Platinenfrästechnik
* Chemikalien für die Platinenherstellung: Ätzmittel, Flussmittel für Lötanlagen, etc.
* Profilgehäuse, u.a. von Conrad und Reichelt vertrieben

=== QRP-project ===
Homepage: http://www.qrpshop.de/sitemap.htm
* Bausätze vor allem einfache Kurzwellen-Funkgeräte

=== Reichelt ===
Homepage: http://www.reichelt.de

* relativ große Auswahl, aber nicht viele "brandaktuelle" Bauteile
* wenn man höflich fragt, liefern sie ganz selten auch Bauteile, die nicht im Katalog stehen zu "normalen" Preisen (vorausgesetzt der Hersteller ist im Sortiment), z. B. Xilinx XC2S50, aber meist erhält man die Antwort, dass der Artikel nicht im Sortiment ist, obwohl auf der Homepage unter Service extra ein Punkt angeführt ist: "Ich benötige einen Artikel, der nicht im Programm ist"
* reagiert aber teilweise auch auf Anregungen, neue Produkte in das Angebot aufzunehmen; siehe dazu auch den Artikel [[Reichelt-Wishlist]]
* liefert schnell und vollständig; wenn etwas ausnahmsweise nicht verfügbar ist, dann liefern sie es auf eigene Kosten nach, wenn der Artikel in absehbarer Zeit wieder vorrätig ist (selbst wenn er nur 0,20€ wert ist).
* lässt einen dennoch manchmal warten, wenn ein Artikel nicht lieferbar ist! Daher bei der Bestellung immer darauf hinweisen, dass man auch eine Teillieferung akzeptiert. (Laut Auskunft dauert das länger, besser nach der Inet-Bestellung anrufen und nicht lieferbare Teile aus der Bestellung streichen lassen)
* Lieferzeiten normalerweise 2 - 4 Arbeitstage
* niedrige Preise (aber unbedingt Qualität des Artikel checken)
* Versandkosten 5,60€ (Deutschland); 10€ Österreich; Schweiz 16€; EU 15 - 19€;
* 10€ Mindestbestellwert für alle Länder
* auch in die Schweiz sehr guter Service
* holt sich auch ohne Erlaubnis Bankauskünfte bei großen Bestellungen ein

=== RFW Elektronik ===
Homepage: http://www.rfw-elektronik.de

* HF Bauelemente

=== Ribu ===
Homepage: http://www.ribu.at

* Sehr guter Elektronikversand in Österreich mit zahlreichen Entwicklungsboards und zahlreichen Elektroniklösungen.
* Liefert sehr schnell und hat eine ausgezeichnete Beratung.
* Online-Shop ist sehr übersichtlich und einfach zu bedienen.
* Lieferstatusanzeige für alle Artikel. Bei Auslaufartikeln ist sogar die noch verfügbare Stückzahl sichbar.
* Günstige Sonderangebote
* innerhalb Österreichs 4,90€ Versandkosten, ab 80,- keine Versandkosten
* ausserhalb Österreichs 13€ Versandkosten, ab 225€ versandkostenfrei
* liefert auch an Privatkunden
* Mindestbestellwert innerhalb Österreichs 10€, ausserhalb 30€

=== Richardson Electronic ===
Homepage: http://www.rell.com/international/index.asp?ID=GE

* Hochfrequenz-Halbleiter, HF-Röhren,

=== Riedl Elektronik ===
Homepage: http://www.riedl-electronic.at

* großes Angebot v.a. ICs und Trafos
* recht günstig
* Rabatt für Schüler/Student
* Versand nach AT: 3,95€ bis 1kg, ab 100€ frei Haus
* Versand AT über 1kg sowie Ausland: Nach Aufwand (wird nicht direkt angezeigt)

=== RLX COMPONENTS s.r.o. ===
Homepage: http://www.rlx.sk

* Man spricht Deutsch
* Messgeräte, Mikrocontroller-Boards, Bauelemente

=== RM Computertechnik GmbH ===
Homepage: http://www.rm-computertechnik.de

* Kerngeschäft ist PC-Technik, aber auch großes Sortiment an Kabeln, Litzen und Steckverbindern
* handelt auch mit einigen Bauelementen, wie LED's

=== Robotikhardware===
Homepage: http://www.robotikhardware.de

* Microcontroller
* Entwicklungsboards
* Sensoren
* Robotik-Zubehör
* günstige Angebote für Hobbyelektroniker
* auch einzelne Platinen

=== Robotik-Teile.de===
Homepage: http://www.robotik-teile.de

* Große Auswahl an Elektronik Produkten
* Microcontroller, Sensoren, Zubehör, u.v.m.
* Versandkosten betragen immer 4,90 €
* Zahlbar ber PayPal, Sofortüberweisung, Vorkasse und Nachnahme

=== Benno Rößle Elektronik ===
Homepage: http://www.roessle-elektronik.de

* Masten, Antennen, Befestigungsmat.,Zubehör, Geräte, Anpassteile, HF-Stecker

=== RS Components ===
Homepage: http://de.rs-online.com

* lt. AGB nur an gewerbliche Abnehmer und an Studenten. Bei Internetbestellungen wird per Mail nach Belegen gefragt.
* gute Auswahl insbesondere an "mechanischen Bauteilen"
* gute Verfügbarkeit
* sehr schneller Versand, Ware ist in 99% aller Fälle am nächsten Tag da (GP)
* Preise wurden angepasst, gute Preis/Leistung
* Preis im Onlineshop sind ohne MwSt angegeben
* Bei Onlinekauf ist der Versand kostenfrei, ohne Mindesbestellwert.
* Notify-Me Service für Produktabkündigung
* Auch größere Stückzahlen über Allied möglich
* Relativ große Auswahl an Sortimenten (Widerstände, Kondensatoren), Einzelteile können teilweise nachgekauft werden
* Verfügbarkeitsanzeige im Internet ist ziemlich hilfreich
* Nützliche Tipps zum Thema RoHS
* Macht anscheinend Abfragen bei SCHUFA & Co. ohne Einverständnis oder Hinweis in den AGB.

=== Sander Elektronik ===
Homepage: http://www.sander-electronic.de

* beliefert auch Privatkunden, Bankeinzug möglich
* ähnlich Segor ein Berliner Versender
* Hier findet man manche [[MSP430]], die es sonst nicht in kleinen Stückzahlen gibt
* Herr Sander ist sehr kompetent und selbst Autor von Fachartikeln
* selbst abgekündigte Halbleiter können noch beschafft werden
* Bezahlung auch mit Kreditkarte möglich
* Versandkosten innerhalb Deutschlands ab 3,35€, innerhalb Europas ab 6€

=== Sasco Holz ===
Homepage: http://www.sasco.de

* Wie Spoerle eine Tochter von Arrow.
* Distributor für Analog Devices...
* Liefert wie Spoerle und Arrow in Deutschland nicht an Privatkunden.

=== Sat-Schneider ===
Homepage: http://www.sat-schneider.de
* Bauteile, Ersatzteile Online-Shop
* Baugruppen zum Empfang des Digitalen Kurzwellenrundfunks DRM

=== Satistronics ===
Homepage: http://www.satistronics.com

* typischer "China-Versender", mit allen Vor- und Nachteilen
* Lieferzeit bei Standardversand sehr lange (etwa 1 Monat nach D), aber schnellere Lieferung gegen Aufpreis möglich
* tritt auch bei eBay in Erscheinung ([http://stores.ebay.de/satistronicsstore eBay-Shop]), die Preise dort sind in der Regel aber etwas höher als im Online-Shop

=== Otto Schubert GmbH ===
Homepage: http://www.schubert-gehaeuse.de

* Kein Online-Shop. Bestellungen nur per Telefon, Fax oder E-Mail
* Weissblechgehäuse, Gerätegehäuse, wetterfeste Gehäuse
* Drehkondensatoren
* Sonderanfertigungen

=== Schramm-Software ===
Homepage: http://www.schramm-software.de/bausatz/
* Online-Shop, bietet Elektronik-Bausätze mit Mikrocontrollern
* Bausätze als Lehrmaterial geeignet, da ausführliches Begleitheft mitgeliefert wird (Aufbauanleitung, Schaltung, Controllerprogramm, Experimente...)
* bisher nur ein relativ kleines Sortiment, soll ergänzt werden
* Versandkosten innerhalb Deutschlands 2,50 €, innerhalb der EU 3,50 €

=== Schukat elektronic ===
Homepage: http://www.schukat.de

* liefert nicht an privaten Endverbraucher
* einfache und passiver Bauteile oft nur in großen Mindeststückzahlen
* ICs teilweise recht preiswert (vor allem bei mehr als 1 Stück, z. B. auch AVR)
* LCDs sehr preiswert und auch als Einzelstücke
* aktuelle Preise und Verfügbarkeit im Internet (aber nur nach Anmeldung -jetzt nicht mehr bei kleinen Stückzahlen), ebenso Bilder von Gehäusefootprints u.dgl.
* Abholung in Monheim am Rhein nach Vereinbarung möglich
* Versandkosten innerhalb Deutschlands ab 5€ (bis 10kg!)

=== Schuricht ===
Homepage: http://www.schuricht.de

* deutscher Ableger der Distrelec- (Elektronik) und Disdata-Gruppe (Computertechnik)
* Liefert auch an Privatkunden (getrennte AGBs für gewerbliche und Privatkunden, Lieferung an Privat per Nachnahme: Versandkosten ab 6,54€ plus 4,76€ Nachnahmegebühr).
** Online-Bestellung von Privatkunde scheiterte daran, dass die Onlineshop-Bestellformulare nur für gewerbliche Kunden ausgelegt sind und der Onlineshop Bestellungen ohne Firmenangaben nicht annimmt oder gar mit einer internen Fehlermeldung quittierte.
**Online Bestellung mit "Privat" als Firmenangabe funktionierte einwandfrei.
**Telefonische Bestellung von Privat funktioniert. Nette, freundliche Behandlung am Telefon, kein Callcenter. Versprochener Rückruf erfolgte mit gewünschten Informationen. Neben Nachnahme wurde für einen relativ teuren Artikel persönliche Abholung angeboten. Angegebene Lieferfrist wurde leicht unterschritten.
* Papierkatalog über 2000 Seiten, durchgehend farbig, nur für Geschäftskunden erhältlich.
* Ziemlich teuer

=== Schuro Elektronik GmbH ===
Homepage: http://www.schuro.de

* Elektronische Bauelemente und Bauteile für den Audio- und Lautsprecherbau (Kondensatoren, Spulen u.dgl.)
* kein Mindestbestellwert
* Versandkosten innerhalb Deutschlands gewichtsabhängig ab 5,75€

=== Segor-electronics ===
Homepage: http://www.segor.de

* Spezialist für Halbleiter, die ansonsten für nicht-gewerbliche Abnehmer nur schwer erhältlich sind (Preise dahingehend "angemessen")
* auch Privatkunden gerne gesehen
* Ladengeschäft in Berlin
* kein Mindestbestellwert bei Versand innerhalb der EU

=== SE Spezial-Electronic AG ===
Homepage: http://www.spezial.de

* Distributor
* Laut AGB auch Verkauf an Privat.
* Große Verpackungseinheiten/Mindestbestellmengen pro Bauteil
* Versandkosten pauschal 9,- € (Deutschland) (Stand 08/2008)

=== Shortec Electronics ===
Homepage: http://www.shortec.com

* Unabhängiger Distributor von elektronischen und elektromechanischen Bauelementen aller Hersteller.

=== Small Control Shop ===
Homepage: http://www.small-control.de

* "Bernd Walter Computer Technology"
* kleines Lieferprogramm aber ein paar interessante Produkte

=== SMG Diffusion - F1GE ===
Homepage: http://www.smgdiffusion.com
( Seite nur französisch )

* Videotechnik,
* 1,2 GHz / 2,4GHz Module
* Gebraucht-Messgeräte HP, Tek, Philips u.a.
* GHz-Halbleiter
* Koax-Adapter
* Antennen

=== Spoerle ===
Homepage: http://www.spoerle.de

* Früher eine Tochterfirma von Arror. Mittlerweile komplett in Arrow aufgegangen, Webseite leitet auf Arrow um.
* Aus dem Webshop: "Unser Angebot richtet sich nur an Kaufleute und nicht an Verbraucher."
* Wenn es wirklich über Arrow sein muss, dann kann man es als Privatperson bei Arrow Electronics North American Components http://www.arrownac.com/ versuchen, die sich normalerweise nicht weigern ihre Produkte zu verkaufen. Allerdings muss man mit großen Mindestmengen (z. B. BC547 in Schritten von 2000 Stück) und hohen Kosten rechnen.
:Zu den Kosten gehören zum Beispiel ein mehrfacher Mindermengenzuschlag (''$10 handling charge will be added to each line item less than $30''), eine satte ''handling and energy fee of $10.22'' (mehr als 10x zu hoch wie die vergleichbare Gebühr für amerikanische Besteller), hohe Versandkosten (ab $20 nach Deutschland). Dazu kommen die üblichen Kosten für den Import aus dem Ausland (Einfuhrumsatzsteuer, Kreditkartengebühr, ...)

=== SR-Systems ===
Homepage: http://www.sr-systems.de

* Baugruppen für Digital-TV, Sende- und Empfangstechnik
* DVB-S, DVB-T

=== Strixner&Holzinger ===
Homepage: http://www.sh-halbleiter.de

* Ladengeschäft in München
* Versand
* riesiges Angebot an Halbleiter, auch schwer beschaffbare
* Online-Shop

=== TAUTEC-ELECTRONICS ===
Homepage: http://www.tautec-electronics.de

* Online Shop für aktive elektronische Bauelemente
* günstige Preise (Vorsicht, Preisangaben enthalten keine Mehrwertsteuer) aber Mindestbestellwert 100 Euro
* alle Artikel ab Lager lieferbar, daher kurze Wartezeiten
* weltweiter Versand
* zahlreiche Mengenrabatte
* viele Ersatzteile aus dem Audio-, Car-HiFi und TV-Bereich

=== TCB-Versand ===
Homepage: http://www.tcb-versand.de

* insbesondere für Modellbauer ein sehr interresantes Sortiment
* Stecker,Kabel etc. recht günstig und kleine Mengen abnehmbar
* Lieferung normal zwischen 1 und 3 Tage
* leider nur Online-Shop

=== Tec-Shop (Wolfgang Rompel Elektronik) ===
Homepage: http://www.tec-shop.de

* Kleines, aber ausgesuchtes Sortiment
* Interessantes Angebot an Sensoren

=== Technik-Welt / Industrieshop.at ===
Homepage: http://www.industrieshop.at

* Laut Homepage richtet man sich "an den industriellen Kunden". Laut AGB sieht man das jedoch nicht so eng, Zitat:
:: ''TW schließt online Verträge nur mit Kunden ab, die natürliche oder juristischen Personen sind, die ihren Wohnsitz oder Sitz in Österreich, einem Mitgliedsstaat der Europäischen Union (EU25) oder der Schweiz haben.''
* [[#Farnell|Farnell]] Teile
* In Österreich
* Schnelle Lieferung (2 Tage)

=== TIGAL KG ===
Homepage: http://www.tigal.com

* Boards und Tools für Embedded-Elektronik
* In Österreich
* Versandkosten ab € 7,00 in Österreich, ab € 10,00 nach Deutschland.
* Preisangaben ohne MWSt. Für Privatkunden kommen 20% österreichische Mehrwertsteuer hinzu.
* U.a. ZeroLogic Logik-Analysatoren.

=== TME (Transfer Multisort Elektronik) ===
Homepage: [http://www.tme.pl/index.phtml?lang=de www.tme.pl]

* Firmensitz in Łódź, Polen
* Zahlungsabwicklung über deutsches Konto oder PayPal
* Firmenvertretung in Leipzig, man spricht deutsch
* Versand mit UPS (etwa 8 Euro inkl. MwSt.); Trackingnummer wird sofort nach Kommissionierung zugesendet
* als Privatkunde: Mehrwertsteuer beachten (22%)
* sehr großes günstiges SMD Sortiment
* unmittelbar aktualisierter Lagerbestand, Mindestmengen und Vielfache beachten

=== Trade-Shop / AIR Electronics GmbH ===
Homepage: http://www.trade-shop.de

* Trotz knackiger Sprüche auf der englischen Version der Webseite ("Electronic Components Superstore") eher kleines Angebot elektronischer Bauteile
* 20 Euro Mindestbestellmenge (Stand Februar 2008)
* ab 6,90 Euro Versandkosten (Deutschland, bis 1kg) (Stand Februar 2008)

=== Trenkenchu & Stadler GbR ===
Homepage: http://www.ts-audio.de

* die meisten Artikel sind deutlich teurer als der Marktpreis, nur bei exotischen Bauelementen kann man durchaus ein Schnäppchen machen

=== TV-Ersatzteile ===
Homepage: http://www.tversatzteile.de

* TV-, Audio-, Video-Ersatzteile, Aktive / Passive Bauteile
* Fernbedienungen Haushaltstechnik

=== UKW-Berichte ===
Homepage: http://www.ukw-berichte.de

* Antennen, Bauteile, Bausätze, Literatur für Amateurfunk

=== Voelkner ===
Homepage: Kein Link, entsprechend der Vorgabe des Betreibers der Voelkner Webseite im Impressum:
<blockquote>voelkner - direkt günstiger
 
wird produziert und betreut von 
Re-In Retail International GmbH 
... 
Eine Verlinkung auf die Website der Firma Re-In Retail International GmbH bedarf einer schriftlichen Genehmigung. </blockquote>

* Großer Teil des Conrad-Programms, identische Nummern, identische Aufkleber auf der Ware, Preise identisch oder nur ein paar Cent abweichend
* Versandkosten Deutschland: 4,95€; ab 25€ Warenwert und Sofortüberweisung.de versandkostenfrei / Versandkosten-Flatrate für 15€ pro Jahr
* Versandkosten EU: 9,95€
* Möglichkeit der Versandkostenflatrate (D): Einmalig 9,95€ / gültig für ein Jahr
* Legt jeder Bestellung gleich wieder einen Gutschein über 5€ bei MBW 25€ bei (Flat nur bei häufigen, kleinen Bestellungen sinnvoll); außerdem kommt etwa alle 2-3 Monate selbiger Gutschein + versandkostenfreie Lieferung per Mail, ebenfalls MBW 25€
* Verpackungsqualität wechselnd, mal brauchbar, mal eher Pollin-Niveau. Selbst kleine Bestellungen, die gefahrlos per Brief/Großbrief verschickt werden könnten werden in einem großen Paket versendet.

=== VOTI Webshop ===
Homepage: http://www.voti.nl/shop/catalog.html

* relativ kleines Lieferprogramm
* einige interessante Restposten (Surplus)

* Sitz in Amersfoort, Niederlande

=== Walter elektronik ===
Homepage: http://www.walter-elektronik.de

* Bauteile, Röhren

=== Watterott electronic GmbH===
Homepage: http://www.watterott.com

* Distributor für Arduino, BeagleBoard, FriendlyARM, Pololu, Seeed Studio, Solarbotics, SparkFun...vollständige [http://www.watterott.net/about#distri Liste hier]
* Entwicklungskits von Atmel, Luminary Micro, Microchip, Raisonance, TI
* Spezialbauteile von Davicom, FTDI, VLSI, WIZnet
* Bungard Basismaterial + Chemie
* kein Mindestbestellwert
* Zahlung: Vorkasse, Sofortüberweisung, PayPal, Nachnahme, Kreditkarte (Visa/Mastercard), Rechnung (nur gewerbliche Kunden)
* Versandkosten Dtl. (UPS):
** bis 25 EUR Warenwert: 3,50 Euro
** bis 50 EUR Warenwert: 2,90 Euro
** bis 150 EUR Warenwert: 2,00 Euro
** ab 150 EUR Warenwert: versandkostenfrei
* Versandkosten EU (UPS):
** bis 150 EUR Warenwert: 10,00 Euro
** bis 250 EUR Warenwert: 8,90 Euro
** bis 500 EUR Warenwert: 7,00 Euro
** ab 500 EUR Warenwert: versandkostenfrei
* Schneller, entgegenkommender Service

=== Westfalia ===
Homepage Deutschland: http://www.westfalia.de
Homepage Österreich: http://www.westfalia-versand.at

* Vor 85 Jahren in Hagen, Westfalen gegründet
* Elektronik nur ein kleiner Teil des Angebotes. Eher insgesamt Haushalts-, Werkstätten-, Agrar- und Gartenbedarf
* Elektroniksortiment stark schwankend. Momentan (Juni 2008) wenig Auswahl.
* Mindestbestellwert 18 €, bei Neukundenbestellungen mit Prämienanforderungen (wenig wertiges Geschenk) sogar 50 €.
* 4,95€ Versandkosten, ab 150€ Bestellwert versandkostenfrei
* Transportversicherung wird zusätzlich mit einem Zuschlag von 0,8% des Warenwertes berechnet.
* Einmalige Bestellung führte zu jahrelanger Zusendung von Werbung für Westfalia-Angeboten mit Gewinnspielen (Glücksnummern, Rubbellose, Glücksschlüssel, etc.)
* Verpackung ähnlich "sorgfältig" wie bei [[#Pollin_Electronic|Pollin Electronic]]. Übergroße Kartons, wenig Verpackungsmaterial, schweres Teil (Labornetzgerät) flog lose im Karton herum und zertrümmerte andere Ware.

=== WilTec Wildanger Technik GmbH ===
Homepage: http://shop.wiltec.info

* Aoyue Lötgeräte (Heißluft, Löten, Entlöten), Netzteile, Werkzeuge
* Aoyue Zubehör (Lötspitzen, Heißluftdüsen), Ersatzteile
* Andere, nicht Elektronik-Angebote, wie KFZ-Tuningteile
* Versand. Bei Voranmeldung auch Lagerverkauf.

=== Wüstens frag-jan-zuerst ===
Homepage: http://www.die-wuestens.de/dindex.htm

* Röhrentechnik
* Hochspannungs-Spezialteile

=== WIMO ===
Homepage: http://www.wimo.de

* Große Auswahl an Amateurfunktechnik

=== Zech DG0VE ===
Homepage: http://www.dg0ve.de

* Baugruppen für Amateurfunk

=== Diverse ===
* http://www.chip-flip.com - Europäisches Bauelementesuchsystem, franchised Lieferantensuche, Datenblätter und viele nützliche Informationen
* http://www.ecomponents-store.com/ Elektronische Bauelemente kaufen - Hier finden Sie eine große Auswahl an elektronischen und elektromechanischen Bauelementen von über 40 Herstellern.
* http://www.franchised-distributors.eu/ - Finden Sie Vertragsdistributoren von über 800 Halbleiterherstellern für elektronische und elektromechanische Bauelemente.

TODO: elektronik-fundgrube

==Ebay-Shops==

===Ego-China===
http://stores.ebay.de/Ego-China-Electronics TFTs und LCDs Versand aus China (2-3 Wochen)

===Sure-Electronics===
http://stores.ebay.de/Sure-Electronics Highpower LEDs und Verstärker 
Hat auch einen eigenen Shop: http://www.sureelectronics.net/ 
Versand aus China

===Ether-Deal===
http://stores.ebay.de/ether-deal Unter sonstiges viele versch. Elektronik-teile Versand aus China

===NooElec===
http://stores.ebay.de/NooElec USB-AVR Boards (mega32u2) und rgbled-matrizen Versand aus Kanada

==Messgeräte ==
=== Neue Messgeräte ===

Viele der oben genannten Elektronikversender verkaufen auch Messgeräte. Darüber hinaus gibt es diverse Versender, die sich hauptsächlich oder ausschließlich auf Messgeräte spezialisiert haben. Allerdings verkaufen viele davon nicht an Privat.

==== CalPlus GmbH ====
Homepage: http://www.calplus.de 
Shop: http://www.scopeshop.de

==== Cosinus ComputerMesstechnik ====
Homepage: http://www.cosinus.de

* Nicht an Privat

==== dataTec ====
Homepage: http://www.datatec.de

* Große Auswahl
* <s>(Nicht an Privat)</s> Bestellung von Privat problemlos möglich, Privatpersonen werden laut ABG per Vorkasse beliefert
* Studenten bekommen Rabatt, je nach dem, was bestellt wird
* Umständlicher Bestellvorgang, seitens DataTec teilweise auf dem Postweg -> Es dauert teil sehr lange bis die Ware ankommt
* Sehr freundlicher und kompetenter Service, per eMail als auch telefonisch

==== Donald4646 ====
Homepage: http://www.donald4646.co.uk

* In Schottland
* Als eBay-Shop gestartet
* Einfache, No-Name und Billigmarken (z. B. Oszilloskope)

==== Elektronik-Kontor Messtechnik GmbH ====
Homepage: http://www.ekomess.de

==== Meilhaus Electronic GmbH ====
Homepage: http://www.meilhaus.de

* Diverse Markenhersteller
* Eigenmarken

==== PinSonne-Elektronik ====
Homepage: http://www.pinsonne-elektronik.de

* Onlineshop
* Sehr kleines Sortiment
* UNI-T, RIGOL und andere asiatische Firmen

==== PK elektronik Poppe GmbH ====
Homepage: http://www.pk-elektronik.de

* U.a. Fluke Distributor.

====Präzitronic Hennig / Messgeräte Chemnitz====
Homepage: http://www.messgeraete-chemnitz.de

* Owon
* Selbst übersetzte deutsche Owon-Handbücher
* Fluke
* Zusätzlich kleines Angebot an Gebrauchtgeräten

==== ScopeShop Hamburg ====

* Von CalPlus übernommen, siehe [[#CalPlus_GmbH|CalPlus]]

==== SI Scientific Instruments GmbH ====
Homepage: http://www.si-scientific.de (Onlineshop) 
Homepage: http://www.si-gmbh.de (komplettes Programm)

* Onlineshop auf si-scientific.de
* Akzeptiert PayPal

==== SKY Messtechnik GmbH ====
Homepage: http://www.sky-messtechnik.de

* Kein Onlineshop (E-Mail oder Telefon)

==== TESTEC ====
Homepage: http://www.testec.info

* Tastköpfe-Hersteller
* Hameg Vertriebspartner
* B+K Precision Generalimporteur

==== Zeitech ====
Homepage: http://zeitech.eu/shop/

* Diverses (Rigol, Owon, etc.)

=== Gebrauchte Messgeräte ===

Dieser Abschnitt enthält Anbieter bei denen gebrauchte Messgeräte erhältlich sind.

==== Astro Electronic ====
Homepage: http://www.astro-electronic.de

==== eumex GmbH ====
Homepage: http://www.eumes.com/pub/de/

* Gebrauchte Messgeräte

==== HTB-Elektronik ====
Homepage: http://www.htb-elektronik.com

* Gebrauchte Messgeräte

==== IX Instrumex ====
Homepage: http://www.instrumex.de/index.cgi?User:LANGUAGE=de

* Gebrauchte Messgeräte

==== Christoph Lüders MessTechnik ====
Homepage: http://www.CLMT.de 
Online-Shop: http://www.shop-016.de/shop-CLMT.html 
eBay: http://myworld.ebay.de/c_h_r/

* Hat 2010 die Restbestände von Förtig übernommen

==== mbmt Messtechnik ====
Homepage: http://www.mbmt.com

* Gebrauchte Messgeräte
* Verkauf nur an Gewerbetreibende

==== Rosenkranz Elektronik ====
Homepage: http://www.rosenkranz-elektronik.de 
eBay Shop: http://stores.ebay.de/Rosenkranz-Elektronik-GmbH-Shop

* Gebrauchte Messgeräte
* Auch auf eBay zu finden

==== Helmut-Singer-Elektronik ====
Homepage: http://www.helmut-singer.de

* Gebrauchte Messgeräte
* Verkauf auch an Privat
* An den meisten Samstagen im Jahr auch Lagerverkauf, sonst Versand

==== Sphere ====
Homepage: http://www.sphere.bc.ca 
Messgeräte und Ersatzteile: http://www.sphere.bc.ca/test/index.html

* Gebrauchte Messgeräte
* Ersatzteile
** Besonders bekannt für Tektronix-Ersatzteile

==== Tektronix TekSelect ====
Homepage: http://www.tek.com/Measurement/tekselect/

* Tektronix verkauft selber gebrauchte und überarbeitete Tektronix-Messgeräte unter dem Label ''TekSelect''.
* Original Tektronix-Garantie
* Der Bestellvorgang nervt, man muss Kontaktaufnahme durch einen "Representative" erbeten.

== Siehe auch ==
* [[Platinenhersteller]]
* [[Lokale Elektroniklieferanten]]
* [[Eisenwarenversender]]

== Links ==

* http://www.xs4all.nl/~ganswijk/chipdir/ Suche nach integrierten Schaltkreisen
* http://www.alldatasheet.com Datenblätter

[[Kategorie:Bauteile|!]]
[[Kategorie:Lieferanten]]

Benutzer:Haku/Für:Target

2012-06-17T18:02:26Z

Haku: Die Seite wurde neu angelegt: „= Für Target = Warum ich Target nicht mag. Ohne Geflame, nur objektiv nachvollziehbare Fakten. Nicht alles hiervon betrifft effektiv Programmfehler, das wenigst…“

= Für Target =

Warum ich Target nicht mag. Ohne Geflame, nur objektiv nachvollziehbare Fakten. Nicht alles hiervon betrifft effektiv Programmfehler, das wenigste sogar. Viele Dinge sind einfach nur '''unnötig''' in der Art, dass es absolut keinen Mehraufwand für den Programmentwickler gemacht hätte, es sinnvoller (oder: in der ''üblichen'' Weise) zu lösen.

== Installation ==
* Obwohl ich ''Benutzerdefinierte'' wähle und alle Verknüpfungen (so nennen sich wohl die Pseudo-Links unter Windows) abstelle, erzeugt es Verknüpfungen im Startmenü.

== Allgemeines ==
* Beim Programmstart blitzen Fenster ohne Titelzeile und Rahmen herum, das widerspricht '''unnötigerweise''' gängigen GUI-Standards und bringt Target beim Start immer wieder in den Vordergrund.
* Die Werkzeugleisten sind irgendein selbstgebastelter Blödsinn und nicht die Standardkomponenten von Windows. Lassen sich auch nicht verschieben oder mehrzeilig anordnen oder so. Bei zu kleiner Bildschirmauflösung oder zu kleinem Fenster fehlen halt rechts Knöpfe. Da kommt auch kein 'Nicht sichtbare Schaltflächen'-Pfeil oder Ähnliches.
* Weiter dazu, manche Tasten klappen aus (kleiner Pfeil daneben). Man ''muss'' aber zwingend zweimal klicken und kann nicht einfach den Pfeil drücken, mit der Maus auf den Menüpunkt ziehen und lösen. Denn das Menü klappt erst beim lösen aus. All das hätte die Windows-Standardkomponente geboten.
* Die Tastenbelegungen in den Menüs sind wohl mit Leerzeichen eingerückt. Oder zumindest hat man das versucht, es ist Kraut-und-Rüben.
* Die Tastenbelegungen sind nicht einstellbar. Insbesondere gut, weil viele neue Tastaturen kein ''Einfg'' mehr haben.
* Mal heißt es, Target gibts mehrsprachig<ref>http://server.ibfriedrich.com/wiki/ibfwikide/index.php?title=TARGET_3001!</ref>, im Datenblatt ist es dann wieder deutsch<ref>http://server.ibfriedrich.com/wiki/ibfwikide/index.php?title=TARGET_3001!_Datenblatt</ref>. Effektiv lässt es sich nicht umschalten, sondern man muss die entsprechend-sprachige Version herunterladen und installieren.
* Ziemlich labiles Bibliothekskonzept. Insbesondere schon das dritte oder so (erst lokaler Binärkram, dann Online, dann SQLite-Datenbank). Mal gespannt.
* Das Datenbankschema ist aus informationstechnischer Sicht Schrott weil praktisch überhaupt nicht normalisiert. Beispiel: Tabelle 'components' mit den Federn 'param_double1', 'param_double2', ..., 'param_double12'. Target meldet sich dann mit 'Es sind nur 12 Gleitkommazahlen, 6 ganze Zahlen und 6 Bezeichner erlaubt.'. Auch die Sprachen sind divers, es gibt Englisch, Deutsch und Französisch. Natürlich in allen Tabellen mit '_de', '_en' und '_fr' vertreten. Weitere Sprachen sind also unwahrscheinlich...
* Lustige Beschreibungs-'Sprache' für die 3D-Modelle. Hätte man vielleicht doch lieber auf Povray setzen sollen, aber gut. Neuentwicklung irgendwie '''unnötig'''.
* Man kann 'Target-Bauteile' nicht bearbeiten, sondern muss davon stets eine Kopie erzeugen.

== Bedienung ==
* Das ganze Programm ist als MDI konzipiert. Die Verwendung auf zwei Monitoren erübrigt sich damit. Selbst wenn man das Hauptfenster breitzieht über beide Monitore und Schaltplan und Platine darin auf separaten Monitoren hat, gibt es nur eine Werkzeugleiste auf dem linken Monitor und nur eine Sidebar (Einstellungen, Ebenen usw.).
* Da ist jede Menge Müll in den Menüs, mit Einträgen, die im CAD einfach nichts zu suchen haben. Sei es das 'Service'-Menü oder die 'Versionen'. Und Distrelec taucht dann auch ein zweites Mal im 'Datei'-Menü auf. Ist ja schön, dass sowas eingebunden wird, aber dann doch irgendwie abschaltbar oder über einen zentralen Anlaufpunkt 'Beschaffung' oder sowas. Aber nicht derart platzraubend. Gleiches im 'Hilfe'-Menü: Lob, Forum, Email hin, Email zurück, Homepage, Empfehlen, über die Schulter. Voll überladen.
* Im 'Elemente'-Menü musste man die Ziffern (zusätzlich zur Tastenbelegung rechts daneben) nochmal links davorsetzen, um sie für die Alt-Taste ansprechbar-unterstrichen zu bekommen.
* Die Sidebar ist wieder selbstgefrickelt. Wenn der Bildschirm klein ist und nicht alle Ebenen drauf passen, hat man halt Pech. Oder man versucht, alles andere einzuklappen, um Platz zu schaffen. Hat man offenbar auch im Ingenieurbüro gemerkt und einen Knopf plaziert, der zumindest die ersten oder zweiten 50 Ebenen anzeigt.
* Immerhin, man kann sie links und rechts andocken. Oben und unten wieder nicht.
* Immer mal wieder versteckt gibt es 'L'- und 'S'-Knöpfe um irgendeinen Teil der aktuellen Konfiguration zu speichern. Etwa die momentan sichtbaren Ebenen. Oder die Farben ('Ansicht'->'Farben').
* Die Farbwahldialoge sind auch wieder selbstgebastelt. Dabei bietet Windows auch die schon fix-und-fertig an.
* Irgendwie ist die 3D-Ansicht ja nett, noch netter wärs aber, wenn man damit irgendwas anfangen könnte. Etwa in ein Bild rendern oder so. Es gibt keinen Knopf dafür...
* Es gibt nur den Universal-Bus, in dem sämtliche Signale des Projektes auftauchen. Anklemmen an den Bus ist umständlich, man muss das gewünschte Signal aus einer Liste heraussuchen. Das ist bei Eagle deutlich effizienter gelöst (Kontextmenü).

<references />

Taktung FPGA/CPLD

2012-06-09T18:02:56Z

Haku: /* Kombinatorik im Taktpfad */

== Einleitung ==

Von den drei Signalgruppen

* interne Signale
* IO Signale
* Takt (Clock)

ist letztere die mit den höchsten Anforderungen an Signalqualität und Laufzeit. Fehler im Taktnetzwerk führen zu ungewolltem, ja oft ''katastrophalem'' Verhalten der Schaltung. Um dies zu vermeiden sind besondere Aufbauregeln und Komponenten für die Taktverteilung in digitalen ICs entwickelt worden.

== Grundanforderungen Taktnetzwerk ==
Der Takt muss möglichst störungsfrei an alle getakteten Bauelemente (FlipFlops, RAMs) im IC geführt werden. Das Taktnetzwerk muss damit sehr viele Gatter-Eingänge treiben (einige Dutzend bis einige Hundertausend!). Dazu wird ein spezieller Takttreiber genutzt (Xilinx: BUFG). Die Laufzeit vom Eingang des Takttreibers zu jedem Endpunkt des Netzes muss gleich sein. Nur so ist gewährleistet, dass alle FlipFlops zum gleichen Zeitpunkt schalten und die Synchronität gewährleistet ist.

Der Laufzeitunterschied zwischen verschiedenen Endpunkten des Taktnetzes wird Skew genannt und muss sehr klein gehalten werden (bei modernen Digitalschaltkreisen kleiner 100 ps). Dazu wird das Taktnetzwerk als Baumstruktur gestaltet (gleiche Länge von der Baumwurzel zu jeder Astspitze). Man nennt diese Schaltungstechnik "Clock Tree".

[[Bild:clock_tree.png | 320px]]

In fast jeder Digitalschaltung kommt es nun vor, dass verschiedene Bereiche nicht bei jedem Takt eine Aktion ausführen sollen. Einige laufen sogar mit einer erheblich geringeren Taktrate als der Rest der Schaltung. Dazu muss aus dem relativ schnellen Systemtakt ein langsamer Takt gewonnen werden. Was auf den ersten Blick recht einfach aussieht, wird im Detail oft falsch gemacht.

== Geschaltete Takte (Gated Clock)==

Dieser Begriff bezieht sich auf geschaltete, also unterbrochene (engl. "gate"), Taktleitungen. Dies kann durch die Verwendung von:

*'''Multiplexern''' (Auswahl zwischen Taktquelle 1 und 2)
oder
*'''kombinatorischer Logik''' (Schaltungsteile werden unter bestimmten Bedingungen vom Takt getrennt)
geschehen.

===Taktmultiplexer===
Falls ein völliges Abschalten des Taktes wirklich erforderlich ist, z. B. um den Leistungsbedarf zeitweilig zu drosseln, sollte der Takttreiber selbst abgeschaltet werden. Bei Xilinx würde man statt eines BUFG einen BUFGMUX einsetzen. Dieser garantiert durch seinen speziellen Aufbau, daß während des Umschaltens keine [[Glitch]]es entstehen.

===Kombinatorik im Taktpfad===
Ein solches Design ist aus zwei Gründen problematisch:
* es entstehen neben den gewünschten Schaltflanken zusätzliche, ultrakurze Flanken (->[[Glitch]]es)
* bei CLK-Teilern hat der langsame Takt eine Phasenverschiebung zum schnellen Takt (-> Skew).
* bei "gegateten" Takten besitzt der ereugte Takt eine Phasenverschiebung zum Quell-Takt (-> Skew).

Im ersten Fall können durch die Glitches unerwünschte Schaltaktivitäten an FlipFlops in folgenden Schaltungsteilen ausgelöst werden. Das ist fatal! Schon deshalb ist diese Variante nicht brauchbar. Sie wurde dennoch oft in der Vergangenheit angewendet, weil die relativ langsamen ICs die Glitches gefiltert bzw. ignoriert haben. Doch heute sind CPLDs und FPGAs extrem schnell, dass man mit dieser Methode schnell scheitert.

Im zweiten Fall erfolgt durch Skew eine Verschiebung der Schaltzeiten im anderen Schaltungsteil, die insgesamt weniger Zeitreserve für Signale lässt, die aus dem anderen Schaltungsteil wieder in den ersten Schaltungsteil übergeben werden sollen. In der Vorwärtsrichtung bestehen sogannnte race conditions, d.h. Daten innerhalb der Quelltaktdomäne gelangen eher an FlipFlops der Zieldomäne als Daten, die innerhalb der Zieldomäne erzeugt wurden. Sind Signale zu früh, werden sie ggfs. vom falschen Takt übernommen, wodurch das design "komisch" arbeitet, weil scheinbar ein Takt fehlt. Diese Methodik ohne Behandlung oder besondere Betrachung der Fälle nicht zuverlässig und damit allgemein nicht akzeptabel.

In Sonderfällen kann durch einen ausreichende Verschiebung dafür gesorgt werden, dass die Schaltungsteile zueinander korrekt laufen und stabil arbeiten. Dies ist dann einfach zu erreichen, wenn kein Rückwärtspfad der Daten benötigt wird, der im selben Taktzyklus agieren muss.

=== Asynchrone Taktleitung ===

Durch diese Methodik der verschobenen Takte kann jedoch auch eine Geschwindigkeitssteigerung erreicht werden, wenn der Takt quasi wie ein Lauffeuer durch den Chip läuft und bei korrektem Timing der Daten (kurze Kombinatorik), jene aus der zukünftigen Zeitebene nie einholt. Damit sind asynchron gepipelinete Architekturen bildbar, die unterhalb der Taktebene arbeiten und lokal die typischen setup-hold-Bedingungen einhalten.

Dies wird üblicherweise aber nur bei ASICs eingesetzt, bei denen ohnehin die Takte und Daten passend lokal optimiert werden. Im Bereich des typischen FPGA-Designs findet man hierzu jedoch bislang nur akademische Lösungen und manuell plazierte Teildesigns bei Sonderlösungen, z.B. auf dem Gebiet der TDC (Time to Digital Converter, schnelle PMW-Generierung z.B. im [[PICCOLO]] von TI), da die Tools allesamt auf einem FPGA-weit synchronen Takt und Design aufbauen, dies nicht automatisiert unterstützen und folglich ein Design extrem aufwändig und schwer zu testen ist. Geschwindigkeitssteigerungen lassen sich bei FPGAs daher meist einfacher, sicherer und billiger erreichen, wenn man stärker Pipelining oder Parallelisierung nutzt, ggf. unter Nutzung von mehreren FPGAs.

=== Derived Clock ===

Eine geringfügige Verbesserung des Gated Clock erreicht man durch das Anfügen eines FlipFlops hinter den kombinatorischen Dekoder. Durch diese Zwischenspeicherung wird der Takt zumindest frei von Glitches. Wenn im FPGA/CPLD nur ein langsamer Takt gebraucht wird, oder der langsame Schaltungsteil keine logische Verbindung zum schnellen Schaltungsteil hat, dann ist diese Lösung akzeptabel und sicher. Wenn jedoch zwischen dem langsamen Schaltungsteil und schnellen Schaltungsteil Daten oder Steuersignale ausgetauscht werden, dann muss man zu einer anderen Entwurfsmethode greifen.

== Clock Enable ==
Jedes FlipFlop in FPGAs/CPLDs hat einen synchronen Steuereingang namens CE (Clock Enable). Damit kann man festlegen, ob das FlipFlop bei der nächsten Taktflanke neue Daten speichern oder die alten behalten soll. Da es sich um einen synchronen Eingang handelt, ist es vollkommen unkritisch, wenn diese Signal Glitches enthält. Es muss nur im Zeitraum beginnend kurz vor der Taktflanke (Setup Time, Aufbauzeit) bis kurz danach (Hold Time, Haltezeit) stabil anliegen. Eine Verschiebung dieses Signals zum Takt ist auch unkritisch, denn jedes normale Steuersignal ist phasenverschoben zum Takt (Schaltzeit der FlipFlops, Durchlaufzeit der Logik, Laufzeit der Verdrahtung (Routing)). Das CE-Signal kann von der Entwurfssoftware wie ein normales Steuersignal behandelt werden und vereinfacht damit erheblich die automatische Analyse der maximalen Schaltfreqeunz (Timing Analyses).

== Beispiele ==
Im nachfolgenden Bild sind alle drei Typen von Takt kurz skizziert. Der schnelle Takt treibt einen 4Bit Zähler (CNT1). Dessen Ausgänge werden über eine UND-Gatter (Gate1) kombinatorisch verknüpft. Der Ausgang des UND-Gatters ist nur dann HIGH, wenn alle Eingänge HIGH sind. Das ist nur einmal alle 16 Takte der Fall, wenn der Zählerstand binär 1111 erreicht ist. Dieses Signal als Takt zu verwenden wäre sträflich, denn es ist ein Gated Clock. Wenn er jedoch noch einmal mittels FlipFlop (FF1) zwischengespeichert wird ist es ein Derived Clock. Der beste und sinnvollste Weg ist jedoch die Verwendung des CE-Eingangs der FlipFlops (FF2) wie es ganz unten im Bild dargestellt ist.

[[bild:clock_types.png | thumb| left | 640px | verschiedene Taktteiler]]
{{clear}}

== Umsetzung in VHDL ==

<vhdl>
-- Die Verwendung von "Clock Enable" in VHDL
-- die Signale clk und ce sind hier natürlich nur Beispiele
-- es kann dafür jeder beliebige Signalname verwendet werden

-- Das hier muss in die Signaldeklaration zwischen
-- achitecture ... und begin

constant cnt_div: integer:=16; -- Teilerverhältnis
signal cnt: integer range 0 to cnt_div-1; -- Zähler für Teiler
signal ce: std_logic;

-- die Prozesse logischerweise nach begin der Achritecture

-- Prozess mit langsamen Clock Enable

process(clk)
begin
if rising_edge(clk) then
if ce='1' then

-- Aktionen hier einfügen, welche mit langsamen Takt laufen

end if;
end if;
end process;

-- Clock Enable Generator

process(clk)
begin
if rising_edge(clk) then
if cnt=cnt_div-1 then
ce <= '1';
cnt <= 0;
else
ce <= '0';
cnt <= cnt +1 ;
end if;
end if;
end process;

</vhdl>

== Clock Skew ==
Mithilfe der clock skew Einstellung kann ein Synthesewerkzeug angewiesen werden, den Zeitpunkt der Taktflanke entsprechend den Erfordernissen der Schaltungsverzögerungen einzustellen. Dies schafft mehr Reserven.

[[Category:FPGA und Co]]

== Phase Shift==
Innerhalb der FPGA-PLLs können mehrere Takte von demselben Eingangstakt abgeleitet werden, die eine feste Verschiebung aufweisen.

AVR Typen

2012-04-22T16:06:21Z

Haku: /* Weitere Vergleichstabellen */ Beiträge mit Tabellen

== AT90S ==
Die "Basic Line" der Atmel [[AVR]]-Reihe. Sie beinhaltet die ersten [[AVR|AVRs]] die produziert wurden und deren Bezeichnung mit "AT90S" beginnt. Alle Typen wurden mit der Zeit von den beiden Nachfolgereihen ersetzt: ATmega bzw. ATtiny.

Einige neue AVR-Controller tragen eine mit AT90-''ohne S'' beginnende Bezeichnung, haben aber einen "moderneren" Kern. Z.B. sind die Typen AT90PWM2/3 und AT90CAN128 vom Funktionsumfang (interner RC, USART etc.) den ATmegas zuzuordnen.

== ATmega ==
Die ATmega-[[Mikrocontroller]] sind ein Teil der AVR-Controllerfamilie. Zusammen mit den ATtiny lösen die ATmega die AT90S-Serie schrittweise ab, wobei es in den meisten Fällen weitgehend pin- und funktionskompatiblen Ersatz für abgekündigte Controller gibt (ATmega8 statt AT90S4433, ATmega8515 statt AT90S8515 usw.).

Atmel ATmega AVRs werden mit aktiviertem internem Taktgeber ausgeliefert. Schließt man ein andere externe Taktquelle an (Quarz, Quarzoszillator o.ä), wird diese nicht automatisch genutzt. Zum Aktivieren müssen die Fuse-Bits des Controllers entsprechend eingestellt werden (siehe Datenblatt).

ATmegas mit integriertem [[JTAG]]-Interface (z.Zt. solche ab 16kB Flash-Speicher und mehr als 28 Pins) werden ab Werk mit aktiviertem JTAG-Interface ausgeliefert. Dieses Interface belegt vier Port-Pins (z. B. am PORTC bei ATmega16/32), die nicht für eigene Anwendungen genutzt werden können, solange das JTAG-Interface aktiviert ist. Das Interface lässt sich über ein Fuse-Bit (JTAGEN) dauerhaft und über ein Bit (JTD) in dem (oder einem der) MC-Kontroll-Register (Datenblatt nach JTD durchsuchen) per Software zur Laufzeit an- und abschalten. Weiteres im Datenblatt des jeweiligen Controllers in den Abschnitten Memory-Programming (Fuse) und JTAG/ICE (JTD).

Beim ATmega128 ist ab Werk die Mega103-Kompatibilitäts-fuse gesetzt. Um alle Erweiterungen des Mega128 gegenüber dem Mega103 zu nutzen muss diese deaktivert werden. Diese Fuse sorgt außerdem dafür, dass das SRAM in einem anderen Adressbereich liegt. Dadurch funktionieren C-Programme nur bis zum ersten Funktionsaufruf. Siehe auch [[AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Gehäuse | AVR Checkliste: Besonderheiten bei ATmega64 / ATmega128]]

== ATtiny ==

Die ATtiny stellen das untere Ende der neuen AVR Linie von Atmel dar und waren zunächst durch das Fehlen von internem [[RAM#SRAM|SRAM]] gekennzeichnet. Mittlerweile gibt es aber so bemerkenswerte Controller wie den ATtiny4313, deren Möglichkeiten und Funktionen den ATmegas in nichts nachstehen.

Ein weiterer Unterschied zu den ATmegas ist der fehlende Hardwaremultiplizierer. Jede Multiplikation muss also in Software ausgeführt werden. Eine Übersicht über die Verfügbarkeit verschiedener Befehle bietet die [[AVR_Assembler_-_Vergleichstabelle|AVR-Assembler Befehlsvergleichstabelle]].

== ATxmega ==
Neueste Generation von AVR-Controllern mit neuem internen Aufbau, hoher Taktrate (32 MHz), niedriger Spannung (1,6 - 3,6V), vielen Schnittstellen, in 44 - 100 poligen SMD-Gehäusen. Besonderheiten: ADC mit 2 Megasample/12 Bit, vierpoliges Programm- und Debug- Interface PDI (VTref, CLK, DATA, GND) erfordert z.B. einen AVR_JTAGICE-mkII Programmer. PDI (Flash und Debug) funktioniert mit C-Code z.B. mit AVR Studio 4.19.

Leider ist die Xmega-Reihe zu den AVR-Prozessoren der Mega- oder Tiny-Serien nicht kompatibel (viel komplizierter, anderer Aufbau der IO-Baugruppen, der Interrupts, der C-Funktionen etc.). Prozessor-Manuals zeigen weder Assembler noch C-Beispiele für Ansteuerung der IO-Baugruppen. C-Programmbeispiele (geeignet für AVR-Studio) findet man erst in Xmega Application Notes. Einen Überblick gibt [http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial Florian Grotz].

== Sonstiges ==

Die AT89-Familie gehört nicht zu den AVR-Typen mit dem AVR-RISC-Befehlssatz, sondern ist eine [[8051|Intel-8051]]-kompatible 8-Bit µC-Serie.

=== Tiny vs Mega ===
Die modernen Typen sind die Tiny und die Mega. Die ATTiny haben kleinere Gehaeuse als die ATMega, mit weniger Pins. Dies fuehrt bei aehnlicher Funktionalitaet wie die Megas zu extremerer Mehrfachbelegungen der Pins und auch eher zu Ueberschneidungen der Pinfunktionalitaet. Die Tiny sind daher eher fuer sehr hohe Stueckzahlen geeignet, wo die Einsparung ueber die Stueckzahl kommt. Anfaenger und Bastler sind mit den ATMega besser bedient, da die weniger Limitationen besitzen.

==Nomenklatur==
===ATmega===
Auch wenn die Namensgebung auf den ersten Blick bedingt durch die vielen verfügbaren Modelle kompliziert aussieht, so folgt sie doch immer (von wenigen Ausnahmen abgesehen) einem einfachen Schema.

Nehmen wir einen aktuellen Baustein als Beispiel: *ATmega48PA-AU*. Der Name besteht aus 5 Teilen:
# Der Baureihe (hier: "ATmega")
# Einer Nummer, immer eine Zweierpotenz (hier: 4). Diese Zahl gibt die Größe des Flashspeichers in Kibibyte an.
# Bis zu zwei weiteren Ziffern (hier: 8). Sie definieren die Zusatzfunktionen sowie Zahl der I/O-Ports.
# Bis zu zwei Buchstaben (hier: PA), die für die Revision sowie spezielle stromsparende Architekturen stehen.
# Einem Bindestrich und zwei weiteren Buchstaben, die die Bauform angeben (hier: AU).

====Baureihe====

Hier gibt es nur zwei Reihen: Den kleinen ATtiny mit reduziertem Funktionsumfang und den großen ATmega.

====Speichergröße====

Während die Größe des Flashspeichers (Programmspeicher) direkt im Namen angegeben ist, ergibt sich die Größe von RAM und EEPROM nur indirekt aus dieser Nummer, wobei natürlich die Bausteine mit großem Flash auch mehr RAM und EEPROM haben als kleinere. Grob gilt diese Zuordnung:

{| class="wikitable"
|-
! Flash (kB) !! EEPROM (B) !! RAM (B)
|-
| 2 || tiny: 128 || tiny: 128
|-
| 4 || tiny: var., mega: 256 || tiny: 256, mega: 512
|-
| 8 || tiny: var., mega: 512 || tiny: 512, mega: 1024
|-
| 16 || 512 || 1024
|-
| 32 || 1024 || 2048
|-
| 64 || 2048*) || 4096*)
|-
| 128 - 256 || 4096 || 4K - 16K
|}
*)Atmega640 verfügt über den doppelten Speicher

====Zusatzfunktionen / Größe====
Die Ziffer(n) nach der Flashgröße geben die Ausstattungsmerkmale des Bausteins an. Die folgende Tabelle gilt für die Atmega-Reihe:
{| class="wikitable"
|-
! Ziffer !! Beschreibung
|-
| - || Keine Ziffer markiert die Bausteine der ersten Generation. Sie verfügen in der Regel über eine niedrigere maximale Taktrate (8/16 MHz anstatt 10/20 MHz), eine höhere Minimal-Spannung (2,7 anstatt 1,8 Volt), weniger Interrupt-Quellen und PWM-Kanäle
|-
| 0 || Reihe von 32 - 256 kB in einem größeren Gehäuse mit höherer Anzahl an I/O-Pins. Etwas älter als die aktuellen Reihen 4 und 8.
|-
| 1 || Kennzeichnet eine verbesserte Version des Atmega128 / 256, aber älter als aktuelle 4er Reihe
|-
| 4 || Reihe von 16 bis 128 kB Flash, alle pinkompatibel in 40-44 poligem Gehäuse. Neueste Baureihe, alle in pico-power-Technologie mit vielen verbesserten Funktionen wie externen Interrupts, Timern, USART...
|-
| 5 || Reihe von 16 bis 64 kB
|-
| 8 || Reihe von 4 bis 32 kB, alle pinkompatibel in 28-32 poligem Gehäuse. Neueste Baureihe, alle in pico-power-Technologie mit vielen verbesserten Funktionen wie externen Interrupts, Timern, USART.... (auch in der Attiny-Reihe vorhanden)
|-
| 9 || Reihe von 16 bis 64 kB mit integriertem Controller für LC-Displays, folglich in großen Gehäusen (64-/100-polig)
|}
Aus dieser Liste stechen einige Bausteine als Außenseiter hervor:
* Atmega8515 / Atmega8535
* Atmega640: Im Prinzip ein Atmega64 mit deutlich mehr Hardware-Ressourcen (4 UARTs, 16 ADC-Kanäle...) und doppelt soviel EEPROM / SRAM.

====Revision / Architektur====
Die (optionalen) Buchstaben vor dem Bindestrich geben Auskunft über den Stromverbrauch und Spannungsbereich
{| class="wikitable"
|-
! Buchstabe !! Beschreibung
|-
| A || Zweite Revision - meist nur eine Umstellung der internen Strukturen ohne Auswirkung für den Benutzer
|-
| L / V || "Low-Voltage": Speziell für niedrigere Taktraten (8 bzw. 10 MHz) sowie niedrigere Eingangsspannungen (1,8 bzw. 2,7V) selektierte Bausteine
|-
| P/PA || "Pico-Power": Reduzierter Stromaufnahme, besonders in tiefen Sleep-Modes (< 1uA); Manche Bausteine (z.B. Mega48) gibt es als P und PA
|}

==== Bauform====
Die beiden Buchstaben nach dem Bindestrich geben Auskunft über die Bauform. Die Zahl der Pins des jeweiligen Gehäusetyps hängt vom Baustein ab.
{| class="wikitable"
|-
! Buchstaben !! Beschreibung
|-
| A || TQFP-Gehäuse
|-
| C || BGA-Gehäuse
|-
| I || Bleihaltig - nicht mehr erhältlich
|-
| J || PLCC-Gehäuse
|-
| M || (V)QFN- / MLF- Gehäuse
|-
| P || DIP-Gehäuse (bastlerfreundlich!)
|-
| S || SOIC-Gehäuse
|-
| U || Bleifrei, RoHS-kompatibel
|-
| X || TSSOP-Gehäuse
|}

===ATtiny===
Bei den ATtiny-Bausteinen ist die Nummerierung deutlich unübersichtlicher als in der ATmega-Reihe. Die erste Ziffer gibt wie auch bei ATmega die Größe des Flash-Speichers an. Die obenstehenden Tabellen für Baureihe, Bauform, Revision und Speichergröße gelten ebenfalls (Ausnahmen: ATtiny5 mit 0,5 Kilobytes Flash sowie ATtiny4 und ATtiny9 mit 0,5 bzw. 1 kB Flash). Die Zusatzfunktionen und Baugröße sind aber nicht deutlich

== Vergleichstabelle(n) / Ausstattung ==
=== AT90S - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_AT90S"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform
|- 
|[http://www.atmel.com/dyn/resources/prod_documents/doc0839.pdf AT90S2313]<ref>veraltet → ATtiny2313</ref>
|2
|128
|128
|15
|10
|2.7-6.0
|Ja
|1
|1
|Nein
|Nein
|1
|Nein
|Nein
|Nein
|Ja
|Nein
|Ja
|Ja
|PDIP20 SOIC20
|- 
|[http://www.atmel.com/atmel/acrobat/doc1004.pdf AT90S2323]<ref>veraltet → ATtiny25/45/85</ref>
|2
|128
|128
|3
|10
|2.7-6.0
|Nein
|0
|1
|Nein
|Nein
|0
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
|- 
|[http://www.atmel.com/atmel/acrobat/doc1004.pdf AT90S2343]<ref>veraltet → ATtiny25/45/85</ref>
|2
|128
|128
|5
|10
|2.7-6.0
|Nein
|0
|1
|Nein
|Ja
|0
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
|- 
|[http://www.atmel.com/atmel/acrobat/doc0841.pdf AT90S8515]<ref>veraltet → ATmega16/162/32/644</ref>
|8
|512
|512
|32
|8
|2.7-6.0
|Ja
|1
|1
|Nein
|Nein
|1 (16-Bit)
|Nein
|Nein
|Nein
|Ja
|Nein
|Ja
|Ja
|PDIP40 PLCC44 TQFP44


|}

=== ATtiny - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATtiny"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||A/D Channels||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform(en)||Preis<ref name="preis"/>
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1006.pdf ATtiny11]
|1
| --
| --
|6
|6
|2.7-5.5
| --
|Ja
| --
|1
|Nein
|Nein
| --
|Nein
|Nein
|Nein
|Nein
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.58-0.87
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1006.pdf ATtiny12]
|1
|64
| --
|6
|8
|1.8-5.5
| --
|Ja
| --
|1
|Ja
|Ja
| --
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 1.00-1.20
|-
|[http://www.atmel.com/Images/doc8126.pdf ATtiny13A]
|1
|64
|64
|6
|20
|1.8-5.5
|4 10bit
|Ja
| --
|1
|Ja
|Ja
|1<ref>Timer-PWM</ref>
|Nein
|Ja
|Ja
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.70-1.20
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1187.pdf ATtiny15]
|1
|64
| --
|6
|1.6
|2.7-5.5
|4 10bit
|Ja
| --
|2
|Ja
|ONLY
|1<ref>150kHz 8bit</ref>
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 1.15
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf ATtiny2313]
|2
|128
|128
|18
|20
|2.7-5.5
| --
|Ja
|1
|1
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Ja<ref name="usart">USART</ref>
|Ja
|PDIP20 SOIC20 QFN20 MLF20
| 1.30
|-
|[http://www.atmel.com/Images/doc8246.pdf ATtiny4313]
|4
|256
|256
|18
|20
|1.8-5.5
| --
|Ja
|1
|1
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Ja<ref name="usart">USART</ref>
|Ja
|PDIP20 SOIC20 QFN20 MLF20
| 1.00-2.00
|-
|[http://atmel.com/dyn/resources/prod_documents/doc8006.pdf ATtiny24]
|2
|128
|128
|12
|20
|1.8-5.5
|8 10bit
|Ja
|Ja
|Ja
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Nein
|Ja
|PDIP14 SOIC14 QFN20/MLF20
|1.45
|-
|[http://atmel.com/dyn/resources/prod_documents/doc2588.pdf ATtiny261]
|2
|128
|128
|16
|20
|1,8-5,5
|11
|1
|1
|1
|Ja
|Ja
|2
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Nein
|Ja
|PDIP20 SOIC20 MLF20 (TSSOP20 bei Tiny261A)
|1,15
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2586.pdf ATtiny85]
|8
|512
|512
|6
|20
|1.8-5.5
|4
|Ja
| --
|2
|Ja
|Ja
|4
|Nein
|Ja
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 1.30-2.00
|}

=== ATmega - Reihe ===
{| class="wikitable sortable" style="font-size: 10px;" id="AVR_Features_ATMega"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||A/D Channels||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform||Preis<ref name="preis"/>
|-
|[http://www.atmel.com/dyn/resources/prod_documents/2486S.pdf ATmega8]
|8
|512
|1K
|23
|16
|2.7-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|3
|Ja
|Ja
|Ja
|Ja
|Ja
|Ja USART
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 1.70-1.90
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf ATmega16]
|16
|512
|1K
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|4
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 2.60-2.85
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2513.pdf ATmega162]
|16
|512
|1K
|35
|16
|2.7-5.5
|Keine
|Ja
|2
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Nein
|2<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 2.70-3.80
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf ATmega32]
|32
|1K
|2K
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|4
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 3.20-4.60
|-
|[http://www.atmel.com/Images/doc8271.pdf ATmega328]
|32
|1K
|2K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 2.00-4.50
|-
|[http://www.atmel.com/atmel/acrobat/doc2490.pdf ATmega64]<ref>Geliefert im ATmega103-Modus. Fuse ändern!</ref>
|64
|2K
|4K
|53
|16
|2.7-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|2 8bit, 6 2-16bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
| TQFP64 QFN/MLF64
| 7.50-9.50
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf ATmega644]
|64
|2K
|4K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref> 2<ref>beim 644P</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 6.80-7.50
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf ATmega128]
|128
|4K
|4K
|53
|16
|2.7-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|2 8bit 6 2-16bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|2<ref name="usart">USART</ref>
|Ja
|TQFP64 QFN/MLF64
|8.05-8.40
|-
|[http://www.atmel.com/dyn/products/product_card.asp?part_id=4331 ATmega1284P]
|128
|4K
|16K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|2<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
|(5.25-8 EUR)
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2549.pdf ATmega2560]
|256
|4K
|8K
|86
|16
|2.7-5.5
|16 10bit
|Ja
|4
|2
|Ja
|Ja
|16
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|4<ref name="usart">USART</ref>
|Ja
|TQFP100
|8-15
|-
|[http://www.atmel.com/atmel/acrobat/doc2512.pdf ATmega8515]
|8
|512
|512
|35
|16
|2.7-5.5
|Keine
|Ja
|1
|1
|Ja
|Ja
|1 8-bit, 1 16-bit
|Nein
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Nein
|1<ref name="usart">USART</ref>
|Ja
|PDIP20 TQFP44 PLCC44 QFN/MLF44
|3.20-3.90
|-
|[http://www.atmel.com/atmel/acrobat/doc2502.pdf ATmega8535]
|8
|512
|512
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|2 8-bit, 2 16-bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP44 PLCC44 QFN/MLF44
|3.15-3.75



|}

=== ATXMega - Reihe ===
{| class="wikitable sortable" style="font-size: 10px;" id="AVR_Features_ATXMega"
|-
!Typ||Flash (Kbytes)||EEPROM (KBytes)||SRAM (KBytes)||Boot (Kbytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||ADC||DAC||PWM Channels||16-Bit Timer||SPI||TWI (I2C)||UART||Bauformen
|-
|ATxmega16a4
|16
|1
|2
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega32a4
|32
|1
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega64a4
|64
|2
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega128a4
|128
|2
|8
|8
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega64a3
|64
|2
|4
|4
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega128a3
|128
|2
|8
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega192a3
|192
|2
|16
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega256a3
|256
|4
|16
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega64a1
|64
|2
|4
|4
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega128a1
|128
|2
|8
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega192a1
|192
|2
|16
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega256a1
|256
|4
|16
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega384a1
|384
|4
|32
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega16d4
|16
|1
|2
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega32d4
|32
|1
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega64d4
|64
|2
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega128d4
|128
|2
|8
|8
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega64d3
|64
|2
|4
|4
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega128d3
|128
|2
|8
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega192d3
|192
|2
|16
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega256d3
|256
|4
|16
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|}

== Weitere Vergleichstabellen ==
Vergleichstabellen zum Downloaden gibt es unter Anderem
* [http://www.mikrocontroller.net/topic/242328 von Andreas], Stand 19.12.2011; vollständig,
* [http://www.mikrocontroller.net/topic/232939 von Sven], Stand 22.09.2011; weiter eingedampft.

=== ATtiny ===

{| class="wikitable"
|+ '''Device-specific Features'''  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! Max. &fnof;CPU [MHz]
! of Touch Kanäle
! Hardware Qtouch
! Max I/O Pins
! Ext Interrupts
! SPI
! TWI
! UART
! LIN
! ADC Kanäle
! ADC Auflösung [bits]
! ADC Speed [ksps]
! Temp. Sensor
! SRAM [KiB]
! EEPROM [Bytes]
! Self Program Memory
! picoPower
! Temp. Bereich [°C]
! I/O Supply Class [V]
! Operating Voltage [VCC]
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! 32kHz RTC
! Device
|-
| '''ATtiny28L''' || 2 || 28 || 4 || — || — || 11 || 10 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 0 || 0 || 0 || — || '''ATtiny28L'''
|-
| '''ATtiny26''' || 2 || 20 || 16 || — || — || 16 || 11 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || — || 0.12 || 128 || — || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 3 || 0 || 4 || — || '''ATtiny26'''
|-
| '''ATtiny13''' || 1 || 8 || 20 || — || — || 6 || 6 || 0 || 0 || 0 || 0 || 4 || 10 || 15 || — || 0.06 || 64 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 0 || 2 || — || '''ATtiny13'''
|-
| '''ATtiny2313''' || 2 || 20 || 20 || 4 || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny2313'''
|-
| '''ATtiny25''' || 2 || 8 || 20 || 4 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 105 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || '''ATtiny25'''
|-
| '''ATtiny85''' || 8 || 8 || 20 || 3 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || '''ATtiny85'''
|-
| '''ATtiny45''' || 4 || 8 || 20 || 3 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || '''ATtiny45'''
|-
| '''ATtiny24''' || 2 || 14 || 20 || 4 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny24'''
|-
| '''ATtiny44''' || 4 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny44'''
|-
| '''ATtiny84''' || 8 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny84'''
|-
| '''ATtiny261''' || 2 || 20 || 20 || 4 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny261'''
|-
| '''ATtiny461''' || 4 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny461'''
|-
| '''ATtiny861''' || 8 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny861'''
|-
| '''ATtiny13A''' || 1 || 8 || 20 || — || — || 6 || 6 || 0 || 0 || 0 || 0 || 4 || 10 || 15 || — || 0.06 || 64 || √ || √ || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 0 || 2 || — || '''ATtiny13A'''
|-
| '''ATtiny48''' || 4 || 32 || 12 || 12 || — || 28 || 28 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 64 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || '''ATtiny48'''
|-
| '''ATtiny88''' || 8 || 32 || 12 || 12 || — || 28 || 28 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 64 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || '''ATtiny88'''
|-
| '''ATtiny24A''' || 2 || 14 || 20 || 4 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 128 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny24A'''
|-
| '''ATtiny44A''' || 4 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny44A'''
|-
| '''ATtiny43U''' || 4 || 20 || 8 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.25 || 64 || √ || √ || −40 – 85 || 0.7 – 5.5 || 0.7 – 5.5 || 2 || 4 || 0 || 4 || — || '''ATtiny43U'''
|-
| '''ATtiny10''' || 1 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 4 || 8 || 15 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || '''ATtiny10'''
|-
| '''ATtiny4''' || 0.5 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || '''ATtiny4'''
|-
| '''ATtiny5''' || 0.5 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 4 || 8 || 15 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || '''ATtiny5'''
|-
| '''ATtiny9''' || 1 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || '''ATtiny9'''
|-
| '''ATtiny261A''' || 2 || 20 || 20 || 4 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.12 || 128 || √ || √ || −40 – 105 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny261A'''
|-
| '''ATtiny461A''' || 4 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny461A'''
|-
| '''ATtiny861A''' || 8 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || '''ATtiny861A'''
|-
| '''ATtiny2313A''' || 2 || 20 || 20 || — || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.12 || 128 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny2313A'''
|-
| '''ATtiny4313''' || 4 || 20 || 20 || — || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny4313'''
|-
| '''ATtiny167''' || 16 || 20 || 16 || 8 || — || 16 || 16 || 2 || 1 || 1 || 1 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 3 || 1 || 9 || √ || '''ATtiny167'''
|-
| '''ATtiny87''' || 8 || 20 || 16 || — || — || 16 || 16 || 2 || 1 || 1 || 1 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 3 || 1 || 9 || √ || '''ATtiny87'''
|-
| '''ATtiny20''' || 2 || 14 || 12 || 5 || √ || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 3 || — || '''ATtiny20'''
|-
| '''ATtiny40''' || 4 || 20 || 12 || 12 || √ || 18 || 18 || 1 || 1 || 0 || 0 || 12 || 10 || 15 || √ || 0.25 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || '''ATtiny40'''
|-
| '''ATtiny84A''' || 8 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || '''ATtiny84A'''
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''CPU''' || 8-bit AVR
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''USB Transceiver''' || 0
|-
| '''USB Speed''' || nein
|-
| '''USB Interface''' || nein
|-
| '''CAN''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Segment LCD''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''Analog Comparators''' || 1
|-
| '''Resistive Touch Screen''' || nein
|-
| '''DAC Kanäle''' || 0
|-
| '''DAC Auflösung [bits]''' || 0
|-
| '''External Bus Interface''' || 0
|-
| '''DRAM Memory''' || nein
|-
| '''NAND Interface''' || nein
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''Crypto Engine''' || nein
|-
| '''Calibrated RC Oscillator''' || ja
|}

=== ATmega ===

{| class="wikitable"
|+ '''Device-specific Features'''  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! Max. &fnof;CPU [MHz]
! of Touch Kanäle
! Max I/O Pins
! Ext Interrupts
! USB Transceiver
! USB Speed
! USB Interface
! SPI
! TWI
! UART
! CAN
! LIN
! Segment LCD
! ADC Kanäle
! ADC Auflösung [bits]
! ADC Speed [ksps]
! Analog Comparators
! DAC Kanäle
! DAC Auflösung [bits]
! Temp. Sensor
! SRAM [KiB]
! EEPROM [Bytes]
! Self Program Memory
! picoPower
! Temp. Bereich [°C]
! I/O Supply Class [V]
! Operating Voltage [VCC]
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! 32kHz RTC
! Device
|-
| '''ATmega8''' || 8 || 32 || 16 || 12 || 23 || 2 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 3 || 1 || 3 || √ || '''ATmega8'''
|-
| '''ATmega8515''' || 8 || 44 || 16 || 16 || 35 || 3 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 3 || 1 || 3 || — || '''ATmega8515'''
|-
| '''ATmega8535''' || 8 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega8535'''
|-
| '''ATmega16''' || 16 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega16'''
|-
| '''ATmega32''' || 32 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega32'''
|-
| '''ATmega64''' || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''ATmega64'''
|-
| '''ATmega128''' || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''ATmega128'''
|-
| '''ATmega162''' || 16 || 44 || 16 || 16 || 35 || 3 || 0 || — || — || 1 || 0 || 2 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 4 || 6 || 2 || 6 || √ || '''ATmega162'''
|-
| '''ATmega48''' || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 0.5 || 256 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega48'''
|-
| '''ATmega88''' || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega88'''
|-
| '''ATmega168''' || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega168'''
|-
| '''AT90CAN128''' || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''AT90CAN128'''
|-
| '''ATmega325''' || 32 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega325'''
|-
| '''ATmega3250''' || 32 || 100 || 16 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3250'''
|-
| '''ATmega6450''' || 64 || 100 || 16 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6450'''
|-
| '''ATmega645''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega645'''
|-
| '''ATmega329''' || 32 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega329'''
|-
| '''ATmega3290''' || 32 || 100 || 16 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3290'''
|-
| '''ATmega649''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega649'''
|-
| '''ATmega6490''' || 64 || 100 || 16 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6490'''
|-
| '''ATmega640''' || 64 || 100 || 16 || 16 || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || '''ATmega640'''
|-
| '''ATmega1281''' || 128 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 2 || 8 || √ || '''ATmega1281'''
|-
| '''ATmega2561''' || 256 || 64 || 16 || — || 54 || 17 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 2 || 8 || √ || '''ATmega2561'''
|-
| '''ATmega2560''' || 256 || 100 || 16 || — || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || '''ATmega2560'''
|-
| '''ATmega1280''' || 128 || 100 || 16 || 16 || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || '''ATmega1280'''
|-
| '''ATmega644''' || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega644'''
|-
| '''AT90CAN32''' || 32 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''AT90CAN32'''
|-
| '''AT90CAN64''' || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''AT90CAN64'''
|-
| '''AT90USB1286''' || 128 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || '''AT90USB1286'''
|-
| '''AT90USB1287''' || 128 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbo">Device + OTG</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || '''AT90USB1287'''
|-
| '''AT90USB647''' || 64 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbo">Device + OTG</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || '''AT90USB647'''
|-
| '''AT90USB646''' || 64 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || '''AT90USB646'''
|-
| '''ATmega164P''' || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega164P'''
|-
| '''ATmega324P''' || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega324P'''
|-
| '''ATmega165P''' || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega165P'''
|-
| '''ATmega169P''' || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega169P'''
|-
| '''ATmega644P''' || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega644P'''
|-
| '''AT90PWM1''' || 8 || 24 || 16 || 8 || 19 || 4 || 0 || — || — || 1 || 0 || 0 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || '''AT90PWM1'''
|-
| '''ATmega329P''' || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega329P'''
|-
| '''ATmega3290P''' || 32 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3290P'''
|-
| '''ATmega325P''' || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega325P'''
|-
| '''ATmega3250P''' || 32 || 100 || 20 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3250P'''
|-
| '''AT90USB82''' || 8 || 32 || 16 || 12 || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || '''AT90USB82'''
|-
| '''AT90USB162''' || 16 || 32 || 16 || — || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || '''AT90USB162'''
|-
| '''AT90PWM216''' || 16 || 24 || 16 || 12 || 19 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 1 || 10 || — || 1 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || '''AT90PWM216'''
|-
| '''AT90PWM316''' || 16 || 32 || 16 || 12 || 27 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || — || 1 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 5 || 16 || 1 || 12 || — || '''AT90PWM316'''
|-
| '''ATmega48P''' || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega48P'''
|-
| '''ATmega88P''' || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega88P'''
|-
| '''ATmega168P''' || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega168P'''
|-
| '''ATmega328P''' || 32 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega328P'''
|-
| '''AT90PWM3B''' || 8 || 32 || 16 || 8 || 27 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 5 || 16 || 1 || 12 || — || '''AT90PWM3B'''
|-
| '''AT90PWM2B''' || 8 || 24 || 16 || 8 || 19 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 1 || 10 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || '''AT90PWM2B'''
|-
| '''ATmega32U4''' || 32 || 44 || 16 || 14 || 26 || 13 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 12 || 10 || 15 || 1 || 0 || 0 || √ || 2.5 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 2 || 8 || — || '''ATmega32U4'''
|-
| '''ATmega1284P''' || 128 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 16 || 4096 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega1284P'''
|-
| '''ATmega16U4''' || 16 || 44 || 16 || 14 || 26 || 13 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 12 || 10 || 15 || 1 || 0 || 0 || √ || 1.25 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 2 || 8 || — || '''ATmega16U4'''
|-
| '''ATmega16A''' || 16 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega16A'''
|-
| '''ATmega32A''' || 32 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega32A'''
|-
| '''ATmega88PA''' || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega88PA'''
|-
| '''ATmega324PA''' || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega324PA'''
|-
| '''ATmega48PA''' || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega48PA'''
|-
| '''ATmega164PA''' || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega164PA'''
|-
| '''ATmega64A''' || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''ATmega64A'''
|-
| '''ATmega128A''' || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || '''ATmega128A'''
|-
| '''ATmega8A''' || 8 || 32 || 16 || 12 || 23 || 2 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || — || — || 3 || √ || '''ATmega8A'''
|-
| '''ATmega168PA''' || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega168PA'''
|-
| '''ATmega8U2''' || 8 || 32 || 16 || — || 22 || 20 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || '''ATmega8U2'''
|-
| '''ATmega16U2''' || 16 || 32 || 16 || 12 || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || '''ATmega16U2'''
|-
| '''ATmega32U2''' || 32 || 32 || 16 || 12 || 22 || 20 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 1 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || '''ATmega32U2'''
|-
| '''ATmega644PA''' || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega644PA'''
|-
| '''ATmega16M1''' || 16 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || '''ATmega16M1'''
|-
| '''ATmega32M1''' || 32 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || '''ATmega32M1'''
|-
| '''ATmega64M1''' || 64 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || '''ATmega64M1'''
|-
| '''ATmega169PA''' || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega169PA'''
|-
| '''ATmega48A''' || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega48A'''
|-
| '''ATmega88A''' || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega88A'''
|-
| '''ATmega168A''' || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega168A'''
|-
| '''ATmega328''' || 32 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega328'''
|-
| '''ATmega164A''' || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega164A'''
|-
| '''ATmega324A''' || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega324A'''
|-
| '''ATmega644A''' || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega644A'''
|-
| '''ATmega1284''' || 128 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 16 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || '''ATmega1284'''
|-
| '''AT90PWM81''' || 8 || 20 || 16 || — || 20 || 3 || 0 || — || — || 1 || 0 || 0 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || √ || 0.25 || 512 || √ || — || −40 – 125 || 2.7 – 5.5 || 2.7 – 5.5 || 1 || 8 || 1 || 6 || — || '''AT90PWM81'''
|-
| '''ATmega165PA''' || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega165PA'''
|-
| '''ATmega325A''' || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega325A'''
|-
| '''ATmega3250A''' || 32 || 100 || 20 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3250A'''
|-
| '''ATmega645A''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega645A'''
|-
| '''ATmega645P''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega645P'''
|-
| '''ATmega6450P''' || 64 || 100 || 20 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6450P'''
|-
| '''ATmega6450A''' || 64 || 100 || 20 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6450A'''
|-
| '''ATmega169A''' || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega169A'''
|-
| '''ATmega329A''' || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega329A'''
|-
| '''ATmega649A''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega649A'''
|-
| '''ATmega3290A''' || 32 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega3290A'''
|-
| '''ATmega649P''' || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega649P'''
|-
| '''ATmega6490A''' || 64 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6490A'''
|-
| '''ATmega6490P''' || 64 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega6490P'''
|-
| '''ATmega329PA''' || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || '''ATmega329PA'''
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''CPU''' || 8-bit AVR
|-
| '''Hardware Qtouch''' || nein
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''Resistive Touch Screen''' || nein
|-
| '''External Bus Interface''' || 0
|-
| '''DRAM Memory''' || nein
|-
| '''NAND Interface''' || nein
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''Crypto Engine''' || nein
|-
| '''Calibrated RC Oscillator''' || ja
|}

=== ATxmega ===

{| class="wikitable"
|+ '''Device-specific Features'''  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! of Touch Kanäle
! Max I/O Pins
! Ext Interrupts
! USB Transceiver
! USB Speed
! USB Interface
! SPI
! TWI
! UART
! Segment LCD
! ADC Kanäle
! ADC Speed [ksps]
! Analog Comparators
! DAC Kanäle
! DAC Auflösung [bits]
! SRAM [KiB]
! EEPROM [Bytes]
! External Bus Interface
! DRAM Memory
! Crypto Engine
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! Device
|-
| '''ATxmega64A1''' || 64 || 100 || 16 || 78 || 78 || 0 || — || — || 12 || 4 || 8 || 0 || 16 || 2000 || 4 || 4 || 12 || 4 || 2048 || 1 || ja<ref name="sdram">SDRAM</ref> || ja<ref name="cry">AES/DES</ref> || 8 || 24 || 24 || 24 || '''ATxmega64A1'''
|-
| '''ATxmega128A1''' || 128 || 100 || 16 || 78 || 78 || 0 || — || — || 12 || 4 || 8 || 0 || 16 || 2000 || 4 || 4 || 12 || 8 || 2048 || 1 || ja<ref name="sdram">SDRAM</ref> || ja<ref name="cry">AES/DES</ref> || 8 || 24 || 24 || 24 || '''ATxmega128A1'''
|-
| '''ATxmega64A3''' || 64 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega64A3'''
|-
| '''ATxmega128A3''' || 128 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega128A3'''
|-
| '''ATxmega192A3''' || 192 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega192A3'''
|-
| '''ATxmega256A3''' || 256 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega256A3'''
|-
| '''ATxmega16A4''' || 16 || 44 || 16 || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 3.3 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega16A4'''
|-
| '''ATxmega32A4''' || 32 || 44 || 16 || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega32A4'''
|-
| '''ATxmega64A4''' || 64 || 44 || — || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega64A4'''
|-
| '''ATxmega128A4''' || 128 || 44 || — || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega128A4'''
|-
| '''ATxmega256A3B''' || 256 || 64 || 16 || 47 || 49 || 0 || — || — || 8 || 2 || 6 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega256A3B'''
|-
| '''ATxmega256D3''' || 256 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 16 || 4096 || 0 || — || — || 5 || 18 || 18 || 18 || '''ATxmega256D3'''
|-
| '''ATxmega192D3''' || 192 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 16 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || '''ATxmega192D3'''
|-
| '''ATxmega128D3''' || 128 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 8 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || '''ATxmega128D3'''
|-
| '''ATxmega64D3''' || 64 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 4 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || '''ATxmega64D3'''
|-
| '''ATxmega128D4''' || 128 || 44 || — || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 8 || 2048 || 0 || — || — || 4 || 14 || 14 || 14 || '''ATxmega128D4'''
|-
| '''ATxmega64D4''' || 64 || 44 || — || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 4 || 2048 || 0 || — || — || 4 || 14 || 14 || 14 || '''ATxmega64D4'''
|-
| '''ATxmega32D4''' || 32 || 44 || 16 || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 4 || 1024 || 0 || — || — || 4 || 14 || 14 || 14 || '''ATxmega32D4'''
|-
| '''ATxmega16D4''' || 16 || 44 || 16 || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 2 || 1024 || 0 || — || — || 4 || 14 || 14 || 14 || '''ATxmega16D4'''
|-
| '''ATxmega16A4U''' || 16 || 44 || 16 || 34 || 34 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 3.3 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega16A4U'''
|-
| '''ATxmega32A4U''' || 32 || 44 || 16 || 34 || 34 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || '''ATxmega32A4U'''
|-
| '''ATxmega64A3U''' || 64 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega64A3U'''
|-
| '''ATxmega128A3U''' || 128 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega128A3U'''
|-
| '''ATxmega192A3U''' || 192 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega192A3U'''
|-
| '''ATxmega256A3U''' || 256 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega256A3U'''
|-
| '''ATxmega256A3BU''' || 256 || 64 || 16 || 47 || 49 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 8 || 2 || 6 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || '''ATxmega256A3BU'''
|-
| '''ATxmega64B3''' || 64 || 64 || 16 || 36 || 36 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 100 || 8 || 2000 || 2 || 0 || 0 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 2 || 6 || 6 || 6 || '''ATxmega64B3'''
|-
| '''ATxmega128B3''' || 128 || 64 || 16 || 36 || 36 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 100 || 8 || 2000 || 2 || 0 || 0 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 2 || 6 || 6 || 6 || '''ATxmega128B3'''
|-
| '''ATxmega128B1''' || 128 || 100 || 16 || 53 || 53 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 3 || 1 || 2 || 160 || 16 || 2000 || 4 || 0 || 0 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 3 || 10 || 10 || 10 || '''ATxmega128B1'''
|-
| '''ATxmega64B1''' || 64 || 100 || 16 || 53 || 53 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 3 || 1 || 2 || 160 || 16 || 2000 || 4 || 0 || 0 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 3 || 10 || 10 || 10 || '''ATxmega64B1'''
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''Max. &fnof;CPU [MHz]''' || 32
|-
| '''CPU''' || 8-bit AVR
|-
| '''Hardware Qtouch''' || nein
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''CAN''' || 0
|-
| '''LIN''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''ADC Auflösung [bits]''' || 12
|-
| '''Resistive Touch Screen''' || nein
|-
| '''Temp. Sensor''' || ja
|-
| '''Self Program Memory''' || ja
|-
| '''NAND Interface''' || nein
|-
| '''picoPower''' || ja
|-
| '''Temp. Bereich [°C]''' || −40 – 85
|-
| '''I/O Supply Class [V]''' || 1.6 – 3.6
|-
| '''Operating Voltage [VCC]''' || 1.6 – 3.6
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''32kHz RTC''' || ja
|-
| '''Calibrated RC Oscillator''' || ja
|}

== Referenzen ==
<references/>

== Weblinks ==

* [http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=devCompare Vergleichstabelle] von AVRFreaks
* [http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC#760 Vergleichstabelle aller aktuellen AVR Controller bei Atmel]

[[Category:AVR]]

GPIB-RS232-Schnittstelle

2012-04-22T15:25:52Z

Haku: /* Downloads */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337Hz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Schaltung ==
[[Datei:gpib-rs232-sch.png|miniatur|Schaltplan]]
[[Datei:gpib-rs232-brd.png|miniatur|Board]]
Die Schaltung ist in EAGLE realisiert; Maßstab des Board ist 1:2, also nicht wundern... Das ganze hat mit drei Drahtbrücken einseitig funktioniert. Die Drahtbrücke oben links verbindet die Schirmung mit Masse.

Schaltplan und Board stelle ich vorerst unter der aktuellen [http://creativecommons.org/licenses/by-nc-sa/3.0/de/ CC-BY-NC-SA] zur Verfügung.

== Downloads ==
Die jeweils aktuelle Version hängt am jüngsten Beitrag im Thread.

== Siehe auch ==
* [http://www.mikrocontroller.net/topic/256475 Thread zum Artikel]
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]
[[Kategorie:UART und RS232]]

GPIB-RS232-Schnittstelle

2012-04-22T15:24:20Z

Haku: /* Siehe auch */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337Hz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Schaltung ==
[[Datei:gpib-rs232-sch.png|miniatur|Schaltplan]]
[[Datei:gpib-rs232-brd.png|miniatur|Board]]
Die Schaltung ist in EAGLE realisiert; Maßstab des Board ist 1:2, also nicht wundern... Das ganze hat mit drei Drahtbrücken einseitig funktioniert. Die Drahtbrücke oben links verbindet die Schirmung mit Masse.

Schaltplan und Board stelle ich vorerst unter der aktuellen [http://creativecommons.org/licenses/by-nc-sa/3.0/de/ CC-BY-NC-SA] zur Verfügung.

== Downloads ==

== Siehe auch ==
* [http://www.mikrocontroller.net/topic/256475 Thread zum Artikel]
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]
[[Kategorie:UART und RS232]]

Datei:Gpib-rs232-brd.png

2012-04-12T14:50:49Z

Haku: Board RS232-GPIB-Schnittstelle

Board RS232-GPIB-Schnittstelle

Datei:Gpib-rs232-sch.png

2012-04-12T14:49:36Z

Haku: Schaltplan RS232-GPIB-Schnittstelle

Schaltplan RS232-GPIB-Schnittstelle

GPIB-RS232-Schnittstelle

2012-04-12T14:49:04Z

Haku:

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337Hz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Schaltung ==
[[Datei:gpib-rs232-sch.png|miniatur|Schaltplan]]
[[Datei:gpib-rs232-brd.png|miniatur|Board]]
Die Schaltung ist in EAGLE realisiert; Maßstab des Board ist 1:2, also nicht wundern... Das ganze hat mit drei Drahtbrücken einseitig funktioniert. Die Drahtbrücke oben links verbindet die Schirmung mit Masse.

Schaltplan und Board stelle ich vorerst unter der aktuellen [http://creativecommons.org/licenses/by-nc-sa/3.0/de/ CC-BY-NC-SA] zur Verfügung.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-06T08:51:46Z

Haku: /* Beispiel */ kHz -> Hz

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337Hz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-06T08:09:59Z

Haku: /* Beispiel */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337kHz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-06T06:49:20Z

Haku: /* Software */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM1" > ttyUSB1
Interne 10MHz-Referenz aufschalten:
$ echo "OUTPUT;CH1" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 0010.000000E+6

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-02T14:24:56Z

Haku:

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

Datei:Gpib-rs232.jpeg

2012-04-02T14:15:43Z

Haku: Fertig aufgebaute Schnittstelle.

Fertig aufgebaute Schnittstelle.

GPIB-RS232-Schnittstelle

2012-04-02T14:14:35Z

Haku: /* Einleitung */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu nehmen'', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T18:51:11Z

Haku: /* Terminologie */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu nehmen'', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T18:48:29Z

Haku: /* Controller-Betrieb */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu nehmen'', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T18:42:10Z

Haku:

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu nehmen'', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

''Jemand anderes'' sind genaugenommen wir, also arbeiten wir nur als Controller... und wären wieder beim Ausgangsproblem.

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T18:33:06Z

Haku: /* Hardware */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

''Jemand anderes'' sind genaugenommen wir, also arbeiten wir nur als Controller... und wären wieder beim Ausgangsproblem.

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T18:32:30Z

Haku: /* Controller-Betrieb */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft (beim GPIB spricht man quasi immer von Botschaften, auch wenn es sich dabei nur um eine der Steuerleitungen handelt, die ihren Pegel ändert) vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft (die ATN-Steuerleitung wird Low) ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns).

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

''Jemand anderes'' sind genaugenommen wir, also arbeiten wir nur als Controller... und wären wieder beim Ausgangsproblem.

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T17:14:16Z

Haku: /* Siehe auch */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft (beim GPIB spricht man quasi immer von Botschaften, auch wenn es sich dabei nur um eine der Steuerleitungen handelt, die ihren Pegel ändert) vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft (die ATN-Steuerleitung wird Low) ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. ''Jemand anderes'' sind genaugenommen wir, also arbeiten wir nur als Controller... und wären wieder beim Ausgangsproblem.

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T17:11:36Z

Haku: /* Software */

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Es hadelt sich dabei um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat und der mittlerweile vielfach genormt ist. Unter anderem als IEEE488 und als IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Graphik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft (beim GPIB spricht man quasi immer von Botschaften, auch wenn es sich dabei nur um eine der Steuerleitungen handelt, die ihren Pegel ändert) vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft (die ATN-Steuerleitung wird Low) ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. ''Jemand anderes'' sind genaugenommen wir, also arbeiten wir nur als Controller... und wären wieder beim Ausgangsproblem.

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

== Downloads ==

== Siehe auch ==
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]

GPIB-RS232-Schnittstelle

2012-04-01T17:02:33Z

Haku: /* Siehe auch */

GPIB-RS232-Schnittstelle

2012-04-01T17:01:29Z

Haku: /* Software */

GPIB-RS232-Schnittstelle

2012-04-01T16:46:45Z

Haku:

GPIB-RS232-Schnittstelle

2012-04-01T13:21:15Z

Haku: Die Seite wurde neu angelegt: „Achtung, Baustelle. ''von Sven Pauli'' Einfacher GPIB-Controller mit serieller Schnittstelle (RS232). == Einleitung == Viele Messgeräte sind (auch heute immer…“