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

== Hardware ==

'''Fuses richtig gesetzt?'''

Die AVR-Controller haben 'Fuses' (deutsch: 'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene beeinflussen. Ein häufiger Fehler ist beispielsweise, dass die falsche Taktquelle gewählt wurde: einige AVRs können mit dem internen Oszillator oder mit einem externen Oszillator oder mit einem Quarz oder mit einem Resonator betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu paßt, bekommt man auf der seriellen Schnittstelle Nonsens, und die Timer oder Zeitschleifen laufen mit der falschen Frequenz (evtl. läuft der Controller auch garnicht).
Eine andere Fuse schaltet auf einem Port (z. B. PORTC auf ATMega32) die JTAG-Unterstützung ein bzw. aus. Wenn sie eingeschaltet ist, funktionieren vier Bits dieses Ports nicht wie gewohnt.
In dem zum STK500 gehörenden Entwicklungstool 'AVR Studio' gibt es in der Programmer-Dialogbox einen Tab 'Fuses', der controllerabhängig den Status der Fusebits anzeigt und Änderungen ermöglicht.
Siehe auch: [[AVR Fuses]].

'''ISP-Adapter'''

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

'''Spannungsversorgung richtig angeschlossen?'''

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

'''Reset-Pin korrekt beschaltet?'''

Der Reset-Anschluss am AVR ist 'active-low', d. h. verbindet man den Pin mit GND (Masse), wird ein Reset ausgelöst. Zwar haben AVRs einen internen Pull-Up-Widerstand, der den Reset-Pin gegen VCC "zieht", dieser ist jedoch sehr hochohmig und reicht unter Umständen nicht aus, um den Reset-Pin sicher "hochzuhalten". Als Mindestbeschaltung empfiehlt sich dringend, einen externen Pull-Up-Widerstand vorzusehen (typ. 10 kOhm), der den Reset-Pin mit VCC verbindet. Er sollte nicht kleiner als 4,7 kOhm sein, da der Programmieradapter sonst eventuell den Reset-Pin während des Programmiervorgangs nicht sicher auf "low" ziehen kann. Zusätzlich sollte man auch noch einen Kondensator 47 nF oder 100 nF zwischen Reset-Pin und GND anordnen. (Atmel empfiehlt zusätzlich noch eine externe "Clamp-Diode" nach VCC, da für den Reset-Pin keine interne vorhanden ist. Diese Diode bereitet jedoch bei manchen Programmieradaptern Schwierigkeiten). Dieses RC-Glied sorgt dafür, dass beim Einschalten der Versorgungsspannung, für eine definierte Zeitspanne der Prozessor im Reset gehalten wird. Im laufenden Betrieb sorgt der Kondensator dafür, dass der Reseteingang unempfindlich gegenüber Spikes und Glitches wird. Der Kondensator sollte deshalb unmittelbar in Pin-Nähe beim Prozessor untergebracht werden.

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

Abblockkondensatoren ("Bunker-Kondensatoren") dienen dazu, Vorsorgungsspannungseinbrüche, die durch Schaltvorgänge verursacht werden können, zu kompensieren. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden: 1. Ein Abblockkondensator sollte möglichst dicht am IC sitzen, 2. Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen, 3. Bei ICs mit mehreren Anschlüssen für VCC und GND sollte jedes VCC-GND-Paar mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). 4. Es sollten keramische Kondensatoren mit einer Kapazität von 100 nF verwendet werden. Größere Kondensatoren wie etwa 10 µF-Elkos sind für diese Aufgabe nicht geeignet, weil sie "zu langsam" sind.

'''Quarz angeschlossen?'''

Die neueren AVRs haben einen internen [[Oszillator]], der im Auslieferungszustand über die entsprechenden Fuses eingeschaltet ist. In diesem Fall muss kein externer [[Quarz]] mehr angeschlossen werden. Man kann in den [[AVR Fuses|Fuse-Bits]] aber einstellen, dass man einen externen Taktgenerator (''ext. Clock'', z. B. Quarzoszillator) oder externen Quarz (''ext. Crystal'') verwenden möchte.
Dann, oder wenn der AVR keinen internen Takt hat, wird an die entsprechenden Pins des Controllers ein Quarz oder [[Quarzoszillator]] angeschlossen. Im Falle eines Quarzes werden die XTAL-Pins mit den beiden Anschlüssen des Quarzes und jeweils mit einem Kondensator (ca. 22 bis 27 pF) gegen Masse angeschlossen. Im Falle eines Quarzoszillators (Bauteil mit vier "Beinchen") reicht es aus, den Taktausgang mit dem XTAL1-Pin zu verbinden, und den XTAL2-Pin unbeschaltet zu lassen.

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

