Hallo, nun habe ich das Board mit dem AT90USB162 gebaut, kann auch Daten senden und auch empfangen. Habe 8 LEDs angeschlossen und sie Leuchten dann auch beim Schalten. Für die PC Seitige Steuersoftware habe die Software aus dem Internet von der Seite http://janaxelson.com/files/generic_hid_vb_50.zip runtergeladen. Ich sende die Date von 0 - 255 für die 8 LEDs. Soweit ist alles in Ordnung. Nun, mein HW sendet auch ständig sein Zustand zurück, damit ich auch am PC sehen kann, was geschaltet ist oder was nicht. Ein kleines Problem habe ich da, es wird immer die Vorletzte Zustand angezeigt. D.h. wenn mein HW alle LEDs geschaltet sind, liest die VB.NET Software den Vorletzen Zustand also alles aus. Beim eingeschalteten Zustand auch die 255 zu lesen, muss ich dann für das Schalten zweimal auf Schalten klicken d.h. zweimal die 255 senden. Das ist aber nicht Sinn der Sache. Kann mir einer sagen, woran das an dem VB.NET Software liegt? Ich habe an der Software nichts verändert, habe sie so eins zu eins übernommen. Nur das ich statt mit Hex, mit Byte arbeite. VG Frank
Frank Neumann schrieb: > Kann mir einer sagen, woran das an dem VB.NET Software liegt? Sehr wahrscheinlich liegt es garnicht an der VB.net-Software, sondern an der Firmware deines Device. Vermutlich arbeitet die so, dass zu sendenden Daten sozusagen "vorab" in einen Puffer gelegt werden, in der Hoffnung, dass sie mal abgeholt werden. Weiterhin wird der weitere Schreibzugriff auf den Puffer blockiert sein, bis die Daten darin abgeholt wurden. Das ist ein durchaus legitimes Vorgehen (vor allem, wenn der Firmwarecode nicht schnell genug ist, um sozusagen "live" USB-Requests zu handeln, dann geht's nämlich garnicht anders. ;o). Der Fragende (sprich: die PC-Software) muss aber in diesem Fall seine Abfragestrategie auf diesen Sachverhalt anpassen. Dazu gibt's mehrere Möglichkeiten, welche man verwendet, hängt vor allem davon ab, ob nur die Reaktion auf irgendein relativ seltenes (aus Computersicht) Kommando gebraucht wird (das wäre wohl dein Fall mit dieser Testsoftware) oder ob man die mögliche Bandbreite wirklich ausnutzen möchte bzw. muss. In deinem Fall würde es also genügen, einfach mindestens zweimal zu lesen, nachdem das Kommando abgesetzt wurde. Die erste Lesung holt den veralteten Pufferinhalt, den wirft man weg. Die nächste Lesung holt entweder nix (dann muss man weitere Lesungen anhängen, bis was kommt) oder halt die tatsächlich aktuellen Daten. Übrigens: deine Shift-Taste klemmt und deine Beherrschung der deutschen Sprache läßt stark zu wünschen übrig. Du hast Glück, dass ich heute gute Laune habe...
Hallo C. Hater, danke für die schnelle Antwort. Ist das eine Vermutung oder hast du aus Erfahrung geschrieben? Ich meine damit, kennst du dich mit der USB Technik aus?
Frank Neumann schrieb: > Ist das eine Vermutung oder hast du aus Erfahrung geschrieben? Ich meine > damit, kennst du dich mit der USB Technik aus? Das hat in erster Linie nichts mit USB zu tun. Und ja, es hat mit Erfahrung zu tun, mit der Überlegung wie ich es realisieren würde. Das blockiert mich manchmal im Umgang mit fremden Geräten/Software. Gruss Chregu
Hi Christian, habe ich dich richtig verstanden? du sagst, wenn ich von der HW keine Daten abrufe, bekomme ich auch nichts? Aber mein HW sendet in der Do Loop Schleife ständig Daten an den PC. Und wen ich an die HW Daten sende, dann kann ich doc die LED ein bzw ausschalten. Da ruft mein HW auch nicht Daten vom PC Ich dachte, ich könnte über die USB Schnittstelle genau so kommunizieren wie mit der TCP/IP Verbindung über die Winsock. VG Frank
Nein, über USB kommt nichts selber, das muss man pollen. Ich stelle es mir so vor, dass der Entwickler der FW einfach bei einem Zugriff die Daten zurückgibt, die nach dem letzten Zugriff bereitgestellt wurden. Gruss Chregu
Oh man, was ist bitte dann der Vorteil von USB? Dann könnte man doch gleich bei der guten alten RS232 Schnittstelle geblieben, denn der liest die Daten vom HW ohne zu pollen. Ich sehe schon im Internet, wie komplex die USB Welt ist. Vg Frank
Frank Neumann schrieb: > was ist bitte dann der Vorteil von USB? Das habe ich mich vor 16 Jahren auch schon mal gefragt, ich zitiere aus dem immer noch aktiven Usenet: "Christian Müller" <chr...@tiscalinet.ch> schrieb im Newsbeitrag news:3ed675fc$1_1@news.tiscalinet.ch... - zitierten Text ausblenden - > Hallo NG, > > ich weiss nicht wie es Euch geht, aber mich beunruhigt der aktuelle Trend > der Computer- und Peripheriehersteller, die Entwicklung Richtung seriell und > Extern zu treiben. > > Wie (relativ) einfach war doch noch das Basteln mit RS232 und dem > Druckerport und ISA-Slots. Einfach so schnell ein paar Bits gesetzt und so. > Aber heute, alles USB, PCI und andere Komplizierte... > > Und dann das ganze noch seriell, bei den Festplatten geht's nun auch schon > los. Und technisch gesehen ist das doch ein Irrsinn!!! Die meisten Geräte > brauche das eh wieder parallel. Und schneller kann das doch nicht sein bei > gleichem Bustakt (der Schnittstelle). Was ist denn der Vorteil davon? Ja, > die Kabel sind dünner, weniger Kontakte. > > Also vielleicht red ich etwas wirr, aber ich muss das mal loswerden, und > vielleicht versteht mich ja der eine oder andere. Ich gerate einfach in > Panik, wenn ich keinen neuen Rechner mehr kaufen kann ohne serielle und > parallele Schnittstelle. Beim einten Rechner ist mir schon eine > Schnittstelle vom Basteln abgebraten und die kann ich ja nicht mal mehr > reparieren. > > Vielleicht soll ich ja alle Occasionen und Schnittstellenkarten > zusammenkratzen, damit... > > Gute Nacht wünscht Euch > > Chregu > > Billiger und schneller kann man heutzutage nur seriell werden. Chipfunktionalität wird immer billiger und schneller, also warum nicht alles auf dem chip komplizierter, aber aussen einfacher und billiger machen? Man sieht ja schon an den Ultra-DMA Kabeln für die Harddisks, dass die Kabel immer teurer und aufwändiger werden. Ein gutes IEEE1284 Kabel für die parallele Schnittstelle ist auch teurer als ein USB Kabel (wenn man's überhaupt herkriegt), und 480mbits (USB2) kann die parallele Schnittstelle nie. Technisch ist der skew - also die Laufzeitdifferenz auf parallelen Kabeln - ab einer bestimmten Frequenz nicht mehr in den Griff zu bekommen (Jitter). Das geht seriell besser. Und 2.5 bis 3.5 giga Bits pro Sekunde sind heute technisch Standard und billig, 10 giga stehen vor der Tür (siehe Xilinx RockePHY etc.). Die Bahn machts auch so. Die Züge weden schneller statt parallele Gleise zu ziehen. Ist einfach billiger. MIKE Gruss Chregu PS: Leider funktionieren Links aus Google Groups nicht.
Frank Neumann schrieb: > habe ich dich richtig verstanden? > du sagst, wenn ich von der HW keine Daten abrufe, bekomme ich auch > nichts? So isses. USB basierte schon immer auf Polling. Selbst "interrupt" transfers werden nur gepollt. > Aber mein HW sendet in der Do Loop Schleife ständig Daten an den PC. Über welchen Endpoint? > Und wen ich an die HW Daten sende, dann kann ich doc die LED ein bzw > ausschalten. Ja klar, da läuft ja der Transfer auch in die entgegengesetzte Richtung, in die Richtung, wo der Sender der ist, der die Macht über die Verbindung hat. Diese Konzept ist überhaupt nicht ungewöhnlich, I2C und SPI z.B. machen es ganz genauso. Allein der Master bestimmt, wann kommuniziert wird. Der Client kann selbst dringende Sachen nicht von sich aus signalisieren, er muss immer darauf warten, dass ihn der Master befragt. > Ich dachte, ich könnte über die USB Schnittstelle genau so kommunizieren > wie mit der TCP/IP Verbindung über die Winsock. Kannst du nicht. Das Socket-API kennt ein Paket-Konzept und gleichberechtigte Peers, USB und das USB-API kennt das beides nicht. Beim USB-API wird zunächst aller Datenverkehr als Stream dargestellt. Es gibt also für jeden aktiven Endpoint des Device auf dem PC einen Stream. Bei Streams, deren Datenrichtung Device->PC ist, musst du also entweder den Stream pollen oder asynchron auf Dateneingang im Stream warten. Das eigentliche Polling des Device hingegen musst du nicht selber machen, das nimmt dir die USB-Infrastruktur ab. Die Firmware des Device muß z.B. nur den Interrupt-Endpoint mit Daten beschicken, dann werden die automatisch vom PC abgeholt und in den entsprechenden Stream reingefädelt. Allerdings gibt es auch da wieder ein Problem: Streams dürfen nicht über alle Grenzen wachsen. Deswegen haben sie typisch eine limitierte Pufferkapazität. Wenn du den Stream also nicht liest, wird der Puffer vollgemacht und dann kommt nix mehr nach. weitere vom Device gepollte Daten wandern in den Orkus. Erst, wenn du den Stream "leergelesen" hast, kommen wieder aktuelle Daten. Also im Prinzip wieder genau das gleiche Problem, was es auch auf Device-Seite gibt. Und auch die Konzepte zur Lösung sind wieder die gleichen... Übrigens, da du dich weiter oben auf Sockets bezogen hast: auch da gelten für Empfangs-Streams natürlich dieselben Gesetzmäßigkeiten. Sowas ist einfach ein sehr universelles Problem...
Hi Timmo, Ich habe aus dem Netz von Jan axelson das Beispiel Projekt in VB. NET runtergeladen. Aber was genau machten das was du geaendet hast?
Frank Neumann schrieb: > Aber was genau machten das was du geaendet hast? OMG Lerne deutsch. Dieses Gestammele ist ja wirklich nicht auszuhalten.
Frank Neumann schrieb: > was meinst du über welchen Endpoint? Genau das: über welchen Endpoint. HID hat mehrere. Mindestens zwei, es können aber auch drei sein. Noch komplizierter wird es dadurch, das Endpoint0 (immer) bidirektional ist. Daten in Richtung Device->Host können entweder über Endpoint0 oder einen InterruptIn-Endpoint gesendet werden. Ersteres passiert nur "on demand", letzteres regelmäßig.
Hi hater, Ich tippe am Handytastatur. Tippfehlern sind dadurch nicht auszuschließen. Zur der Frage Endpoint, Const Nb_endpoints = 2 ' number of endpoints in the application including control endpoint Const Ep_hid_in = 1 Const Ep_hid_out = 2 Const Endpoint_nb_1 = Ep_hid_in Or &H80 Const Ep_attributes_1 = 3 ' BULK = 0x02, INTERUPT = 0x03 Const Ep_in_length_1 = 16 Const Ep_size_1 = Ep_in_length_1 Const Ep_interval_1 = 1 ' Interrupt polling interval from host Const Endpoint_nb_2 = Ep_hid_out Const Ep_attributes_2 = 3 ' BULK = 0x02, INTERUPT = 0x03 Const Ep_out_length = 16 Const Ep_size_2 = Ep_out_length Const Ep_interval_2 = 1 Frag mich nicht warum ich diese Einstellungen habe, habe sie so von der Beispieldatei übernommen.
Frank Neumann schrieb: > Ich tippe am Handytastatur. Tippfehlern sind dadurch nicht > auszuschließen. Dann lerne einfach, wie man sie korrigiert. Wird dich vielleicht überraschen, aber das kann man tatsächlich tun, auch auf dem Handy! > Zur der Frage Endpoint, [...] Nun, das klärt garnix. Das ist offensichtlich nur die Konfiguration für die VB.net-Seite. Das Problem ist: die muss einfach mal zum Device passen. Ist wie beim Fernseher: Da kannst du auch auf Kanal23 stellen, wenn dein lokaler Kabelprovider auf Kanal23 nix sendet oder zumindest kein TV, wirst du nix sinnvolles empfangen können...
Frank Neumann schrieb: > Das sind die Endpoinds im AVR ? Mit welcher Sprache erzeugst du AVR Code, der folgende Zeile enthält: > Const Endpoint_nb_1 = Ep_hid_in Or &H80 ? Aber nehmen wir mal an, es wäre etwas so unsäglich schlechtes wie BASCOM im Spiel, dann wäre immer noch nicht die Frage geklärt, über welchen der beiden deklarierten Endpoints nun deine Schleife sendet...
In meiner Glaskugel (grep) leuchten im Sourcecode der Steuersoftware so Bereiche auf, die mit Buffering der Input Reports zu tun haben... (SetNumberOfInputBuffers(), numberOfInputBuffers...) Kann es sein, dass da irgendwo mit Double-Buffering gearbeitet wird? Vielleicht kann man diese vermutete Einstellung ja irgendwo von 2 auf 1 ändern... Oder eben den bereits genannten Workaround nehmen (2x hintereinander abfragen).
:
Bearbeitet durch User
die mit Buffering der Input Reports zu tun haben... (SetNumberOfInputBuffers(), numberOfInputBuffers...) Kann es sein, dass da irgendwo mit Double-Buffering gearbeitet wird? Vielleicht kann man diese vermutete Einstellung ja irgendwo von 2 auf 1 ändern... Was meinst du damit?
Frank Neumann schrieb: > Was meinst du damit? Dass es für die Input Reports offenbar einen Buffer gibt und man die Anzahl der Reports, die in diesem Buffer landen vermutlich irgendwo einstellen kann. Es kann sein, dass das über eine Konfigurationsdatei möglich ist, evtl. ist auch ein Menu oder eine andere Einstellmöglichkeit im Programm dafür vorhanden.
Hallo Zusammen, die Sache mit dem Endpoint und USB Descriptors machen mich verrückt. Gibt es eine Deutsche Erklärung für die USB Schnittstelle, wo ausführlich erklärt wird was Endpoints und die Descriptors machen? Wieviele und welche Endpoints sind wichtig? Was machen die Einzelnen Endpoints? Output reports Input Reports Feature Reports Was sind Reports und wofür sind die da? Topologie? Und und und... Vg Frank Neumann
Frank Neumann schrieb: > Gibt es eine Deutsche Erklärung für die USB Schnittstelle, wo > ausführlich erklärt wird was Endpoints und die Descriptors machen? Nein. Ohne "Datenblatt-Englisch" hast du keine Chance. Das ist allerdings ein viel einfacheres Englisch als die englische Umgangssprache. Wenn man Schulenglisch hatte, dann kann man das schon recht flüssig lesen. Man muss es halt auch wollen... > Wieviele und welche Endpoints sind wichtig? Das hängt davon ab. Nämlich: welche Geräteklasse. In der Klassendefinition ist das meist recht eng eingegrenzt. Es gibt allerdings auch USB-Geräte, die keiner der vordefinierten Klassen entsprechen. Da ist die Zahl und Verwendung der Endpoints fast vollkommen frei. > Was machen die Einzelnen Endpoints? Wie oben schon gesagt: Das hängt davon ab. Der einzige Endpoint, den wirklich alle Gerätearten haben müssen, ist Endpoint0, denn darüber werden grundlegende Aufgaben, wie Enumeration, Addressierung und Konfiguration der Geräte abgewickelt. Für diese grundlegenden Aufgaben existiert dementsprechend auch ein Satz vordefinierter Funktionen, die ausnahmslos alle Geräte beherrschen müssen. > Was sind Reports und wofür sind die da? Reports sind im Gegensatz zu Endpoints eine Spezialität der HID-Geräteklasse, keine allgemeine USB-Sache. Im Prinzip nix anderes als eine Datenstruktur bzw. die Beschreibung einer solchen. Wobei der Begriff Report oft sowohl für die Beschreibung der Struktur als auch für die Instanzen der Struktur selber benutzt wird, was natürlich nicht gerade förderlich für das Verständnis der Sache ist. > Topologie? USB hat, anders als die Ausschreibung des Akronyms vermuten lassen würde, keine Bustopologie, sondern eine Sterntopologie, es ist nämlich de facto ein Baum. Mit einem root hub als Wurzel und den devices als Blättern. Benutzt wird dieser Baum aber busähnlich, man kann sich das so vorstellen, dass zu jedem beliebigen Zeitpunkt immer nur ein Blatt mit der Wurzel reden kann. Der Controller hinter dem root hub bestimmt, wann welches Blatt wie lange labern darf. Es geht allerdings noch weiter, so ein Blatt kann mehrere Kommunikationskanäle haben, der Controller bestimmt, über welchen dieser Kanäle gelabert wird. Tja und diese Kanäle enden halt in Endpoints...
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.