Sourcecode Fortschritt
-
Version 0.0.5.56:
- OHCI: Implementation von Interrupt-Transfers (ungetestet); Behandlung von head/tail-Pointern an Spezifikation angepasst
- Heap: HEAP_CONTINUOUS implementiert und in diversen Treibern eingesetzt
- Heap: Optimierung: Speichern von erster freier Region
- devmgr: Anzeige von Geräteklassen verbessert
- prettyos.cfg erweitert
-
0.0.5.57 - Rev: 1723
webcam daten erfassung weiter optimiert. TODO: warum lücken? wieso so langsam?
-
0.0.5.58 - Rev: 1724
Webcam Datenerfassung weiter optimiert. Nun kommen schon recht gute Datenmengen an, die Lücken nehmen ab. Geschwindigkeit ist nach wie vor langsam. Es wird auf den USBINT und auf ACTIVE-Bit == 0 gewartet.
-
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
