Habe soeben ein LED Array gebastelt, welches Werte aus dem RAM im Nultiplexverfahren an das Array ausgibt. Momentan funktioniert das ganze über DMX und ist daher auf 512 Pixel beschränkt (bei Farbe um das 3fache weniger). Jetzt kommt mir die Idee, ein Videosignal (BAS, FBAS oder auch DVI oder VGA, Super Video??) auszuwerten (welches ist mir eigentlich egal, hauptsache es geht) und im RAM des uCs zu speichern. Es gibt wenige Themen hier, die um das ganze handeln, jedoch alles kompliziert. Ich bräuchte eigentlich nur 50x100 oder MAXIMAL!!! 200x300 Pixel, zum Anfang mal Schwarz/Weiß (also wahrscheinlich mit BAS anfangn) mit einer Widerholrate von zwischen 10 und den 25 Frames/Sekunde. Wenn das ganze im RAM gespeichert wird (Ram Adresse 0x0070 = Pixel links oben, RAM Adresse 0xXXXX = Pixel rechts unten) wäre ich absolut zufrieden. Es gibt AVR uCs, die 2k und 4kByte RAM haben. Somit wird man erst mal mit dem auskommen müssen und die Pixelanzahl an das anpassen. Hat wer einen Vorschlag oder auch nützliche IC's/Schaltungen, wie man ein normales Video in den Atmel bekommt?
Mein erster Gedanke ist, ffmpeg dazu zu verwenden, um Videodaten in ein "gäbiges" Format zu konvertieren. Habe ein ähnliches Bastelprojekt (LED Matrix, einfarbig, 4 Helligkeitsstufen), für das ich's auch gerne mal ausprobieren möchte. Also offline Videodaten aufbereiten, auf Speicherkarte schreiben und diese dann aufm AVR auslesen und ausgeben. Hab mir aber noch nicht durch das ffmpeg Manual und die Myriaden Codecs und Konfigurationsoptionen gekämpft. Wenn du damit etwas weiter kommst, lass uns teilhaben. :) Schönen Sonntag!
Ansatz wäre auch das Video mit mplayer in einzeldateien zu exportieren und dann mit ImageMagick die restlichen Bearbeitungsschritte auszuführen und die Rohdaten zu exportieren.
Ich weiß nicht ob es überlesen wurde oder einfach von mir unklar formuliert wurde: Es geht darum, da dran einen DVD Player oder sowas anzuschließen und diese Daten dann an das LED Array auszugeben. Daher kein ffmpeg und dergleichen vorhanden.
Mit den CPUs aus der ST20-Serie z.B. STM5516 kein Problem. MPG-Stream dekodieren und in den Arraypuffer blitten. Ein STM5516 hat dem AVR aber auch einen MPG-HW-Dekoder und einige MIPS voraus.
Ich denke, die Idee ist es auch nicht, einen MPEG STream zu dekodieren, sondern einen 'LED-Bildschirm' zu bauen, dem man ein BAS oder PAL Signal anbietet und das Gerät analysiert dann das Signal. Also Schwarzschulter rausholen, Zeilen zählen, Austastlücke auswerten u dgl. Da aber noch nicht einmal Grossmeister ELM-CHAN da was fertiges hat, denke ich, wird ein AVR du nur schwer mitkommen. Lass mich aber auch bekehren. Beim ELM-CHAN findet sich ein Gerät, welches aus einem Videosignal eine bestimmte Zeile ausfiltert und ein Triggersignal für diese Zeile für einen Oskar generiert. Hauptproblem wird wohl sein, das Farbsignal auszufiltern und nur das Schwarz/Weiß Signal übrig zu lassen. Da man vom Videosignal sowieso das meiste wegwirft, müsste man allerdings ausprobieren, ob man da mit dem Timing mitkommt.
Karl heinz Buchegger schrieb: > Also > Schwarzschulter rausholen, Zeilen zählen, Austastlücke auswerten u dgl. Das heißt man muss sich hier etwas in die thematik Videosignal einlesen (eh klar). Vorerst gehts nur um SW und da nicht die ganze PAL Auflösung sondern weit kleiner.
Für S/W wäre S-Video ganz gut, da hast du ja direkt das BAS-Signal für die reinen Helligkeitswerte. Reicht es dir, wenn du z.B. jede m-te Zeile mit jedem n-ten Bildpunkt ausgeben kannst oder willst du die Werte über ein m*n-Rechteck gerundet haben? Ersteres wäre deutlich einfacher.
So einfach wie möglich, also das erste. Die meisten DVD Player haben einen SVideo Anschluss. Sonnst kann man das - soweit ich gehört hab - mit Filtern trennen. Aber nehmen wir den einfachsten Fall an, dass man einfach jeden nten Bildpunkt in jeder nTen Zeile hernimmt und das ganze von einem SVideo aus - den Rest kann man ja dann immernoch erweitern. Lernen tut man aber dennoch aus einfachen Dingen am besten.
Michael Juen schrieb: > Lernen tut man aber dennoch aus einfachen Dingen am besten. In diesem Forum lernt man allerdings sehr schnell, dass Variationen des Satzes "Ich lerne am besten aus Beispielen" ein Pseudonym sind für 'Kann mir das mal wer machen' sind. Also: Was hast du denn bisher über dein Signal in Erfahrung gebracht, welchen Verlauf hat es, welche Information steckt in welchem Signalverlauf?
Mit einem (8-Bit-)AVR eine Auflösung 200x300-Bildpunkte zu erreichen ist illosorisch! Man kann vielleicht Standbilder ausgeben, aber kein Video "aufnehmen", um es anzuzeigen.
Ich würde eher sagen, dass der Bau einer ordentlichen 200x300 LED-Matrix das größere Problem ist. Wenn er beispielsweise nur 1 Bit pro Bildpunkt mit Hilfe eines Komparators aufnimmt, dann sind das gerade mal 1,5MBit pro Sekunde für den AVR, das sollte man noch hin bekommen, je nachdem wie die Matrix organisiert und angesteuert wird. Also er sollte sich erst einmal Gedanken über die Matrix machen, wie die realisiert wird, wie man ihr schnell die nötigen Daten ohne großen Aufwand übermitteln kann und die Sache mit dem BAS Signal kann dann beliebig vereinfacht werden, so dass ein AVR das auch schafft.
Das mit der Matrix funktioniert bereits. Dabei macht ein Atmega8515 genau 8x8 RGB Pixel. Reiht man mehrere dieser Arrays aneinander bekommt man dann die dementsprechende Auflösung. Das funktioniert bereits per DMX bestens und gibt auch seine "Videos" aus, jedoch per DMX Software. Ich hätte dann vor über ein eigenes Protokoll die Daten von diesem Bilddekoder an dieses einzelnen Arrays zu senden (so wie es eigentlich DMX ja auch schon macht).
Du hast also 900 Teilarrays mit je 8x8 Pixeln und je einem AVR? Das ist sportlich! Am besten benutze zur Kommunikation zwischen den AVRs einen Einweg-Bus der per Hardware auf dem Haupt-AVR zur Verfügung steht. Beispielsweise indem du alle Matrix AVRs parallel an eine RS232-Leitung hängst und dann in deinem Haupt-AVR einfach nur die Bytes in das RS232-Senderegister schreibst. Wenn du das versuchst über ein Software-Protokoll zu lösen, dann verbraucht das zu viel Zeit. Bei 200x300x1Bit und 25 Bildern / Sekunde muss dein Haupt-AVR 1,5 MBit pro Sekunde einlesen, in 8er Gruppen sammeln und dann z.B. in das RS232-Senderegister schieben. Du hast also so ca. 10 Assembler-Befehle pro Bit bei 16 MHz zur Verfügung. Das sollte genügen. Du musst dir dann nur noch Gedanken machen, wie du dein Haupt-AVR auf das BAS-Signal synchronisierst (Zeilen- und Bildsynchroninformationen aus dem Signal zurückgewinnen) und wie du deinen Matrix-AVRs mitteilst, welcher Matrix-AVR das gerade gesendete Byte entgegen nimmt. Das könnte man eventuell so machen, dass diese intern mitzählen wie viele Bytes gesendet wurden und dann eben nur das verarbeiten, was für sie relevant ist. Das ganze kann dann auch regelmäßig über einen Impuls synchronisiert werden.
Die schon vorhandenen Module haben 6x24 LED Kanäle, die per 64 Step PWM einzeln Dimmbar sind. Momentan halt auf DMX Basis, bei der die DMX Hardware schon am UART des ICs hängt - somit wäre das mit einem Firmwareupdate alleine umgestellt. DMX ist zwar nicht Bidirektional, aber man kann ja auf der Platine vor dem DMX Treiber schon auf RS232 abweichen, da sehe ich wenig Problem. Mit "Eigenem Protokoll" meine ich in der Art von DMX die Pakete mitzählen, die per UART reinkommen und jeder Chip nimmt sich dann seine raus oder so in der Art. Es geht mir hier wirklich nur um das, dass der Videocontrollerchip das Video in seinen Ram mit vorerst 1000 oder 1500 Pixeln/Bild einliest. Das ist dann vorerst eine Auflösung von rund 40x50 Pixeln (nichteinmal das). Ich hab nur absolute Probleme diese Analogtechnik zu verstehen und erhoffe mir (wie die Vorredner eh schon vermutet haben) ein wenig Hilfe ausm Forum (es gibt sicher schon Leute, die sich mit sowas gespielt haben und so schon Erfahrung gesammelt haben).
Der AVR dürfte überfordert sein. Die Zeilenfrequenz beträgt beim BAS Signal 15,625kHz, was erst mal kein Problem darstellt. Davon sind 52µs Bildinfo - bei 50 Pixel pro Zeile ist das 1µs pro Pixel. In den horizontalen Austastlücke hast du 12µs und in der vertikalen sogar 1,6ms für alles Mögliche. Und natürlich noch die 64µs all jener Zeilen aus denen du keine Pixel liest. Also reichlich Zeit. Die Frage ist es ob du in 1 µs dein Pixel in einen Digitalwert gewandelt und ggf in den AVR bekommst. Bei einem einzelnen Bit kein Problem. Bei externer Wandlung und einem hohen Takt kannst du bestimmt auch Bytes über ein Port einlesen und für die Weiterleitung vorbereiten. Willst du die 50 eingelesenen Bytes innerhalb einer Zeile wieder loswerden brauchst du bei einem UART mindestens 7,845 Megabaud. Bei 1 Bit (7 Byte) immer noch 1,1 MBaud. Verteilst du die Datenübertragung auf das gesamte Bild genügen 1 bzw. 0,125 MBaud. Eigentlich brauchst du etwas mehr, weil in irgendeiner Form noch zumindest ein Bildstart Signal eingebunden werden muss (selbst wenn es als Signallücke geschieht, kostet es Zeit). Wenn das ganze noch in ein Protokoll verpackt werden muss, steigt das Datenvolumen noch weiter an. Falls du Schwierigkeiten mit der Einlesegeschwindigkeit bekommst könnte man die Pixel versetzt einlesen. Da du nur etwa jede 8 Zeile einliest, wäre es möglich z.B. die geraden und ungeraden Pixel aus aufeinanderfolgenden Zeilen zu lesen. Das würde bedeuten, du hast 2µs zum "Einlesen" eines Pixels statt nur einer. Ob der "Versatz" bei einem 50 x 40 Bild auffällt muss man sehen. Also es sollte mit dem AVR machbar sein, wenn man die Datenübertragung auf das gesamte Bild verteilt, oder eine Zeile liest und ihre Daten dann in den nächsten 7 ignorierten Zeilen überträgt. Mit einem hohen Takt, kann man bei versetzten Pixeln sogar den internen AD Wandler verwenden. Bei höheren Auflösungen wird es allerdings ganz schnell eng. Bei einem F-Bas Signal geht es nur schlecht ohne externer "Farbumwandlung". Ein RGB Signal und seine Derivate sind angenehmer zu verarbeiten als F-BAS (ohne Zusatzhardware), aber man braucht halt drei Wandler (was bei einem Bit pro Farbe natürlich kein Problem darstellt) und die Datenmenge verdreifacht sich im Vergleich zum BAS Signal bei gleicher Auflösung und Bittiefe pro Komponente. MfG SH
Moin.. Warum hat eigentlich die Datensicherung vom Amiga 500 über den Parallel- port auf einen Videorecorder und zurück funktioniert? Weil man kein Echtzeitvideo darstellen wollte.. einfach nur Bitmuster, wenn man das Video auf nem Fernseher betrachtet hat, war es nicht viel mehr. Videotext ist doch auch sowohl erzeugbar als auch dekodierbar, mit nem Z80 !! Also, nicht übertreiben, sondern auf das Problem eingehen: Die Matrix hat nen RAM, und die vorhandene Schaltung liest aus dem RAM und schickt an die LEDs. Soweit so gut.. Nun wollen wir also nur von der Datenquelle DMX512 weg, zu einer anderen. Also nehmen wir uns nen schnellen AVR, nen LM1881, und erwarten dann halt die Pixel für die LEDs an der Stelle, wo unser AVR mit rechnen und übertragen fertig ist. Wie erzeugt man dann das FBAS-Signal mit den Pixeln ? Na im Endeffekt schnappt man sich irgendein Gerät, das nen FBAS-Signal erzeugt, so ne dumme kleine CCD-Kamera oder irgendwas.. es geht ja nur um die schwer selbst zu erzeugenden Dinge am FBAS.. Mit nem weiteren LM1881 holt man sich die Impulse, und schaltet dann anstelle des FBAS-Erzeugers eine definierte Spannung auf die Ausgabeleitung. Ist dann mangels Phase halt nicht wirklich Farbfähig, aber wir übertragen ja nur Bitwerte.. 1 oder 0 .. und aus diesem Bitstream liest ja der andere AVR seine Daten fürs LED-PWM .. Gruss, Tim
>Videotext ist doch auch sowohl erzeugbar als auch dekodierbar, mit nem >Z80 !! Videotext ist ja auch Pippifax gegenüber dem Videosignal: Da werden nur die Informationen digital in der Austastlücke übertragen. Die Anzeige hat ein anderer Chip dann übernommen (STV53... oder so). >Warum hat eigentlich die Datensicherung vom Amiga 500 über den Parallel- >port auf einen Videorecorder und zurück funktioniert? Weil die Daten nicht gerade in Hochgeschwindigkeit (2GiB bei 240er-VHS-Cassette) gespeichert wurden. Pendant wäre da wohl die Datasette (auch Commodore). Mit einem AVR wirst du keine 8Bit Helligkeitauslösung hinbekommen. 4 Bit mit externem Flash-Wandler vielleicht.
Moin.. Also, nochma das, was der TE wünscht: > Jetzt kommt mir die Idee, ein Videosignal (BAS, FBAS oder auch DVI oder > VGA, Super Video??) auszuwerten (welches ist mir eigentlich egal, > hauptsache es geht) und im RAM des uCs zu speichern. > Es gibt wenige Themen hier, die um das ganze handeln, jedoch alles > kompliziert. > Ich bräuchte eigentlich nur 50x100 oder MAXIMAL!!! 200x300 Pixel, zum > Anfang mal Schwarz/Weiß (also wahrscheinlich mit BAS anfangn) mit einer > Widerholrate von zwischen 10 und den 25 Frames/Sekunde. > Wenn das ganze im RAM gespeichert wird (Ram Adresse 0x0070 = Pixel links > oben, RAM Adresse 0xXXXX = Pixel rechts unten) wäre ich absolut > zufrieden. Also doch.. LM1881 - warten auf Sync-Impuls, Verarbeitung starten -> Über Komparator schauen, wie "hell" der Pixel ist. Schwarz/weiss halt. 1 oder 0. Wert im Bitpuffer sichern. Jetzt ist Zeit vergangen, und der nächste Pixel kann gelesen werden. Nun ist es doch für die Auswertung egal, ob das der erste sichtbare Pixel ist, den man auf einem normalen TV sehen würde. Und ob der nächste Pixel dann der rechts daneben ist. Selbst die Zeilen sind egal. Die 50x100 wird man in der PAL-Auflösung also auf jeden Fall unterbringen können. Um natürlich nun ein dazu passendes Signal zu erzeugen, --- moment, das hab ich ja schon beschrieben. Gruss, Tim
Man könnte auch einen Teil der Intelligenz und vor allen Dingen den Bildspeicher in die Anzeigemodule verfrachten. Dazu ein paar Gedanken: 1. der zentrale Controller tastet das Signal ab und schickt es, in Bytes verpackt über seine serielle Schnittstelle. Die Geschwindigkeit dieser ist so hoch zu wählen, daß das vorhergehende Byte sicher raus ist bevor das nächste zu senden ist. 2. die seriellen Ports der Anzeige-Controller sind wie in einer Kette hintereinander gehängt, der Ausgang des letzten Anzeigemoduls ist offen. 3. Die Anzeige-Controller haben einen Ringpuffer, der so groß ist wie die gesamte Zeilenbreite mal die Zeilenanzahl des Moduls. In einer Mainloop wird auf das nächste Byte gewartet, in den Ringpuffer gelesen und ein um die Anzahl der Bytes pro Modulzeile verzögertes Byte auf den UART gegeben. 4. Nach dem Ende der letzten Darstellungszeile wird für eine Zeile die Ausgabe gestoppt und ein SYNC-Signal an alle Controller gesendet. Jetzt übernimmt jeder Controller die für ihn relevanten Daten aus dem Ringpuffer und speichert sie in seinem Anzeigespeicher. 5. Der Eingang eines Bytes wird zusätzlich (mit entsprechendem Vorteiler) zum Multiplexen der Anzeige benutzt. Aus diesem Grund werden in der vertikalen Austastlücke Dummy-Bytes gesendet. So könnte ich mir das zumindest vorstellen. Jörg
Vielleicht gibt dir Peggy Inspirationen: HW:LED-Matrix --- HW:Peggy ---TWI--- HW:Arduino ---USB--- HW:PC Aufbereitung des Videosignals auf dem PC mit Processing. http://www.evilmadscientist.com/article.php/peggy2twi
Danke für den Ideeninput. Da die LED Arrays ja eigentlich jedes seinen RAM hat, der für sich selbst auch mehr als ausreichend ist kann man wirklich einen Seriellen Bus bauen und der Videoumwandel AVR macht aus dem Video einfach einen Seriellen Echtzeitstream mit den einzelnen Pixeln. Die Arrays holen sich dann ihre Bytes da raus und die Sache läuft. Werd mir dann in der nächsten Zeit das mit dem AVR Video mal anschauen und ausprobieren, wenns Fragen gibt bin ich ohnehin wieder hier ;-)
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.