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
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?
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.
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 ...
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
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.
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
"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.
"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?
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
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
> 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
@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?
"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!
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.
"@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...
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)
Schade, das dieser hochinteressante Thread in persöhnliche Beleidigungen übergeht.
"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.
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
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
"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.
. "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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.