Sourcecode Fortschritt


  • 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.



  • 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


  • Mod

    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.


Anmelden zum Antworten