Ziel: USB-Treiber
-
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?
-
erik.vikinger schrieb:
XanClic schrieb:
mal sehen, wie weit ich bis zu meinem Geburtstag
Wann ist denn der?
Mitte April.
erik.vikinger schrieb:
Falls man nen RS232-Pegel-Umsetzer selber bauen müsste, wie fit bist Du am Lötkolben?
*hust*
Ähm, mal in der vierten Klasse einen in der Hand gehabt...
-
Hallo,
XanClic schrieb:
erik.vikinger schrieb:
Falls man nen RS232-Pegel-Umsetzer selber bauen müsste, wie fit bist Du am Lötkolben?
*hust*
Ähm, mal in der vierten Klasse einen in der Hand gehabt...
also erst im gerade vergangenen ersten Halbjahr
das ist ja noch ziemlich frisch 
Im Ernst, falls sich kein gescheites Board finden lässt und Du möchtest mach ich was passendes fertig.
Ich hab mal hier http://www.mikrocontroller.net/topic/168335 eine Anfrage gestellt.Erhard Henkes schrieb:
Vielleicht sollten wir noch eine Hardware-Ecke aufmachen?
Für welches Thema genau?
Grüße
Erik
-
erik.vikinger schrieb:
Im Ernst, falls sich kein gescheites Board finden lässt und Du möchtest mach ich was passendes fertig.
Ich hab mal hier http://www.mikrocontroller.net/topic/168335 eine Anfrage gestellt.Wie gesagt, Zeit hats schon noch.
Aber wirklich ganz großen Dank für die Mühen, die du auf dich nimmst bzw. auf dich zu nehmen bereit bist.
-
Hallo,
XanClic schrieb:
Aber wirklich ganz großen Dank für die Mühen, die du auf dich nimmst bzw. auf dich zu nehmen bereit bist.
Blos nicht falsch verstehen, wenn ich mit meinem Projekt an dieser Stelle bin würde ich mich gerne ins gemachte Nest setzen (also den fertigen Quell-Code für den "Debug-USB-Stick" und viel Erfahrung übernehmen). Ganz uneigennützig bin auch ich nicht.
Den Lötkolben nehme ich beruflich zur Zeit leider nur selten in die Hand (FPGAs haben auch BGA-Behausungen) so das ich einfach mal wieder etwas sinnvolle Übung haben möchte.Grüße
Erik
-
Dann bin ich ja beruhigt.
-
Hallo,
Als Entwicklungs-Board mit dem LPC2888 hab ich nur noch das http://www.icetech.com/emularm/lpc2880_board.html gefunden. Dieses Board ist zwar umfangreich ausgestattet (viel zu umfangreich und trotzdem fehlt es an DRAM, es benötigt auch immer ein Netzteil da es sich nicht per USB versorgen lässt) aber der Preis ist schlicht indiskutabel.
Für vertretbares Geld scheint es wirklich nur das Olimex-Board zu geben. Wenn Du das wirklich machen möchtest sag mir bitte rechtzeitig bescheid, den fehlenden RS232-Anschluss kannst Du dann von mir haben.Ich hab auch mal nach anderen µC mit High-Speed-USB-Device geschaut aber da gibt es sonst fast nur größere ARM9-CPUs die z.B. Ethernet mitbringen und eben auch nur auf reichlich bestückten und entsprechend teuren Boards zu haben sind, nebst dessen das schon der µC an sich mehr Geld kostet (ein ARM9 fällt eher in die Klasse Pentium I mit >100MHz, wogegen der ältere ARM7-Kern eher mit nem 486-50MHz zu vergleichen ist und auch deutlich weniger Lizenzgebühren an ARM fließen). Am Wochenende klappere ich mal noch die anderen üblichen Verdächtigen (auch abseits der ARM-Lizenz-Nehmer) ab ob sich eventuell doch noch ein anderer interessanter µC auf einem adäquatem Board finden lässt.
Gerade im Hinblick auf Mass-Storage bin ich wirklich der Meinung das Full-Speed nicht in Frage kommt, oder bist Du da anderer Meinung? Ich denke das die Beschränkung auf EHCI ein sinnvoller Schritt ist um möglichst schnell ein möglichst gutes Ergebnis zu erzielen. Trotzdem unterstützen die USB 2 Devices in den µC auch immer noch Full-Speed.
Hierzu währe sicher auch die Meinung von Erhard interessant.Grüße
Erik
-
erik.vikinger schrieb:
... aber der Preis ist schlicht indiskutabel.
Als FPGA Entwickler solltest Du dich ja von solchen Preisen nicht abschrecken lassen
-
Ich denke das die Beschränkung auf EHCI ein sinnvoller Schritt ist, um möglichst schnell ein möglichst gutes Ergebnis zu erzielen.
Ja, das wäre super, wenn das ginge. Am Netzwerk sind wir ja auch schon heftig dran.
-
erik.vikinger schrieb:
Gerade im Hinblick auf Mass-Storage bin ich wirklich der Meinung das Full-Speed nicht in Frage kommt, oder bist Du da anderer Meinung?
Bisher bin ich da noch ziemlich anderer Meinung.
Ich möchte USB erstmal zum Laufen bekommen, dann kann ich immer noch daran arbeiten, es schnell zu machen.abc.w schrieb:
Als FPGA Entwickler solltest Du dich ja von solchen Preisen nicht abschrecken lassen
Ich bin aber keiner.
Erhard Henkes schrieb:
Ja, das wäre super, wenn das ginge. Am Netzwerk sind wir ja auch schon heftig dran.
Netzwerk ist ja auch was anderes und meiner Meinung nach (aus Erfahrung) um einiges einfacher.
-
Hallo,
XanClic schrieb:
Ich möchte USB erstmal zum Laufen bekommen, dann kann ich immer noch daran arbeiten, es schnell zu machen.
Dafür musst Du mindestens 2 unterschiedliche Host-Controller-Treiber schreiben und der Umstieg von USB 1 auf USB 2 im Basis-Treiber (z.B. die 8 fache Frame-Häufigkeit) ist sicher auch nicht ohne. Ich persönlich bin der Meinung das man sich damit den Weg nur unnötig lang macht. Aber jedem das seine, ich hoffe ich kann Dir trotzdem helfen.
XanClic schrieb:
Netzwerk ist ja auch was anderes und meiner Meinung nach (aus Erfahrung) um einiges einfacher.
Oh ja, bei Netzwerk muss man nur senden und empfangen, Timing ist auch nicht ganz so wichtig.
abc.w schrieb:
Als FPGA Entwickler solltest Du dich ja von solchen Preisen nicht abschrecken lassen
In einer Firma gibt es da auch andere Kriterien. Wenn man das Board von einer Firma kauft wo man auch mal unkompliziert einen Application-Engineer ans Telefon bekommt der einem aus ner Klemme befreit für die man selber mal 2 Tage braucht dann hat sich das teurere Board schon fast bezahlt gemacht. Privat gibt es einfach ganz andere Prioritäten.
Außerdem gibt es auch preiswerte FPGA-Entwicklungs-Boards.Grüße
Erik
-
Zurück zum USB-Einstieg. Man fängt ja gemäß dem Stand der Diskussion wohl mit dem Host-Controller für EHCI an.
OK, ich hab mir jetzt mal die EHCI-Spec runtergeladen und da steht tatsächlich: A USB 2.0 Host Controller includes one high-speed mode host controller and 0 or more USB 1.1 host controllers ...
In Sun VirtualBox steht ja EHCI zur Verfügung. Da wir nun das ID Paging im MMIO-Bereich beherrschen, was sollte man da alles über die EHCI-USB-BaseAddress abfragen? Einiges haben wir ja während des PCI Scans beispielhaft dargestellt:
http://www.henkessoft.de/OS_Dev/Bilder/rev131.PNG
Was benötigen wir da alles an Infos?Links:
Um zu dieser Spezfikation kompatibel zu sein, muss man Companion Controller unterstützen
http://forum.osdev.org/viewtopic.php?f=1&t=21103&hilit=EHCI
http://wiki.osdev.org/index.php?title=Programming_the_EHCI <--- leider noch leer!
-
XanClic schrieb:
Netzwerk ist ja auch was anderes und meiner Meinung nach (aus Erfahrung) um einiges einfacher.
Schon mal einen TCP/IP Stack oder sowas wie PPP programmiert?
-
Ich habe mal in pci.c begonnen die wichtigsten Daten mittels der USB-Basis-Adresse heraus zu lesen, z.B. Adresse der Operational Registers (=Basis+CapLength) oder Vorhandensein von Extended Capabilities.
Ich denke, dass hier die "Musik" des Host-Controllers spielt:
OpRegs:
Offset Mnemonic Register-Name 00h USBCMD USB Command 04h USBSTS USB Status 08h USBINTR USB Interrupt Enable 0Ch FRINDEX USB Frame Index 10h CTRLDSSEGMENT 4G Segment Selector 14h PERIODICLISTBASE Frame List Base Address 18h ASYNCLISTADDR Current Asynchronous List Address Register 1C-3Fh (Reserved) 40h CONFIGFLAG Configure Flag Register 44h PORTSC(1-N_PORTS) Port Status/ControlUSB Command Register indicates the command to be executed by the serial bus host controller. Writing to the register causes a command to be executed.
USB Status Register indicates pending interrupts and various states of the Host Controller. The status resulting from a transaction on the serial bus is not indicated in this register. Software sets a bit to 0 in this register by
writing a 1 to it.
USB Interrupt Enable Register enables and disables reporting of the corresponding interrupt to the software. When a bit is set and the corresponding interrupt is active, an interrupt is generated to the host. Interrupt sources that are disabled in this register still appear in the USBSTS to allow the software to poll for events.
USB Frame Index Register is used by the host controller to index into the periodic frame list. The register updates every 125 microseconds (once each micro-frame). Bits [N:3] are used to select a particular entry in the Periodic
Frame List during periodic schedule execution.
Control Data Structure Segment Register allows the host software to locate all control data structures within the same 4 Gigabyte memory segment.
Periodic Frame List Base Address Register contains the beginning address of the Periodic Frame List in the system memory.
Current Asynchronous List Address Register contains the address of the next asynchronous queue head to be executed.
Configure Flag Register is only reset by hardware when the auxiliary power is initially applied or in response to a host controller reset.
Port Status and Control Register is only reset by hardware when the auxiliary power is initially applied or in response to a host controller reset.Sehe ich das richtig?
