www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB-Spezifikation


Autor: AiM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Kann mir hier jemand einen Tipp geben, was alles Passiern muss, wenn
ich einen Atmel Mega 128 über den USB-Controller USBN9604 an den PC
anschließe?

Was muss alles Ausgeführt werden bzw. welche Daten sind dabei wichtig?
Brauche ich noch etwas, um die Geräteinstallation ohne zusätzliche
Treiber ablaufen zu lassen?
Oder gibts da andere Full Speed USB-Controller, die einfacher zu
verwenden sind?

Google war hierfür leider nicht mein Freund :-(

gruß
AiM

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die USB-Spezifikation gibts hier: www.usb.org

Wie Du weiter vorgehen musst, hängt davon ab, was Du erreichen willst.
Wenn Du einfach nur Daten mit dem PC austauschen möchtest, empfiehlt
sich die Verwendung eines FTDI-USB-Controllers (FT245 oder FT232), dann
ist auf der PC-Seite keinerlei Treiberentwicklung mehr erforderlich und
auch die Microcontrollerseite gestaltet sich äußerst einfach.
Einfacher als mit den FTDI-Controllern geht es wohl nicht.

Alternativ ist die Implementierung einer der Standardgeräteklassen
anzuraten, da auch in diesem Falle auf der PC-Seite keine
Treiberentwicklung erforderlich ist; dafür muss allerdings auf der
Microcontrollerseite mehr Aufwand getrieben werden.
Zu den Standardgeräteklassen gehören beispielsweise HIDs, das sind
Tastaturen, Mäuse, Graphiktabletts etc.; auf Anwendungsebene können mit
solchen Geräten aber auch ganz andere Daten ausgetauscht werden.

Die Entwicklung von Devicetreibern auf der PC-Seite ist äußerst
kompliziert, wenn es um die Nutzung unter Betriebssystemen wie Windows
geht; auch unter Linux und dergleichen ist das nicht trivial. Daher
sollte das nach Möglichkeit vermieden werden.

Also: Was willst Du erreichen? Was soll Dein Projekt machen?

Autor: AiM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also:

Bei meinem Projekt geht es darum, dass eine Software am PC
(wahrscheinlich in VB6 erstellt) Daten berechen und über USB ausgeben
soll. Die Hardware soll diese Daten dann in Analoge Spannungen
umwandeln.

Wichtig dabei ist:
1) dass so schnell wie möglich, so viele Daten wie möglich übertragen
werden. (die Daten werden mind. 8 Bit, vileicht aber auch 12 oder gar
16Bit lang)

2) die Hardware muss sowohl auf USB 1.0/1.1 und 2.0 funktionieren.

3) die Hardware soll sich beim anschließen an den USB-Port bei Windows
melden, und wenn irgendwie (einfach) möglich soll der benötigte Driver
auf der HW vorhanden sein, so dass er sich selbstständig installieren
kann.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Mit den FTDI-Bausteinen sind Übertragungsraten von bis zu 1
MByte/sec hinzubekommen, allerdings muss dazu der zugehörige
Devicetreiber installiert werden und dieser mittels spezieller DLLs aus
der Anwendung heraus angesprochen werden.
Wird der virtuelle serielle Treiber verwendet, liegt die maximale
Datenrate bei 300 kByte/sec, das ist dann aber aus der Anwendung heraus
einfacher zu programmieren (wird halt wie 'ne serielle Schnittstelle
programmiert).

Eine Installation des Treibers aus dem Gerät heraus ist nicht
vorgesehen. Um so etwas hinzubekommen, müsste sich das Gerät als
Mehrfunktionsgerät identifizieren und eine der Funktionen ein "Mass
Storage Device" sein, das einen ziemlich großen ROM-Bereich zur
Verfügung stellt, damit daraus der Devicetreiber geladen werden kann,
der die andere Funktion bedient.
Kein guter Ansatz, aufwendig, nicht mit FTDI zu realisieren und vor
allem ein Krampf bei Treiberupdates oder gar anderen Betriebssystemen.

Punkt 2 ist kein Thema, das ist bei USB-Geräten so vorgesehen.