Bei AVRs mit mehreren Ground-Anschlüssen müssen alle Anschlüsse beschaltet werden.

http://www.mikrocontroller.net/forum/read-1-107259.html

'''Alle Lötstellen in Ordnung?'''

"Kalte", d. h. schlechte Lötstellen erkennt man an ihrer matten Oberfläche. Bei beschädigten Lötstellen erkennt man oft einen Riss, der sich kreisförmig um die Mitte des Lötpunktes herum gebildet hat. Solche Stellen verursachen oft erst bei mechanischer Beanspruchung Probleme.
Bei kleinen Abständen (SMD-Bauteile) müssen besonders Verbindungen zwischen benachbarten Lötungen kontrolliert werden.
Bei Lochrasterplatinen kann man mit einem spitzen Messer (Bastelmesser) die Zwischenräume von möglichen leitenden Verbindungen befreien.

'''Eingänge'''

Taster müssen a) entprellt werden ([[Entprellung]]) und b) einen [[Pullup-Widerstand]]
besitzen, so sie ''active-low'' betrieben werden, d. h. wenn beim Tastendruck der Pin mit GND (Masse) verbunden wird (dies ist die übliche Anschaltung). Man kann einen externen Pull-Up Widerstand (typ. 10 kOhm) benutzen oder den internen aktivieren (DDR als Eingang also "0", PORT auf "1").
Symptome: Aufgrund des Prellens bekommt man bei einem Tastendruck statt eines Signals mehrere,
und beim fehlenden Pullup fängt man sich Störungen (z. B. das 50 Hz-Netzbrummen) ein, da der Pin nicht auf einem "definierten Pegel" liegt, wenn der Taster nicht geschlossen ist. Soll
z. B. bei einem Tastendruck eine LED angehen, dann leuchtet die LED durch das
Netzbrummen plötzlich mit 50 Hz anstatt aus zu sein.
Will man einen Taster ''active-high'' betreiben, soll also bei Tastendruck eine "1" in PIN gelesen werden, ist ein externer Pull-Down-Widerstand (typ. 10 kOhm) gegen GND anzuschließen, denn interne Pull-Downs sind nicht verfügbar.

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

'''Ausgänge'''

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

'''ATMega128'''

Der ATMega128 hat zwei besondere Fallstricke, über die man bei nicht ausreichendem Datenblattstudium leicht stolpert.

* Der erste betrifft den Anschluß der ISP-Signale (MISO, MOSI, SCK, RESET). Dieser erfolgt nicht wie bei den meisten anderen AVR-Controllern an den gleichnamigen Pins, sondern an PDI, PDO, SCK und RESET. Die Pinzuordnung ist: MOSI->PE0 (Pin 2), MISO->PE1 (Pin 3), SCK->PB1 (Pin 11) und RESET->RESET (Pin 20). PEN (Pin 1) hat für normale ISP-Adapter keine Bedeutung und kann offen gelassen oder direkt mit Vcc verbunden werden.

* Die zweite kleine Gemeinheit betrifft die "M103C"-Fuse. Diese ist bei fabrikneuen ATMega128 gesetzt und sorgt dafür, dass sich dieser wie ein ATMega103 verhält. Andererseits hat dies zur Folge, dass ein für den ATMega128 geschriebenes Programm beim ersten "ret" abstürzt, da der SRAM an einer anderen Stelle liegt als erwartet und somit der Prozessor keine gültige Rücksprungadresse vom Stack holen kann. Außerdem funktionieren einige IO-Pins nicht korrekt.

== Software ==

'''Alle Interruptvektoren definiert?'''

