USB-Profi gesucht

Das l=E4=DFt mich spontan an =DCbersprechen und den dadurch verursachten Schmutzeffekten denken. Sowas mu=DF sich bei "normalem" Gebrauch nicht unbedingt st=F6rend bemerk= bar machen.

--=20 gru=DF hdw

|> Interessant auch, daß bei Aktivität auf dem einen port das DSO auch |> auf dem anderen port Aktivität anzeigt. Es war uns aber zu müßig, die |> bits rauszuzählen und zu eruieren, was da genau abgeht, bei der Hitze |> kann man eh nimmer denken.

Anderer Port, aber selber Hostcontroller? Das ist normal, das B steht ja für Bus ;-)

Eigentlich nicht, das Einzige, was da dran ein Bus ist, ist das B im Namen :) Ansonsten ist das ja sternförmige Verkabelung, und sollen mehr Geräte an eine Strippe, dann nur mit zusätzlicher Logik in Form eines hubs.

Nein, es sind normgerechte wirkende Signale, kein unklares Gespratzel.

Bus

Doch, physikalisch ist es ein Bus mit ein paar Treibern zur Isolation. Zumindest bei Signalen vom Root-Hub aus sehen alle Geräte an allen Ports dasselbe. Die Hubs sind ja eben keine Switches, die wissen, welche USB-Adresse an welchen Ports liegt. Bei USB2 ist das leicht anders, weil die Hubs da die High-Speed nach Full-Speed Konvertierung machen. Das wird dann aber nur anhand des angeschlossenen Gerätetyps gemacht und braucht auch noch SW-Support, sonst geht es nicht.

Hubs

Hmmm...das stelle ich mit dem DSO nur dann fest, wenn eben neue Geräte angeschlossen werden, die normale Kommunikation geht dann zielgerichtet nur über den Port, für den es auch bestimmt ist.

Ich habe in dem mainboard die Konstellation, daß die sechs ports von drei UHCI controllers bedient werden, aber bei 480 mbit/sec dann ein EHCI controller für alle sechs ports zuständig ist. Warum auch immer...

Wenn ich nur in den vermaledeiten specs bissl mehr Informationen finden würde, wie die Zusammenhänge zwischen mehreren ports sind. Irgendwie scheint da immer nur ein port isoliert betrachtet zu werden, oder ich bin zu doof, in dem Wust an Informationen das Richtige herauszupicken.

Wir sind inzwischen aufgrund von Vergleichen mit normalen PCs und notebooks so weit, daß es definitiv am mainboard liegt, dennoch bin ich nicht damit zufrieden, wenn ich nicht weiß, woran es liegt bzw. wie der ganze Sch*#* zusammenhängt :-)

Ralph.

Die heilige Kuh der Abwärtskompatibilität.

Gruß Henning

Zumindest

Hubs

Mag an der High/Full-Speed-Trennung liegen. Die Controltransfers zur Erkennung eines Geräts laufen AFAIR nur Fullspeed, bevor EHCI übernimmt.

Das liegt am Prinzip der High/Fullspeed-Steuerung. Im Hostcontroller steckt tatsächlich eine Art Signalschalter, der das auf UHCI oder EHCI verteilt, je nachdem was dranhängt. EHCI kann *nur* Highspeed und beherrscht den ganzen Schnickschnack dazu (Microframes, etc.). Ein Full/Lowspeed-Gerät direkt am Roothub wird vom UHCI angesprochen, an einem Hub-Port übernimmt der Hub die Geschwindigkeitskonvertierung. Neben der Kompatibilität zu nur Fullspeed-HC-Treibern erreicht man damit auch eine Entkoppelung der Bandbreiten. Ein Fullspeed-Gerät bremst den Highspeed-Bus nicht runter (wie es zB. bei Full vs. Low-Speed ist).

Ralph A. Schmid, DK5RAS schrub:

Schonmal mit Linux gegengetestet? Da sind die Logs idR aussagekräftiger...

Ansgar

PS: Prinzipiell hat unsere Firma hier auch prima Know-How im Embedded-Bereich, allerdings nicht speziell mit USB i.V.m. PC-Hardware. Bei generellem Interesse Mail an mich privat: stargar at gmx de - vielleicht können wir euch ja etwas "pauschaler" bedienen ;) .

Nein, mangels Zeit des Menschen, der entspr. know-how besitzt.

Momentan sieht es einfach so aus, als wäre das mainboard schuld, und wir werden dem Hersteller einfach mal eine Erklärung abverlangen, es sei voll USB2.0-kompatibel. Gibt er diese ab, dann werden wir das prüfen lassen...

Moin,

wer sich noch an mein USB-problem erinnert...wir konnten es definitiv auf den Chipsatz oder evtl. noch dessen Treiber eingrenzen, wie bereits befürchtet bzw. vermutet.

Mir ist nämlich eingefallen, daß mein altes notebook den gleichen chipset (speziell den 82801DB bzw. 82801DBM) verwendet, also flugs dort die Situation nachgestellt, und siehe da, das gleiche Problem, zwei highspeed-Geräte behindern sich gegenseitig, obwohl sie an unterschiedlichen ports hängen. Ich werde dann heute Abend daheim noch die Kiste von einer linux-live-CD booten, um zu sehen, ob es evtl. doch eine Treibersache ist, doch zumindest die Verwendung verschiedener Treiber von Intel und Microsoft brachte unter WinXP keine Änderung.

Momentan werden wir noch bei Intel das Problem einkippen, ob es irgendwo insgeheim doch schon bekannt ist, da die neueren chipüsets in dieser Hinsicht anscheinend einwandfrei arbeiten, auch werden wir die MS-knowledgebase durchforsten, vielleicht gibt es ja irgendwo ganz versteckt einen Würgaround-patch.

Ansonsten steht ein ziemlich umfangreiches redesign an, neues board, neue Mechanik, viel Neues hinsichtlich Treibern :( *grmbl*

Viele Grüße

Ralph.

Ist das ein neues Un-Wort für "Bugliste" ?

MfG JRD

Rafael Deliano schrub:

Die Knowledge-Base ist AFAIK nur eine Liste der Bugs, für die es wenigstens den Ansatz einer Lösung oder eines Würgarounds gibt.

Ansgar

Ja, und sie ist oft ein Quell großer Hilfe; leider werden viele patches gar nicht durch die automatischen updates abgekippt, sondern man muß sie sich manuell suchen und installieren.