Was heisst "so schnell wie möglich"?

Wenn entsprechender Aufwand getrieben wird, kann über USB2.0 eine
Datenrate von annähernd 40 MByte/sec erreicht werden; es ist allerdings
mehr als fraglich, ob das ein VB-Programm überhaupt liefern kann.

Recht schnelle, präzise und kostengünstige Zweikanal-D/A-Wandler gibt
es übrigens in fast jedem PC - die Soundkarte. Die liefert 44.1
kSamples/sec oder auch 48 kSamples/sec mit zwei Kanälen und 16 Bit
Auflösung. Das ist schon 'ne ganze Menge ...

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

das man für mehr als 300kByte/s die DLL-Treiber und nicht die
VCP-Treiber verwenden muß stimmt nicht. Dursatzraten von über
700kByte/s sind mit den VCP-Treiber durchaus möglich. Allerdings muß
man dann den FT245 verwenden da der FT232 prinzipbedingt nicht mehr als
300kByte/s liefern kann.

Matthias

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab' nur die FTDI-Seite höchstselbst zitiert ... /Auszug aus der
Beschreibung des '245)

  # Data transfer rate of up to 1M Byte/second (D2XX drivers)
  # Data transfer rate of up to 300K Byte/second (VCP drivers)

's ist aber schön, wenns auch über VCP schneller geht.

Autor: AiM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das mit dem virtuellen Seriellen Driver kann ich warscheinlich
vergessen, weil zu langsam?

Die nachgeschaltete Hardware kann bis zu 30.000 pps verarbeiten (bei
16Bit Auflösung)
Diese 16Bit müssten dann auch schnell genug übertragen werden, so dass
2x 30.000 pps bei 16bit zur Verfügung stehen.
Außerdem kommen dann noch einige Positionsangaben für Schrittmotoren
dazu, die dann zwar nicht immer, aber Teilweise mitübertragen werden
müssen. Dabei darf aber die Übertragung der übrigen Daten nicht ins
stocken kommen!

Wenn VB nicht mit der Geschwindigkeit klarkommt, dann muss eben C/C++
dafür herhalten, dann sollte es auch damit kein Problem mer geben.
Außerdem sind die Daten sowiso schon Voerberechnet in ner ini Datei und
werden von der Software nur noch ausgelesen und gesendet.

gruß
AiM

Autor: Rufus, das dicke Ei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die Entwicklung von Devicetreibern auf der PC-Seite ist äußerst
kompliziert, wenn es um die Nutzung unter Betriebssystemen wie Windows
geht; auch unter Linux und dergleichen ist das nicht trivial."

Naja, schwer übertrieben ist das schon.
Das Debugging kann ein bißchen aufwendiger sein, aber zumindest unter
Linux ist ein "Hello, world"-Kerneltreiber nicht mehr als ein
10-15Zeiler.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"schwer übertrieben"? Das bezweifle ich.
Ich kenne das Windows-DDK. Die "Qualität" der von vielen
Hardwareherstellern abgelieferten Treiber spricht für sich.

Wenn die Treiberentwicklung für Linux so simpel wäre, dann gäbe es wohl
auch mehr Devicetreiber dafür ...

Bereits in einem anderen Thread fragte ich Dich übrigens, ob Du Deinen
"Nicknamen" hier besonders komisch findest ... gibt es eine
Erklärung?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab das gemacht, genauer gesagt einen USB9604 an einem Mega8
angeschlossen. Du musst halt nur die USB Spezifikation durchlesen, und
den Beispiel Source zum USB9604 und du kannst den Teil im
Microcontroller relativ schnell programmieren. Es gibt auch einen
Japaner der hat das Dingen an einem PIC (schauder) angeschlossen. Sein
Programm ist als inspiration auch nicht schlecht.

Auf dem PC installierst du libusb wenn das bei deiner Distribution
nicht schon dabei ist. Das macht das Leben richtig einfach. Da du dort
die USB Geraete fast sofort ansprechen kannst.

Ich bin uebrigens auf eine Datenrate von etwa 5-6kb gekommen,
allerdings habe ich den USBN nur seriell angeschlossen. Parallel waere
sicherlich einiges mehr moeglich.

