Mikrocontroller.net - Benutzerbeiträge [de]

Statemachine

2017-06-06T10:55:16Z

84.191.221.238: /* Weblinks */

==Einleitung==

Bei einem sogenannten [http://de.wikipedia.org/wiki/Finite_State_Machine Endlichen Zustandsautomaten] (engl. '''f'''inite '''s'''tate '''m'''achine, kurz FSM) handelt es sich um die Realisation eines Steuerungskonzeptes, welches eine abstrahierte Maschine zum Vorbild hat, die eine Reihe von Zuständen besitzt, durch die sich ihr Betriebsablauf definiert. Diese Maschine arbeitet, indem sie von einem Zustand in einen anderen Zustand übergeht und bei derartigen Zustandsübergängen und im Verharren von Zuständen bestimmte Aktionen ausführt. Dabei ergibt sich der Folgezustand aus dem momentanen Zustand und einem externen Ereignis, z. B. einem Tastendruck. Dabei ist die Maschine in verschiedenen Zuständen für ganz bestimmte Ereignisse sensibel.

Die FSM selbst wird fast immer in irgendeiner Weise über einen Takt angetrieben, kann also nicht in beliebig kurzen Zeitspannen auf Ereignisse reagieren und Zustände wechseln. In jedem Takt wird anhand des vorliegenden Zustands und dem Status der Eingabekanäle entschieden, welcher Zustand als nächstes vorliegen soll und welche Aktionen auszuführen sind.

Abstrahierte Formen dieser Maschine werden in vielen elektronischen Geräten eingesetzt, um Bedieneraktivitäten und andere Ereignisse im System zu verarbeiten und autark ablaufende Prozesse geeignet zu beeinflussen. Entsprechend formulierte FSMs können sowohl in Software als auch Hardware aufgebaut werden.

Die Beschreibung einer FSM ist auf mehrere Arten möglich. Zum einen kann sie in Form einer Tabelle beschrieben werden, aber auch eine graphische Darstellung der Zustände und deren Abhängigkeiten in Form eines Zustandsdiagramms ist möglich.

==Darstellung von Zustandsautomaten==

Zustandsautomaten haben den großen Charme, dass es meistens leicht möglich ist, ihre Funktion durch eine Grafik zu veranschaulichen.

Beispiel: Es ist eine FSM zu entwerfen, die eine Rollosteuerung übernimmt. Es gibt einen Motor, der sich in 3 Zuständen befinden kann: stop, rauf drehend, runter drehend. Außerdem gibt es Endschalter, welche betätigt werden, wenn das Rollo die jeweilige Endposition erreicht hat. Und es gibt 2 Taster "Up" und "Down" durch welche der Benutzer den Bewegungswunsch an die FSM weitergibt. Irgendwie weiß jeder, wie so eine Rollosteuerung funktioniert, und so recht und schlecht kann das auch jeder in der einen oder anderen Form beschreiben. Aber kann man das ganze auch so 'beschreiben', dass man im Vorfeld, vor der Programmierung tatsächlich alle Eventualitäten erfasst und so darstellt, dass auch ein Nicht-Informatiker die Funktionsweise versteht? Genau an dieser Stelle kommt die graphische Darstellung ins Spiel.

Wie sieht nun eine derartige FSM aus? Jede Wolke im Bild sei ein Zustand, dem man einen Namen gibt. Die Pfeile zwischen den Wolken zeigen die Zustandsübergänge an, wobei am Pfeil vermerkt ist, unter welcher Bedingung dieser Übergang genommen werden kann (in Rot) und welche Aktionen dabei auszuführen sind (in Blau).

[[Datei:StateRollo.jpg|center|framed|Zustandsautomat für eine Rollosteuerung]]

Aus der Zeichnung ist ablesbar:
Befindet sich die Maschine im Zustand "unten" und wird die Taste "Up" gedrückt, dann folgt als Aktion, daß der Motor auf "rauf drehend" gestellt wird und gleichzeitig wechselt die Maschine in den Zustand "nach oben". In diesem Zustand verbleibt die Maschine, während der Motor immer weiter dreht, bis der Endschalter meldet, dass das Rollo oben angekommen ist. Dies ist eine Möglichkeit wie die Maschine den Zustand "nach oben" verlassen kann. In diesem Fall wird dann der Motor abgeschaltet und die Maschine wechselt in den Zustand "oben".

Man sieht hier schon, dass es mit so einer Grafik relativ einfach ist, sich von der korrekten Logik zu überzeugen. In einfachsten Fall legt man zur Simulation einfach einen Gegenstand in die betreffende Wolke, die den gerade aktiven Zustand symbolisiert. Danach geht man alle Möglichkeiten durch, wie diese Maschine von aussen (Taster, Schalter, etc) beeinflusst werden kann und sieht sich an, ob es dafür in der Grafik einen Pfeil gibt, der von der aktiven Wolke wegführt. Gibt es keinen, dann passiert auch nichts. Gibt es einen, dann verschiebt man den Gegenstand in die betreffende Wolke und führt (in Gedanken) die Aktion aus. Auf die Art kann man ganz leicht einige typische Benutzerszenarien durchspielen aber auch ausprobieren, ob man alle Eventualitäten berücksichtigt hat. Denn gerade diese Evantualitäten, an die man am Anfang gar nicht denkt, die sind es, die einem in weiterer Folge oft Probleme bereiten.

Um bei der Rollosteuerung zu bleiben: Was soll denn passieren, wenn das Rollo gerade hochfährt und der Benutzer ein weiteres mal auf "Up" drückt? Oder wenn er auf "Down" drückt? In der Grafik ist ersichtlich, wie in diesem Fall zu verfahren ist. (Und Hand aufs Herz: Hätten Sie daran gedacht, dass diese Fälle zu berücksichtigen sind, als sie 'Rollosteuerung' gelesen haben?)

==Implementierungsvariationen==

Der konkrete softwaremässige Aufbau einer FSM kann in weiten Grenzen variieren. Das grundlegende Konzept, Aktionen an Zustände zu knüpfen und logische Abläufe an die Abfolge von Zuständen zu binden, bleibt dabei in allen Fällen erhalten. Aber je nach Lust und Laune und dem Können des Programmierers gibt es viele unterschiedliche Möglichkeiten eine FSM zu implementieren. Ziel ist es dabei immer, die eigentliche Maschine, also das was in der Zustandstabelle ausgedrückt wird, so einfach und überschaubar wie möglich zu präsentieren. Sie implementiert die Logik und definiert was die Maschine eigentlich macht und warum sie es macht. Ein einfacher Ansatz ist die Verwendung des C-Konstukts switch, in der in jedem case-zweig die einzelnen Zustände kodiert werden. Es ist aber auch durchaus möglich eine universelle FSM zu bauen, bei denen eine generische Funktion die Tabelle in Arrayform bekommt und zusammen mit einigen globalen Variablen die Maschine implementiert. Oft wird auch eine Statemaschine dadurch gebaut, indem das zentrale switch-case Konstukt der Sprache [C] durch einen einzelnen [[Funktionszeiger in C | Funktionszeiger]] ersetzt wird und jeder Zustand nichts anderes als eine Funktion ist. Der Übergang von einem Zustand in einen anderen Zustand ist dann nichts anderes als das Zuweisen einer Funktion an diesen Funktionszeiger. Oder aber man kombiniert Tabelle und Funktionszeiger in ein gemeinsames Konzept.

==Grundlegender Aufbau==

Im Folgenden wird eine FSM in Software verwirklicht, welche die Ampelsteuerung einer Kreuzung übernimmt.
[[Bild:Statemachine_Kreuzung.png|center|framed|Ampeln an einer Kreuzung]]

Die Abfolge der Lichtzeichen einer einzelnen Ampel ist dabei
 [[Bild:Statemachine_Ampel.png|center|framed|Zustände einer einzelnen Ampel]]

Die komplette Lichtfolge aller Ampeln in der Kreuzung stellt sich dann wie folgt dar: Es ist dabei ausreichend, nur Ampel 1 und Ampel 2 zu betrachten, da Ampel 3 bzw. Ampel 4 die jeweils gleichen Lichtsignale anzeigen. Dies muss nicht immer so sein! Auf einer Kreuzung kann es durchaus für eine Fahrtrichtung Zusatzampeln geben, die die Lichtfolge der Hauptampel modifizieren.

<center>
{| {{Tabelle|min-width:20em;text-align:center;}}
|+ '''Zustandstabelle der Ampelanlage'''
|- style="background-color:#ffddcc"
!width="20%"| Zustand ||width="20%"| Ampel 1 ||width="20%"| Ampel 2 ||width="20%"| nächster Zustand
|-
| 1 || rot || grün || 2
|-
| 2 || rot || gelb || 3
|-
| 3 || rot || rot || 4
|-
| 4 || rot/gelb || rot || 5
|-
| 5 || grün || rot || 6
|-
| 6 || gelb || rot || 7
|-
| 7 || rot || rot || 8
|-
| 8 || rot || rot/gelb || 1
|-
|}
</center>

Die Zustandsnummer ist in diesem Fall einfach die Taktung der FSM. Verfolgt man die Zustände von einem Zustand zum nächsten, dann kann man sich sehr leicht davon überzeugen, daß die Lichtfolge der beiden Ampeln tatsächlich der gewünschten Abfolge entspricht.

Hat man die Funktionalität einer FSM erst mal soweit in Tabellenform festgelegt, dann ist es sehr einfach daraus ein Programm in einer Programmiersprache wie z.B. C abzuleiten, welches diese Statemachine implementiert.

Kochrezeptartig kann man dabei folgenden Aufbau vornehmen:
* Es gibt eine globale Variable, die den aktuellen Zustand der Maschine repräsentiert. Die Zustände wurden in obiger Tabelle bereits durchnummeriert, so dass es sich anbietet, Zustände innerhalb der Maschine durch ebendiese Zahlen darzustellen.
* Die FSM wird als Funktion implementiert, die für jeden einzelnen Takt aufgerufen wird.
* Jeder Zustand wird innerhalb der Funktion durch einen case innerhalb einer switch Anweisung dargestellt.
* Jeder Zustand kann vor verlassen der Funktion den aktuellen Zustand der FSM beim nächsten Aufruf der Funktion festlegen, indem er an die globale Variable die Nummer des nächsten Zustands zuweist.
* Jegliche Form von Warteschleifen innerhalb der FSM sind verboten. Wenn die FSM auf ein Ereignis warten müsste, dann ist dafür ein eigener Zustand vorzusehen, der auf das Eintreten des Ereignisses prüft und nur dann den nächsten Zustand auswählt, wenn das Ereignis tatsächlich eingetreten ist. Damit erreicht man [[Multitasking]].
* Es ist sinnvoll, den Ampelfarben Namen in Form eines #define oder enums zu geben, damit wird das Konstrukt deutlich leichter lesbar.

<syntaxhighlight lang="c">
#define ROT 1
#define ROT_GELB 2
#define GRUEN 3
#define GELB 4

void Ampel1( unsigned char Farbe ); // schaltet Ampel1 auf eine Farbe
void Ampel2( unsigned char Farbe ); // schaltet Ampel2 auf eine Farbe

unsigned char state = 1; // globale Variable, die den Status repräsentiert

void stateMachine()
{
switch( state ) {
case 1:
Ampel1( ROT );
Ampel2( GRUEN );
state = 2;
break;

case 2:
Ampel1( ROT );
Ampel2( GELB );
state = 3;
break;

case 3:
Ampel1( ROT );
Ampel2( ROT );
state = 4;
break;

case 4:
Ampel1( ROT_GELB );
Ampel2( ROT );
state = 5;
break;

case 5:
Ampel1( GRUEN );
Ampel2( ROT );
state = 6;
break;

case 6:
Ampel1( GELB );
Ampel2( ROT );
state = 7;
break;

case 7:
Ampel1( ROT );
Ampel2( ROT );
state = 8;
break;

case 8:
Ampel1( ROT );
Ampel2( ROT_GELB );
state = 1;
break;
}
}

int main()
{
....

while( 1 ) {
stateMachine();
delay_ms( 1000 );
}
}
</syntaxhighlight>

Wird diese Funktion im Sekundentakt aufgerufen, so werden die Funktionen Ampel1() bzw. Ampel2() mit der jeweils richtigen Lichtstellung in der richtigen Reihenfolge aufgerufen um die Lichtwechsel der Ampeln einer Kreuzung zu realisieren. Der Einfachheit halber wird in diesem Beispiel die Funktion delay_ms() verwendet. Praktisch wird man in den meisten Fällen besser einen [[Timer]] benutzen, um die Statemachine periodisch aufzurufen. Wie das geht und was das für Vorteile hat ist im Artikel [[Multitasking#Verbesserter Ansatz mit Timer | Multitasking]] beschrieben.

==Reaktionen auf äußere Ereignisse==

Obige Statemaschine ist noch sehr primitiv. Angenommen an dieser Ampelkreuzung gibt es eine Induktionsschleife. Diese sei derartig geschaltet, dass die Hauptrichtung über Ampel2/Ampel4 ständig Grün zeigt und nur bei Annäherung eines Fahrzeugs auf der Strecke Ampel1/Ampel3 wird ein Lichtwechselzyklus durchgeführt, um diesem Fahrzeug die geordnete Durchfahrt zu ermöglichen. Die Statemaschine muss daher auf ein äußeres Ereignis reagieren können. Der Übergang von Zustand 1 in Zustand 2 ist von diesem Ereignis abhängig. Nur wenn es auftritt wird dieser Übergang durchgeführt, ansonsten verbleibt die Maschine im Zustand 1. Die Beschreibung der FSM wird also um einen weiteren Tabelleneintrag ergänzt, in dem festgehalten wird, wie mit dem zusätzlichen Eingang verfahren werden soll. In dieserm erweiterten Beispiel sollen die Zustände mit einem aussagekräftigen Namen versehen werden, denn Menschen sind sehr schlecht im Umgang mit abstrakten Zahlen, sie sind viel besser mit Wörtern vertraut. Die x in der Tabellenspalte "Induktionsschleife" besagen, daß dieses Eingangsignal für die Entscheidungen der Statemaschine keine Rolle spielt (engl. don't care).

<center>
{| {{Tabelle|min-width:20em;text-align:center;}}
|+ '''Zustandstabelle der Ampelanlage mit zusätzlichem Eingang'''
|- style="background-color:#ffddcc"
!| Zustand ||| Name ||| Ampel 1 || | Ampel 2 || Induktionsschleife || | nächster Zustand
|-
| 1 || OSTWEST_GRUEN || rot || grün || ==1 ? || 2
|-
| 2 || OSTWEST_GELB || rot || gelb || x ||3
|-
| 3 || ALLE_ROT_1 || rot || rot || x || 4
|-
| 4 || NORDSUED_ROTGELB ||rot/gelb || rot || x || 5
|-
| 5 || NORDSUED_GRUEN || grün || rot || x || 6
|-
| 6 || NORDSUED_GELB || gelb || rot || x || 7
|-
| 7 || ALLE_ROT_2 || rot || rot || x || 8
|-
| 8 || OSTWEST_ROTGELB || rot || rot/gelb || x || 1
|-
|}
</center>

<syntaxhighlight lang="c">
#define ROT 1
#define ROT_GELB 2
#define GRUEN 3
#define GELB 4

void Ampel1( unsigned char Farbe ); // schaltet Ampel1 auf eine Farbe
void Ampel2( unsigned char Farbe ); // schaltet Ampel2 auf eine Farbe
unsigned char Induktionsschleife(); // fragt die Induktionsschleife ab
typedef enum { NORDSUED_ROTGELB, NORDSUED_GRUEN, NORDSUED_GELB, ALLE_ROT_1,
OSTWEST_ROTGELB, OSTWEST_GRUEN, OSTWEST_GELB, ALLE_ROT_2} state_t ;

state_t state = ALLE_ROT_1;

void stateMachine()
{
switch( state ) {
case OSTWEST_GRUEN:
Ampel1( ROT );
Ampel2( GRUEN );
if( Induktionsschleife() ) {
state = OSTWEST_GELB;
}
break;

case OSTWEST_GELB:
Ampel1( ROT );
Ampel2( GELB );
state = ALLE_ROT_1;
break;

case ALLE_ROT_1:
Ampel1( ROT );
Ampel2( ROT );
state = NORDSUED_ROTGELB;
break;

case NORDSUED_ROTGELB:
Ampel1( ROT_GELB );
Ampel2( ROT );
state = NORDSUED_GRUEN;
break;

case NORDSUED_GRUEN:
Ampel1( GRUEN );
Ampel2( ROT );
state = NORDSUED_GELB;
break;

case NORDSUED_GELB:
Ampel1( GELB );
Ampel2( ROT );
state = ALLES_ROT_2;
break;

case ALLES_ROT_2:
Ampel1( ROT );
Ampel2( ROT );
state = OSTWEST_ROTGELB;
break;

case OSTWEST_ROTGELB:
Ampel1( ROT );
Ampel2( ROT_GELB );
state = OSTWEST_GRUEN;
break;
}
}
</syntaxhighlight>

==Warteschleifen==

Das Warten auf ein äußeres Ereignis kann mit dem Verzweigen oder auch nicht Verzweigen in einen anderen Zustand realisiert werden. In obiger Statemaschine soll z.B. die Grünphase der Ampel1 von einem Takt auf 5 Takte angehoben werden. Grundfalsch wäre es, dies jetzt mit einer while-Schleife im Zustand 5 zu realisieren. Warten wird immer über zusätzliche Zustände realisiert. Eine Statemaschine darf innerhalb eines Zustands niemals auf etwas warten, sondern muss so schnell als möglich die Kontrolle wieder abgeben. Geht man naiv an die Sache ran, dann könnte man die 5 Takte über die Einführung von zusätzlichen Zuständen leicht erreichen.

<center>
{| {{Tabelle|min-width:20em;text-align:center;}}
|+ '''Zustandstabelle der Ampelanlage mit zusätzlichem Eingang'''
|- style="background-color:#ffddcc"
!width="20%"| Zustand ||width="20%"| Ampel 1 ||width="20%"| Ampel 2 ||width="20%"| Induktionsschleife ||width="20%"| nächster Zustand
|-
| 1 || rot || grün || ==1? || 2
|-
| 2 || rot || gelb || x ||3
|-
| 3 || rot || rot || x || 4
|-
| 4 || rot/gelb || rot || x || 5
|-
| 5 || grün || rot || x || 9
|-
| 6 || gelb || rot || x || 7
|-
| 7 || rot || rot || x || 8
|-
| 8 || rot || rot/gelb || x || 1
|-
| 9 || grün || rot || x || 10
|-
| 10 || grün || rot || x || 11
|-
| 11 || grün || rot || x || 12
|-
| 12 || grün || rot || x || 6
|-
|}
</center>

Daß ein derartiges Vorgehen bei längeren Wartezeiten oder gar bei berechneter Wartezeitdauer nicht praktikabel ist, dürfte auf der Hand liegen. Besser ist daher die Einführung eines internen Zählers sowie nur eines einzigen, neuen Wartezustands. Beginnt die Wartezeit wird der Zähler auf einen Wert entsprechend der Wartezeit gestellt. Im neuen Zustand wird der Zähler um 1 verringert und nur dann, wenn der Zähler 0 erreicht hat, wird in den ursprünglichen Folgezustand gewechselt. Der Zähler kann also in ähnlicher Form wie die Induktionsschleife als Ereignislieferant aufgefasst werden.

<center>
{| {{Tabelle|min-width:15em;text-align:center;}}
|+ '''Zustandstabelle der Ampelanlage mit zusätzlichem Eingang'''
|- style="background-color:#ffddcc"
!width="10%"| Zustand ||width="10%"| Ampel 1 ||width="10%"| Ampel 2 ||width="10%"| Induktionsschleife ||width="10%"| Wartezeit ||width="10%"| nächster Zustand
|-
| 1 || rot || grün || ==1 ? || x || 2
|-
| 2 || rot || gelb || x || x || 3
|-
| 3 || rot || rot || x || x || 4
|-
| 4 || rot/gelb || rot || x || x || 5
|-
| 5 || grün || rot || x || =4 || 9
|-
| 6 || gelb || rot || x || x || 7
|-
| 7 || rot || rot || x || x || 8
|-
| 8 || rot || rot/gelb || x || x || 1
|-
| 9 || x || x || x || dec / ==0 ? || 6
|-
|}
</center>

<syntaxhighlight lang="c">
#define ROT 1
#define ROT_GELB 2
#define GRUEN 3
#define GELB 4

void Ampel1( unsigned char Farbe ); // schaltet Ampel1 auf eine Farbe
void Ampel2( unsigned char Farbe ); // schaltet Ampel2 auf eine Farbe
unsigned char Induktionsschleife(); // fragt die Induktionsschleife ab
typedef enum { NORDSUED_ROTGELB, NORDSUED_GRUEN, NORDSUED_GELB,
ALLE_ROT_1,
OSTWEST_ROTGELB, OSTWEST_GRUEN, OSTWEST_GELB,
ALLE_ROT_2, WARTE_NORDSUED} state_t;

state_t state = ALLE_ROT_1;
unsigned char zaehler;

void stateMachine()
{
switch( state ) {
case OSTWEST_GRUEN:
Ampel1( ROT );
Ampel2( GRUEN );
if( Induktionsschleife() ) {
state = OSTWEST_GELB;
}
break;

case OSTWEST_GELB:
Ampel1( ROT );
Ampel2( GELB );
state = ALLES_ROT_1;
break;

case ALLES_ROT_1:
Ampel1( ROT );
Ampel2( ROT );
state = NORDSUED_ROTGELB;
break;

case NORDSUED_ROTGELB:
Ampel1( ROT_GELB );
Ampel2( ROT );
state = NORDSUED_GRUEN;
break;

case NORDSUED_GRUEN:
Ampel1( GRUEN );
Ampel2( ROT );
zaehler = 4;
state = WARTE_NORDSUED;
break;

case NORDSUED_GELB:
Ampel1( GELB );
Ampel2( ROT );
state = ALLES_ROT_2;
break;

case ALLES_ROT_2:
Ampel1( ROT );
Ampel2( ROT );
state = OSTWEST_ROTGELB;
break;

case OSTWEST_ROTGELB:
Ampel1( ROT );
Ampel2( ROT_GELB );
state = OSTWEST_GRUEN;
break;

case WARTE_NORDSUED:
zaehler = zaehler - 1;
if( zaehler == 0 )
state = NORDSUED_GELB;
break;
}
}
</syntaxhighlight>

== Umsetzung in Tabellenform ==

Im letzten Beispiel wollen wir die Ampelsteuerung noch etwas realistischer gestalten. Denn die einzelnen Phasen sind unterschiedlich lang, der Zustand Gelb ist deutlich kürzer als der Zustand Grün. Wenn wir also in fast jedem Zustand eine bestimmte Anzahl Takte warten wollen, erscheint es nicht sinnvoll, dafür jedesmal einen neuen Zustand anzuspringen. Sinnvoller ist die Integration des Wartens direkt in den Zustand, so wie im vorherigen Beispiel der Zustand "WARTE_NORDSUED". Dabei fallen jedoch zwei Sachen auf.

* In jedem Zustand muss die Wartezeit des ''nächsten'' Zustands zugewiesen werden. Das ist etwas verwirrend.
* Fast alle Anweisungen sind gleich in den Zuständen, nur die Zahlen und der Wert für den nächsten Zustand ändern sich.

Darum soll hier die FSM von einer großen switch Anweisung auf eine Tabelle geändert werden. Das hat den Vorteil, dass die Zustandstabelle nahezu 1:1 in den Quelltext geschrieben werden kann und sie so sehr kompakt und übersichtlich ist. Die eigentliche FSM wird sehr klein und arbeitet sich durch die Tabelle durch. Zur weiteren Verbesserung der Lesbarkeit (siehe [[Strukturierte Programmierung auf Mikrocontrollern]]) nutzen wir einen Struct, welche den Zustand der State machine mit sinnvollen Variablennamen beschreibt. Bei dieser Methode muss man beachten, dass die Reihenfolge der Zustände in der enum Definition gleich sein muss mit der Reihenfolge der Zustände in der Tabelle, sonst funktioniert es nicht.

<syntaxhighlight lang="c">
#define ROT 1
#define GRUEN 2
#define GELB 4
#define ROTGELB 5

void Ampel1( unsigned char Farbe ); // schaltet Ampel1 auf eine Farbe
void Ampel2( unsigned char Farbe ); // schaltet Ampel2 auf eine Farbe
int Induktionsschleife(); // fragt die Induktionsschleife ab

typedef enum { OSTWEST_GRUEN=0, OSTWEST_GELB, ALLE_ROT_1,
NORDSUED_ROTGELB, NORDSUED_GRUEN, NORDSUED_GELB, ALLE_ROT_2,
OSTWEST_ROTGELB } state_t;

typedef struct {
int Ampel1;
int Ampel2;
int I_Schleife;
int Wartezeit;
int Naechster;
} ampel_state_t;

state_t state = ALLE_ROT_1;
int zaehler=1;

// Tabelle fuer state machine

ampel_state_t state_table[8] = {

// AMPEL1 AMPEL2 Induktionsschleife ?
// | | | Wartezeit in s
// | | | |
// | | | | naechster Zustand Name
//----------------------------------------------------------------------
{ROT , GRUEN , 1, 10, OSTWEST_GELB}, // OSTWEST_GRUEN
{ROT , GELB , 0, 1, ALLE_ROT_1}, // OSTWEST_GELB
{ROT , ROT , 0, 3, NORDSUED_ROTGELB}, // ALLE_ROT_1
{ROTGELB , ROT , 0, 1, NORDSUED_GRUEN}, // NORDSUED_ROTGELB
{GRUEN , ROT , 0, 10, NORDSUED_GELB}, // NORDSUED_GRUEN
{GELB , ROT , 0, 1, ALLE_ROT_2}, // NORDSUED_GELB
{ROT , ROT , 0, 3, OSTWEST_ROTGELB}, // ALLE_ROT_2
{ROT , ROTGELB , 0, 1, OSTWEST_GRUEN}}; // OSTWEST_ROTGELB

void stateMachine()
{
Ampel1(state_table[state].Ampel1);
Ampel2(state_table[state].Ampel2);

if (zaehler>0) {
zaehler--;
} else {
if ( (state_table[state].I_Schleife == 1 && Induktionsschleife() ) ||
(state_table[state].I_Schleife == 0) )
{
state = state_table[state].Naechster;
zaehler = state_table[state].Wartezeit;
}
}
}
</syntaxhighlight>

== Implementierung einer objektorientierten Finite State Machine in C++==

* Notation von Endlichen Automaten in UML
* Praktisches Beispiel, anhand dessen die Funktionsweise eines Toasters erklärt wird. Dazu wird die Notation in UML verwendet.
* Implementation des Beispiels in C++ auf einem AVR-Controller

Die gezeigte Möglichkeit bzw. das Beispiel sollte als Denkanstoss verstanden werden und nicht als Referenzimplementation. Es wurden bewusst bestimmte Feinheiten von endlichen Automaten verzichtet, um das Beispiel auf gut verständlichem Niveau zu halten.

* Dokumentation im PDF Format [http://www.mikrocontroller.net/attachment/137066/ImplementierungEinerFiniteStateMachine_V1.1.pdf ImplementierungEinerFiniteStateMachine_V1.1.pdf]
* LaTeX Source der Dokumentation [http://www.mikrocontroller.net/attachment/137067/Dokumentation_Source_V1.1.zip Dokumentation_Source_V1.1.zip]
* Beispielcode für AVR-Studio 4 [http://www.mikrocontroller.net/attachment/135434/AVR_Beispiel_Source.zip AVR_Beispiel_Source.zip]

* [http://www.mikrocontroller.net/topic/248837#2556592 Forumsbeitrag]: Eine objektorientierte State Machine in C++

== Grafische Modellierung einer Finite State Machine ==
Das Open Source Werkzeug Yakindu Statechart Tools (http://www.statecharts.org) ermöglicht es Zustandsautomaten grafisch zu modellieren, deren Verhalten zu simulieren und Code für verschiedene Sprachen (C/C++, Java) zu generieren.
Die grafischen Modellelemente entsprechen denen der UML2 und werden durch eine einfache und zweckmäßige Expression-Language ergänzt.

'''Einfaches Ampel Modell'''

Das Modell einer einfachen Ampel wie oben beschrieben sieht in Yakindu SCT wie folgt aus:

[[Datei:Sct_beispiel1.jpg|center|framed|Einfaches Ampel Modell]]

Wie erwartet hat die Ampel vier Zustände, die wiederum mit Übergangs-Pfeilen (Transitionen) verbunden sind. Jede Transition verfügt über einen Auslöser, in diesem Fall mit dem Namen ''tick''
Mit Hilfe der Yakindu DSL wird im linken Teil des Editors ein internes Event mit dem Name "tick" definiert, das entsprechend der Taktung des Zustandsautomaten "gefeuert" werden soll. Der Ausdruck ''every 1s / raise tick'' sorgt dafür, dass das Event ''tick'' jede Sekunde einmal gefeuert wird.
Da Yakindu SCT es erlaubt Zustandsautomaten zu simulieren, ist es jederzeit überprüfbar ob das modellierte Verhalten den Erwartungen entspricht. Über ''Run as... --> YAKINDU Statechart'' lässt sich in die ''Simulation View'' wechseln. Der jeweils aktive Zustand wird nun rot hinterlegt.

[[Datei:Sct_beispiel1b.jpg|center|framed|Simulation View]]

'''Einfache Kreuzung mit Zwei Ampel-Gruppen'''

Im zweiten Beispiel soll eine einfache Ampelkreuzung modelliert werden. Es wird davon ausgegangen, dass die Ampeln in zwei Gruppen geschaltet werden. Ampel 1 und 3 bilden die nord_süd – Gruppe, während die übrigen Ampeln die ost-west – Gruppe bilden. Der Einfachheit halber werden Ampeln einer Gruppe immer gleich geschaltet. Wie oben darf eine Ampel-Gruppe nur dann den Zustand ''rot'' verlassen, wenn die jeweils andere Gruppe sich im Zustand ''rot'' befindet.

[[Datei:Sct_beispiel2.jpg|800px|center|Ampelkreuzung]]

Im Yakindu SCT Modell gibt es nun für jede Ampel-Gruppe eine eigene Region. Wird der Zustandsautomat betreten so wird nun parallel der Zustand ''rot'' in der ''nord_sued'' Region und der Zustand ''gruen'' in der ''ost_west'' Region aktiv. Wie bereits im ersten Beispiel wird der Zustandsautomat über das ''tick'' Ereignis angetrieben, das jede Sekunde einmal auftritt.
Um das gewünschte Ampel-Verhalten zu modellieren wird nun die Transition von ''rot'' zu ''rot-gelb'' mit einem ''Guard'', also einer Bedingung geschützt. Zwar wird der Übergang weiterhin mit dem Ereignis ''tick'' angestoßen, allerdings wird der Übergang nur ausgeführt wenn die in eckigen Klammern formulierte Boolesche-Bedingung erfüllt ist. Die Funktion ''active()'' gehört zu den Bordmitteln von Yakindu SCT und prüft ob ein bestimmter Zustand aktiv ist. In diesem Beispiel kann in der Region ''nord_sued'' der Zustand ''rot'' nur verlassen werden, wenn in der Region ''ost-west'' der Zustand ''rot'' aktiv ist. Wie auch im vorhergegangenen Beispiel lässt sich das Verhalten simulieren, so das überprüft werden kann ob das Verhalten den Erwartungen entspricht.

'''Ampel mit Induktionsschleife'''

Das Verhalten der Ampelanlage aus Beispiel 2 soll um eine Induktionsschleife erweitert werden. Der Verkehr an der Ampelanlage fließt normalerweise in ''ost_west'' – Richtung, daher die Ampel in dieser Richtung immer den Zustand ''grün'' haben, es sei denn die Induktionsschleife in ''nord-süd'' - Richtung wird ausgelöst.

[[Datei:Sct_beispiel3.jpg|800px|center|Ampelkreuzung mit Induktionsschleife]]

Um dieses Verhalten in das SCT-Modell zu integrieren muss zunächst ein neues Ereignis definiert werden. Dieses Ereignis wird als Teil des ''Interface-Scopes'' definiert, da es außerhalb des Zustandsautomaten erzeugt werden soll. Ereignisse die Teil einer externen Schnittstelle sind werden mit einer Richtung (in / out) deklariert, die angibt ob das Ereignis den Zustandsautomat betritt, oder verlässt.

Nach dem das neue Ereignis definiert ist, muss nur noch der Auslöser für den Übergang von ''gruen'' zu ''gelb'' geändert werden. Statt wie bisher durch das ''tick'' Event, wird nun das ''induktionsSignal'' als Auslöser verwendet. In der Simulations-Ansicht kann das neue Ereignis manuell mit einem Klick ausgelöst werden, so dass das korrekte Verhalten wieder getestet werden kann.

[[Datei:Sct_simView.jpg|center|framed|Induktionsschleife auslösen]]

'''Warteschleife'''

Es soll die Grün-Phase verlängert werden, so dass erst nach dem 5. ''tick'' der Übergang in den ''gelb'' Zustand erfolgt.

[[Datei:Sct beispiel4.jpg|800px|center|Ampelkreuzung mit Warteschleife]]

Um eine Warteschleife zu realisieren wird dem ''Internal-Scope'' zuerst eine neue Variable hinzugefügt. Da während des Wartens der ''grün'' Zustand nicht verlassen wird, lässt sich das Herunterzählen der Wartezeit mittels eines zusammengesetzten Zustands darstellen. Wird der Zustand ''grün'' betreten, wird zunächst einen Eintritts-Aktion ausgeführt, die den Wert von ''wartezeit'' auf 5 setzt. Außerdem wird ebenfalls der Zustand ''Warten'' aktiv. Erfolgt nun ein ''tick'' wird ohne ''grün'' zu verlassen in ''WartezeitVerringern'' gewechselt und der Wert von ''wartezeit'' um 1 verringert.
Der Übergang zu ''gelb'' ist wieder durch einen Guard geschützt und kann nur erfolgen wenn die Bedingung ''wartezeit == 0'' erfüllt ist.

'''C-Code aus dem Modell generieren'''

Um nun Code aus dem Modell zu generieren muss zuerst eine GeneratorModel-Datei erzeugt werden, in der unter anderem die Ziel-Sprache angegeben wird.
Um den Zustandsautomaten abzubilden verwendet die konkrete Implementierung ein ''switch case'' Konstrukt, das dem oben Gezeigten ähnelt. Außerdem wurde ein ''code-only'' Ansatz verfolgt, so dass keine externen Bibliotheken oder Frameworks benötigt werden. Das komplette Eclipse Projekt kann [http://statecharts.org/Examples/ampel.zip hier] runtergeladen werden.

== Realisation von FSMs in Hardware ==
=== Aufbau einer FSM in digitalen Chips ===

Sollen sehr schnelle Steuerungen und Entscheider aufgebaut werden, wurden und werden digitale Bausteine mit Logikgattern verdrahtet, die steuerbare Zähler enthalten. Damit lassen sich effektive Taktgeschwindigkeiten im Bereich von mehreren MHz erreichen, die in Sicherheitsbereichen eingesetzt werden. Oft werden solche Schaltungen auch zur Überwachung von anderen Schaltungsteilen eingesetzt.

Früher wurden fast alle logischen Schaltungen auf diese Weise entworfen, z.B. auch die ersten Computer von IBM.

=== Umsetzung von FSMs in programmierbarer Hardware ===

Da heute digitale Hardware vielfach in Form programmierter PLD- und [[FPGA]]-Bausteine eingesetzt wird, verlagert sich der Entwurf der FSM mehr zu Softwareentwicklung hin. Dabei besteht je nach Vorliegen der funktionellen Beschreibung und eventueller Primärinformation die Möglichkeit, ein Abbild der digitalen Schaltung in VHDL zu formulieren und zu importieren, bzw. ein klassisches state diagram neu zu entwerfen oder die Zustandswechsel in Tabellenform zu importieren und das Erzeugerwerkzeug die FSM generieren zu lassen.

Letztendlich kann in Hardware jede sequentielle Logikschaltung, welche [[FlipFlop]]s und Dekoder enthält als FSM betrachtet werden, egal ob es ein einfaches Schieberegister oder eine komplexe ALU einer CPU ist. Die einfachste, denkbare FSM ist ein Toggle-FlipFlop, welches mit jedem Takt seinen Ausgangszustand wechselt.

== Geschwindigkeitsvergleich ==
In Software realisierte state machines erreichen unter C++ in Windows auch bei hoher Prozessauslastung selten niedrigere Reaktionszeiten als im ms-Bereich. Die damit in Echtzeit erfassbaren und prozessierbaren externen Ereignisse bewegen sich üblicherweise im Bereich von einigen 100Hz. Mit Microcontrollern und DSPs erreicht man mit Nicht-Multi-tasking-FSMs Abtastraten bis einige 100kHz.

In VHDL realisierte state machines besitzen je nach Taktfrequenz des FPGAs, Art der Codierung und Zyklustiefe typische Reaktionsgeschwindigkeiten von 10...100MHz.

== Weblinks ==

* [http://www.aqdi.com/state.htm Using State Machines In Your Designs] (C) 2003 Hank Wallace
* [http://qfsm.sourceforge.net/ Qfsm] - A graphical tool for designing finite state machines (GPL)
* [https://www.itemis.com/en/yakindu/statechart-tools/ YAKINDU Statechart Tools] Ein Werkzeug zum Modellieren und Simulieren von Statecharts sowie Code-Generatoren für Java, C und C++.
* [http://www.sinelabore.com www.sinelabore.com] Ein Werkzeug das aus UML State Machines C-Code speziell für eingebettete Systeme erzeugt.
* [http://smc.sourceforge.net SMC The State Machine Compiler]
* [http://block-net.de/Programmierung/cpp/fsm/fsm.html C/C++ event driven FSM] Open source Werkzeug zur Generierung von C++ FSM Code und UML Diagramm mittels Transitionstabelle.
* http://astade.tigris.org/ -> http://wiki.astade.de/dokuwiki/doku.php (https://www.mikrocontroller.net/search?query=astade)
[[Kategorie:Algorithmen und Arithmetik]]

USB

2017-06-01T11:02:23Z

84.191.221.238: /* Allgemeine Informationen */

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

== Einleitung ==

Ü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)
* SuperSpeed: 5 GBit/s (nur USB 3.0)
Die in Datenblättern oder Verpackungen gern verwendete Angabe "USB 2.0 Full Speed" darf man also nicht wörtlich verstehen, das sind trotz USB 2.0 nur 12 Mbit/s.

Zu beachten ist, dass es bei USB im Gegensatz 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, dass 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 muss man eben einen erstellen. Dazu werden bei manchen Chips kostenlose Treiber mitgeliefert, bei anderen muss 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 plattformübergreifende libusb ([http://libusb-win32.sourceforge.net/ Win32-Port (nicht Vista!)]) 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).
* [http://halvar.at/elektronik/usb/arnold_da.pdf Diplomarbeit von Eik Arnold] Viele Informationen über USB (Vergleich mit anderen Bussystemen, Elektrisches Interface, Transferarten, Übersicht über die verschiedenen USB Chips, ...)
* [http://www.beyondlogic.org/usbnutshell/usb1.htm USB in a NutShell] Eine kleine Wanderung durch die USB-Spezifikation
* [http://www.b-redemann.de Steuern und Messen mit USB - FT232, 245 und 2232] "Das aktuelle Buch zu den USB-Controllern von FTDI. Viele Beispielprogramme in C, zwei Projektbeschreibungen: I2C-Bus mit LM75A und ein Web-Projekt. Bauteilesatz und USB-Modul mit dem FT2232 zum schnellen Einstieg in die Thematik. Buch / Teilesatz über Segor oder dieser Seite erhältlich."
* [http://www.netzmafia.de/skripten/hardware/PC-Schnittstellen/usb.html Universal Serial Bus] Eine gute Einführung und detaillierte Beschreibung.
* [http://www.b-kainka.de/MSRUSB.pdf Buch: Messen, Steuern, Regeln mit USB] von B. Kainka.
* [https://de.wikipedia.org/wiki/Universal_Serial_Bus Wikipedia-Artikel: Universal Serial Bus]

== USB-Hostcontroller ==
=== Host-Controller im Mikrocontroller ===
Es gibt eine erfreuliche Anzahl geeigneter Schaltkreise, nur für den Amateur unschön beschaffbar. Entsprechend der USB-Spezifikation kann jeder Full-Speed-Hostcontroller auch mit Low-Speed arbeiten.

{| border="1" class="wikitable sortable" id="usb_controller" style="border-collapse:collapse;"
!Hersteller
!IC
!Speed
!Pins
!Ucc/Uio
!CPU
!Takt
!Flash
!RAM
!ADU
!DAU/PWM
!Async
!Sync
!Extras
!Bezug
|-
| [http://mcu.emea.fujitsu.com/ Fujitsu]
| MB96F338U
| Full
| 144
| 3-5 V
| 16bit / 16FX Core
| 4 MHz extern
| 544Kbyte
| 32Kbyte
| 36x10bit
| 20xPWM, 12xOCU
| 8
| 8
| 3xCAN, 2xI²C
| [http://www.glyn.de/ Glyn], [http://www.ebv.com/ EBV]
|-
| [http://mcu.emea.fujitsu.com/ Fujitsu]
| MB90F334
| Full
| 120
| 3,3 V
| 16bit / 16LX Core
| 4 MHz extern
| 384Kbyte
| 24Kbyte
| 16x10bit
| 6xPWM, 4xOCU
| 4
| 1
| 3xI²C
| Glyn, EBV
|-
| [http://mcu.emea.fujitsu.com/ Fujitsu]
| MB90F337
| Full
| 64
| 3,3 V
| 16bit / 16LX Core
| 4 MHz extern
| 64Kbyte
| 4Kbyte
| -
| 4xPWM
| 2
| 1
| 1xI²C
| Glyn, EBV
|-
| [http://www.cypress.com/ Cypress]
| CY7C67300
| Full
| 100
| 3,3 V
| 16bit RISC
| 48 MHz
| 4K x 16bit OTP
| 8K x 16bit
| -
| 1
| 1
| 1
| IDE
|
|-
| [http://www.atmel.com/ Atmel]
| AT90USB647
| Full
| 64
| 3,3 - 5 V
| AVR
| 16 MHz
| 64 K
| 4 K
| 8 x 10 bit
|
|
|
|
| [http://de.farnell.com Farnell] ca. 11,42 €
|-
| [http://www.atmel.com/ Atmel]
| AT32UC3B0128
| Full/OTG
| 64 (40)
| 3,3 V
| AVR32
| 60 MHz
| 128 K
| 32 K
| 8 x 10 bit
| (7+6) x PWM
| 2 (1x full)
| I²C, SPI, SSC
| Kernspannungsregler 1,8 V
| [http://de.farnell.com Farnell] ca. 6 €
|-
| [http://www.microchip.com/ Microchip]
| PIC24FJ256GB106
| Full
| 64
| 3,3V/5V
| PIC24
| 16 MHz
| 64 KB
| 16 KB
| 10bit
| -
| -
|
| Spannungsregler
| [http://de.farnell.com Farnell] ca. 5,70 €
|-
| [http://www.microchip.com/ Microchip]
| PIC32MX420FxxxH
| Full
| 64
| 3,3V/5V
| MIPS32
| 80 MHz
| ab 32 KB
| 8 - 32 KB
| 16 x 10bit
| -
| 1 mit IRDA
|
| Spannungsregler, JTAG
| [http://de.farnell.com Farnell] ca. 4,83 €
|-
| [http://www.nxp.com/ Philips/NXP]
| LPC2388
| Full
| 144
| 3,3V/5V
| ARM7
| 72MHz
| 512KB
| 32KB
| 8 x 10bit
| 1 x 10bit, 6 PWM
| 2 USART, 2 CAN
| SPI, I²C, SSC
| SD/MMC, Ethernet 10 Mbit, Businterface, JTAG
| [http://de.digikey.com/ Digikey] ca. 8 €
|-
| [http://www.st.com/ ST]
| STM32F10x
| Full
| 36..144
| 3,3V/5V
| Cortex-M3
| 72MHz
| 512KB
| 64KB
| 21 x 12bit
| 2 x 12bit, 32 PWM
| 5 USART, 1 CAN
| SPI, I²C, SSC
| Siehe Artikel [[STM32]]
| [http://de.farnell.com/ Farnell] ab ca. 5 €
|-
| [http://www.st.com/ ST]
| STM32F4xx
| Full + Hi
| 64..176
| 3,3V/5V
| Cortex-M4
| 168MHz
| 1024KB
| 192KB
| 24 x 12bit
| 2 x 12bit, 32 PWM
| 6 USART, 2 CAN
| SPI, I²C, SSC
| Siehe Artikel [[STM32]]
| [http://de.mouser.com/ Mouser] ab ca. 7 €
|}

Alle mit „USB OTG“ beworbenen Schaltkreise sind als Host-Controller
''und'' Device-Controller verwendbar. Mikrocontroller mit High-Speed-USB sind selten.

=== Implementierung in Software auf Atmel AVR ===
Solche Hostcontroller sind nur für Low-Speed-Geräte geeignet, in der Regel Tastaturen, Mäuse und ggf. Joysticks oder ähnliche HID-Geräte.

* [http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html Reine Softwarelösung, kann nur USB Low Speed] (Seite auf japanisch, mit [http://babelfish.altavista.com/ Babelfish] übersetzen lassen).
* [http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html SIAM32 USB HC] - Software Implemented Atmel Mega32 Universal Serial Bus Host Controller (Atmega32, GPL)


Software-Implementierungen auf anderen Mikrocontrollern scheitern wegen zu geringer Taktfrequenzen bzw. Durchsatzraten, oder – bei leistungsstärkeren Controllern – wegen Sinnlosigkeit durch Verfügbarkeit von Mikrocontrollern mit USB (siehe oben).

=== Spezielle Schaltkreise ===

USB-Schaltkreise, die vorzugsweise für den Anschluss an ein „Externes Businterface“ eines Mikrocontrollers oder per [[SPI]] vorgesehen sind.

* [http://www.nxp.com/products/connectivity/usb/products/index.html#hostc Produkte von NXP] (ehem.Philips), bspw. ISP1760
* SL811HST von [http://www.cypress.com/ Cypress] (Host/Device/OTG möglich)
* VNC1L von [http://www.vinculum.com/ Vinculum]
* [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639 MAX3421E] z. B. verwendet im [http://www.circuitsathome.com/category/mcu/arduino/usb-shield Arduino USB Host Shield] von Circuits@Home
* [http://www.ghielectronics.com/catalog/product/340 ALFAT SoC Processor] - A seamless way to access files on SD & MMC cards and on USB memory drives. Simple commands are used on [[UART]] (serial), [[SPI]] or [[I2C]] to access files at high rates.

Außerdem gibt es eine Reihe Schaltkreise, die einen PCI-Bus haben. Diese sind für Mikrocontrollerprojekte in der Regel nicht zu gebrauchen.

=== USB HOST taugliche Stacks ===

* [http://www.mikrocontroller.net/topic/75254 Freier USB-Stack für Embedded Systeme (LGPL)] von Benedikt Sauter (Treiber für SL811HS von Cypress). Source auf [http://svn.berlios.de/svnroot/repos/usbport/trunk/ svn.berlios.de]
* [https://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html SIAM32 USB HC] - Software Implemented Atmel Mega32 Universal Serial Bus Host Controller (Atmega32)

=== Fertige Module mit einem USB-Host ===

* [http://www.vinculum.com/prd_vdip1.html VDIP1] von FTDI (UART, SPI und parallel)
* [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=20659 STI 100] von elv (UART und SPI)
* [http://www.rz-robotics.de/z-module/z-usb/ Z-USB] von rz-robotics (UART und SPI, kann auch stehend montiert werden)
* [http://www.fischl.de/usbsticklogger/ USBStickLogger] OpenSource-Projekt, Bausatz verfügbar (UART)

== USB-Devices ==

===Implementierung in Software===
* [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/vusb/ V-USB] - gleiches Prinzip wie IgorPlug, aber Entwickler-Schnittstellen in C, englisch kommentierter Code. Projekt von [http://www.obdev.at/ Objective Development]. Viele Folgeprojekte. Beispielsweise:
** [http://www.recursion.jp/avrcdc/ AVR-CDC] – Ein USB-RS232C-Interface mittels CDC-Protokoll (Communication Device Class) bspw. mit ATtiny45. Kein Treiber erforderlich, nur .INF-Datei. Von Osamu Tamura.
** [http://www.recursion.jp/avrcdc/ CDC-IO] Ein experimentelles 18-bit Parallelport mittels AVR-Mikrocontroller (ATmega8/48/88). Von Osamu Tamura.
** [http://1010.co.uk/avrhid.html AVR-HID] - Low budget USB sensor input into Pure Data/Supercollider and other free softwares based around the ATmega8 microcontroller. This allows for very fast, multiple sensor input at high resolutions on a range of platforms (GNU/Linux, MAC OS X, Windows). Based on workshops with Derek Holzer.
* [http://www.xs4all.nl/~dicks/avr/usbtiny/ USBtiny] - Programmiergerät für AVR, Lizenz: GPL
* [http://www.elektor.de/Default.aspx?tabid=27&art=5551005&PN=On AVR steuert USB] und [http://www.elektor.de/Default.aspx?tabid=27&art=5551006&PN=On Universeller USB-Treiber] in der Zeitschrift [http://www.elektor.de Elektor] März 2007. Reine Softwarelösung für ein USB-I/O-Board mit einem ATmega32 und einem [http://libusb-win32.sourceforge.net/ ''open source'' USB Treiber].
* [http://www.sprut.de/electronic/pic/projekte/usb4all/usb4all.htm USB Client für universelle Steuerungsaufgaben mit PIC18F2455 oder PIC18F2550]
* Für MSP430 gibt es mittlerweile eine Implementation [http://mecrisp.sourceforge.net/mecrimus-b.htm] und einen darauf aufbauenden Bootloader [https://github.com/simpleavr/boot430].

===Spezielle USB-µC===

* Diverse µCs von [http://www.cypress.com/ Cypress], siehe unten
* 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] (EXPL_DHTML.C Virus ?))
* PIC18F2455/2550/4455/4550/67J50/67J55/87J50/87J55 sowie alle PIC24FXXXGBXXX von [http://www.microchip.com/ Microchip], üppig ausgestattet mit USB, seriellem Port (RS232/SPI), PWM-Ausgängen, A/D-Wandler und vielen IO-Pins
* [http://www.freescale.com/ Freescale]
** 69HC908JB8 - 20 Pin DIP . . . MC6'''8'''HC908JB8 ?
** 69HC908JB16 - Mehr Peripherie u.a. RS232
** 69HC908JG16 - Mit A/D wandler
** 69HC908JW32 - Mehr Speicher, mehr Ports
* [[LPC2000]]/3000-Reihe von NXP (LPC2888: High Speed USB 480Mbps)
* C8051F320 & C8051F340 von Silicon Laboratories (USB, UART, SPI, SMBus, 10-Bit-ADC, Komperator, integr. Spannungsregler & Oszillator)
* [[AT91SAM]] Familie von Atmel, ARM7-basiert, nicht OTG-fähig
* [[AVR32]] ([http://www.atmel.com/products/avr/uc3.asp?category_id=163&family_id=607 AT32UC3]A/B) Familie von Atmel mit AVR32-Kern ohne MMU für einfachere Firmware, OTG-fähig, auch High-Speed, Externes Businterface, Ethernet. Alle AT32UC3A or -B's haben vorprogrammierten USB Device Firmware Upgrade (DFU) bootloader.<ref>http://www.atmel.com/dyn/resources/prod_documents/doc7818.pdf</ref>
* [http://www.atmel.com/dyn/products/devices.asp?family_id=607#1761 AT90USB Familie] von Atmel.
** Eine Experimentierplatine und eine [http://www.ssalewski.de/Misc.html.de GPL Library für den AT90USB1287] gibt es von Dr. Stefan Salewski. Siehe auch Forenbeitrag [http://www.mikrocontroller.net/topic/61499#483966 Anwendersoftware (Generic HID Demo) für den AT90USBKEY].
** [http://www.fourwalledcubicle.com/LUFA.php LUFA] (Lightweight USB Framework for AVRs) is an open source USB library for the USB-enabled AVR microcontrollers. It is written from scratch and provides an easy to use, clean interface for rapid firmware development (MIT). Alter Name: MyUSB
** [http://freaklabs.org/index.php/FreakUSB-Open-Source-USB-Device-Stack.html FreakUSB Open Source USB Device Stack] (mod. BSD Lizenz)
* Atmel
** ATmega(8|16|32)U2 -
** ATmega(16|32)U4 - 1x USB 2.0 full-speed/low speed device
** (USB Appnotes AVR270..273, 282, 287, 293)

Alle hier genannten Mikrocontroller haben keinen USB-Host (nur Client)!

Eine Auswahl:
{| border="1" class="wikitable sortable" id="usb_controller" style="border-collapse:collapse;"
! Hersteller
! IC
! Speed
! Pins
! Ucc/Uio
| CPU Takt
! Quarz
! Flash
! RAM
! ADU
! DAU/PWM
! Async
! Sync
! Extras
! Bezug
|-
| [http://www.cypress.com/ Cypress]
| AN2131 AN2135
| Full
| 44
| 3,3V/5V
| 8051 24MHz
| 12MHz
| 0
| 4KB
| -
| -
| UART
| I²C
|
| '''veraltet'''
|-
| [http://www.cypress.com/ Cypress]
| CY7C68013A
| High
| 56,100,128
| 3,3V/5V
| 8051 48MHz
| 24MHz Grundton
| 0
| 16KB
| -
| -
| 2 UART (ab 100 Pin)
| I²C
| GPIF (State Machine)
| [http://de.digikey.com/ Digikey] ca. 11,28 €, [http://www.trade-shop.de/catalog/index.php?cPath=72_173 Air Electronics] ca. 9 €
|-
| [http://www.cypress.com/ Cypress]
| CYUSB3014
| Super
| 121 (BGA)
| 1,8V
| ARM9
| ?
| 0
| 256KB?
| -
| -
| 2 UART
| I²C
| GPIF II (State Machine)
| ?
|-
| Microchip
| PIC18F2550
| Full
| 28
|
| PIC
| 12MHz
| 16K x 16bit
| 2KB
| 8 x 10bit
|
|
|
|
| [http://www.reichelt.de/ Reichelt] ca. 7,95 €
|-
| Atmel
| AT91SAM7S64
| Full
| 64
| 3,3V/5V
| ARM7 55MHz
| für Bootloader: 18,432MHz
| 64KB
| 16KB
| -
| 4 PWM
| 2 USART
| SPI, I²C, SSC
| größere Chips auch mit Ethernet
| [http://www.reichelt.de/ Reichelt] ca. 6,25 €
|-
| Philips/NXP
| LPC2378
| Full
| 144
| 3,3V/5V
| ARM7 72MHz
| bspw. 12MHz
| 512KB
| 32KB
| 8 x 10bit
| 1 x 10bit, 6 PWM
| 2 USART, 2 CAN
| SPI, I²C, SSC
| SD/MMC, Ethernet 10 Mbit, Businterface
| [http://de.digikey.com/ Digikey] ca. 7,85 €
|-
| Texas Instruments
| MSP430F55xx
| Full
| bis 80
| 3,3V
| MSP430 25MHz
| bspw. 24MHz
| bis 128KB
| bis 8+2KB
| 8 x 12bit
| PWM
| 2 USART
| SPI, I²C
| verschiedene Ausbaustufen
| [http://www.ti.com/ TI] zurzeit als Muster
|-
| [http://www.st.com/ ST]
| STM32F10x
| Full
| 36..144
| 3,3V/5V
| Cortex-M3
| 72MHz
| 512KB
| 64KB
| 21 x 12bit
| 2 x 12bit, 32 PWM
| 5 USART, 1 CAN
| SPI, I²C, SSC
| Siehe Artikel [[STM32]]
| [http://de.farnell.com/ Farnell] ab ca. 5 €
|-
| [http://www.silabs.com/ Silicon Laboratories]
| C8051T3xx, -T6xx, -F3xx, -F6xx
| Full
| 24 28 32 48
| 1,8..5,25V
| 8051
| 25/48MHz
| 8KB..64KB
| 1,25..256KB
| 1 x 10bit, 500 ksps, 23 ins
| 5 x PWM
| 2 x UART
| SPI, I²C
| Temperatursensor, Komparator, 4 x 16bit timer
| [http://de.mouser.com/Search/Refine.aspx?Keyword=C8051+usb&FS=True&Ns=Pricing Mouser] OTP ab 0,81 €, Flash ab 1,11 €
|-
| [http://www.atmel.com/products/microcontrollers/arm/sam3u.aspx Atmel]
| SAM3U
| High
| 100 144
| 1,62..3,6V
| Cortex M3
| 96MHz
| 64..256KB
| 20..52KB
| 8-channel 12-bit 1MSPS, 8-channel 10-bit
| bis zu 7 x PWM
| bis zu 4 x UART
| SPI, I²C, I2S, 1 HSMCI (SDIO/SD/MMC)
| 3 x 16bit timer, 32-bit Real Time Timer, bis zu 96 IO-Pins
| [http://de.mouser.com/Semiconductors/Embedded-Processors-Controllers/_/N-6hpef?Keyword=sam3u&Ns=Pricing Mouser] ab 4,09 €
|}

* '''Ucc/Uio''' gibt die maximale Betriebsspannung und die maximale Eingangsspannung an Eingabeports an. 3,3V/3,3V heißt: nicht 5V-verträglich!
* '''Takt:''' CPU-Taktfrequenz, bei Microchip ehrlicherweise durch 4 geteilt
* '''Async:''' Anzahl und Art der asynchron-seriellen Schnittstellen (also mit Startbit operierend)
* '''Sync:''' Anzahl und Art der synchron-seriellen Schnittstellen (also mit einer Taktleitung, also auch I²C)
* '''SSC:''' Serielles Interface besonders für Audiochips, verschiedene Namen bei den Mikrocontroller-Herstellern

===Via µC ansteuerbare USB-Controller===

{| border="1" class="wikitable sortable" id="usb_controller" style="border-collapse:collapse;"
! IC
! Hersteller
! Host oder Device
! IC-Pins
! Interface
! Beschreibung
! Bezugs-Quelle(n)
! Sonstiges
|-
| FT232 FT245
| [http://www.ftdichip.com/ FTDI]
| Device
| 28-32
| RS232 parallel 8 bit
| 1 bidirektionale FIFO **
| [[Elektronikversender#Reichelt|Reichelt]], ab 1,95 €
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
|-
| FT232R
| [http://www.ftdichip.com/ FTDI]
| Device
| 28-32
| RS232/Bitbang/CBUS
| 1 bidirektionale FIFO **
| [[Elektronikversender#Reichelt|Reichelt]], ab 3,15 €
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
| FT2232D
| [http://www.ftdichip.com/ FTDI]
| Device
| 48
| RS232 / parallel 8 bit / I2C, SPI, JTAG
| 2 bidirektionale FIFOs **
| [[Elektronikversender#csd-electronics|csd-electronics]] [[Elektronikversender#Watterott electronic|Watterott electronic]]
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
| FT2232H
| [http://www.ftdichip.com/ FTDI]
| Device
| 64
| RS232 / (synchron/asynchron) parallel 8 bit / I2C, SPI, JTAG
| 2 bidirektionale FIFOs, HS **
|
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
| FT4232H
| [http://www.ftdichip.com/ FTDI]
| Device
| 64
| RS232 / I2C, SPI, JTAG (2 Kanäle)
| 4 bidirektionale FIFOs, HS **
|
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
| FT232H
| [http://www.ftdichip.com/ FTDI]
| Device
| 48
| RS232 / (synchron/asynchron) parallel 8 bit /I2C, SPI, JTAG/CBUS
| 1 bidirektionale FIFOs, HS **
| [[Elektronikversender#Reichelt|Reichelt]], ab 3,20 €
| [http://www.intra2net.com/de/produkte/opensource/ftdi/ libftdi] - ''FTDI (bitbang) software collection'' von Intra2net (Opensource)
|-
| PDIUSBD11
| [http://www.semiconductors.philips.com Philips]
| Device
|
| I²C
| USB-Device Controller
|
| abgekündigt
|-
| PDIUSBD12
| [http://www.semiconductors.philips.com Philips]
| Device
| 28
| parallel 8 bit
| 1 bidirektionale FIFO **
| [[Elektronikversender#Reichelt|Reichelt]], ab 2,65 €
|
|-
| MAX3420E
| [http://www.maxim-ic.com Maxim]
| Device
| 24-32
| SPI
| Fullspeed-Controller, 4 Endpoints
|
|
|-
| [[USBN960x]]
| National
| Device
| 28
| Datenbus 8 bit, SPI
| Fullspeed-Controller, 7 Endpoints, 3,3-V-Längsregler enthalten
| [[Elektronikversender#Reichelt|Reichelt]], ab 4,65 €
| Siehe [[USBN960x]], NRND
|-
| [http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/Interface/en/interface_documentation.htm CP210x]
| [http://www.silabs.com Silabs]
| Device
|
| UART
| USB2.0 kompatibler (arbeitet Fullspeed) UART-USB Umsetzer.
|
| Sehr kompakt, Intel MAC OSX: [http://www.mikrocontroller.net/topic/67398#542129 Forenbeitrag] beachten
|-
|[http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-uart-bridge.aspx CP2110]
| [http://www.silabs.com Silabs]
| Device
| 24-28
| UART
| UART-USB ohne Treiber (HID-Klasse)
|
|
|-
|[http://www.silabs.com/products/interface/usbtouart/Pages/HID-USB-to-SMBus-Bridge.aspx CP2112]
|[http://www.silabs.com Silabs]
|Device
|24
|SMBUS
|SMBUS-USB HID
|
|
|-
| [http://www.prolific.com.tw/eng/Products.asp?ID=59 PL2303]
| [http://www.prolific.com.tw/ Prolific]
| Device
| 28
| RS232
| „USB CDC 1.1“-konform
|
| Im Gegensatz zum FT232 sollte kein Treiber erforderlich sein: Von wegen!
|-
| [http://www.oti.com.tw/oti-6858.html OTI-6858]
| [http://www.oti.com.tw/ Ours Technology Inc.]
| Device
| 28
| UART
| USB to RS232 Bridge Controller - USB2.0 bis 12MB
|
|
|-
| [http://www.arkmicro.com/en/products/view.php?id=10 ARK3116T]
| [http://www.arkmicro.com/ Arkmicro]
| Device
|
| UART
| USB-to-UART Controller - USB2 bis 3MB)
|
|
|-
| TUSB3410
| [http://focus.ti.com/ Texas Instruments]
| Device
|
| UART
| USB to Serial Port Controller
| [[Elektronikversender#Digi-Key|Digi-Key]], ca. 5,60 €
| USB 2.0 full Speed, Basis 8052 µC
|-
| [http://www.ftdichip.com/Products/ICs/VNC1L.htm VNC1L]
| [http://www.vinculum.com/ Vinculum]
| 2x Host
|
|
| Dual USB Host-Controller
| [[Elektronikversender#Watterott electronic|Watterott electronic]]
| [http://freshmeat.net/projects/lvprog/?branch_id=71957&release_id=265079 LVProg] is an (X11/Qt)application for programming a ROM file into a Vinculum USB host controller from FTDI. (GPL v2)

Siehe auch:
[[USB-Stick am Mikrocontroller]]
|-
| SL811HST
| [http://www.cypress.com/ Cypress]
| 1x beides
| 48
| Datenbus 8 bit
| Controller 1 Port
| [[Elektronikversender#Digikey|Digikey]], [http://www.trade-shop.de/catalog/index.php?cPath=72_173 Air Electronics] ca. 8 €
| für OTG viel Außenbeschaltung erforderlich
|-
| ISP1160
| [http://www.nxp.com/ Philips/NXP]
| 2x Host
| 64
| Datenbus 16 bit
| Host-Controller 2 Ports
| [[Elektronikversender#Reichelt|Reichelt]], ca. 6,85 €
| für ATmega unzweckmäßig, eher für ARM-Prozessoren
|-
| MCP2210
| [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en556614 Microchip]
| Device
| 20 SOIC, SSOP
| USB nach SPI (Master) Bridge, GPIO
| USB SPI Bridge (HID-Klasse) + 9 GPIO / SPI CS
| [[Elektronikversender#Reichelt|Reichelt]], ca. 1,75 €
| Durch HID simpel anzusteuern, aber in der Praxis nur (sehr) langsame SPI (ca. 80 kbit/s @ 12Mbit/s SPI). HW Ansteuerung sehr simpel.
|}

Reine FIFO-Schaltkreise sind nicht für benutzerspezifische
Deskriptoren geeignet.
Damit lassen sich nahezu keine klassenspezifische Geräte-Interfaces
realisieren.
Folglich kann man damit bspw. kein HID-Gerät bauen.

NRND = Not recommended for new designs = wird alsbald abgekündigt

UART: Gemeint sind die Signale RxD und TxD sowie Flusskontrolle /RTS und /CTS

RS232: Gemeint ist eine UART mit den 4 Modemsteuersignalen /DTR, /DSR, /DCD und /RI

Tipp: USB-Handy-Datenkabel arbeiten oft mit FT232-ähnlichen Chips!

===USB-Transceiver===
USB-Transceiver können nur verwendet werden für:
* speziell dafür ausgelegte Mikrocontroller (PIC 18F2455/2550/4455/4550 u.ä.)
* FPGAs (wenn diese nicht selbst über geeignete Portpins verfügen)
* [http://www.obdev.at/vusb/ V-USB] (Software-Anpassungen erforderlich)
Vorteil: Zwischen Transceiver und Mikrocontroller kann eine galvanische Trennstufe angeordnet werden.

Heutzutage ist es besser, einen seriell ansteuerbaren USB-Controller (siehe oben) zu verwenden und dazwischen eine maßgeschneiderte galvanische Trennung.
Daher sind Transceiver heutzutage eher obsolet.

{| border="1" class="wikitable sortable" id="usb_controller" style="border-collapse:collapse;"
! IC
! Hersteller
! Speed
! IC-Pins
! Interface
! Beschreibung
! Bezugs-Quelle(n)
|-
| MAX345xE
| [http://www.maxim-ic.com Maxim]
| ?
| 14-16
| -
| Transceiver
|
|-
| ISP1106
| [http://www.nxp.com Philips/NXP]
| Low, Full
| 16
| -
| Transceiver
| [[Elektronikversender#Reichelt|Reichelt]], ca. 1,15 €
|}

===USB-Converter===
Es exisitieren eine Reihe von Adaptern, mit denen man ausgehend vom USB-Bus viele Standards und Protokolle emulieren und treiben kann, darunter RS-232, RS-422, RS-485, [[MODBUS]] und [[I2C]].

== Tipps + Tricks ==
* Selbstgebastelte USB-Hardware an den PC nur über einen anständig konstruierten self-powered Hub anschließen - [http://www.mikrocontroller.net/topic/97331#841881 Forumbeitrag von Rufus t. Firefly]
* Es ist sinnvoll eigene Entwicklungen mit den Tools von usb.org zu testen, usbcv kann z.B. Fehler in USB-Deskriptoren oder bei der Enumeration aufdecken: [http://www.usb.org/developers/tools/usb20_tools/ usb20cv] [http://www.usb.org/developers/tools/ usb30cv]
* Eine [[Galvanische Trennung | galvanische Trennung]] von USB selbstzubauen ist sehr aufwändig [http://www.electronics-shop.dk/usb_isolation.htm?currency=EUR aber hier für 31,76€ zu haben].
Herausforderung bei USB ist
** das USB-Signal bidirektional ist
** USB keine Steuerleitungen hat, man kann nur aus der vollständigen Dekodierung der Daten erfahren, in welche Richtung die Daten jetzt gehen müssen. Dieses Problem betrifft V-USB-basierte Projekte nicht, eine solche Leitung lässt sich leicht nachrüsten.
** es sehr kurze Antwortzeiten von den USB-ICs verlangt (im Bereich von ~10 Bitzeiten!)
*Es gibt auf dem Markt einige wenige, aufwändige und damit teure Lösungen. Wer also ein galvanisch getrennte Schnittstelle braucht, sollte '''nicht''' USB nehmen. Allerdings ist es leicht möglich, einen USB-RS232/RS485 Wandler galvanisch auf der RS232/RS485 Seite zu trennen.
*Eine einfache Lösung wäre einen FT232 zu verwenden und diesen auf der TTL-Seite mit Optokopplern zu trennen.
*Die zur Zeit einfachste und kostengünstigste Möglichkeit zur galvanischen Trennung ist der ADUM3160BRWZ oder der ADuM4160 von Analog Devices.
**Einschränkungen: nur Full- und Low-Speed, keine automatische Erkennung der Übertragungsrate.
** ADuM3160 im AD Newsletter: [http://www.analog.com/en/interface/digital-isolators/adum3160/products/product.html]
** [https://www.it-wns.de/themes/kategorie/detail.php?artikelid=979&kategorieid=53&source=1 Leerplatine] für ADuM4160 im IT-WNS Webshop
** [http://www.mikrocontroller.net/topic/114555?goto=2065917#2065236 Forumsbeitrag] mit Eagle 3D Bild und Schaltplan
* [http://www.mikrocontroller.net/search?query=%2BUSB+%2Bgalvanisch&forums%5B%5D=1&forums%5B%5D=19&forums%5B%5D=9&forums%5B%5D=10&forums%5B%5D=2&forums%5B%5D=4&forums%5B%5D=3&forums%5B%5D=6&forums%5B%5D=17&forums%5B%5D=11&forums%5B%5D=8&forums%5B%5D=14&forums%5B%5D=12&forums%5B%5D=7&forums%5B%5D=5&forums%5B%5D=18&forums%5B%5D=15&forums%5B%5D=13&forums%5B%5D=16&max_age=-&sort_by_date=0 Suche nach USB und galvanischer Trennung im Forum]

== Analysetools ==

* [http://www.pcausa.com/Utilities/UsbSnoop/default.htm Sniff USB] - USB Sniffer - freeware - Windows
* [http://www.openvizsla.org/ OpenVizsla] ([http://www.kickstarter.com/projects/bushing/openvizsla-open-source-usb-protocol-analyzer/posts/62083 OpenVizsla auf kickstarter.com]) - OpenSource USB sniffer, basierend auf XMOS und FPGA (under dev. right now)
* [http://www.wireshark.org/ Wireshark] - Eigentlich Netzwerk Sniffer, kann aber in neueren Versionen auch USB (insbesondere unter Linux) [http://wiki.wireshark.org/CaptureSetup/USB Wireshark Wiki, USB]
* [http://www.basic.io/ ALogic Analyzer] - Protokoll-Dekoder für USB, UART, I2C und SPI. Software mit Demos zum Download.

== Weblinks ==

* [http://janaxelson.com/usbchips.htm Links to USB Host and Device Controller Chips] by Jan Axelson.
* [http://www.eltima.com/products/usb-over-ethernet/ USB over Network]
* [http://replay.waybackmachine.org/20090210000605/http://g.fondeville.free.fr/usb_host_en.html Mass storage host USB example] - The purpose of this article is to introduce a host USB Full Speed implementation. This host is designed to control MASS storage peripherals like USB key, cameras, hard drive... ([[PIC]]18F452, Cypress SL811HS)
* [http://chaosradio.ccc.de/cre086.html ChaosradioExpress #86 USB] - Der Universal Serial Bus im Detail. Podcast mit Tim Pritlove (Moderation) und Daniel Mack
* [http://hackaday.com/2008/11/19/how-to-the-bus-pirate-universal-serial-interface/ Bus Pirate (hackaday.com)] - How-to: The Bus Pirate, universal serial interface USB <-> [[I2C]], [[SPI]], Async. Seriell [[UART]]. Firmware-Update für die [http://hackaday.com/2008/12/01/bus-pirate-firmware-update-v0c-jtag-and-more/ Ergänzung] u.a. für [[JTAG]]. Das Herzstück ist ein PIC24FJ64GA002.
* [http://www.sourceforge.net/projects/easyusb EasyUSB] - Generischer USB Treiber für Windows
* [http://www.eltima.com/products/usb-port-monitor/ USB Port Monitor]
* [http://www.embedded24.net AHID.DLL] - Noch ein generischer USB Treiber für Windows (C++/C#/VB/MinGW/wxWidgets)
* [http://www.embedded.com/design/219400265 Simple circuit prevents USB current overshoot during insertion] von Luciano Bordogna (MAXIM) auf www.embedded.com
* [http://www.circuitsathome.com/mcu/usb/usb-isolator USB-Isolator]
* [http://events.linuxfoundation.org/sites/events/files/slides/understand_usb_in_linux_krzysztof_opasiak.pdf Vortragsfolien von Krzysztof Opasiak (auf Seite 16 gibt es eine Übersicht der USB-Descriptor-Hierarchie) ]

[[Kategorie:USB| ]]

Schrittmotoren

2017-04-18T12:25:32Z

84.191.221.238: /* Beschleunigungsrampen richtig wählen und berechnen */

Schrittmotoren eignen sich als Stellmotoren. Sie können eine vorherbestimmte Anzahl von Schritten drehen und dann stehen bleiben. Ein Positionsgeber für die Rückmeldung, ob die gewünschte Position erreicht ist wird nicht zwingend benötigt. Einsatzgebiete sind Robotik und Stellantriebe. Man findet sie auch in alten 5,25 Zöllern (Floppy-Laufwerken), in sehr alten Festplatten, in Faxgeräten, Druckern und Plottern. Die größeren Motoren erreichen teils sehr hohe Drehmomente, die ein Untersetzungsgetriebe unnötig machen.

== Aufbau ==
===Mechanischer Aufbau===
Schrittmotoren bestehen aus einem (magnetisierten) Ankerkonstrukt und einem Spulensystem, wodurch bei Stromfluss eine Bewegung generiert werden kann. Kohlebürsten oder Schleifringe braucht der Motor nicht. Der Anker (Innenläufer) kann z. B. aus einem gezahnten Permanentmagneten bestehen. Durch diesen geschickten Aufbau wird erreicht, dass je Motorumdrehung mehrere Schrittpositionen geschaffen werden, in die der Motor einrasten kann. So gibt es Motoren mit 200 Vollschritten je Umdrehung. Aufgrund der Magnetisierung besitzt der Motor Ruhepunkte, in denen ein Haltemoment vorliegt.

===Elektrischer Aufbau===
Es gibt aus elektrischer Sicht zwei grundlegende Typen von Schrittmotoren. Unipolare und bipolare Schrittmotoren. Die einfachsten Typen haben zwei getrennte Wicklungen, auch Phasen genannt. Der Unterschied besteht in der Ansteuerung der Wicklungen:

==== Unipolare Schrittmotoren ====
Unipolare Schrittmotoren haben Wicklungen mit Mittelanzapfungen. Die Mittelanzapfungen sind mit der Versorgungsspannung verbunden, die Spulenendanschlüsse über Leistungstransistoren auf Masse. Durch das Einschalten der Transistoren kann man die Spulen jeweils zur Hälfte mit Strom durchfluten.

Vorteil
* einfache Ansteuerung durch Transistoren (Low Side Driver)
* kann auch wie ein bipolarer Schrittmotor angesteuert werden, erreicht dann aber nicht ganz das Drehmoment eines vergleichbaren Bipolartyps

Nachteil
* verringertes Drehmoment, da immer nur eine halbe Spule vom Strom durchflossen ist

==== Bipolare Schrittmotoren ====
Bipolare Schrittmotoren haben einfache Wicklungen. Die Spulen werden über H-Brücken angesteuert, um sie umpolen zu können. Dadurch fließt der Strom immer durch die ganzen Spulen. Änderung der Drehrichtung von Linearachsen kann durch vertauschen der Spulenanschlüsse am Motortreiber erreicht werden: A -> B, #A -> #B, B -> A, #B -> A#.

Vorteil
* hohes Drehmoment
* hohe Präzision

Nachteil
* erhöhter Ansteuerungsaufwand durch H-Brücken

== Ansteuerung ==
Durch passendes Anlegen der Spannungen an die Wicklungen wird ein Drehfeld erzeugt, dem der Motor folgt. Bevor der Motor die durch das Feld vorgegebene Position erreicht, muss es weitergeführt werden, um die Drehung zu erhalten. Der Motor wird dadurch hinter dem Feld her geführt. Die Winkeldifferenz zwischen Feld und Position ist ein Maß für die Belastung des Motors und die Beschleunigung.

Es ist etwas Logik und ein Leistungstreiber nötig, damit sich ein Schrittmotor in Bewegung setzt. Bekannteste Vertreter sind die ICs L297 (Ansteuerlogik) und L293/L298 (2fache H-Brücke). Alternativ zur Kombination aus L297/L298 gibt es auch leistungsfähige DMOS ICs wie z.B. [http://www.allegromicro.com/en/Products/Motor-Driver-And-Interface-ICs/Bipolar-Stepper-Motor-Drivers/A4988.aspx Allegromicro A4988]
===Betriebsarten===
====Vollschrittbetrieb====
Die einfachste Betriebsart ist die des Vollschrittbetriebs, bei der das Drehfeld immer um 90 Grad vorgeschoben werden muss, was durch wechselseitiges Ansteuern der Spulen sowie Negation der Ströme nach dem Muster + + - - sowie - + + - erfolgt. Es sind dabei immer beide Spulen aktiv.

====Halbschrittbetrieb====
Zeitweises Abschalten jeweils einer Spule entstehen Zwischenstufen, die gegenüber dem Vollschritt um (elektrisch) 45 Grad gedreht sind, da der Motor z.B. gleichzeit in Nord- als auch in Ostrichtung gezogen wird. Werden beide Betriebsarten gemischt, entsteht das Halbschrittverfahren. Dadurch entstehen 45 Grad-Schritte. Das Bestromungsmuster sieht wie folgt aus: + + 0 - - - 0 + sowie 0 + + + 0 - - - für die andere Spule, wobei man wieder eine 90 Grad-Verschiebung der beiden Ströme erkennt.

====Micro-Step-Betrieb====
Bei weiterer Verfeinerung der Methode entsteht der sogenannte microstep Betrieb, bei dem die beiden Wicklungen mit Sinus/Cosinus-Strömen angesteuert werden. Dennoch bleiben bei Schrittmotoren jeweils die Ruhepunkte pro Vollschritt erhalten, in die sie bei Abschalten des Stromes hineinfallen. In diesen Punkten ist das magnetische Haltemoment vergleichsweise gering (theoretisch null), wächst aber bei infinitisimaler Motordrehung rasch an, um dann wieder abzuflachen, sodass es bei 90 Grad, wenn der Anker gerade zwischen zwei magentischen Positionen steht, wieder Null ist. Vereinfacht kann man sich dies durch einen sinusförmigen Kurvenverlauf, wie im Diagramm rot dargestellt, vorstellen.

[[Datei:schrittmotor-ansteuerung-sin-con-js.gif|thumb|500px]]

Den beiden ansteuernden Strömen Sinus/Cosinus kann nun ein dem Haltemoment eitgegengesetzter Strom aufaddiert werden, der dem Anker dort, wo er am stärksten Widerstand erfährt, mehr Drehmoment von aussen zuführt. Dazu muss eine Welle mit 4facher Frequenz, die immer exakt 90 Grad Vorlauf zur Ankerstellung hat, hinzuaddiert werden.

In Realität ist das Moment nicht sinusförmig und dessen Maximum leicht nach vorne verschoben. Unter der Annahme, dass der Vorlauf des Drehfeldes für den Motor günstig ist, kann vereinfachend eine leichte Abflachung der Kurven in den Maxima von Sinus und Cosinus vorgenommen werden. Dies ist bei der einfachen Methode [[Digitale_Sinusfunktion#Sinus-Approximation_1]] bereits ansatzweise berücksichtigt, da die Kurve im Bereich 30 und 150 Grad steiler verläuft, als der ideale Sinus.

=== Schrittverlust ===
Das Hauptziel einer sinnvollen Ansteuerung ist neben dem schnellen Erreichen der Endposition bei möglichst geringem Stromaufwand die Vermeidung des so genannten Schrittverlustes, der auftritt, wenn der Motor dem Drehfeld nicht folgen kann. Der Motor schwingt dann in die Position des letzten Vollschritts zurück, teilweise sogar darüber hinaus, wenn schwere Mechanik über Getriebe angetrieben wird und hohe Torsionsmomente gespeichert waren. Damit wird die Sollvorgabe nicht erreicht.

==== Erkennung ====
Eine Möglichkeit ist, auf der Achse des Motors einen Winkelsensor (Encoder) zu montieren und die Schritte permanent mitzuzählen und später nachzufahren. Eine echte Erkennung vor Eintreten eines Verlustes mit der Möglichkeit der Vermeidung gibt es hier meist nicht. Eine weitere Möglichkeit besteht in der Messung des Gegenmagnetmoments des Motors. Bei einem Schrittverlust entstehen bestimmte Oberwellen, insbesondere die dritte Harmonische ist sichtbar. Damit ist es möglich, bereits einen drohenden Verlust im Vorhinein zu erkennen und gegenzusteuern, denn besser, als die Erkennung des erfolgten Verlustes ist dessen Vermeidung.

==== Vermeidung ====
Entscheidend ist, das Drehfeld des Motors zum richtigen Zeitpunkt und im Idealfall kontinuierlich so weiterzuführen, dass immer ein optimaler Lastwinkel besteht. Bei gepulstem Betrieb darf das Weiterführen nicht zu früh passieren. Der kritischste Fall ist der des Starts. Der Motor sieht noch kein Lastmoment, das Drehfeld beginnt sich aber gfs schon, schnell zu bewegen. Daher kommt der richtigen Wahl der Beschleunigungskurve eine grosse Bedeutung zu.

===Beschleunigungsrampen richtig wählen und berechnen===
Dazu ein kurzer Ausflug zu meinen ersten Schrittmotor-Untersuchungen: 
In einem Matrix-Nadeldrucker der stabilen Bauart (1980: ca. 70 kg) wird der Druckkopf mittels Stepper und Zahnriemen angetrieben. Auf der Welle des Motors sitzt ein Drehgeber (Zahnrad mit Hallsensor). Dieser gibt zum Einen den Takt für die Nadeln, zum Anderen den Zeitpunkt für den nächsten Schritt vor. Das ist ideal, denn der neue Schritt wird im günstigsten Moment ausgeführt und der Motor beschleunigt mit seiner vollen Leistung, auch bei dynamischer Belastung. Der Drehgeber ist natürlich zusätzlicher Aufwand, den man gerne einsparen wollte. Später wurden typische Beschleunigungskurven aufgezeichnet und in SW nachgebildet. 
 
Einfache Rampen wie lineares Dekrementieren der Periode von Schritt zu Schritt sind bestenfalls für kleine Beschleunigungen von sagen wir mal 1 bis 2 kHz ausreichend. Will man auf 5 bis 8 kHz drehen, muss vieles bedacht werden: 
 
1. Das größte Manko vorneweg: Das sinkende Drehmoment bei hoher Drehzahl bedingt durch den Abfall der Stromanstiegsgeschwindigkeit und durch steigende Verluste in Eisen und Wicklung (Wirbelstrom). 
Daher muss die Kurve oben flacher verlaufen, da weniger Kraft zum Beschleunigen zur Verfügung steht. 
 
2. Obwohl im unteren Drehzahlbereich viel Kraft zur Verfügung steht, ist es aus dynamisch-mechanischen Überlegungen manchmal nicht wünschenswert, voll loszubeschleunigen: Eine plötzlich einsetzende oder ausbleibende Kraft (Ruck) kann mechanische Resonanzen in der restlichen Mechanik (Getriebe, Motoraufhängung, Rahmen...) auslösen. 

Wünschenswert ist ein sin(0..2pi)-förmiger Verlauf der Kraft, also der Beschleunigung. Da diese die erste Ableitung der Geschwindigkeit nach der Zeit ist, ist der Verlauf der Geschwindigkeit 1-cos(0..2pi) = 1+cos(pi..3pi) 
Nachteil: Maximale Beschleunigung in der Mitte 55% höher als bei linear. 
Kompromiss: Quadratische Rampe (Beschleunigung steigt linear an): 33% höheres Drehmoment erforderlich. 
 
Atmel bietet für Steppermotoren eine Application Note (AVR446) und ein entsprechendes Demoprogramm für lineare Rampen: 
http://www.atmel.com/dyn/resources/prod_documents/doc8017.pdf http://www.atmel.com/images/avr446.zip 
Den fertigen Funktionen kann die Beschleunigung, Verlangsamung, gewünschte Geschwindigkeit und Anzahl der zu fahrenden Schritte übergeben werden. Es werden automatisch die Rampen berechnet und die Timersteuerung für 16-bit Timer berechnet.
Das Programm ist sehr ausführlich dokumentiert (u.a. mit Doxygen) und kann fast komplett in eigene Applikationen übernommen werden. 
Achtung: Das Programm ist für den IAR-Compiler und muss ggf. leicht abgeändert werden.

====Häufigster Fehler====

Die Rampe wird unter der Prämisse erstellt, die Zeit zwischen den Einträgen sei konstant, man könne also die linear berechneten Frequenz- oder Timerwerte einfach so eintragen. DEM IST NICHT SO. Die Mitte der Liste ist bei Weitem nicht nach der halben Rampenzeit erreicht, da Schritte am Anfang wesentlich langsamer ausgeführt werden. Die Liste muss bei niedrigen Geschwindigkeiten grobe, bei hohen Geschwindigkeiten feine Abstufungen haben.

Richtig ist: Nach jedem Step die Zeit seit Beschleunigungsbeginn (einfach die Timer-Werte aufaddieren), daraus die gewünschte Frequenz und daraus den benötigten Timer-Wert berechnen.

====Tipps zur Rampe====

Eine einfache Methode ist es, kontinuierlich steigende Werte auf die Sollfrequenz zu geben. Damit ergibt sich ein beschleunigter Zeitverlauf.

==''Veraltet''! Treibermodule==

===Oriental Motor: Vexta AlphaStep ASD16AC und ASD20AC (230 VAC -> 324 VDC, Preisklasse 220-700 Euro)===

* Vorteile
**verhält sich wie ein Servo, regelt Schlupf und auch statische Laständerungen aus
** neue AlphaStepPlus sind frei programmierbar; ist extrem gutmütig, läuft ohne mechanische Last auch mal mit 50 kHz (!) Schrittfrequenz = 6000 1/min
** Drehmomentverlauf über Drehzahl sehr gut wegen hoher Spannung
** Opto-Trennung
** Error-Ausgang
** Enable-Eingang
** 500, 1000, 5000 oder 10000 Schritte pro Umdrehung einstellbar
** hoher Wirkungsgrad
** Strom in 16 Stufen einstellbar

*Nachteile
**passender Motor (Preis~100-200 Euro) mit Resolver nötig
**eingebauter v-Filter kann zwar beschleunigen, aber nicht abbremsen, das müßte er ja vorher wissen, leider macht er deshalb zu viel gemachte Schritte nicht zurück -> Rampen müssen doch selbst programmiert werden
**teuer
**Motorspannung netzgekoppelt -> VDE

===3 und 4 Achsen blaue TB6560 Schrittmotorplatinen von hyu68.com, wie sie auf eBay angeboten werden (Preisklasse 50 Euro)===

*Vorteile
**sehr günstig
**state of the art Schrittmotor-IC (TB6564AHQ ist jedoch der bessere Nachfolger)
**Mikroschritt bis 16
**eigener Spannungsregler, benötigt nur die Motorspannung
**Optokoppler
**Enable-Eingang
**Strom in 3 Stufen, 100%, 75%, 50% vom Nennstrom, einstellbar
**Bedienteil ansteckbar

*Nachteile
**nur die blanke Platine mit Kühlkörper, ohne Gehäuse
**trotz Optokoppler nicht galvanisch getrennt
**wegen der Optokoppler nur langsame Pulse, langsamer als Mach3 überhaupt einstellbar ist. Entfernt man die Optokoppler (überbrücken mit jeweils 1 Draht, unterschiedlich bei DIR/STEP und ENABLE), geht das Handbedienteil nicht mehr.
**Chopperfrequenz und Nennstrom nur durch Austausch von Bauelementen veränderbar
**Freilaufdiode am Relais fehlt
**offiziell darf die Spannung der ICs nicht aus der Motorspannung abgeleitet werden, weil damit die Einschaltsequenz des TB6560 nicht eingehalten wird. Dennoch ist bisher keiner kaputt gegangen.
**obwohl viele Dioden auf dem Board verbaut sind, haben die Ausgänge nur nach Masse Freilaufdioden (der TB6560A benötigt laut Hersteller keine Freilaufdioden) die anderen entkoppeln die Versorgungsspannung der 3 oder 4 Kanäle und dienen als Verpolschutz.
**wenn die Schrittmotoren gedreht werden, ohne dass das Board an Versorgungsspannung liegt, können die ICs gehimmelt werden.
**die Fähigkeiten des TB6560, wie Bremstempo, Umschalten der Mikroschritte während der Fahrt, Fehlermeldungen wie Übertemp, können nicht genutzt werden, werden aber von Mach3 sowieso nicht unterstützt.

===3 und 4 Achsen rote TB6560 Schrittmotorplatinen, wie sie auf eBay angeboten werden (Preisklasse 50 Euro)===

Wesentlich besser als die blauen aber etwas grösser. Tatsächlich galvanisch per (ausreichend schnellem) Optokoppler getrennt dank DC/DC Wandler. Aber auch diese Karten erfordern in MACH3 den Sherline Mode damit die vom TB6560 benötigte Impulslänge eingehalten wird.

===RTA Deutschland / Italy: GMD03, HGD06 (32-85 V, Preisklasse 140-180 Euro)===

*Vorteile
**sehr günstig
**wenig EMV-Probleme
** kann auch 8tel-Schritt
** HGD-Ein-und Ausgänge über Optokoppler
** automatische Ruhestromabsenkung
** Enable-Eingang
** Error-Ausgang
** Strom in 8 Stufen einstellbar

*Nachteile
**nur die blanke Platine mit Kühlkörper, ohne Gehäuse (gibt es vermutlich als Zubehör)

===IMS IB104, IB106, IB110 (Preisklasse 160-300 Euro)===

*Vorteile
**mechanisch geschickt gelöst
**Digitaleingänge opto-isoliert

*Nachteile
**analoger StromSet nicht galvanisch getrennt
**schlechte EMV
**weder home noch reset des eingebauten L297 sind herausgeführt, sodass man z. B. zum Umschalten in den Wave-Mode nicht weiß, ob er in einem geraden oder ungeraden Schritt ist
**Ruhe-Verlustleistung zu hoch (bei 60 V, 150 mA, 9 W, Linearregler)
**teurer als RTA
**IB106 und IB110 wesentlich teurer als IB104, obwohl nur ein paar Bauteile andere Werte haben

=== Anregungen ===

*Hohe Versorgungsspannung erforderlich
*Abbremsrampe ist schneller möglich wg. mechanischer Verluste (Reibung).
*Besonderheiten der Last (Drehmomentverlauf über Drehzahl) beachten.
*Startfrequenz knapp oberhalb der Hauptresonanzfrequenz. Nicht so hoch wie es möglich wäre, wg. Ruck beim Starten / Stoppen.
*Effekte bei Resonanz: kein Drehmoment, sogar Rückwärtslauf.
*Leistungsverbrauch sehr wohl lastabhängig.

== Alternative Stellantriebe ==

Eine preiswerte Alternative zu Schrittmotoren sind die [[Servo|Modellbau-Servos]], die es schon ab 5,- € gibt. Sie sind im Vergleich geradezu spielend einfach auch von µC anzusteuern und ermöglichen das exakte Anfahren bestimmter (speicherbarer) Winkel. Da sie nicht den Schrittmotor-typischen Schlupf haben, der gerne beim Anfahren unter mechanischer Last auftritt, eignen sie sich auch gut für größere Kräfte. Das integrierte Getriebe und die Stellautomatik blockieren die angefahrene Position, was bei kleineren Schrittmotoren mitunter problematischer ist. Für höhere Genauigkeit sollte man sogenannte digitale Servos nehmen. Eine Sonderform sind die Servowinden, mit denen man auch mehrere Umdrehungen erreichen kann. ("Segelwinden" bei Modellsegelbooten).

== Diskussionsthreads ==

* http://www.mikrocontroller.net/topic/51534
* http://www.mikrocontroller.net/topic/232355
* http://www.mikrocontroller.net/topic/215261

== Weblinks ==

* [http://www.mikrocontroller.net/forum/read-1-113751.html#new Bipolare Schrittmotoren] Forumsbeitrag zum Thema
* [http://www.mikrocontroller.net/topic/262652#new G-Code-Interpreter und 3-Achs Schrittmotorsteuerung mit ATMega644 und Trinamic TMC260]
* [http://www.roboternetz.de/wissen/index.php/Schrittmotoren Ausführlicher Grundlagenartikel auf roboternetz.de]
* Folgende 2 Beiträge beziehen sich auf http://www.mikrocontroller.net/forum/read-1-309923.html?reload=yes#310455
* [http://de.nanotec.com/support/tutorials/schrittmotor-und-bldc-motoren-animation Onlinetool zur Darstellung verschiedener Ansteuerungsarten von Nanotec.de] (Flash erforderlich)
* [http://de.nanotec.com/support/motorauswahl-assistent Motor-Assistent] - Onlinetool zur Berechnung von Motorkennzahlen anhand von Drehzahl und Drehmoment von Nanotec.de .
* [http://ww1.microchip.com/downloads/en/AppNotes/00907a.pdf Microchip AN907: Stepping Motors Fundamentals] - Gute und allgemeine Einführung zum Thema Schrittmotoren.
* [http://www.schrittmotor-blog.de/ Schrittmotor-blog.de] - Blog mit technischen Hintergrundinformationen und Detailwissen zum Schrittmotor
* [[Schrittmotor-Controller (Stepper)]] Mikrocontrollerprojekt für die Anwendung von (unipolaren) Schrittmotoren als Strahlschalter

[[Kategorie:Motoren]]