Datenkommunikation USB richtig implementieren

Seit geraumer Zeit findet USB seinen Weg in Embedded Systeme, dort lassen sich mithilfe der Schnittstelle neue Funktionen implementieren und die Leistungsfähigkeit steigern. Doch wie implementiere ich USB bei Neu-entwicklungen am besten? Wie rüste ich bestehende Systeme richtig nach? Die eine perfekte Lösung gibt es nicht, sondern der Entwickler muss die jeweiligen Vor- und Nachteile sorgfältig abwägen.

Statten Entwickler eine Anwendung mit USB aus, eröffnen sich viele interessante Möglichkeiten. So lassen sich neue Geräte einfach in ein bestehendes System einbinden und Daten bequem übertragen. Zudem können Geräte ihren Strombedarf über den Bus decken, wenn dieser 2,5 W nicht übersteigt. In neue Systeme kann USB gleich mitintegriert werden, aber oft besteht auch der Wunsch, bestehende Systeme mit USB aufzurüsten. Welche Lösung ist für die eigene Anwendung die richtige?

Tabelle 1 zeigt die verschiedenen Möglichkeiten, USB in ein System zu integrieren, sowie die Anforderungen an Entwickler und Endanwender. Welche von diesen die richtige ist, hängt von mehreren Faktoren ab, beispielsweise ob ein Entwickler ein bestehendes System aufrüstet oder ein neues System entwirft. Weitere Aspekte sind die Zielanwendung, die USB-Erfahrung des Entwicklers und die zur Verfügung stehende Entwicklungszeit.

Wie aus Tabelle 1 ersichtlich, bietet eine USB-MCU die größte Flexibilität, erfordert aber auch USB-Erfahrung und eine mögliche Treiberentwicklung. Ein USB-Bridge-IC erfordert keinerlei USB-Firmware oder Treiberentwicklung, was die Gesamtentwicklungsdauer verringert. Dies wäre der einfachste Weg, USB mit minimaler Überarbeitung in ein System zu integrieren. Diese und noch mehr Aspekte sollen im Folgenden näher beleuchtet werden. Als erstes geht es um ein neu zu entwickelndes System mit USB-Funktion, weiter unten um ein schon bestehendes System, das mit einem USB-Port nachgerüstet werden soll.

Ein neues System mit USB ausstatten

Bei einem neuen System können die Entwickler die für sie beste Art der USB-Datenkommunikation wählen. Das System lässt sich auf einer USB-MCU oder einem USB-Bridge-IC aufbauen, und die Designaspekte lassen sich an die USB-Lösung anpassen. So kann das anfängliche Leiter-plattendesign alle erforderlichen Komponenten enthalten, einschließlich USB-Baustein und USB-Anschluss, und der Entwickler kann die Komponenten bei Bedarf neu positionieren.

Die Art der Anbindung an das System ist frei wählbar, und der Entwickler kann jede der vier Optionen aus Tabelle 1 wählen. USB-Bridge-ICs mit Festfunktion stel-len die einfachste Lösung dar, um USB in neue Designs zu integrieren, bieten aber die geringste Flexibilität. Sie sind als HID- (Human Interface Device) oder Nicht-HID-USB-Bridge-IC erhältlich, zum Beispiel als USB-zu-UART-Bridge mit virtuellem COM-Port (VCP).

Beim Einsatz dieser Bridge-ICs sind keine USB-Kenntnisse erforderlich, da weder USB-Firmware noch Treiber zu entwickeln sind. Bei Anwendungen ohne HID stellen die Anbieter die erforderlichen Treiber für die jeweiligen Betriebssysteme zur Verfügung. Die Hersteller bieten oft DLLs (Dynamic-Link Libraries) an, um die Entwicklung von USB-Host-Anwendungen zu unterstützen. Durch Einsparen der Entwicklung von Firmware, DLL und Treiber verkürzt sich die Dauer zur Markteinführung. Dabei ist die USB-Schnittstelle nicht direkt mit dem Zielsystem (Target) verbunden, sondern ein weiteres Bridge-IC für UART, SPI oder I2C stellt die Verbindung mit der Zielapplikation her.

Im nachfolgend beschriebenen System kommuniziert eine USB-zu-UART-VCP-Bridge über die UART-Schnittstelle mit dem Target (Bild 1).

Entwickler, die damit USB in ein System integrieren wollen, müssen sicherstellen, dass das Zielsystem mit der UART-Schnittstelle kommunizieren kann. Zudem muss der Datendurchsatz des Bridge-ICs berücksichtigt werden, der durch die Kommunikationsgeschwindigkeit des UART begrenzt ist.

Darüber hinaus müssen ein Treiber und ein Treiber-Installationspaket für den End-anwender zur Verfügung stehen. Der Endanwender muss den Treiber installieren, um eine USB-Funktion zu erhalten.

