USB MP3-Player will nicht am Mac

Versteh ich nicht. UHCI hat als Hostcontroller doch damit überhaupt nix zu tun. Das Ding ist zwar etwas simpel, aber wenigstens von Intel damit halbwegs fehlerfrei implementiert.

Und das kann man von den diversen OHCI-Varianten ja nicht gerade behaupten:

SIS: Disconnected spontan Devices im Betrieb, liefert manchmal 1-3Bytes mehr als angefragt. ALi: Verheddert sich manchmal in der Done-List AMD: Roothubregister haben manchmal falsche Werte

Die Schuld hat (wenn überhaupt) wirklich MS, weil sie bei der Erkennung viel zu tolerant vorgegangen sind. Windows hat da teilweise das 10-20fache an den in der Spec festgelegten Timeouts und macht Retries, wenn es nicht auf Anhieb was bekommt. Es gibt zig Devices, die dann auch diese Retries wirklich brauchen.

Weiterhin hat MS auch eine etwas seltsame Art des Deskriptorholens, und prompt meinen einige USB-FW-Programmierer, dass man es anders gar nicht machen könnte...

tun.

am Mac mit nur OHCI gibt es das Problem nicht. Wieviele FW Programmer gibt es die die Unterschiede nicht kennen (kannten)?

behaupten:

einverstanden aber die kamen alle erst später und MS hatte dann jedesmal die Schuld wenn sie Patches schreiben musten?

mehr als

du hast diese komischen alten NECs vergessen die gar nicht gehen Auserdem gibt es noch diese VIA UHCI ich blaube mit PatchNr 44 inzwischen. Ich habe hier extra noch eine Machine damit laufen...

viel zu

in der

brauchen.

das Geschrei wäre wohl nich viel größer gewessen wenn MS mit Win98 (SE) plötzlich 2/3 der Devices nicht mehr erkannt hätte. (speziell dies Tastaturen und Mäuse) (die Intel Maus ist ein tolles Beispiel)

prompt

könnte...

auch einverstanden. Ich benutze dieses Feature um zu entscheiden ob meine Kisten am Mac oder Linux laufen oder unter Win :-)

Thomas

Thomas Zepf schrieb:

Ja toll. Du wei=DFt schon, da=DF bei Win98 dann immer gleich "Schicht im =

Schacht" war/ist? OK, Treiberproblem, oder OS-Problem - aber warum hatte =

und habe ich mit diversen USB-Ger=E4ten diese Probleme, und mit=20 Firewire-Ger=E4ten nicht?

ec.

ffallen

Aha. Warum habe ich blo=DF noch keinen funktionieren USB1.0-Controller=20 gesehen? Wei=DF wer, bei welchen Chips=E4tzen ein USB1.0-Controller=20 funktioniert hat? INtel KX scheidet schonmal aus ...

gg

Gab es nicht auch einmal USB2-Karten mit Chip von NEC die in bestimmten Boards mit INTeL-Chipset den PCI-Durchsatz allein durch ihre Anwesenheit auf die Haelfte gedrueckt haben?

Koennen wir uns darauf einigen, dass die Idee hinter USB halbwegs brauchbar war, aber die Implementationen schwer zu wuenschen uebrig lassen? (Bis hin zur Unbrauchbarkeit)

Gerrit

nein die USB2 Nec Chips sind schon ok was ich meinte war ein alter USB1.1 host der in machen alten Laptops drin war.

ich kann dem nicht zustimmen USB funktioniert gut. Die Hersteller musten das halt erst lernen wie das geht. Wer Scanner oder Speicher LW s am LPT Port kennt wird mir da zustimmen. Nur weil Device Hersteller in China Schrott abliefern kann ich den USB Bus nicht verdammen.

Thomas

Wenn man von Kleinigkeiten wie fehlender Multi-Master-Faehigkeit und der zu sehr eingeschraenkten Stromversorgung absieht.

Sagte ich doch, die Idee war halbwegs brauchbar, die Implementationen hingegen lassen zu wuenschen uebrig. Im Moment ist das noch recht oft ein SB, das 'Universal' in 'USB' ist noch nicht gegeben.

Gerrit

Gerrit Heitsch schrieb:

Abgesehen davon, da=DF mit USB (mit FW nat=FCrlich auch nicht) nicht 2=20 Rechner einfach durch ein Kabel zu verbinden sind, OK.

Ja.

GG

Doch, mit Firewire geht das. Gibt auch die Moeglichkeit da TCP/IP drueber zu benutzen. XP liefert die noetige Software meines Wissens mit. (ieee1394 network)

