Sourcecode Fortschritt


  • Mod

    0.0.5.57 - Rev: 1723

    webcam daten erfassung weiter optimiert. TODO: warum lücken? wieso so langsam?


  • Mod

    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.


  • Mod

    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?)


  • Mod

    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


  • Mod

    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.


  • Mod

    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.


  • Mod

    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.


  • Mod

    0.0.5.64 - Rev: 1730

    Webcam-Erfassung noch etwas korrigiert.

    http://henkessoft.de/Sonstiges/webcam4.png


  • Mod

    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


  • Mod

    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


  • Mod

    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


  • Mod

    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


  • Mod

    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


  • Mod

    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 )


  • Mod

    0.0.5.72 - Rev: 1738

    An der zeitschleife im periodic scheduler gedreht (experimentell)
    Für ein iTD benötigt man ca. 2-3 ms

    Mehr Fragen als Antworten z.Z.

    Bild: http://henkessoft.de/Sonstiges/webcam7_camblack.gif
    ser. Log: http://codepad.org/tGFcqod3


  • Mod

    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.


  • Mod

    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 verbessert

    Bildergebnis: 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


  • Mod

    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.


Anmelden zum Antworten