Hi, gerade wollte ich eine Bestellung für ein Board mit ATmega2560 oder 2561 bereitmachen, da kam mir doch tatsächlich noch eine Frage... Mein Gerät sollte den USB als HID realisiert bekommen. - Als Messgerät soll es viele Jahre als Vergleich dienen ohne wegen einem Treiberproblem hinfällig zu werden. Viele kleine Module (z.B. Crumb2560 V1.1 oder ATm2561-UC-TB von siphec.com) bieten da bereits einen USB realisiert mit einer USB-Brücke, häufig SilLab CP2102 an. Diese USB-Lösung beseitigt aber nicht mein Treiberproblem. Als AVR-Neuling frage ich mich nun wie das so grundsätzlich vor sich geht und was einfacher ist: Wenn ich eine USB-Schnittstelle zum Programmieren verwende und gleichzeitig um als HID zu kommunizieren, kann der uC das vollautomatisch unterscheiden oder muß man da noch etwas tun? Ich denke mal um einen Treiber zum Programmieren komme ich wohl nicht umhin, oder? Ist es wegen dieser doppelten Benützung ggf. einfacher neben der oft bereits gesetzten USB-Schnittstelle eine zweite per USB-Warrior anzubringen? Oder macht es Sinn sich so ein Board, z.B ATm2561-TB1.2 http://www-user.tu-chemnitz.de/~sjoc/new/index.html mit einfacher 6pin-ISP-Schnittstelle zu besorgen, wenn man sowieso später den I/O-Warrior & Co verwendet? Danke schonmal im Vorraus!
Schnarchi schrieb: > Mein Gerät sollte den USB als HID realisiert bekommen. - Als Messgerät > soll es viele Jahre als Vergleich dienen ohne wegen einem Treiberproblem > hinfällig zu werden. Das ist eine gute Möglichkeit. Aber schau dir auch mal die Klasse USBTMC an. Die NI-VISA api kann damit arbeiten und etabliert sich mehr oder weniger hoffentlich zum standard in der Messgeräte-Kommunikation (verbindet Oszis, Messgeräte, Labview, Matlab etc..) > Viele kleine Module (z.B. Crumb2560 V1.1 oder ATm2561-UC-TB von > siphec.com) bieten da bereits einen USB realisiert mit einer USB-Brücke, > häufig SilLab CP2102 an. Diese USB-Lösung beseitigt aber nicht mein > Treiberproblem. Hab den Chip jetz nicht angeschaut, aber wie du schon sagtest, lieber auf Standardlösungen setzen statt was eigenes oder Herstellerbasierendes zu verwenden. > Wenn ich eine USB-Schnittstelle zum Programmieren verwende und > gleichzeitig um als HID zu kommunizieren, kann der uC das > vollautomatisch unterscheiden oder muß man da noch etwas tun? AVR uCs werden normal immer über 6-pol ISP programmiert. Jedoch kann z.b. ein Bootloader auf den uC geflashed sein, welcher beim Bootvorgang die USB-Schnittstelle für eigene Zwecke nutzt, u.a. um als Programmer zu fungieren. Nach dem Programmieren klinkt sich der Bootloader aus und die USB-schnittstelle steht dir gang allein für deine Anwendung zur Verfügung. Es gibt also keinen Ressourcenkonflikt um die Schnittstelle. > Ich denke mal um einen Treiber zum Programmieren komme ich wohl nicht > umhin, oder? naja, mit Treiberschreiben würde ich nicht anfangen.
S. Matlok schrieb: >> Ich denke mal um einen Treiber zum Programmieren komme ich wohl nicht >> umhin, oder? > > naja, mit Treiberschreiben würde ich nicht anfangen. Nun, das möchte ich auch jeden Fall vermeiden. Was ich meinte ist, daß man wohl einen Treiber benötigt, damit der uC programmiert werden kann. Liege ich da falsch? Vielen Dank, Deine Antwort war wirklich gut!
Schnarchi schrieb: > Was ich meinte ist, daß > man wohl einen Treiber benötigt, damit der uC programmiert werden kann. > Liege ich da falsch? Treiber zum Programmieren ja, aber ist alles schon irgendwo dabei. Wenn es um das reine Beschreiben des uC geht: Möglichkeit #1: Du programmierst den uC über ISP. Das geht z.B. mit einem USB/ISP programmer. Das AVR Studio liefert einen passenden Treiber mit um diesen Programmer aus dem Studio heraus zu verwenden. Natürlich gibt es auch Programmer die über Serialschnittstelle gehen und nichts mit USB zu tun haben. Desweiteren gibts natürlich auch andere Programmiersoftware neben dem AVR-Studio. Beispiel Programmer: ispMKII (40 euro) oder ICE-MKII (300 euro) Möglichkeit #2: Ein DEV-Board hat irgendeinen Programmer schon onboard. Je nach dem brauchst du für den Programmer dann eben einen Treiber, der mitgeliefert werden sollte, oder er ist zu anderen Programmiersoftwares kompatibel. Beispiel: AVR-Dragon dev-board. Möglichkeit #3: Der uC hat schon Bootloader darufgeflashed und verfügt über USB-Hardware. Das sind z.B. die AT90USBxxx chips con atmel. Zieht man gewisse Pins auf bestimmte logikpegel, so wird beim Einschalten der Bootloader gestartet und dieser verwendet wie gesagt die USB-Schnitstelle. Auf der PC seite brauchst du dann in diesem Falle wieder entsprechende Treiber und Software, z.B. bei Atmel das Flashprogramm "FLIP". Über welche class oder treiber das abläuft weiß ich garnicht, aber das ist auch egal, da der bootloader eh nur zum flashen da ist und die Software FLIP die Daten -irgendwie- rüberschaufelt. Beispiel AT90USBKEY (dev-board). Die zum flashen über USB benötigten Treiber sind also bei der entsprechenden software (AVR Studio oder FLIP oder Anderes) bzw. bei dem Programmiertool schon dabei.
Danke Matlok, ich schätze Deine direkten und ausführlichen Antworten. Im Grunde sind so schon alle meine Fragen mit einem Happs erschlagen. S. Matlok schrieb: > Aber schau dir auch mal die Klasse USBTMC > an. Die NI-VISA api kann damit arbeiten und etabliert sich mehr oder > weniger hoffentlich zum standard in der Messgeräte-Kommunikation > (verbindet Oszis, Messgeräte, Labview, Matlab etc..) Werde ich machen. Doch ich denke diese Klasse ist auch sehr viel schwieriger zu programmieren, oder? Ich möchte mein Programm so einfach wie möglich halten, zum einen weil ich mir selbst nur eine bestimmte Zeit gesetzt habe, zum anderen, weil die Kollegen in der Abteilung nicht viel Programmiererfahrung haben. Nicht zuletzt sollte es für mich auch wirklich sicher sein, daß ich auf einen Standardtreiber setzte. Danke, nochmal.
Schnarchi schrieb: > Hi, > > gerade wollte ich eine Bestellung für ein Board mit ATmega2560 oder 2561 > bereitmachen, da kam mir doch tatsächlich noch eine Frage... > > Mein Gerät sollte den USB als HID realisiert bekommen. - Als Messgerät > soll es viele Jahre als Vergleich dienen ohne wegen einem Treiberproblem > hinfällig zu werden. Ich sitze gerade an einem Board mit dem NXP LPC1343. Der hat einen USB-HID und einen USB-MassStorage Treiber fix&fertig im ROM, und er kann in einen Bootloadermodus geschaltet werden, in dem er sich als Mass Storage anmeldet und per Filecopy seine Firmware bekommt. Das hat doch was, oder? fchk
> Was ich meinte ist, daß man wohl einen Treiber benötigt, damit > der uC programmiert werden kann. Fuer das programmieren wird man schon immer eine Loesung finden. Notfalls auf Basis eines Bootloaders im Target. Aber du willst doch wohl nicht nur programmieren sondern auch einen Debugger benutzen oder? Aus dem Grund ist es sinnvoll zwei unabhaengige Schnittstellen zu haben. Olaf
Frank K. schrieb: > Ich sitze gerade an einem Board mit dem NXP LPC1343. Der hat einen > USB-HID und einen USB-MassStorage Treiber fix&fertig im ROM, und er kann > in einen Bootloadermodus geschaltet werden, in dem er sich als Mass > Storage anmeldet und per Filecopy seine Firmware bekommt. > > Das hat doch was, oder? Schau ich mir gleich an. Vielen Dank, Frank!! Hallo Olaf, S. Matlok schrieb: > AVR uCs werden normal immer über 6-pol ISP programmiert. Jedoch kann > z.B. ein Bootloader auf den uC geflashed sein, welcher beim Bootvorgang > die USB-Schnittstelle für eigene Zwecke nutzt, u.a. um als Programmer zu > fungieren. i.V.m. Olaf schrieb: > Aus dem Grund ist es sinnvoll zwei unabhaengige > Schnittstellen zu haben. Ein 6-pol-Stecker und ein USB ähnlich dem was Matlok oben beschreibt ist wohl nicht unabhängig genug zum Debuggen, oder? - ich meine USB bei herausgeführten 6 Pins zum Programmieren. Die 6 Pins kann man wohl später kaum für etwas anderes als Programmieren verwenden, oder?
Hi Frank, das NXP LPC1343 scheint mehr etwas zu sein, wenn ich mit meinem momentanen Projekt fertig bin. für das jetzige wollte ich nicht mit ARM anfangen. Aber ich schaue es mir bei Gelegenheit nochmal genauer an, aus reinem Interesse.
Angehängte Dateien:
-
lpc1343board.jpg
110 KB
Schnarchi schrieb: > Hi Frank, > > das NXP LPC1343 scheint mehr etwas zu sein, wenn ich mit meinem > momentanen Projekt fertig bin. für das jetzige wollte ich nicht mit ARM > anfangen. > > Aber ich schaue es mir bei Gelegenheit nochmal genauer an, aus reinem > Interesse. Da ist es. Nicht komplizierter als ein AVR. fchk
Hallo Schnarchi, grundsätzlich muss man zwei Sachen unterscheiden: 1. die Applikation auf Deinem Mikrocontroller und 2. die notwendigen Treiber auf PC-Seite. Zu 1.: Auf jedem Mikrocontroller, der eine USB-Schnittstelle hat, lässt sich auch eine HID-Klasse implementieren. D.h. für die Auswahl Deines Controllers solltest Du nicht den USB heranziehen, sondern eher was Du sonst noch brauchst an Schnittstellen/Leistung/RAM usw.. Zu 2.: Die Wahl eine HID-Schnittstelle ist sehr gut, solange man nicht mehr als 64 kBytes/s (eher weniger) an Daten zu Übertragen hat. Man spart sich nämlich den Mist mit der .inf-Datei unter Windows - bei HID sind bereits alle Treiber vorhanden. Was jetzt noch fehlt ist eine API, mit der Du die Daten dann verarbeiten kannst (CreateFile(), ReadFile(), WriteFile() usw.). Genau sowas habe ich für die USB HID-Klasse geschrieben (in C für Visual Studio Express incl. Beispiel-Applikation). Bei Bedarf schick mir einfach eine EMail. Gruß Ralf
Hallo Ralf! Ralf Handrich schrieb: > Auf jedem Mikrocontroller, der eine USB-Schnittstelle hat Du meinst einen uC der einen USB-Controller inne hat, wie z.B. AT90USB... . Ralf Handrich schrieb: > sondern eher was Du > sonst noch brauchst an Schnittstellen/Leistung/RAM usw.. Aus diesem Grunde habe ich mich für den ATmega2560 oder 2561 entschieden, mit externem USB-Controller. Ralf Handrich schrieb: > Die Wahl eine HID-Schnittstelle ist sehr gut, solange man nicht > mehr als 64 kBytes/s (eher weniger) an Daten zu Übertragen hat. Du meinst pro Endpunkt? Ich rechne im Moment mit 4 Endpunkten + Endpunkt 0, zwei rein (1x Daten, 1x Steuerung) und zwei raus (Daten). Wobei die Daten rein (ins Gerät) maximal ca 500kByte betragen, i.d.R. wird es deutlich weniger sein. Diese Übertragung benötigt Fehlererkennung und es ist egal, wann genau die Infos im Gerät ankommen. Siehst Du hier bzgl. HID Schwierigkeiten? Ich wollte den einfachsten Weg der Programmierung mit Standardtreiber wählen.
Olaf schrieb: > Aber du willst doch wohl nicht nur programmieren sondern auch einen > Debugger benutzen oder? Aus dem Grund ist es sinnvoll zwei unabhaengige > Schnittstellen zu haben. Wie kann ich mir 2 Schnittstellen an einem AVR realisiert vorstellen? Kann ich x-beliebige Pins für JTAG und USB wählen? Wie stelle ich den Bezug zum Programmieren her? Kann ich die üblichen 6-Programmierpins auch für andere Zwecke verwenden? Danke für Eure Mitarbeit!
Schnarchi schrieb: > Olaf schrieb: >> Aber du willst doch wohl nicht nur programmieren sondern auch einen >> Debugger benutzen oder? Aus dem Grund ist es sinnvoll zwei unabhaengige >> Schnittstellen zu haben. > > Wie kann ich mir 2 Schnittstellen an einem AVR realisiert vorstellen? > Kann ich x-beliebige Pins für JTAG und USB wählen? Wie stelle ich den > Bezug zum Programmieren her? Die Pins für einzelnen Peripheriebestandteile sind beim AVR vorgegeben und können nicht wie z.B. beim dsPIC verschiedenen IO-Pins zugewiesen werden. Ein Mega 2560 hat selber keinen USB-Controller, d.h. Du brauchst einen externen wie z.B. den NXP PDIUSB12 (den verwendet auch Atmel in seinem JTAGICE mkii und im AVRISP mkii), oder Du nimmst einen AVR mit USB drin (AT90USB1286/1287). > Kann ich die üblichen 6-Programmierpins auch für andere Zwecke > verwenden? Du meinst die ISP-Schnittstelle. Ja. Beim Mega128 z.B. sind PDI und PDO auf den Pins für einen UART. Das habe ich ab und an für eine Wartungsschnittstelle benutzt, über die man den Controller entweder per ISP programmiert oder den UART als Service- und Debugport benutzt. Du kannst das natürlich auch aufteilen: Einen Mega32u2 als USB-Komunikationsprozessor (wenn Du eben unbedingt bei AVR bleiben musst), und einen 2560 als Applikationsprozessor. Mit passender Verschaltung der beiden kannst Du dann per USB den Applikationsprozessor updaten oder mit ihm kommunizieren. fchk
Ok, ich möchte doch noch ein paar Fragen stellen: Ist der Debugzugang auch auf bestimmte Pins festgelegt? Gibt es noch andere Schnittstellen außer JTAG zum Debuggen? Ich verstehe es bzgl. des Programmierens so: - Wird ein Bootloader verwendet, so bestimmt dieser auf welche Schnittstelle zur Programmierung zurückgegriffen wird. - Wird über ein Programmiergerät programmiert (sei es auf dem Dev-Board oder einzeln) so programmiert man über festgelegte Pins. Liege ich da richtig? ... So, ich denke ich bestelle mir jetzt ein Board/Modul. Denke ich weiß jetzt, daß ich beim Kauf bzgl. vorhandener oder nichtvorhandener USB-Schnittstelle keinen Fehler machen kann...
Schnarchi schrieb: > Ok, ich möchte doch noch ein paar Fragen stellen: > > Ist der Debugzugang auch auf bestimmte Pins festgelegt? > Gibt es noch andere Schnittstellen außer JTAG zum Debuggen? Bei den AtMegas nicht. Über ISP geht nur das Flashen, aber kein Debuggen. > Ich verstehe es bzgl. des Programmierens so: > > - Wird ein Bootloader verwendet, so bestimmt dieser auf welche > Schnittstelle zur Programmierung zurückgegriffen wird. Da schreibt der Prozessor selbst die Daten ins Flash rein, und das Programm dafür mußt Du selber liefern. > - Wird über ein Programmiergerät programmiert (sei es auf dem Dev-Board > oder einzeln) so programmiert man über festgelegte Pins. Da ist der Prozessor stillgelegt, und eine externe Mimik programmiert das Flash. > Liege ich da richtig? ja.
@smatlok hast du eine funktionierende usbtmc firmware? Wenn ja, auf welchem µc? tweaker
Thread beobachten
Seitenaufteilung abschaltenBitte 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.