In diesem Beispiel erscheint das Bridge-IC dem USB-Host als COM-Port. Entwickler, die ein USB-Bridge-IC mit Festfunktion wünschen, der keine Host-seitige Treiberinstallation erfordert, sollten ein HID-Bridge-IC bevorzugen. Ein solches HID-Device gewinnt als allgemeine Anbindungsoption für Embedded Systeme immer mehr Popularität.

Da HID von den meisten Betriebssystemen unterstützt wird, ist keine Treiberentwicklung erforderlich, und Endanwender können ein Device direkt anschließen und betreiben. Eine Treiberinstallation durch den Endanwender ist somit nicht erforderlich.

Im vorgenannten Beispiel mit USB-zu-UART-VCP kann man das Bridge-IC durch einen HID-USB-zu-UART-Baustein ersetzen (Bild 2). Der Großteil der Designüberlegungen für die HID-Bridge ist identisch zur VCP-Bridge - es bestehen aber auch einige Unterschiede.#

Bei der HID-Konfiguration ist die Grenze des Bridge-IC-Datendurchsatzes gleich dem maximalen HID-Datendurchsatz, der 64 KByte/s beträgt. Der Baustein erscheint am USB-Host auch nicht als COM-Port, sondern als HID-Class-Device. HID-Bridges mit Festfunktion lassen sich sofort einsetzen beziehungsweise dienen als Austausch-IC für Entwickler, welche die USB-Gesamtentwicklungsdauer minimieren und gleichzeitig USB in ein System integrieren wollen.

Falls der Datendurchsatz oder die allgemeine Funktion eines USB-Bridge-ICs mit Festfunktion nicht ausreichend ist, sollten Entwickler stattdessen eine USB-MCU in Betracht ziehen.

MCUs machen flexibel

USB-MCUs bieten die größte Flexibilität und Kontrolle über die USB-Schnittstelle, erfordern aber den umfangreichsten Designaufwand. Entwickler müssen die gesamte USB-Firmware generieren; wird ein Nicht-HID-Class-Device entwickelt, müssen sie auch Gerätetreiber schreiben. Dies erfordert USB-Erfahrung und ist nicht ganz trivial.

Da sich eine eigene MCU-Firmware aber anpassen lässt, kann die USB-MCU je nach Bedarf weitere Aufgaben erfüllen. Dies erhöht die Flexibilität weiter, was mit einem Bridge-IC nicht möglich ist. Verfügt die USB-MCU beispielsweise über einen A/D-Wandler (ADC), kann der Entwickler Firmware zur Konfiguration des ADC hinzufügen und Messungen durchführen. Der USB-Deskriptor ist ebenfalls über Firmware anpassbar.

USB-Hosts legen dann fest, ob eine Einrichtung ein HID- oder Nicht-HID-Device ist - und zwar über die Deskriptoren, die der Host während des Enumerationsprozesses vom Device empfängt.

Bei einer USB-MCU stellt die USB-Kommunikation eine direkte Schnittstelle zum Target dar, und das System kann rund um die USB-MCU aufgebaut werden (Bild 3).

Neben der längeren Entwicklungsdauer sollten Entwickler auch den erforderlichen Datendurchsatz berücksichtigen. Der maximale Durchsatz eines HID-Class-Device beträgt 64 KByte/s oder 512 KBit/s. Der maximale Datendurchsatz für ein Nicht-HID-Class-Device liegt bei 12 MBit/s oder 12 000 KBit/s. Es erzielt also einen wesentlich höheren Datendurchsatz als das HID-Device, erfordert aber auch kundenspezifische Treiber und die Installation des Treibers durch den Endanwender.

Dadurch verlängert sich die Gesamtentwicklungsdauer der Anwendung. Die Treiberentwicklung und -installation lässt sich durch eine HID-konfigurierte USB-MCU vermeiden - aber nur, wenn der HID-Datendurchsatz für die Anwendung ausreicht. Die Entwicklung eines Systems mit USB-MCU sorgt für Flexibilität, wenn sich die Anforderungen an das Design so ändern sollen, dass es der besten USB-Lösung genügen soll.

Entwickler eines medizintechnischen Geräts, das beispielsweise über USB Messdaten an einen Host sendet, können die Datentransferart der USB-MCUs ändern, um so die Anforderungen an den Datendurchsatz zu erfüllen, oder einen Multi-Interface-Baustein mit isochroner und HID-Schnittstelle integrieren. Bei einer neuen USB-Anbindung können Entwickler die Anforderungen einer jeden USB-Option analysieren und die beste Wahl treffen. Im Folgenden wird das Aufrüsten eines bestehenden Systems näher beschrieben.