Apple-Systeme beherrschen sogar den Firewire-Target-Mode, damit wird aus dem Rechner eine Firewire-Platte. Alles was du brauchst ist ein normales Kabel und schon sind die Daten vom alten auf den neuen Rechner einfachst umkopiert. Oder falls die Kiste mal nicht booten sollte auf diese Art die Platte mounten, Problem beheben und passt. (Die Funktionalitaet ist im ROM, das OS braucht dafuer nicht bootfaehig sein)

Deutlich durchdachter als USB ist Firewire schon...

Gerrit

Hey, Danke! Das hab ich glatt =FCbersehen ...

Hmm, hast tats=E4chlich recht.

Eigentlich macht UHCI oder OHCI für den Enduser keinen Unterschied, um Bugs müssen sich ja die Hostcontrollertreiber-Schreiber kümmern ;-) Zu UHCI kann ich nur sagen, dass zumindest die Intel-Implementierung (bis auf einen Bug, den im Treiber problemlos umgehen kann) wirklich geht. Mir sind da keine Fehler oder sporadischen Bugs aufgefallen. Es gibt da eine Anwendung, die 24/7 ca. 400Kbyte/s isochron über USB streamen muss, das funktioniert nur auf Intel-UHCI einwandfrei, an einigen Einsatzorten schon seit mehreren Jahren.

VIA-UHCI konnte man vergessen, die haben eine vernünftige PCI-Arbitrierung wohl erst im letzten Jahr geschafft.

Und zum ewigen Kampf FWUSB: FW war einfach zu früh dran, zu teure Technik, zuviele "professionelle" Features. Damit wurde noch keine Technik Standard im Massenmarkt ;-)

Ich hab mal was von EHCI gelesen... Was ist das genau?

Stimmt. Der Massenmarkt will 'ist mit viel Aufwand gerade so eben halbwegs zum Laufen zu bekommen, dafuer aber billig'. Genau das bekommt er auch, jedesmal.

Gerrit

Technik,

Standard im

Aber 100Mbit Ethernet war zu dem Zeitpunkt bereits Massenware. USB hat man nicht wirklich gebraucht, das war in meinen Augen die typische Marketing-Entscheidung "Bedürfnisse wecken, die keiner hatte". Und bloss nicht fragen, wenn schon ein Bus mit lächerlicher Bandbreite, warum nicht I2C? Wegen der eingeschränkten Anzahl der Devices???, wohl kaum.

FW ging marketingmäßig nach hinten los, aber war eigentlich die wirkliche Weiterentwicklung. SCSI ist inzwischen auch nur noch im Wikipedia und bei mir im Rechner zu finden. Es ist eben nicht die technisch schönste oder beste Lösung die, die sich durchsetzt. (Leider)

Henry

SCSI und FCAL sind im Serverbereich noch weit verbreitet. Wer Multitasking-Performance auch beim Plattenzugriff braucht kommt da nicht drum herum.

Meine Workstation in der Firmat hat FCAL-HDs. Sehr nett das, doch...

Nein, es setzt sich meist die Loesung durch die billiger ist und den Job halbwegs erledigen kann. Wenn sie sich dann durchgesetzt hat werden die ganzen Features nachgeruestet, die die bessere Loesung von Anfang an hatte. Siehe DMA bei IDE (gabs zu Anfang nicht, bei SCSI schon), Command Queueing bei S-ATA (Bei SCSI ein alter Hut), Geschwindigkeit bei USB mit USB2 (FW: 400 MBit, jetzt

Gerrit

Der Controllertyp für USB2.0, d.h. da gibt es nur noch einen. EHCI behandelt aber nur 2.0-Transfers, Low/Fullspeed wird an UHCI/OHCI delegiert, die es weiterhin braucht. Das ist recht raffiniert...

aber

Aha... das koennte erklaeren, warum der USB-Stick mit USB2 nicht wollte, mit USB1.1 hingegen schon (erzwungen mit USB1.1-Hub).

Gerrit

Bugs

kann ich

den im

oder

Ich kenne diese Anwendung und kenne auch die HW ;-) was ist mit dem Mac? Trotzdem hat sie einen Bug weil eben nur UHCI.

Technik,

im

mit FW meinte ich nicht Firewire (da kenn ich nicht wirklich gut aus) sondern Firmware bzw Framework um bei USB zu bleiben.

Thomas

nein das liegt dann ein einer kaputten Firmware. Es gibt massenhaft Geräte die USB2.0 Requests nicht mit STALL beantworten Die Spec schreibt vor, dass jeder unbekannte Request mit STALL beantwortet wird

Thomas

das kannst solche USB Kabel kaufen. Die Umsätze mit solchem Mist sind gewaltig. (A-A Kabel) und nein ich meine jetzt nicht die spez. Datenübertragungskabel.

Thomas

Thomas Zepf schrieb:

Ich dachte, da ist dann immer ein Controller dazwischen?

GG