www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB für Programmierung und für HID-Kommunikation


Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: S. Matlok (smatlok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: S. Matlok (smatlok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schnarchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tweaker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@smatlok

hast du eine funktionierende usbtmc firmware? Wenn ja, auf welchem µc?

tweaker

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.