"Eigenes USB-Gerät" für eigene Software

Das Standard Interface ist USB-to-Serial zB von FTDI. Auf der PC Seite 
steckt man USB ein, und das Device erscheint als Serialport. Auf der 
anderen Seite ist es ein UART, das kann man direkt mit dem UART des 
controllers verbinden.

Oder, du nimmst dir gleichen einen USB µC ala Atmega32u4 oder ein PIC 
Derivat und setzt dort einen USB CTC (Das gleiche wie ne UART-USB 
Bridge) auf.

Ob nun mit einem FTDI oder direkt einem USB-µC - aber UART ist das was 
du suchst.

Es gibt viele verschiedene USB Klassen, z.B. CDC (serielle Schnittstelle 
über USB). Die serielle Schnittstelle kannst Du mit relativ wenig 
Aufwand in Deiner PC Software ansprechen und von dieser lesen und 
schreiben. Dann gibt es noch die HID (Human Unterface Device) Klasse, 
das passt gut wenn Du Potis, Knöpfe, LEDs, etc. ansprechen willst.

Oh D. schrieb:
> HID kann allerding nur etwas 64 Meldungen pro Sekunde.

Die minimale Intervall-Zeit liegt bei bei 1ms. Aber wieviel nun 
tatsächlich rauskommt, wäre schon mal Interessant zu wissen. Ich arbeite 
gerade an einer HID, kann ja mal ne Messung mit implementieren.

Warum besteht ihr alle auf UART? FTDI liefert doch gute Treiber für 
direkte USB-Verbindung.
Oder meldet sich der Chip als HID an und darauf bezieht sich
> HID kann allerding nur etwas 64 Meldungen pro Sekunde.
?

Dussel schrieb:
> Warum besteht ihr alle auf UART? FTDI liefert doch gute Treiber für
> direkte USB-Verbindung.

Warum immer das Pferd von hinten aufzäumen?! Für eine einfache 
Kommunikation zwischen PC und µC - egal in welche Richtung - ist nunmal 
UART die beste Lösung. Sie läuft ohne Treiber, sie läuft auf allen 
Systemen, sie läuft unter µCs - sie läuft.

Hab ich dann noch nen doofen USB Stack dazwischen fangen doch die 
Probleme wieder an - Angefangen bei den Treibern für die einzelnen 
Systeme (Oder das man überhaupt einen Treiber braucht!) darüber das man 
nichtmal eben flexibel nen anderes System (vom µC über nen Oszi hin zum 
Pc) anstöbseln kann, und aufgehört das man ja das PC Programm auch noch 
schreiben muss.

Le X. schrieb:
> UART ist eine Bastlerlösung.

Deßhalb wird sie auch heute noch reichlich in der Industrie eingesetzt.
Dummschwätzer.

Auch für eine Hid Device muss man sich ein eigenen Parser schreiben um 
zu sehen welches Bit / Byte an welcher Position steht. Die Arbeit für 
einen Parser bleibt einem bei überhaupt keiner Kommunikation aus, sei es 
UART, HID oder I2C...

Und das UART eine Bastlerlösung ist... :-D Naja, dazu sag ich mal nun 
nichts mehr ^^ Bei uns im Labor werden ALLE Aparaturen per UART 
angesprochen, seien es die Präzisionswagen, der Gas-Chromatograph oder 
der Maschinenpark an sich. Also wo du diese Einstellung gelernt hast... 
kein Plan! :-D

> Du wirst also, zumindest bei ernsthaften Anwendungen, irgendein
Protokoll implementieren dürfen. Dieses Protokoll verursacht Arbeit 
(Design, Implementieren, Debuggen) und wird niemals an bereits bewährte, 
gut abgehangene Standardlösungen heranreichen.


Schwätzer. Weg mit dem Troll.

> und wird niemals an bereits bewährte, gut abgehangene Standardlösungen 
heranreichen.

Und diese gut abgehangenen Standardlösungen waeren ?
-CAN ?  .. Der Brüller. Eine maximale Packetgroesse von 8 Byte, oder so.
-USB ?  .. der Brüller. Nach 5m Kabel ist Schluss.
-HPIB ? .. der Brüller. Das Kabel taugt sogar gegen Einbrecher.