Olaf

Autor: AiM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was haltet ihr von dem hier:

TUSB3210 von Texas Instruments,
Da kann die gesamte Firmware in einem Seriellen I2C EEPROM gespeichert
werden, und wird dann beim einschalten in den RAM geladen. Von da aus
installiert sich dieser USB-Controller dann selbst als HID.

gruß
AiM

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn die Treiberentwicklung für Linux so simpel wäre, dann gäbe es
wohl
> auch mehr Devicetreiber dafür ...

Also mit 10 Zeilen kommt man wohl nicht hin, aber mehr als ein paar
kb fuer Testprogramm sind auch wieder nicht notwendig.

[olaf] ~/usbhardware/megausb: l
insgesamt 44K
-rw-r--r--  1 olaf  381 Jan  2 00:18 makefile
-rwxr-xr-x  1 olaf  28K Jan  2 00:18 usbtest*
-rw-r--r--  1 olaf 5,5K Jan  2 00:18 usbtest.c
-rw-r--r--  1 olaf 3,5K Jan  2 00:18 usbtest.o

Und wenn es fuer irgendwas unter Linux keine Devicetreiber gibt dann
wohl eher deshalb weil die Gegenseite nicht mit Dokus rausrueckt. Aber
wenn man die Hardware ja selber baut hat man alles in der Hand.
Ich war wirklich positiv ueberrascht wie einfach das war.

Olaf

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf: Warum wohl erscheinst Du mir glaubwürdiger als der Wortbeitrag,
den hier jemand um 23:06 ablassen musste?

Das klingt gut; somit scheint ja meine Aussage zum Thema
Devicetreiber/Linux so gut wie widerlegt. Auch schön.
Noch ein Grund, sich nur noch im Notfall mit Windows
auseinanderzusetzen. Allerdings gibt es für Windows eine Portierung der
libusb; hat da wer schon mal mit gearbeitet?

Autor: Rufus, das dicke Ei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn die Treiberentwicklung für Linux so simpel wäre, dann gäbe es
wohl auch mehr Devicetreiber dafür ..."

Wie hängt denn das eine mit dem anderen zusammen?
Ist doch unlogisch. Da spielen viele Faktoren eine Rolle.
Wieso hat sich das lausige VHS durchgesetzt?
Wieso hat sich MS-DOS durchgesetzt?
Wieso hat sich windows durchgesetzt?


"Bereits in einem anderen Thread fragte ich Dich übrigens, ob Du
Deinen "Nicknamen" hier besonders komisch findest ... gibt es eine
Erklärung?"

Schön, daß Du das in einem anderem Thread gefragt hast.
Nein, warum sollte ich das komisch finden?
Findest Du Deinen komisch?


"Also mit 10 Zeilen kommt man wohl nicht hin, aber mehr als ein paar
kb fuer Testprogramm sind auch wieder nicht notwendig."

Also hier mal ein <10zeiliger Kerneltreiber:

********************************************
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Dual BSD/GPL");

static int test_init(void) {
        printk(KERN_ALERT "Hello, Kernel-World!\n");
        return 0;
}

static void test_exit(void) {
        printk(KERN_ALERT "Bye, Kernel-World\n");
}

module_init(test_init);
module_exit(test_exit);
********************************************


Bevor jemand nachzählt:
Den "Hello, world"-Kram habe ich reingemacht, damit das ein bisschen
nach etwas aussieht.

Da ich beruflich Kerneltreiber entwickle, kann ich mich nur
wiederholen: Es ist nicht schwierig, auch wenn Rufus das behauptet.
Das Debugging kann ein bisschen kniffliger sein und man muss ein paar
Sachen beachten, schließlich ist man nicht in einem freien Umfeld wie
eine "normale" Applikation, aber kompliziert? Quark!

Autor: Rufus, das dicke Ei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, falls jemand auf die Idee kommt, den komplizierten
Kerneltreiber zu kompilieren und auszuprobieren:

Hier ein mögliches Makefile:

************************************************
ifneq ($(KERNELRELEASE),)
        obj-m := test.o
