Sourcecode Fortschritt
-
0.0.5.59 - Rev: 1725
- Webcam-Daten werden bereits rasch übertragen (30 iTD verteilt auf die periodic list im Abstand 34)
- YUV-Rohdaten enthalten noch Lücken (Nullen), die über ein Cleaning-Programm entfernt werden (beide Dateien werden gespeichert)
- Header werden gesucht und angezeigt (Sortierhilfen?)
- Die Bilddaten kommen in Streifen an, die noch falsch geordnet sind ("Überrennen" von iTDs, die dann in einem späteren frame dran kommen, dadurch kommen die Datenpakete unzusammenhängend an)TODO: Sequentieller Empfang (wie?) oder Sortierung (SRC-Daten sind vorhanden, also innere Webcam-Uhr?)
-
0.0.5.60 - Rev: 1726
Webcam-Datenübertragung:
- Fähigkeiten zur Auslösung eines Still Images eingefügt (STI Bit im Payload Header wird gesetzt).
- Erster Ansatz zur Erfassung des Still Images (sondert noch zu viele Daten aus)TODO: Idealen Aufbau für die periodic list und optimale Video-Parameter finden
-
0.0.5.61 - Rev: 1727
usb-webcam: Beim Einhängen in die periodic list bei ehci wird Isochronous Scheduling Threshold berücksichtigt. Damit gelingt eine geordnete Abfolge der Payload Header.
-
0.0.5.62 - Rev: 1728 (ckernel: versehentlich noch 0.0.5.61 u. 1727)
Webcam-Datenerfassung optimiert durch Einhängen der iTD kurz über FRINDEX. Damit bleibt der 1-sec-Abwarteeffekt (wenn man unter anstelle über FRINDEX einhängt) beim Platzieren an eine bestimmte Position aus! Test mit 1024 iTD rast Vollgas durch. Zum Schluss gibt es allerdings im Test nur noch wenige freie Löcher (noch kein Abräumen).
TODO: Einhängen/Auslesen/Löschen optimieren
Alternative: Der von supernicky favorisierte QH-Netzwerk-Link-Ansatz mit QH 256/128/64/32/16/8/4/2/1 ms (bekannt vom interrupt-Transfer), dort entfällt das Besetzungsmanagement (freie Positionen suchen, iTD abräumen) direkt an der Liste. Was besser ist, kann man z.Z. noch nicht sagen. Beides könnte funktionieren.
-
0.0.5.63 - Rev: 1729
Thema webcam weiter verfolgt - Videostreaming-Daten können noch nicht in wirklich größeren Blöcken zusammenhängend empfangen werden (VBox). Hierfür fehlt noch die zündende Idee.
-
0.0.5.64 - Rev: 1730
Webcam-Erfassung noch etwas korrigiert.
-
0.0.5.65 - Rev: 1731
- Webcam-Datenerfassung weiter verfeinert (Bilddarstellung gelingt bei mir wegen vbe-Problem nur extern)
- webcam-Datenerfassung: Ausgabe der video- und iTD-spezifischen Details nach serial_log (funktioniert bisher bei Emulatoren wie VBox oder vmware)
Beispiel: http://codepad.org/E2Z2tvi2
-
0.0.5.66 - Rev: 1732
- Webcam Videostreaming-Datenerfassung umgestellt auf eine iTD-chain, die jede ms vom periodic schuler getriggert wird.
- Die wesentlichen Daten werden per serial_log erfasst
-
0.0.5.67 - Rev: 1733
Fehler im periodic scheduler behoben (last iTD war eins zu hoch, damit wurde das active bit falsch bestimmt)
Als experimentelle Basis für die Videodatenerfassung erscheint diese Version nun als Ausgangspunkt geeignet.
Bsp. serial log: http://codepad.org/O2eChaab
-
0.0.5.68 - Rev: 1734
Diese Version bereinigt die von Nullen gereinigte Version nun auch um die 12-Byte-Payload-Header. Man erhält vier YUYV-Files im 4:2:2-Format: Raw (alle Transfers, auch die leeren), Cleaned (ohne Nullen, im Viererpack gelöscht, noch mit Header für Analyse), videodat.yuv (ohne Header) und selektiv die Still-Image-Daten (mit STI bit, noch mit Headern).
-
Version 0.0.5.69:
- USB: *_issueTransfer in drei Funktionen aufgeteilt: *_scheduleTransfer, *_waitForTransfer und *_destructTransfer
- USB: Sinnvollen Einsatz von Interrupt-Transfers vorbereitet
- Paging: Neuimplementation weiter vorbereitet
- editor.cpp: Unterstützung von hexadezimaler Ausgabe
- saveYUYV() nach usb_video.c verschoben
- devicemanager.c: Sinnlose sleeps entfernt
-
0.0.5.70 - Rev: 1736
webcam:
- Interlaced/Progressive wird nun abgefragt (beides wurde im Originalzustand bisher gesehen) und wie gewünscht (z.Z. Progressive) gesetzt
-
0.0.5.71 - Rev: 1737
- Clock frequency wird jetzt korrekt ausgelesen/gespeichert aus dem VC header (typisch: 30 MHz oder 48 MHz, diese bezieht sich auf das Delta der Uhrzeitstempel in den Payload Headern )
-
0.0.5.72 - Rev: 1738
An der zeitschleife im periodic scheduler gedreht (experimentell)
Für ein iTD benötigt man ca. 2-3 msMehr Fragen als Antworten z.Z.
Bild: http://henkessoft.de/Sonstiges/webcam7_camblack.gif
ser. Log: http://codepad.org/tGFcqod3
-
0.0.5.73 - Rev: 1739
IOC auf den letzten iTD->tsc der iTD-Kette gelegt und damit aus der Warteschleife beim Periodic Scheduler gesprungen.
-
0.0.5.74 - Rev: 1740
webcam-Datenerfassung:
- isochronous Transfer im usb-Bereich weiter korrigiert
- aus clamped-length system heraus genommen
- Kopieren nur bei IN-Transaction
- ser log bei der webcam weiter verbessertBildergebnis: nach wie vor "zerstückelt"
-
Version 0.0.5.75:
- USB: usb_hid_t, usb_msd_t und usb_video_t in usb_interface_t::data (statt usb_device_t::data) gespeichert
- USB: Callback-Mechanismus für Interrupt-Transfers implementiert
- USB-HID: Maustreiber; Anzeige der Rohdaten von der Tastatur
- OHCI: Periodic-List aktiviert, Frequenz von 4ms für Interrupt-Transfers
-
0.0.5.76 - Rev: 1742
Zwischenstand der Fehlerbehebung bei usb auf Hardware:
Reparatur der Fehler, die sich bei dem usb-Umbau (rev. 1698 -> 1699) einschlichen, sowie von Schwächen in xhci. Diese wirkten sich ab rev. 1698 auf Hardware im usb-Bereich aus.
- IN/OUT-Verwechslung behoben in usb_controlSet (korrekt ist IN)
- xhci.c: zur Portbestimmung wird dort notgedrungen uint8_t portNr = (uint8_t)(size_t)((hc_port_t)transfer->device->port->data)->data;* verwendet. Diese Information wurde nun in usb_hc.c in hc_setupUSBDevice mittels port->data = (void)(uintptr_t)(portNumber+1);* übergeben. Damit gelingt die Kommunikation zwischen usb und xhci.
- xhci.c: in xhci_waitForTransfer muss bei SET_ADDRESS ebenfalls sofort ausgestiegen werden. Nun erledigt.TODO bei xhci (bekannte Baustelle): Kritisch ist noch die Verwendung von Hub-Ports (usb_hc.c, zeile 310).
TODO: vbe steigt mit #PF (verschiedene Varianten) aus (test-PC und VBox) (bekannte Baustelle)
Mit dieser Version können nun wieder ehci- u. xhci-Ports mit usb-Sticks verwendet werden.
-
Version 0.0.5.77:
- USB-Tastaturtreiber implementiert
- USB: Auslesen des Config Descriptors in zwei Schritten (Anfordern von 1024 Bytes scheitert bei UHCI)
- USB: Ausgaben gekürzt und verbessert
- Code in array_resize_ vereinfacht
-
Test: 0.0.5.77 - Rev: 1743 usb: xhci: devmgr.elf load and execute Einbinden usb-stick nicht OK, #PF: usb_getConfigDescriptor --> ... --> xhci_waitForTransfer save screenshot -> floppy and usb-stick n/a ehci: devmgr.elf load and execute OK save screenshot -> floppy and usb-stick OK uhci (test-PC): devmgr.elf load and execute portchange OK, dev no response/stalled (kein Einbinden) save screenshot -> usb-stick usb-stick: n/a ohci (VBox): devmgr.elf load and execute usb-stick wird beim Andocken (VBox) von ohci nicht erkannt save screenshot -> usb-stick n/a ehci (VBox): devmgr.elf load and execute OK save screenshot -> floppy and usb-stick OK ehci (Vbox): webcam OK save big files OK vbe: 1 - start graphical tests VBox: #PF (eip 152h), test-PC: #PF (addr 3400, eip 9051, user mode) user: shell prüfen, neue shell erstellen OK test.elf ausführen VBox: OK (Grafik, neue Konsole geht nicht) networking: browser.elf with prettyos.de, google.de ... browser.elf geht, usability bei files, etc. unklar (verbessern!)Untersuchungen: Das Problem bei xhci ist offensichtlich ein Timing-Problem, denn beim Einbau von Haltepunkten (zur Analyse) wurde der usb-stick sauber eingehängt.