жтампф ден троль schrieb:
> Und diese gut abgehangenen Standardlösungen waeren ?
> -CAN ?  .. Der Brüller. Eine maximale Packetgroesse von 8 Byte, oder so.
> -USB ?  .. der Brüller. Nach 5m Kabel ist Schluss.
> -HPIB ? .. der Brüller. Das Kabel taugt sogar gegen Einbrecher.

Wo ist das Problem? Jede Lösung hat ihre Vor- und Nachteile. Bei UART 
zum PC ist eben normalerweise bei 115200 Baud Ende. Knapp 12 KB/s. Das 
ist ungefähr so schnell wie ein HID bei Low-Speed. Mit Full-Speed 
erreicht man 64 KB/s. Ohne speziellen Treiber, ohne großen 
Softwarestack, anschließbar an so ziemlich jedes Gerät mit USB. Und im 
Gegensatz zu UART paketbasiert. Für Kommunikation mit PCs o.ä. ist USB 
heutzutage einfach Standard.

Auf der anderen Seite ist USB natürlich nicht so einfach wie eine 
serielle Schnittstelle. Das liegt einfach daran, dass USB so viel 
mächtiger ist und vor allem auch ziemlich viel automatisiert abläuft.

Zwölf M. schrieb:
> USB hat das Problem, dass man zu jeder neuen Windowsversion potentiell
> einen neuen Treiber liefern muss, resp einen geliefert bekommen muss.

Nein. Bei HID liefert Windows bzw. alle anderen Betriebssysteme den 
generischen Treiber. Für ein HID muss man selbst keinen Treiber 
schreiben. Genauso verhält es sich bei den ganzen Standard-USB-Klassen. 
Auch für die gibt es generische Treiber. Nur, wenn man was recht 
spezielles braucht, muss man einen eigenen Treiber schreiben.

> Bei UART zum PC ist eben normalerweise bei 115200 Baud Ende.

Diese Geschwindigkeit ist nur relevant, wenn auch wirklich
per (echter) RS-232 Geraete angesteuert werden sollen.

Wenn man nur die serielle USB-Emulation benutzt, ist die
eingestellte Schnittstellengeschwindigkeit voellig ohne Belang.

Ich habe mir hier zum Beispiel einen USB Paralleladapter gebaut,
der per serieller Emulation angesprochen wird.
Den juckt die eingestellte Geschwindigkeit ueberhaupt nicht.


P.S.: Viele serielle USB-Adapter unterstuetzen mittlerweile
auch 1 Mbit/s bzw. 921600 bit/s.

avr schrieb:
> Mit Full-Speed
> erreicht man 64 KB/s. Ohne speziellen Treiber, ohne großen
> Softwarestack, anschließbar an so ziemlich jedes Gerät mit USB.

Was nützen mir 64KB/s wenn nicht alle Pakete ordentlich ankommen?! Ich 
schreibe gerade ein HID Device über einem Atmega32u4 mit FullSpeed, 
beidseitig Interrupt gesteuert. btw... die Initialisierung des Mega:

1

/*(Full-Speed 12Mbit/s) und Interrupts*/

2

void usb_init_device(void)

3

{

4

  UHWCON = (1<<UVREGE); //Regelkreis zur Versorgung der D+ und D- Leitung einschalten

5

  USBCON = ((1<<USBE) | (1<<FRZCLK) | (1<<OTGPADE)); //0xB0 USB Sender/Empf.,Takt und VBUS-Leitung einschalten                                                 

6

  USBCON &= ~(1<<FRZCLK);   // FRZCLK=0, noetig, sonst kein WAKEUP Int

7

  USBCON |= (1<<FRZCLK);          // FRZCLK=1 Strom sparen

8

9

  // Starte PLL

10

  PLLCSR = 0x10;                  // PLL Vorteiler fuer den Quarz

11

  PLLCSR |= (1<<PLLE);            // starte PLL (PLLEnable=1)

12

  while (!(PLLCSR &(1<<PLOCK)));  // Warte bis PLOCK = 1 (PLL eingerastet)

13

  USBCON &= ~(1<<FRZCLK);         // FRZCLK=0, aktiviere den Takt

14

  UDCON &= ~(1<<0);

15

  UDIEN = (1<<EORSTE);            //0x08 erlaube End Of ReSeT Interrupt

16

}

