Ziel: USB-Treiber
-
_fricky u.a. am 22.11 im IRC zum Thema USB-Treiber(Auszüge):
<_fricky> ein usb-treiber muss mit der usb-hardware kommunizieren und dem OS transfer-funktionen bereitstellen
<ehenkes> was versteht man da unter frames genau?
<NN> Wenn ein USB-Treiber nur Frames annimmt und die versendet, ist das nicht mal ein vollständiger HCD. Er sollte schon ganze Pakete annehmen und die entsprechend abstrahierten USB-Geräten zuschicken können
<_fricky> ^^nee, aber das ist der unterste level
<NN> Aber diese Transferfunktion wird das OS hoffentlich wenig interessieren
Deshalb sollte man sie besser nicht bereitstellen
<_fricky> XanClic: an welchem USB bastelst du gerade?
<NN> 1.x
<_fricky> ^^das OS hostet ja auch die treiber der höheren ebene
<NN> "[...] und dem OS transfer-funktionen bereitstellen [...] z.b. um frames über usb zu schicken und zu empfangen"
<_fricky> übrigens: ein treiber-modell fehlt pretty OS wahrscheinlich noch, ne?
<_fricky> Xanclic: ist wichtig, z.b. um sowas wie den CP2102 anzusprechen
<NN> Also, wenn das OS ganze Frames selbst verschicken muss, ist der Treiber kaputt
<_fricky> ^^der will z.b. erstmal konfiguriert werden, ist ein USB<--->RS232 konverter
<NN> Na, da schickt ein entsprechender Treiber halt die entsprechenden Pakete rüber?
<_fricky> ja, aber jeder treiber der hierachie ist bestandteil des OS
<NN> Aber jeder Treiber soll komplett abstrahieren und nicht nur einen Teil
<NN> Also einige Geräte und andere nicht
<NN> Im besten Falle reicht das OS einfach die Daten zwischen den Treiberebenen weiter ohne sich darum zu kümmern, was das ist
<NN> Und am Ende erscheint da z. B. ein Speichergerät, von dem das System nicht wissen muss, ob es eine IDE- oder eine USB-Festplatte ist
<_fricky> klar, aber es muss auch eine möglichkeit geben, usb-devices anzusprechen, die das OS nicht kennt. gewisser massen eine user-mode usb schnittstelle
<NN> Du sagtest, jeder Treiber gehört zum OS. Wenn das OS ein Gerät nicht kennt, heißt das, es hat keinen Treiber dafür und dann kann man halt nix machen
<_fricky> naja, man kann sich auch einen usermode treiber coden. das sollte möglich sein
<NN> Bei richtigen Monolithen nicht.
<_fricky> windoof z.b. fehlt eine low-level USB API, unnötige einschränkung
<NN> Widersprichst du dir nicht grad selbst? Würde man einen Treiber schreiben, würde er ja wieder zum OS gehören
<ehenkes> Warum soll ein Treiber nicht zum OS gehören? ... Bei einem Monolithen gehört er dazu, sogar im Kernel
-
@ _fricky: wie ist der Stand?
Er hat uns für 2009 einen USB-Treiber versprochen.
Er hat uns diesbezüglich gnadenlos versetzt, also sein Wort gebrochen.Mein Fazit: Auf solche "Trolle" kann man hier gut verzichten.
-
Der USB2-Standard ist mittlerweile 10 Jahre alt. Geräte und Mainboards mit dem Nachfolger-Standard USB3 sind seit Anfang des Jahres erhältlich. Die Kompatibilität bleibt gewahrt. Man kann sowohl USB3 Geräte an USB2 Buchsen betreiben, wie auch umgekehrt. In den Genuss der 10-fachen Geschwindigkeit von USB3 kommt man so allerdings nicht.
Theoretische Übertragungsrate:
USB2: 480 MBit/s
USB3: 5000 MBit/s
-
Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann, kann ich mich - hoffentlich unterstützt durch andere OS-Developer - u.a. dem Thema USB-Treiber zuwenden.
Als Simulationsumgebung kann man z.B. Sun VirtualBox einsetzen, hier ein Beispiel der Erkennung und des Auslesens von USB-Devices mittels PCI-Scan (Rev. 0.0.0.107):
http://www.henkessoft.de/OS_Dev/Bilder/Rev107_SunVB_USB.PNG
-
Links für den Einstieg (zum Mitdenken):
http://www.beyondlogic.org/usbnutshell/usb1.htm
http://wiki.osdev.org/USB
http://www.usb.org/developers/docs/usb_20_052709.zip
-
Hallo,
Erhard Henkes schrieb:
Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,
das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern
Erhard Henkes schrieb:
- hoffentlich unterstützt durch andere OS-Developer -
Ich hoffe ich verspreche Dir jetzt nichts was ich später dann nicht halten kann, aber an USB würde ich mich schon gerne beteiligen (dann hab ich es später leichter wenn ich mit meinem Projekt an dieser Stelle bin). Ich werde mir mal die 3 Host-Controller-Specs genau reinziehen.
Seit ihr den der Meinung das PrettyOS reif genug für einen richtigen Treiber-Stack ist?
Grüße
Erik
-
erik.vikinger schrieb:
Hallo,
Erhard Henkes schrieb:
Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,
das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern
*facepalm*
-
erik.vikinger schrieb:
Erhard Henkes schrieb:
Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,
das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern
USB ist hinreichend komplex um einen Entwickler einige Monate zu beschäftigen. Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug.
-
Hallo,
Z schrieb:
USB ist hinreichend komplex um einen Entwickler einige Monate zu beschäftigen.
Ich glaube das hat sich in zwischen unter allen Beteiligten herumgesprochen.
Z schrieb:
Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug.
USB 3 kann man IMHO auch einzeln implementieren, ist ein neues Parallel-Universum, im Gegensatz zum Verhältnis von USB 1 und USB 2. Nur das USB-Basis-Gerüst muss zwischen den einzelnen Standards unterscheiden.
Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.Grüße
Erik
-
Z schrieb:
Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug.
In Linux schon implementiert.
erik.vikinger schrieb:
Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.
Man kann sich bei einem Hobby-OS vielleicht erstmal auch auf USB 1.x beschränken, imo.
-
Das Primärziel besteht darin, permanenten Speicher via USB anzusprechen, um Daten dort ablegen und von dort laden zu können.
-
Hallo,
XanClic schrieb:
erik.vikinger schrieb:
Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.
Man kann sich bei einem Hobby-OS vielleicht erstmal auch auf USB 1.x beschränken, imo.
Bei USB 1 brauchst Du aber 2 verschiedene Host-Controller die der CPU auch nur wenig Arbeit abnehmen, und wenn ich das richtig verstanden hab spart sich Intel in den neuesten Chipsätzen auch die USB 1 Host-Controller ganz (damit stünde PrettyOS wieder im Regen). Wenn man ein Low-/Full-Speed-Device über einen HUB anschließt werden die USB 1 Host-Controller sowieso nicht mehr benötigt, dann läuft alles über diese Split-Transactions, ich vermute Intel hat in den Root-Hub so ein Umsetz-(TT)-Mechanismus eingebaut. Für USB 2 braucht man nur einen Host-Controller, der auch mehr Arbeiten selber erledigt, und zusätzlich die 40-fache Geschwindigkeit anbietet. Für nur Mass-Storage ist das IMHO der bessere Einstieg, später kann man dann in den Hub-Treiber noch Unterstützung für die TTs implementieren und hat USB 1 gleich noch mit erledigt.
Ich werde mir so bald als möglich mal die 3 Host-Controller-Specs reinziehen und kann dann hoffentlich etwas genaueres sagen.
Grüße
Erik
-
erik.vikinger schrieb:
Bei USB 1 brauchst Du aber 2 verschiedene Host-Controller
Bei USB 2.0 brauch ich drei.
erik.vikinger schrieb:
und wenn ich das richtig verstanden hab spart sich Intel in den neuesten Chipsätzen auch die USB 1 Host-Controller ganz (damit stünde PrettyOS wieder im Regen). Wenn man ein Low-/Full-Speed-Device über einen HUB anschließt werden die USB 1 Host-Controller sowieso nicht mehr benötigt, dann läuft alles über diese Split-Transactions, ich vermute Intel hat in den Root-Hub so ein Umsetz-(TT)-Mechanismus eingebaut.
Das wird vermutlich praktisch funktionieren, aber ist nicht USB-2.0-konform. Da müsste Intel erstmal USB 2.1 oder so rausbringen, in der definiert ist, dass es keine Companion Controller gibt.
-
Hallo,
XanClic schrieb:
Bei USB 2.0 brauch ich drei.
Nein, Du kannst mit einem auskommen, es funktionieren dann nur keine Low-/Full-Speed-Devices die direkt am Host (ohne Hub dazwischen) angeschlossen sind. Hinter dem ersten Hub (falls man diese Split-Transactions unterstützt, was die USB 2 Spec ja eh verlangt) funktioniert dann trotzdem alles.
XanClic schrieb:
Das wird vermutlich praktisch funktionieren,
Es funktioniert angeblich mit allen relevanten OS.
XanClic schrieb:
aber ist nicht USB-2.0-konform.
Nein, die USB-Spec sagt nichts über den Host-Controller. Ich kann mir auch nen völlig neuen Host-Controller entwickeln der direkt angeschlossene Low-/Full-Speed-Devices auch auf neue Art integriert und verstoße damit nicht gegen die USB-Spec.
XanClic schrieb:
Da müsste Intel erstmal USB 2.1 oder so rausbringen, in der definiert ist, dass es keine Companion Controller gibt.
Das müsste wenn dann in der EHCI-Spec stehen. Trotzdem bin ich davon überzeugt das man diesen Trick hinbekommt ohne irgendeine software-sichtbare Änderung an USB oder EHCI vornehmen zu müssen.
Grüße
Erik
-
OK, ich hab mir jetzt mal die EHCI-Spec runtergeladen und da steht tatsächlich:
Spezifikation schrieb:
A USB 2.0 Host Controller includes one high-speed mode host controller and 0 or more USB 1.1 host controllers (see Figure 1-2). The high-speed host controller implements an EHCI interface. It is used for all high-speed communications to high-speed-mode devices connected to the root ports of the USB 2.0 host controller. This specification allows communications to Full- and Low-speed devices connected to the root ports of the USB 2.0 host controller to be provided by companion USB 1.1 host controllers. If an implementation does not include companion host controllers, the host controller must include a high-speed device permanently attached to each of the EHCI ports the implementation is planning to utilize. The EHCI controller cannot work with a Full- or Low-speed device.
Also muss ich mich geschlagen geben.
Das Problem ist aber auch: Um zu dieser Spezfikation kompatibel zu sein, muss man Companion Controller unterstützen ("includes [...] 0 or more USB 1.1 host controllers").
Somit muss man alle drei Host Controller unterstützen, um voll kompatibel zu sein, und kann sich nicht darauf verlassen, dass der EHCI einen Hub benutzt, um mit Low- und Full-Speed-Geräten zu kommunizieren.
-
Hallo,
XanClic schrieb:
Somit muss man alle drei Host Controller unterstützen, um voll kompatibel zu sein, und kann sich nicht darauf verlassen, dass der EHCI einen Hub benutzt, um mit Low- und Full-Speed-Geräten zu kommunizieren.
Da hast Du zwar recht aber mein Vorschlag ist ja eben nicht voll kompatibel zu allen USB-Geräten zu sein sondern nur zu den High-Speed-Geräten (alle Mass-Storage-Devices sind High-Speed) und eventuelle Kompatibilität zu Low-/Full-Speed gibt es dann nur hinter einem externen Hub. Das ist zwar eine Einschränkung (außer bei neuen Intel-Chipsätzen, andere Hersteller folgen vielleicht) aber mit der kann man IMHO gut leben wenn es vorrangig nur um Mass-Storage-Devices geht.
Grüße
Erik
-
Hallo,
@XanClic:
Ich hab mal etwas wegen USB 2 µC-Board gesucht.Der LPC2888 von NXP gefällt mir sehr gut. http://www.nxp.com/pip/LPC2880_LPC2888.html Für den UART kann der DMA so das man auch große Logging-Daten ohne viel CPU-Arbeit senden kann.
Von Olimex gibt es ein interessantes Board dazu. http://www.olimex.com/dev/lpc-h2888.html Das braucht nichts weiter als das USB-Kabel und ein RS232-Kabel + Pegel-Umsetzer (MAX232) als Debug-Schnittstelle zum PC. Selbst die Firmware kann man per USB reinladen (der Boot-Loader kann sich als spezielles USB-Device melden und ein spezieller Treiber schickt dann die Firmware).
Da der LPC2888 High-Speed kann und das Olimex-Board 32MByte-SDRAM hat könnte man damit als Übungssystem ein USB-Stick mit 24MB simulieren und hätte ein Mass-Storage-Device das jegliche USB-Kommunikation zum Logging an den PC schickt. Mit so einer Basis könnte man die Entwicklung des USB-Stack vom Host-Controller-Treiber bis zum generischen Mass-Storage-Treiber komplett unterstützen, man macht einfach so lange bis das Log-File vom eigenen System genau so aussieht wie das von Linux/Windows.Ich weiß das für solches Spielzeug über 100 Euronen fällig sind aber deutlich billiger wird man ein µC-Board in der Klasse kaum finden. Ich schau trotzdem mal ob ich noch was finde wo auch die RS232-Schnittstelle schon fertig drauf ist.
Grüße
Erik
-
Vielen Dank für die Suche!
Ich schaus mir mal an, mal sehen, wie weit ich bis zu meinem Geburtstag komme.
-
Hallo,
XanClic schrieb:
mal sehen, wie weit ich bis zu meinem Geburtstag
Wann ist denn der?
Ein richtiges Board mit ordentlichem RS232 hab ich noch nicht gefunden, hatte heute kaum Zeit.
Falls man nen RS232-Pegel-Umsetzer selber bauen müsste, wie fit bist Du am Lötkolben?
Ich würde auch gerne ein Board für den LPC2888 selber entwickeln aber das BGA-Gehäuse kann man nicht händisch löten und nen Reflow-Ofen aus einer alten Fritöse frickeln will ich auch nicht.Grüße
Erik
-
Vielleicht sollten wir noch eine Hardware-Ecke aufmachen?
