Hallo zusammen, ich habe einige Fragen, ich verfolge das folgende Ziel : Problemstellung 1: Ich möchte Daten aus einer DVI - Schnittstelle des Computers aufnehmen das Frame (Bild) bearbeiten (z.b. jeden Pixel um eine Stufe heller setzen oder an eine andere Position) und dann an den Monitor weitergeben. Nun wurde mir ein ARM Controller als Leistungsstark "verkauft". Ich habe bereits gelesen, dass der LPC2106 beim Toggeln eines PortPins nicht besonders schnell ist, somit ist der Controller nicht für mein "End-Ziel" gedacht. Frage 1: Wäre dieser Controller aber eine Basis (da andere ARM Controller ähnlich arbeiten nur viel schneller) oder muss/soll ich mich lieber mit einem DSP wie dem TigerShark beschäftigen (meine Vermutung)? Problemstellung 2: Als Leitfaden zu meinem Durchbruch in ARM-Bereich dient die Lektüre ARM Cross Development with Eclipse. Hier können nicht alle meine Fragenbeantwortet werden, da kann mir das Forum aber sicherlich helfen. Frage 2: Gibt es eine elegantere Methode mit der ARM - Programmierung anzufangen? So ich denke . Ich habe genug Probleme für diese Stunde  Für jede Stellungnahme bin ich Dankbar.
Das ist mit einem LPC2106 nicht zu schaffen. Auch nicht mit anderen vergleichbaren ARMen. Bedenke einfach mal die Datenrate, die an einer DVI-Schnittstelle herrscht (hinter dem TMDS-Receiver) - da werden 24-Bit-Datenworte mit dem Pixeltakt des jeweiligen Graphikmodus übertragen. Und der liegt bereits bei Standard-VGA-Auflösung (640x480) bei über 30 MHz. Bei den interessanteren Auflösungen XGA (1024x768) oder SXGA (1280x1024) liegt der Pixeltakt bei etwa 50 bzw. etwa 80 MHz. Das sind Datenraten, für die schon ein sehr schneller DSP oder aber entsprechend programmierte Hardware (FPGA/CPLD) erforderlich ist. Die Einzeldatenwordbearbeitung (Helligkeit verändern) wäre so realisierbar. Eine Zwischenspeicherung, die zum Verschieben von Bildinhalten erforderlich wäre, steigert die Komplexität des ganzen erheblich - Du musst einen entsprechend schnellen Zwischenspeicher haben, den Du mit dem Pixeltakt beschreiben und simultan mit dem Pixeltakt wieder (an anderen Adressen) auslesen kannst. Damit muss ein kompletter Zugriffszyklus auf diesen Speicher also doppelt so schnell wie ein Pixeltakt sein. Dazu kommen noch die üblichen Verzögerungszeiten Deiner Elektronik - Du brauchst also Speicher mit einer Speicherbandbreite von etwa 200 Megazugriffen pro Sekunde. SDRAM etc. eignet sich hierfür nicht, da dieser Speicher auf lineares Lesen innerhalb von Speicherblöcken optimiert ist - Du aber willst wechselweise an unterschiedlichen Adressen schreiben und lesen. Daher ist statischer Speicher naheliegend, und dessen Zugriffszeit sollte unter 5 nsec liegen (um die geforderten 200 Megazugriffe je Sekunde hinzubekommen). Davon benötigst Du dann -je nach Bildschirmauflösung- einige Megabyte (knapp 4 bei SXGA). Das Vorgaukeln eines Monitors, das Deine Graphikkarte benötigt, damit sie überhaupt ein Signal auf ihrem DVI-Anschluss ausgibt, dürfte durch Kopieren des DDC-EEPROMs Deines bestehenden Monitors zu erledigen sein, dann stimmt wenigstens auch das Timing mit dem gewünschten überein. TMDS-Receiverbausteine musst Du Dir auch noch besorgen (sowas willst Du Dir nicht selberbauen), aber auch das dürfte noch lösbar sein. Was ist der Zweck der Anwendung? Es gibt Graphikkartentreiber, die eine globale Helligkeits-/Kontrastanpassung ermöglichen, das dürfte etwas weniger aufwendig sein ...
@alfsch: ja, ich weiss dass es kein Kinderspiel ist. @Rufus: vielen Dank für deine Antwort; also ich bin im 2 Sem. Elektrotechnik nun programmiere ich aber seit ein paar jahren "leider nur" 8051 Mikrocontroller. Jetzt habe ich einen Prof. auf der FH kennen gelernt der dass Fach "Mikrocontroller" unterrichtet, ich habe ihm von meiner Idee berichtet und er fand es sei eine komplexe aber sehr nette idee. Meine Idee ^^ : Meine Diplomarbeit soll die Entwicklung einer LED-Videowand werden. Ich habe zwar noch ne Paar Semester, aber die Aufgabe ist ja nicht gerade einfach also früh anfangen und vorbereiten damit es dann fluppt :) (Jetzt bitte keinen Post über die Kosten der LED's etc... ich bin mir darüber im klaren). Ziel 1: Das erste Ziel sollte es sein ich sag mal eine BMP bild zu decodieren und auf eine LED wand bringen. Ziel 2: Auf dieser LED Wand werden Variablen plaziert und ein BMP als Maske verwendet. Bit manipulationen. Ziel 3 - 4: Schnellere "Bit manipulation" und auslesen der DVI. Und dann bin ich hoffentlich fertig. Jetzt an alle die direkt mit den ganzen problemen ankommen. Ich bin mir im klaren dass es nicht einfach ist, deshalb fange ich so früh an. Hört sich doch interessant an oder :) Mfg
Hallo Marek! Ich würde die Videoleinwand an deiner Stelle aus kleinen Modulen mit z.B. 32x32 Bildpunkten aufbauen und diese dann über ein schnelles Netzwerk, wie z.B. Ethernet, ansteuern. So kannst Du erstmal klein anfangen und später die Auflösung durch hinzufügen weiterer Module praktisch beliebig erweitern und defekte Module einfach austauschen. Mit der DVI-Schnittstelle dürfte so etwas nur schwer zu realisieren sein. Gruß Thorsten
Hi Thorsten, Ja ich werde die Vieowand aufteilen müssen. Da du ethernet als ansteuerung nennst.... ist es nicht schwerer einen "video stream", an die Anzeige zu bringen als direkte daten( von der div bzw. vga) ? Gruß Marek
Ich denke mal ein UDP-Stream der die Bilddaten anliefert ist sicher die einfachste (und am Ende auch einfach von jedem Laptop ansteuerbar) Lösung,für Netzwerk gibt´s schon etliche fertige ICs oder auch für grössere Controller entsprechende Software-Libs. Die Ansteuerung der LEDs würde der Controller nach dekodierung des mpeg-streams (auch dafür gibt´s libs) übernehmen.Interessant würd auf jedenfall die Stromversorgung des ganzen...Mehrfarbige Low-Power LEDs in grösseren Stückzahlen,da geht einiges an Strom durch....
hmmm irgendwie kann ich mir dass mit dem UDP nicht vorstellen gibt kannst du mir da die gennanten ic's mal nennen oder nen link posten. Vielen dank, .... hört sich interessant an.
Hallo Marek! Such Dir am besten einen µC mit integrierter Ethernetschnittstelle. Noch ein wenig Logik zur Ansteuerung der LEDs, Stromversorgung etc. dazu und fertig ist das Modul. Die einzelnen Module verbindest Du via Ethernet zu einem Netzwerk zusammen und steckst noch einen Steuerrechner dazu. Der Rest ist dann nur noch eine Frage der Software auf dem PC, welche die Bilddaten in Kacheln zerlegt und an die einzelnen Module schickt. Hört sich für mich jedenfalls deutlich machbarer an, als die DVI Signal zu zerpflücken und irgendwie auf die Module zu verteilen. Mit normalen µCs hast Du da keine Chance. Mit einem DSP oder FPGA könnte es vielleicht klappen, ist dann aber nicht so flexibel erweiterbar, wie die Ethernetlösung. Gruß Thorsten
habe mir nochmal gedanken dazu gemacht, mein problem war es, dass die UDP verbindung zu langsam sein könnte aber alleine wenn ich vnc aufmache und eine TCP verbindung zum benachbarten PC mache geht es "recht" schnell. Also wird es mit dem UDP wohl auch gehen. Hört sich gut an :)! Dann habe ich nur noch ein problem undzwar die daten welche auf dem screen sind mittels einer software an die anzeige bzw. die module zu senden. aber wenn der erste teil steht, wird dass andere auch gehen. Vielen Vielen dank, langsam schliessen sich alle lücken. Die frage ist nur welchen controller ich verwenden soll damit eine möglichst große fläche an led's abgedeckt wird. Dass RGB-Modul steht schon. Mom, nur mit 16 * 16 dot. Diese Steuer ich mit einem 8051 an. wenn ich einen schnellen controller verwende müste ich min. eine fläche von 16 * 64 dot hinbekommen. Nun die basic frage einen ARM oder DSP für diese aufgabe? Gibt es Erfahrungswerte ? Gruß Marek
> Dann habe ich nur noch ein problem undzwar die daten > welche auf dem screen sind mittels einer software an > die anzeige bzw. die module zu senden. Dafür hast Du im Satz vorher eine Lösung erwähnt: vnc. Zur Ansteuerung Deiner LEDs würde ich eine Hardwarelösung bevorzugen, die einen Speicherbaustein ausliest und dessen Inhalt an ebenjene LEDs ausgibt. Den Speicher beschreibt dann der Controller, der übers Netzwerk mit dem VNC-Server verbunden ist ... Die Hardware kann entweder "diskret" mit Zählbausteinen, Multiplexern, Schieberegistern und einem SRAM aufgebaut werden, oder aber in ein FPGA/CPLD (mit extern angeschlossenem SRAM) verpackt werden. Die Verwendung von VNC als Protokoll hätte mehrere Vorteile: Du musst die Serversoftware nicht mehr entwickeln und sie existiert für verschiedene Plattformen (Windows, *NIX, MacOs, wasauchimmer). So eine Herangehensweise halte ich jedenfalls für erfolgsversprechender als den Versuch, Daten an einer DVI-Schnittstelle abzugreifen ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.