Nur Probleme damit, die Datenpakete kommen mitunter nicht komplett an, 
ein Workaround dafür hab ich auch noch nicht gefunden, die 64kbit sind 
sowieso nur ein theoretischer Wert. Wenn der Endpoint und der Device 
Descriptor nicht richtig sitzt fischt man sowieso nur im Dunkeln weil 
man überhaupt keinen Hinweis bekommt wo der Fehler sein könnte und 
Debuggen is da nicht. Von dem riesigen USB Stack in C# will ich garnicht 
erst anfangen (Gut, in C++ wird das sicherlich einfacher sein - geb ich 
zu)

Und dann wie gesagt: Der gelegentliche Datenverlust alle paar Sekunden.

Und deine Aussage: Also ich habe noch auf KEINEM Gerät eine USB-CDC 
Treiber gebraucht, der ist ebenso standardisiert wie der HID Treiber. 
Und wer ne USB-HID aufsetzen kann, dem traue ich auch zu das er eine 
UART Paket basierend programmieren kann.

Mein Fazit: Sollte es mir demnächst möglich sein, setze ich bei sowas 
definitiv wieder auf eine UART bassierte Lösung! Nach dem Theater den 
ich gerade mitmache mit HID, kommt bei mir das nur in die Tüte wenn es 
wirklich zwingen notwendig ist, aber für ne reine Datenübertragung?! Nie 
und nimmer wieder!

Aus meiner Sicht ist der Hauptgrund, der gegen eine direkte 
USB-Verwendung spricht, die Vendor ID sowie die damit verbundenen 
Kosten.

Draco schrieb:
> Was nützen mir 64KB/s wenn nicht alle Pakete ordentlich ankommen?!

Was heißt nicht ordentlich? USB-Transfers (außer isochronous) sind 
gesichert.

> Ich
> schreibe gerade ein HID Device über einem Atmega32u4 mit FullSpeed,
> beidseitig Interrupt gesteuert. btw... die Initialisierung des Mega:

Für ein konformes HID-Device ist das nur ein Bruchteil des Codes.

> Nur Probleme damit, die Datenpakete kommen mitunter nicht komplett an,
> ein Workaround dafür hab ich auch noch nicht gefunden, die 64kbit sind
> sowieso nur ein theoretischer Wert. Wenn der Endpoint und der Device
> Descriptor nicht richtig sitzt fischt man sowieso nur im Dunkeln weil
> man überhaupt keinen Hinweis bekommt wo der Fehler sein könnte und
> Debuggen is da nicht.

Richtig, Debuggen ist nicht einfach, wenn man keine entsprechenden Tools 
hat. Aber 64kBit sind keinesfalls theoretisch. Sofern kein Paket 
verloren geht ist das Normalität.

> Und dann wie gesagt: Der gelegentliche Datenverlust alle paar Sekunden.
Was heißt Datenverlust? Ich würde das eher auf ein Softwareproblem 
anstatt USB-Problem schieben. Wenn ein Paket verloren geht, dann sind 
das 64 Byte. Das merkt man kaum.

Falls du Daten über mehrere Outputreports übertragen solltest, ist das 
schon der falsche Weg. Bei größeren Datenmengen sollte man eher zu 
Featurereports greifen und diese auch so groß machen wie die zu 
übertragenden Daten.

> Und deine Aussage: Also ich habe noch auf KEINEM Gerät eine USB-CDC
> Treiber gebraucht, der ist ebenso standardisiert wie der HID Treiber.
> Und wer ne USB-HID aufsetzen kann, dem traue ich auch zu das er eine
> UART Paket basierend programmieren kann.

Wenn nicht das Problem mit dem Öffnen und Schließen von Ports wäre. Es 
ist besser als bei den Hardware-COMs aber immernoch vorhanden. Außerdem 
brauchst du unter Windows eine .inf Datei. Für mich gewinnt hier ganz 
klar das HID-Device.

> Mein Fazit: Sollte es mir demnächst möglich sein, setze ich bei sowas
> definitiv wieder auf eine UART bassierte Lösung! Nach dem Theater den
> ich gerade mitmache mit HID, kommt bei mir das nur in die Tüte wenn es
> wirklich zwingen notwendig ist, aber für ne reine Datenübertragung?! Nie
> und nimmer wieder!

Kannst du ja machen. Bei mir ist es genau andersherum. HID funktioniert, 
wenn es mal einigermaßen richtig implementiert ist, fantastisch.

avr schrieb:
> Was heißt nicht ordentlich? USB-Transfers (außer isochronous) sind
> gesichert.

Es kommen fehlerhaften Daten an.