else
        KERNELDIR ?= /lib/modules/$(shell uname -r)/build
        PWD := $(shell pwd)

default:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

endif
************************************************

Geladen wird der dann mit modprobe oder insmod, wobei je nach
verwendetem Befehl auf den Pfad geachtet werden muss.

Und der Kernel ist ein 2.6er.

Autor: Rufus, das dicke Ei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"@Olaf: Warum wohl erscheinst Du mir glaubwürdiger als der
Wortbeitrag,
den hier jemand um 23:06 ablassen musste?"

Also nimm es mir nicht persönlich, aber als erstes ist mir
"beschränkter Horizont" durch den Kopf geschossen.
Es gab auch mal Zeiten, in denen viele Leute glaubten, die Welt wäre
eine Scheibe...

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja schön, daß es Dir so gut geht.

Einsicht ist immerhin auch manchmal ein Weg zur Besserung; mal sehen,
wann Du damit anfängst.

(Offensichtlich habe ich versehentlich durch Gebrauch eines
Schlüsselwortes 'L*n*x' bei dem dicken Ei eine Art pawlowschen Reflex
ausgelöst)

Autor: Marillion (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, das dieser hochinteressante Thread in persöhnliche Beleidigungen
übergeht.

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Offensichtlich habe ich versehentlich durch Gebrauch eines
Schlüsselwortes 'L*n*x' bei dem dicken Ei eine Art pawlowschen
Reflex
ausgelöst"

Ich denke, dass kam eher durch die Aussage:
"@Olaf: Warum wohl erscheinst Du mir glaubwürdiger als der
Wortbeitrag,
den hier jemand um 23:06 ablassen musste?"

Denn begründet hat Rufus2 seine Aussage ja ziemlich eindrucksvoll.
Aber wir Marillion schon schreibt, solltet Ihr mal den Ball etwas
flacher halten.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab auch schon mal einen Kerneltreiber fuer Linux geschrieben.
Ist aber schon zehn Jahre her und war fuer einen 8253 als ISA
Steckkarte. Auch das waren mehr als zehn Zeilen. Schliesslich soll der
Treiber ja auch noch was machen.

Ich hab auch schonmal ueberlegt einen solchen fuer Windows zu
schreiben. Genauer gesagt sollte das zu Zeiten von 95b mit USBpatch und
Win98V1 ein USB-Treiber im Rahmen meiner Diplomarbeit werden. Nachdem
ich mir die Doku zu Windows angeschaut habe, hat es mich so
erschuettert das ich mir sofort ein anderes Thema ausgesucht habe.

Um mal wieder auf das eigentliche Thema zurueckzukommen. Das Problem
beim Treiberschreiben ist ja das der auch noch etwas machen soll, und
bei USB auch noch das er die andere Hardware mit ihren Treibern nicht
stoert. Die Verwendung von libusb erleichtert da die Arbeit WESENTLICH.

Ich hab damals erstmal den IgorUSB aufgebaut und mir ein Testprogramm
fuer libusb geschrieben. Es hat etwa eine Woche (als Spass in der
Freizeit) gebraucht bis ich den ansprechen konnte. Aber nur deshalb
weil ich Idiot D+ und D- vertauscht hatte. Haette ich die Kabel richtig
angeloetet haette das vermutlich 1-2h gebraucht.

Danach kann man sich dann an sein Eigenentwicklung machen. Dabei immer
schoen in /var/log/messages nachschauen ob Linux irgendwann das Device
erkennt. Sobald das geklappt hat kann man dann versuchen sein Geraet
mit libusb anzusprechen.

Olaf

Autor: AiM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich finde es zwar toll, dass mein Beitrag soo viel interesse weckt,
aber die Antworten entfernen sich leider immer weiter von der
ursprünglichen Frage.

Das mit dem Linux Kernel ist zwar interessant, aber leider für mich
eher keine Alternative, da die Hardware (leider) auf Windows laufen
muss.

Und nach Möglichkeit sollte sich das ding dann beim Anschließen selbst
anmelden und sämtliche Treiber laden (HID).

gruß
AiM

Autor: Geek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Auch das waren mehr als zehn Zeilen. Schliesslich soll der
Treiber ja auch noch was machen."

Das ist natürlich richtig, aber es ging ja weiter oben darum, ob die
Treiber-Entwicklung kompliziert sei.
Wenn man nun einen 'leeren' Treiber mit 8-9 Zeilen schreiben kann, so
ist das nun sicherlich nicht schwer.
Klar muss man das noch mit Funktionalität füllen, aber das trifft auf
jedes Programm zu.

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@AiM:
Guck dir mal die anderen Treads zu den FTDI-Chips an.

Autor: Geek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FTDI nutzt nichts, er möchte eine USB-Standardklasse nutzen (HDI).

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.

  "Und nach Möglichkeit sollte sich das ding dann beim Anschließen
  selbst anmelden und sämtliche Treiber laden (HID)."

Bevor die Diskussion hier abglitt, beschrieb ich die Probleme beim
Laden des Devicetreibers vom USB-Device.

Entweder das Device implementiert eine Standard-Deviceklasse (wie Du
mit "HID" andeutest), dann gehört der Devicetreiber zum Lieferumfang
des OS und Du musst "nur" noch herausfinden, wie Du über diesen
erweiterte Kommunikationsmöglichkeiten mit Deinem Device hinbekommst
(eventuell mit der Win32-Portierung der libusb?),
oder das Device implementiert zwei Devices gleichzeitig; ein "mass
storage device", um Speicherplatz für den Devicetreiber zur Verfügung
zu stellen, und das eigentliche Device, welches ein wie auch immer
geartetes Protokoll verwenden kann.

Es ist aber anzuzweifeln, daß dieser zweite Ansatz überhaupt brauchbar
funktionieren wird (kann man Windows dazu bekommen, Devicetreiber
automatisch von einem neu angeschlossenen "mass storage device" zu
laden? Wie geht man mit Benutzerberechtigungen um?), daher erscheint
die Verwendung einer der Standarddeviceklassen am angesagtesten.

Damit aber scheiden die sonst so eleganten FTDI-Chips aus, diese
verwenden ein proprietäres Protokoll, das nur von den FTDI-eigenen
Devicetreibern bedient wird.

Allerdings ist mir nicht ganz klar, wo nun das Problem der Verwendung
zu installierender Devicetreiber liegt; da das Gerät ja eh' mit einer
eigens dafür geschriebenen/zu schreibenden Software zusammenarbeitet,
sollte eine Auslieferung/Installation der Devicetreiber zusammen mit
dieser Software eigentlich kein großes Problem darstellen.

Autor: R2D2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Treiberprogrammierung würd ich unabhängig vom verwendeten IC die
libusb benutzen.
http://libusb.sourceforge.net
http://libusb-win32.sourceforge.net/

Damit ist ein Treiber innerhalb kürzester Zeit fertig, da er direkt in
die Anwendung integriert wird. Außerdem ist die Platformunabhängigkeit
gegeben, wenn man noch QT oder besser GTK+ (http://www.gimp.org/win32)
verwendet. Dann haben auch die ganzen Linux vs. Windows-Streitereien
ein Ende, weil jede Seite das gewünschte System nutzen kann.

Auch Kerneltreiber sind relativ leicht möglich, jedoch nicht
platformunabhängig. Ich hab mal einen TUSB3410-Bootloader geschrieben.

Den TUSB3410 kann ich aber nicht empfehlen da er zuviele Bugs hat.
z.B.:
P3=0; Chip crasht. Die P3 bits, denen kein Pin zugeordnet ist sind auf
Memory-Enables gemapt. Ohne ein Wort darüber im Datenblatt zu
verlieren.
Wenn sowohl DMA als auch FIFO an sind kommen jeweils vier 64Byte
packete durcheinander gewürfelt an.
Ist also sehr zeitaufwändig diese ganzen Fehler zu finden (man denkt
erst an die eigene Software) und sie dann auch noch zu umgehen. Ich
werd mir diese CP2102-Teile aus dem anderen Thread mal genauer
anschauen. Ich seh da mehr Potential drin.

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jupp libusb(-win32) ist ne echt tolle Sache :)

Gruss Tobias

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.