USB für Programmierung und für HID-Kommunikation

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.

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.

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

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

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

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.