avr schrieb:
> Für ein konformes HID-Device ist das nur ein Bruchteil des Codes.

Das ist sicherlicher richtig, das ist bloß das starten des USB als HS 
Device.

avr schrieb:
> Richtig, Debuggen ist nicht einfach, wenn man keine entsprechenden Tools
> hat. Aber 64kBit sind keinesfalls theoretisch. Sofern kein Paket
> verloren geht ist das Normalität.

Was heißt hier richtige "Tools"? Das Debugen des Megas zeigt zwar welche 
Daten wo hin raus gehen, das sie rausgehen, wenn aber der Rechner das 
HID Device nicht erkennt weil was im Device Descriptor schief liegt, 
oder etwas in der Endpoint Zuordnung, dann hilft auch kein "Tool" selbst 
USB Diagnose Tools fallen dann aus, weil die ein angemeldetes Device 
brauchen.

avr schrieb:
> Was heißt Datenverlust? Ich würde das eher auf ein Softwareproblem
> anstatt USB-Problem schieben. Wenn ein Paket verloren geht, dann sind
> das 64 Byte. Das merkt man kaum.

Es sind nichtmal 64Byte die ich übertrage, zumindest nicht im 1. 
Endpoint, der 0. Endpoint setzt dies ja vorraus, wird aber auch nur 
einmal abgefragt. Ich arbeite mit 16Byte.

avr schrieb:
> Falls du Daten über mehrere Outputreports übertragen solltest, ist das
> schon der falsche Weg. Bei größeren Datenmengen sollte man eher zu
> Featurereports greifen und diese auch so groß machen wie die zu
> übertragenden Daten.

Ein Outputreport mit 16byte und ein Inputreport mit 3Byte:

1

static const uint8_t PROGMEM Rep_Desc_OutIn[32] =

2

{

3

4

  // Output

5

  0x06, 0x00, 0xFF,    //  USAGE_PAGE (Vendor Defined Page 1)

6

  0x09, 0x01,          //  USAGE (Vendor Usage 1)

7

  0x15, 0x00,          //  LOGICAL_MINIMUM (0)

8

  0x26, 0xff, 0x00,    //  LOGICAL_MAXIMUM (255)

9

  0x75, 0x08,          //  REPORT_SIZE (8)

10

  0x95, 0x10,          //  REPORT_COUNT (16)

11

  0x91, 0x02,          //  OUTPUT (Data,Var,Abs)

12

13

  // Input

14

  0x06, 0x00, 0xFF,    //  USAGE_PAGE (Vendor Defined Page 1)

15

  0x09, 0x01,          //  USAGE (Vendor Usage 1)

16

  0x15, 0x00,          //  LOGICAL_MINIMUM (0)

17

  0x26, 0xff, 0x00,    //  LOGICAL_MAXIMUM (255)

18

  0x75, 0x08,          //  REPORT_SIZE (8)

19

  0x95, 0x03,          //  REPORT_COUNT (3)

20

  0x81, 0x02           //  OUTPUT (Data,Var,Abs)

21

};

avr schrieb:
> Wenn nicht das Problem mit dem Öffnen und Schließen von Ports wäre. Es
> ist besser als bei den Hardware-COMs aber immernoch vorhanden. Außerdem
> brauchst du unter Windows eine .inf Datei. Für mich gewinnt hier ganz
> klar das HID-Device.

Ok, das mit dem "Auffinden" des richtigen Ports - da gebe ich mich 
geschlagen, das ist korrekt. Ich habe mir da aber angewöhnt ne "Abfrage" 
in meine Programmierung mit "einzubauen" - bei Auflisten der einzelnen 
Ports auf der Rechnerseite wird, sofern möglich, jeder Port geöffnet - 
eine Zeichenfolge geschicht, welcher (wenn der µC an diesem Port hängt) 
beantwortet und eine andere definierte Zeichenfolge zurückschickt. 
Sollte keine Zeichenfolge zurückkommen, oder eine andere, wird der Port 
wieder geschlossen und der nächste probiert. Das hat sich eigentlich bis 
jetzt sehr gut bewährt. Das HID da einfacher mit VID/PID angesprochen 
werden kann - sehe ich richtig, das stimmt.

Sofern man noch Windows XP/Vista einsetzt braucht man eine .inf - 
richtig. Aber ab Windows 7 schon nicht mehr, da greift er auf ein 
Standard CDC zurück.