Die [[Interrupt]]vektoren sollten alle definiert werden, auch wenn sie nicht verwendet werden. Passiert es dann aufgrund eines Fehlers, daß ein Interrupt unbeabsichtigt ausgeführt wird, so führt der Controller dann eine definierte Aktion aus. Benutzt man eine Hochsprache wie C oder Basic, nimmt einem der Compiler diese Arbeit ab.

Bemerkung: Es gibt keine unbeabsichtigten Interrupts, sondern höchstens Programmfehler. Wer [[sei]] nicht braucht, braucht auch keine Interrupttabelle.

'''Alle Konfigurationsregister korrekt initialisiert?'''

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

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

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

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

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

ldi r16, RAMEND ;Die Adresse der letzten Stelle im RAM in r16 laden
out SPL, r16 ;Die Adresse in das Register SPL ausgeben

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

ldi r16, LOW(RAMEND) ;Untere 8 bit des 16 bit-Wertes RAMEND laden
out SPL, r16
ldi r16, HIGH(RAMEND) ;Obere 8 bit laden
out SPH, r16

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

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

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

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

'''Flag richtig gelöscht?'''

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

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

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

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

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

== Serielle Verbindungen ==

''' ''[[I2C]]: '' Sind die Leitungen SCL und SDA mit einem Pullup-Widerstand ausgestattet?'''

Die I2C-Bus-Leitungen SCL und SDA müssen über einen [[Pullup-Widerstand]] mit einem Wert von 4.7 kOhm bis 10 kOhm mit der Versorgungsspannung (+5 V) verbunden sein.

''' ''[[UART]]/[[USART]]:'' Übertragungsprobleme wegen falschem Takt?'''

* der interne [[Oszillator]] ist nicht [[temperaturstabil]]. Daher kann die Umgebungstemperatur auch den [[USART]]-Takt verändern. Für schnelle serielle Kommunikation sollte man deshalb immer einen Quarz(oszillator) verwenden. Falls doch der interne Oszillator verwendet wird, wurde er für die richtige Frequenz kalibriert?

* Nicht mit allen Quarzen kann man alle [[Baud]]raten exakt erzeugen; deswegen gibt es Quarze mit so "krummen" [[Frequenz]]en wie 3,6864 MHz. Näheres steht im Datenblatt.

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

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

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

* TX/RX vertauscht?

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

== Web-Links ==
* [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]

USB

2005-12-21T15:51:12Z

213.187.90.186: /* USB Hostcontroller */

'''U'''niversal '''S'''erial '''B'''us.

Serieller Bus, der heutzutage an jedem neuen PC zu finden ist und langsam aber sicher die RS-232- und Parallelport-Anschlüsse ersetzt.

Übertragungsgeschwindigkeiten:
* Low Speed: 1,5 MBit/s (USB 1.1 und 2.0)
* Full Speed: 12 MBit/s (USB 1.1 und 2.0)
* High Speed: 480 MBit/s (nur USB 2.0)

Zu beachten ist, daß es bei USB (im Gegensatz etwa zu [[RS-232]]) zwei Arten von Controllern gibt: Host- und Devicecontroller. Host bezeichnet dabei die steuernde Seite und ist z.B. in PCs zu finden; Devices sind die USB-Geräte, z.B. USB-Webcams. Diese Unterscheidung ist ziemlich wichtig, weil die meisten USB-Lösungen für [[Mikrocontroller]] USB-Devices darstellen und man deswegen dort weder Webcams noch USB-Speichersticks anschließen kann. Mit der letzten Ergänzung des Standards (USB On-The-Go) gibt es die begrenzte Möglichkeit, das Geräte Host-Funktionalität zur Kommunikation mit ausgewählten Peripheriegeräten erhalten.

Benutzt man ein USB-Device am PC, dann braucht man auch noch passende Treiber. Die aktuellen Betriebssysteme bringen meist eine Reihe von Treibern für Standardanwendungen (z.B. USB-Festplatte) mit. Gibt es keinen passenden Standardtreiber, dann muß man eben einen erstellen. Dazu werden bei manchen Chips kostenlose Treiber mitgeliefert, bei anderen muß man sie kaufen oder (aufwendig) selbst erstellen.

=== Allgemeine Informationen ===

