Hi, da mir das nicht klar ist und ich nichts im Forum fand meine Frage: Wie funktioniert das mit Linux und DSPs? Nehmen wir mal die VIP1710: So stelle ich mir das vor:... Richtig? Hardware: Ein TMS320DM642 ist ueber PCI angebunden. Software: Linux-->Kernel-->Module... Woher weiss Linux das es zu en-/decodierende Videodaten zum DSP-Module schicken muss? Beim laden des Modules wird dem DSP ein "Programm" geflashed (z.B. H264 codec). Im Module werden die Videodaten ueber PCI zum DSP geschickt. Dieser hat dann die Daten im Empfangsbuffer liegen. Auf dem DSP laeuft ein "Programm" (z.B. H264 codec). Der DSP nimmt Daten aus dem Empfangsbuffer, verarbeitet sie und packt sie danach in den Sendebuffer. Das Module holt sich die Daten aus dem Sendebuffer. Richtig? Woher weiss Linux das die Daten des Modules angezeigt werden muessen? Tschuess muebau
Gast
#2298104
Üblicherweise verwaltet Linux seine Treiberschnittstellen unterhalb des /dev -Verzeichnisbaums. Darin finden alle Gerätetreiber ihren Platz, indem sie sich an "ihre" Device-Datei anhängen (z.B. /dev/dsp). Schickt die Applikation nun Daten in die Device-Datei (schreibender Zugriff auf die Datei), werden diese direkt zum dahinter liegenden Treiber und damit z.B. direkt in den DSP bzw. einen vorgelagerten Puffer gesendet. Ist der DSP fertig mit seiner Arbeit, liegen die verarbeiteten Daten üblicherweise wieder an dieser Gerätedatei an und ein lesender Zugriff der Applikation befördert die Ergebnisse zu tage. So ist zumindest das Prinzip.
Gast
#2298125
Nochmal genauer: Jeder Treiber bzw. Modul registriert sich im System für ein bestimmtes Gerät mit entsprechender Geräteadresse im System und stellt seine Schnittstelle in Form der Gerätedatei zur Verfügung. D.h. die Gerätedatei ist über den Treiber direkt mit dem jeweiligen Gerät verbunden (z.B. /dev/ttyS0 ... /dev/bus/usb/...) Beu Zugriffen auf die Gerätedatei wird vom Treiber die entsprechende Aktion ausgeführt, wie z.B. in den DSP-Puffer schreiben oder daraus lesen. Eigentlich nicht sonderlich kompliziert, wenn man sich mal damit befasst hat. Ein guter Einstieg ist hier zu finden: Linux Device Drivers, Third Edition http://oreilly.com/catalog/linuxdrive3/book/index.csp @Oktanzahl Wieso sollte das nicht möglich sein? Fridolin fragte ja nach meinem Verständnis nur nach der Übergabe durch den Treiber an das Gerät, oder habe ich das falsch verstanden? --> Wieso ist denn der beitrag von 'Oktanzahl' jetzt gelöscht worden? Da war doch nichts schlimmes dran??
>Darin finden alle Gerätetreiber ihren Platz, >indem sie sich an "ihre" Device-Datei anhängen Nein. Schau in /sys nach, dort sind wirklich alle Treiber vertreten. Wenn du wissen willst, wie ein Treiber gestrickt ist, kannst du die Quelldatei aufmachen und oben im Kommentar schauen wo die Dokumentation dazu ist. Meistens im Kernel-Quellcode unter "doc/", dort dann nach Kategorien sortiert.
Hi, danke fuer dir Antworten. Nun soweit war mir das klar (bzw. wurde mir klar als ich es mal niedergeschrieben habe). Nur woher kann z.B. ffmpeg wissen das es die Berechnung eines h264 Videos nicht auf der CPU machen soll sondern den Weg ueber ein
1 | |
.... machen soll. Tschuess muebau
Gast
#2298366
Das müßte in der jeweiligen Config des Programms festgelegt sein bzw. gibst du das ffmpeg als Option mit. Kann natürlich auch in Pipe-Orgien münden à la "cat video > /dev/dsp_1 | ffmpeg -i /dev/dsp_2 /tmp/outputvideo" oder schlimmer ;-) Oder ffmpeg müßte explizit für die Verwendung des DSP umgeschrieben und neu kompiliert werden. Vermutlich wird das mit ffmpeg aber nicht so einfach funktionieren, weil es offenbar nicht für diesen Zweck wie von dir angepeilt gemacht ist. Wird also darauf hinaus laufen, selbst was zu schreiben :-(
helferlein schrieb: > Das müßte in der jeweiligen Config des Programms festgelegt sein bzw. > gibst du das ffmpeg als Option mit. Ach so jetzt verstehe ich das. Bis jetzt hatte ich angenommen, dass Linux bei vorhandenem DSP diesen nutzen würde. Vielen Dank Tschüss muebau
Gast
#2299397
Um Missverständnissen durch Linux-Unkundige vorzugreifen: /dev/dsp ist eine PCM-Audio-Schnittstelle und hat nichts mit DSP-Entwicklungsboards zu tun.
Gast
#2301547
rackandboneman schrieb:
> /dev/dsp ist eine PCM-Audio-Schnittstelle
Ja, das stimmt. Aber um den Zusammenhang herzustellen habe ich es nur
beispielhaft angeführt. Dies ist tatsächlich der von Linux standardmäßig
vorgesehene Zugriff auf die Audio-Schnittstelle.
Eventuelle weitere DSPs im System werden sich hinter anderen Devicenamen
verbergen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.