avr schrieb:
> Kannst du ja machen. Bei mir ist es genau andersherum. HID funktioniert,
> wenn es mal einigermaßen richtig implementiert ist, fantastisch.

Die Betonung liegt auf "einigermaßen" ;-)

Draco schrieb:
> Es kommen fehlerhaften Daten an.

Das kann nicht sein. Da muss noch irgendwo was gewaltig schief gehen. 
Wie gesagt, die USB-Übertragung ist CRC gesichert, solange man keine 
Isochronous endpoints verwendet.

Draco schrieb:
> Was heißt hier richtige "Tools"?

Es gibt verschiedene Arten von Tools:
Man kann man PC Programme nehmen, die sich dort einklinken. Gerade wenn 
sehr früh etwas schief geht, helfen die auch nicht immer so viel. Es 
gibt aber auch richtige Hardware, die auf der USB-Leitung mitsnifft. Das 
geht mit Logikanalysern oder eben mit teurer Hardware, die dann auch 
entsprechende Analysesoftware mitbringt.

Dein HID-Descriptor kommt mir ein bisschen seltsam vor. So gut kenne ich 
mich jetzt auch nicht mehr aus, aber ich meine das diese mindestens eine 
Collection haben müssen. Ich würde folgenden nehmen:

1

Usage Page Vendor

2

Usage Vendor

3

Collection Application

4

 Usage Page Vendor

5

 Logical Minimum/Maximum

6

 Report Size/Count

7

 Input

8

 Usage Vendor

9

 Report Size/Count

10

 Output

11

End Collection

Außerdem stimmen deine Kommentare bei deinem Descriptor nicht immer 
überein. Zumindest steht da zweimal Output.

Bei den PC-Debugging-Tools gibt es durchaus auch Programme mit 
Testversionen. Z.B. USBlyzer. Damit kann man solche Fehler auch finden. 
Denn wenn der Fehler in dem HID Descriptor steckt, dann wird dieser 
zumindest übertragen und das bekommt das Programm mit.

avr schrieb:
> Dein HID-Descriptor kommt mir ein bisschen seltsam vor. So gut kenne ich
> mich jetzt auch nicht mehr aus, aber ich meine das diese mindestens eine
> Collection haben müssen. Ich würde folgenden nehmen:

Das ist richtig - Das ist nur der Teil des Descriptors welche den Output 
und den Input Descriptor sicherstellt. Ohne die korrekte Struktur würde 
die Device sowieso nicht als Hid erkannt werden und einfach ein 
"fehlerhaftes USB-Device" aufgeführt. Der Descriptor String wird ja in 
mehreren Phasen vom Host abgefragt bei der Initialisierung - da wird er 
auch erst komplett gebildet.

avr schrieb:
> Außerdem stimmen deine Kommentare bei deinem Descriptor nicht immer
> überein. Zumindest steht da zweimal Output.

Ja das ist richtig - die hab ich nicht immer mitgeändert, nicht nur dort 
:-D Das ist mitunter Fahrlässig von mir und wird leider immer nen bissle 
Stiefmüterlich behandelt, aber es fällt mir auch immer regelmäßig auf 
die Füße wenn ich mal was suche.

Walter schrieb:
> Ich möchte für ein kleineres Studienprojekt quasi ein USB-Gerät
> aufbauen, was sowohl Daten sendet, als auch empfängt. Soweit alles recht
> einfach, soweit man nen Terminal verwendet und sich die Datenströme
> anschaut.

So wie ich das interpretiere ist bereits ein "Eigenes USB-Gerät" 
vorhanden, oder er weiß zumindest was er verwenden will.

Er sucht nach einer
> plattformunabhängigen Software

Ich bezweifle, dass es eine fertige (plattformunabhängige) Software für 
sein Gerät gibt. Zumal noch nicht mal bekannt ist, was diese Software 
genau machen soll außer Daten senden und empfangen.

Walter schrieb:
> Was mir fehlt sind Suchbegriffe um für diese Thematik Texte zu finden.
> Ich kann mir von der Terminal-Ebene zur Software-Ebene rüber wenig
> vorstellen.

Möchtest du dir ein eigenes Programm schrieben?
Wenn es einfach ist die Daten in einem Terminal anzuschauen, dann wird 
das USB-Gerät wohl als (virtueller) COM-Port im System eingebunden. Was 
du brauchst ist eine Entwicklungsumgebung, die den COM-Port ansprechen 
kann.