* [http://www.usb.org/home USB-Hauptseite] Die Homepage des USB Implementers Forum, Inc., creators of USB technology.
* [http://libusb.sourceforge.net/ libusb] Allgemein ist die Treiberprogrammierung für USB das Hauptproblem. Die plattformubergreifende libusb ([http://libusb-win32.sourceforge.net/ Win32-Port]) ermöglicht die Kommunikation mit USB-Geräten unter Verwendung eines Universaltreibers. Ein deutschsprachiges Projekt, erstellt von [http://www.weinga-unity.at.tt Weichinger Klaus], das libusb verwendet, findet man unter [http://www.ime.jku.at/tusb/] (Programmiersprache C mit MINGW; Dokumentation, Sourcecode und Binärdateien).

=== USB Hostcontroller ===
* http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html (Seite auf japanisch, mit [http://babelfish.altavista.com/ Babelfish] übersetzen lassen). Reine Softwarelösung, kann nur USB Low Speed
* http://www.semiconductors.philips.com/buses/usb/products/host/index.html
* <tt>CY7C67300</tt> von [http://www.cypress.com/ Cypress] Mit integriertem Microcontroller, <tt>SL811HST</tt> (Host/Device möglich, ohne Mikrocontroller)

=== USB Devices ===
====Implementation auf AVR====
* [http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm IgorPlug-USB] ? Reine Softwarelösung. Kann nur USB Low Speed (theoretisch 1.5Mbit/s).
* [http://www.obdev.at/products/avrusb/ AVRUSB] ? gleiches Prinzip wie IgorPlug, aber Entwickler-Schnittstellen in C, englisch kommentierter Code, GPL-ähnliche Lizenz
====Spezielle USB-µC====
* FT245/FT232 von [http://www.ftdichip.com/ FTDI]
* AN2131/2135 von [http://www.cypress.com/ Cypress] mit [[8051]]-kompatiblem Mikrocontroller (AKA EZUSB)
* TUSBxxxx-Serie von [http://www.ti.com/ Texas Instruments] ebenfalls mit [[8051]]-kompatiblem Mikrocontroller ([http://www.ime.jku.at/tusb/ Beispiel Projekt] von [http://www.weinga-unity.at.tt Weichinger Klaus])
* PDIUSBD11 von [http://www.semiconductors.philips.com Philips] mit I²C-Interface ('''mittlerweile abgekündigt''')
* PDIUSBD12 von [http://www.semiconductors.philips.com Philips] mit Parallel-Interface
* MAX3453E, MAX3454E, MAX3455E, MAX3456E - Alternativen zum PDIUSBD11 von [http://www.maxim-ic.com Maxim]
* USBN9603/USBN9604 von [http://www.national.com National] mit Parallel- und Microwire(SPI)-Interface
* PIC18F2455/2550/4455/4550 von [http://www.microchip.com/ Microchip], üppig ausgestattet mit USB, seriellem Port (RS232/SPI), PWM-Ausgängen, A/D-Wandler und vielen IO-Pins
* 69HC908JB8 von [http://www.freescale.com/ Freescale] 20 Pin DIP
* 69HC908JB16 von [http://www.freescale.com/ Freescale] Mehr Peripherie u.a. RS232
* 69HC908JG16 von [http://www.freescale.com/ Freescale] Mit A/D wandler
* 69HC908JW32 von [http://www.freescale.com/ Freescale] Mehr Speicher, mehr Ports

USB

2005-12-21T15:50:43Z

213.187.90.186: /* USB Hostcontroller */

'''U'''niversal '''S'''erial '''B'''us.

Serieller Bus, der heutzutage an jedem neuen PC zu finden ist und langsam aber sicher die RS-232- und Parallelport-Anschlüsse ersetzt.

Übertragungsgeschwindigkeiten:
* Low Speed: 1,5 MBit/s (USB 1.1 und 2.0)
* Full Speed: 12 MBit/s (USB 1.1 und 2.0)
* High Speed: 480 MBit/s (nur USB 2.0)

Zu beachten ist, daß es bei USB (im Gegensatz etwa zu [[RS-232]]) zwei Arten von Controllern gibt: Host- und Devicecontroller. Host bezeichnet dabei die steuernde Seite und ist z.B. in PCs zu finden; Devices sind die USB-Geräte, z.B. USB-Webcams. Diese Unterscheidung ist ziemlich wichtig, weil die meisten USB-Lösungen für [[Mikrocontroller]] USB-Devices darstellen und man deswegen dort weder Webcams noch USB-Speichersticks anschließen kann. Mit der letzten Ergänzung des Standards (USB On-The-Go) gibt es die begrenzte Möglichkeit, das Geräte Host-Funktionalität zur Kommunikation mit ausgewählten Peripheriegeräten erhalten.

Benutzt man ein USB-Device am PC, dann braucht man auch noch passende Treiber. Die aktuellen Betriebssysteme bringen meist eine Reihe von Treibern für Standardanwendungen (z.B. USB-Festplatte) mit. Gibt es keinen passenden Standardtreiber, dann muß man eben einen erstellen. Dazu werden bei manchen Chips kostenlose Treiber mitgeliefert, bei anderen muß man sie kaufen oder (aufwendig) selbst erstellen.

=== Allgemeine Informationen ===

* [http://www.usb.org/home USB-Hauptseite] Die Homepage des USB Implementers Forum, Inc., creators of USB technology.
* [http://libusb.sourceforge.net/ libusb] Allgemein ist die Treiberprogrammierung für USB das Hauptproblem. Die plattformubergreifende libusb ([http://libusb-win32.sourceforge.net/ Win32-Port]) ermöglicht die Kommunikation mit USB-Geräten unter Verwendung eines Universaltreibers. Ein deutschsprachiges Projekt, erstellt von [http://www.weinga-unity.at.tt Weichinger Klaus], das libusb verwendet, findet man unter [http://www.ime.jku.at/tusb/] (Programmiersprache C mit MINGW; Dokumentation, Sourcecode und Binärdateien).

=== USB Hostcontroller ===
* http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html (Seite auf japanisch, mit [http://babelfish.altavista.com/ Babelfish] übersetzen lassen). Reine Softwarelösung, kann nur USB Low Speed
* http://www.semiconductors.philips.com/buses/usb/products/host/index.html
* CY7C67300 von [http://www.cypress.com/ Cypress] Mit integriertem Microcontroller, SL811HST (Host/Device möglich, ohne Mikrocontroller)

=== USB Devices ===
====Implementation auf AVR====
* [http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm IgorPlug-USB] ? Reine Softwarelösung. Kann nur USB Low Speed (theoretisch 1.5Mbit/s).
* [http://www.obdev.at/products/avrusb/ AVRUSB] ? gleiches Prinzip wie IgorPlug, aber Entwickler-Schnittstellen in C, englisch kommentierter Code, GPL-ähnliche Lizenz
====Spezielle USB-µC====
* FT245/FT232 von [http://www.ftdichip.com/ FTDI]
* AN2131/2135 von [http://www.cypress.com/ Cypress] mit [[8051]]-kompatiblem Mikrocontroller (AKA EZUSB)
* TUSBxxxx-Serie von [http://www.ti.com/ Texas Instruments] ebenfalls mit [[8051]]-kompatiblem Mikrocontroller ([http://www.ime.jku.at/tusb/ Beispiel Projekt] von [http://www.weinga-unity.at.tt Weichinger Klaus])
* PDIUSBD11 von [http://www.semiconductors.philips.com Philips] mit I²C-Interface ('''mittlerweile abgekündigt''')
* PDIUSBD12 von [http://www.semiconductors.philips.com Philips] mit Parallel-Interface
* MAX3453E, MAX3454E, MAX3455E, MAX3456E - Alternativen zum PDIUSBD11 von [http://www.maxim-ic.com Maxim]
* USBN9603/USBN9604 von [http://www.national.com National] mit Parallel- und Microwire(SPI)-Interface
* PIC18F2455/2550/4455/4550 von [http://www.microchip.com/ Microchip], üppig ausgestattet mit USB, seriellem Port (RS232/SPI), PWM-Ausgängen, A/D-Wandler und vielen IO-Pins
* 69HC908JB8 von [http://www.freescale.com/ Freescale] 20 Pin DIP
* 69HC908JB16 von [http://www.freescale.com/ Freescale] Mehr Peripherie u.a. RS232
* 69HC908JG16 von [http://www.freescale.com/ Freescale] Mit A/D wandler
* 69HC908JW32 von [http://www.freescale.com/ Freescale] Mehr Speicher, mehr Ports