Für ein kleines Projekt, aber vor allem um was zu lernen, beschäftige ich mich gerade mit digitaler Videosignalverarbeitung. Ich würde gern eine Schaltung aufbauen die in der Lage ist das Bildsignal von vier Videoquellen auf einen Videoausgang abzubilden, so wie man das von Sicherheitskameras kennt. Die Videoquellen sollten FBAS (NTSC oder PAL) sein, ebenso der Ausgang. Das resultierende Ausgangssignal möchte ich auch uC-Seitig mit einem Overlay (Text und einfache Grafik wie Linien, Flächen, Symbole) ergänzen können. Die Auflösung sollte max. XVGA (800x600) sein, die Farbtiefe max 8-Bit RGB (=24 Bit). Wie dimensioniert man eine solche Anordnung? Auf was ist zu achten? Wie sollte man hierbei starten? Zuerst mit der "Grafikkarte" und dann die Digitalisierer später dazu? Welche Datenformate/Ablagestrukturen bieten sich an um im uC damit zu arbeiten? Soweit mir bekannt hat ein Standard PAL FBAS Signal eine Bandbreite von ca. 5,5 MHz und eine sichtbare Zeilenlänge von 52 µS. In dieser Zeit müsste ein A/D-Wandler das Analogsignal 800mal mit der gewünschten Farbtiefe abtasten, in einen binären Datenstrom wandeln, der uC diesen einlesen, abspeichern, verarbeiten und wieder ausgeben. Dazu müsste der A/D mit einer Frequenz von ca. 15,4 MHz arbeiten, bzw. doppelt so hoch (oversampling). Der Datenbus wäre sicher besser parallel um solch hohe Datenmengen in der gebotenen Zeit zu übertragen. Der benötigte Speicher lässt sich doch einfach so ausrechnen: Breite x Höhe x Farbtiefe. Also 800 x 600 x 24 Bit / 8 = 1.440.000 Byte = 1,44 MB pro Bild. Die Frage die ich mir stelle ist, ob man überhaupt jedes Halbbild von jeder Quelle in der Zeit so scannen, verarbeiten, anreichern und ausgeben kann. Oder ob ich in Punkto Auflösung Abstriche machen muss. Da könnte auch schnell ein mit 70 MHz getakteter STM32 mit überfordert sein... Vielleicht hat ja der ein oder andere schonmal ein solches Projekt realisiert. Es geht mir, wie gesagt nicht darum einen fertigen Bauplan zu bekommen, vielmehr möchte ich in die Theorie und spätere Umsetzung reinkommen, lernen solche Schaltungen zu verstehen zu dimensionieren und umzusetzen. Ich bin schon sehr gespannt auf Eure Anregungen diesbezüglich und bedanke mich bereits im Voraus für die Mühen! :-)
Es gibt von NXP Bausteine, die ein analoges PAL Videosignal in einen digitalen Stream wandeln. Und umgekehrt. Damit gehst Du dann in ein FPGA. Hab zwar mit STM32 schon Videosignale von Kameramodulen verarbeitet und auf TFT dargestellt. Ich glaub nicht, dass die Performanche für dein Projekt reicht. -> FPGA
Decoder: http://pvr.sourceforge.net/SAA7113H_1.pdf Encoder: https://www.nxp.com/docs/en/data-sheet/SAA7104H_SAA7105H.pdf
Sowas hab ich schon irgendwie "befürchtet" ;-) STM32 halt nur, weil ich mit FPGAs noch keinerlei Erfahrung gesammelt habe. Da starte ich dann auch bei quasi 0. Danke für die Datenblätter, sehr aufschlußreich! Der SAA ist sicher schon etwas älter, aber immerhin hat der sogar ein JTAG-Interface :-) Bei den Wandler-Chips wäre ich jetzt erstmal bei AnalogDevices auf die Suche gegangen, aber im Grunde ist das auch egal. Frage: Macht man das bei solchen Konzepten nicht auch so, das der A/D-Wandler ein shared-DRAM beschreibt aus dem man dann vom uC aus ausliest?
:
Bearbeitet durch User
Olli Z. schrieb: > Soweit mir bekannt hat ein Standard PAL FBAS Signal eine Bandbreite von > ca. 5,5 MHz und eine sichtbare Zeilenlänge von 52 µS. In dieser Zeit > müsste ein A/D-Wandler das Analogsignal 800mal mit der gewünschten > Farbtiefe abtasten 800 mal? Das ist kompletter Overkill. Die Hälfte reicht dicke. Überleg' mal, was bei 5.5 MHz Bandbreite möglich ist. Und das ist letztlich nur die Bandbreite des s/w-Anteils, die Farbbandbreite ist dank PAL nochmal deutlich geringer. Lass' Dich nicht von der Angabe 720x576i verwirren, das ist die Auflösung des PAL-Timings (15.625 Hz Zeilenfrequenz, 625 Bildzeilen im 50/25-Hz-Interlace), aber nicht das, was mit PAL-Farbcodierung via FBAS transportierbar ist.
Moin, Es gibt Standards fuer digitales SD-Video; da wird mit 27MHz Takt gearbeitet, bzw. 13.5MHz fuer Luminanzabtastung und 6.75MHz fuer die Chrominanzsignale. Guckstu: BT.601 und BT.656. Wenn man sich daran haelt, gibts auch viele ICs, die ein Videosignal dann digitalisieren koennen. Neben den schon genannten z.B. von TI die TVP515x Familie. Oder Intersil muesst' auch sowas haben (Die gibts dann auch in z.B. 4 kanaliger Ausfuehrung). Ich seh's aber auch so, dass dann eher ein FPGA kommt, als ein STM32. Der koennte hoechstens evtl. die Berechnung der Graphikelemente machen, muss aber dann irgendwie einen Framebuffer in seinen Adressraum bekommen, aus dem dann z.b. das FPGA mit dem richtigen Timing das Zeugs ausliest und dem Videosignal ueberlagert. Danach muesst' das digitale Videosignal auch wieder neu PAL-encodiert werden und auf Analog gewandelt. Dafuer gibts ja auch wieder die entsprechenden Chips. Wenn man auf Farbe komplett verzichtet und 's mit Gewalt selber basteln will, waere die erste Huerde, aus dem H-Sync einen stabilen Pixeltakt zu generieren. Da ist wahrscheinlich schon lustiges rumstuempern mit CD4046 und wilden Zaehlern angesagt... Gruss WK
Wie " Dergute Weka" schon gesagt hat, könnte man a) mit einem Filter das Farb-PAL Signal wegfiltern b) mit den internen AD Wandlern direkt (in 8 Bit) das b/w Signal digitalisieren c) H und V Sync rausrechnen d) das ganze auf einem STM32 machen, wenn es nicht Echtzeit sein muss Eine Zeile eines BAS-Signals (https://de.wikipedia.org/wiki/Fernsehsignal) dauert 64 µS, die AD Wandler eines STM32F407 schafft max. 2,4 MSPS, also alle 0,41 µS ein Sample. Das wären dann ca. 156 Samples pro Zeile, wobei aber nur 52/64 konkret Pixel wären, also eine Auflösung von Horizontal 126 Pixel. Nicht viel. Um ein komplettes Halbbild erstmal zu digitalisieren bräuchte man 156 Samples/Zeile * 316 Zeilen = ca. 50 kB. Würden die DA Wandler ebenso 2,4 MSPS schaffen (was sie nicht tun, oder nur mit Tricks http://www.st.com/content/ccc/resource/technical/document/application_note/6f/35/61/e9/8a/28/48/8c/DM00129215.pdf/files/DM00129215.pdf/jcr:content/translations/en.DM00129215.pdf) dann könnte man jetzt das gesampelte Signal einfach wieder per DMA ausgeben und parallel dazu ein weiteres in einem zweiten Buffer einlesen. Der STM32 sucht dann im in beiden Buffern nach dem V-Sync kopiert dann die Helligkeitsinformationen pro Zeile in den 1. Bereich (er startet beides mal jeweils nach dem gefundenen V-Sync). Wenn man das Sampling beim AD und DA Wandler auf 1 MSPS runterschraubt, dann müsste das sogar klappen, halt nur b/w und mit effektiv 52 Pixel pro Zeile. Dann bräuchte man auch nur noch ca. 20 kB pro Bildbuffer, würde also noch in den internen Speicher passen.
2⁵ schrieb: > kopiert dann die Helligkeitsinformationen Naja, ist eher ein addieren, am besten mit Sättigung.
Ich sehe schon das ein STM32 hier wohl wirklich fehl am Platz ist, zumindest für die Videosignalverarbeitung. Mit dem BT.656 Format hatte ich schonmal zu tun. Da wurde ein ADV7181 eingesetz umd FBAS zu digitalisieren. Ein ADV7181 als A/D und ein ADV7179 als D/A-Wandler. "Dazwischen" quatschen die dieses BT.656 Protokoll. "A BT.656 data stream is a sequence of 8-bit or 10-bit Word (computer architecture), transmitted at a rate of 27 Mword/s." bedeutet das man wenigstens mit 27 MByte/s Datendurchsatz da ran muss. Das ist aber auch nicht grad wenig. Und um ein so abgelegtes Bild mit einem selbstproduzierten Overlay zu ergänzen müsste die Software ebenfalls mit YCC umgehen können. Der TI TVP5150 ist ein interessanter Chip, aber leider wie die meisten dieser Chips für "Privatbastler" extrem schwer aufzutreiben.
Moin, > Mit dem BT.656 Format hatte ich schonmal zu tun. Da wurde ein ADV7181 > eingesetz umd FBAS zu digitalisieren. Ein ADV7181 als A/D und ein > ADV7179 als D/A-Wandler. "Dazwischen" quatschen die dieses BT.656 > Protokoll. Ja, das ist auch so die selbe Sorte Video-ADC, wie die NXP, TI oder Intersil Bausteine. > "A BT.656 data stream is a sequence of 8-bit or 10-bit Word (computer > architecture), transmitted at a rate of 27 Mword/s." bedeutet das man > wenigstens mit 27 MByte/s Datendurchsatz da ran muss. Das ist aber auch > nicht grad wenig. Im Vergleich zu ner RS-232 oder Audio ist das schon viel. Aber im Vergleich zum aktuellen HD- und 4kp60-Gedoense doch noch eher gemaechlich. > Und um ein so abgelegtes Bild mit einem selbstproduzierten Overlay zu > ergänzen müsste die Software ebenfalls mit YCC umgehen können. Ja. Da ist's sinnvoll die Graphik gleich im YUV Farbraum zu erstellen. YUV spart halt gegenueber RGB schon mal ordentlich Daten ein, weil die Chromakomponenten mit niedrigerer Bandbreite uebertragen werden koennen, ohne dasses gleich kacke aussieht. Aus 2Pixeln RGB, also 2*3*8bit=48bit wird dann schon "nur noch" YUYV, also 4*8 bit= 32 bit. > Der TI TVP5150 ist ein interessanter Chip, aber leider wie die meisten > dieser Chips für "Privatbastler" extrem schwer aufzutreiben. Ja, das ueblich Malheur. Manchmal gibts noch Samples fuer umme, aber der jetzt grad' nicht. Kannste hoechstens noch auf irgendeiner Messe (Embedded, Electronica, ...) versuchen zu schnorren. Aber die einzuloeten macht auch nicht den Monsterspass. Gruss WK
Olli Z. schrieb: > die in der Lage ist das Bildsignal von vier > Videoquellen auf einen Videoausgang abzubilden Darauf wird schon garnicht mehr eingegangen - es sind aber nicht bloss einfach 4 Eingangs- und 1 Ausgangsstream, sondern ohne weiteres sind die Eingänge ja auch nicht synchron, d.h. es müssen 4 ganze Bilder zwischengespeichert werden, die um bis zu einem ganzen Bild zeitlich versetzt sein können, erst dann kann man diese zusammenrechnen und wieder ausgeben. Man braucht also 5 Framebuffer sowie die Resourcen für 5 Streams und die nötige Rechenzeit für das Kombinieren und mit Text usw. Überlagern. Georg
georg schrieb: > sondern ohne weiteres sind die > Eingänge ja auch nicht synchron eben und die Quellen billig sind üblich nicht synchronisierbar! gut das du darauf hinweist, das vermisste ich bis hier!
Olli Z. schrieb: > Der TI TVP5150 ist ein interessanter Chip, aber leider wie die meisten > dieser Chips für "Privatbastler" extrem schwer aufzutreiben. Digikey hätte welche! Und TQFP mit einem Pinabstand von 0,5 mm gehen noch zu löten...
Der STM ist hier mit Sicherheit am kämpfen, aber mit viel Tricks und abstrichen wird was machbar sein. Ausgabe würde ich über DAC oder der SPI machen, FBAS Generatoren gibt es für den AVR genug um sich das anzusehen. Der Eingang ist deutlich schwerer, weil 4 Signale. Bei einem würde ich einen externen Wandler nehmen und den wenn es geht über DCMI oder SPI rein holen. Ob man einen 4-fach Wandler über 4 SPI rein holen kann wird ein blick in die Datenblätter zeigen. Auf jeden Fall niemals die volle Auflösung laden, sonst must Du die später wieder wegrechnen. Und überlasse so viel wie möglich der Hardware und dem DMA. Aber auch wenn Du die Daten im Speicher hast musst Du diese 4 Signale in ein Signal zusammen kopieren, das kostet nun CPU Zeit. Ein STM mit 70MHz ist garantiert der falche Typ, 168 oder 200 wäre da angesagt, also STM32F4 / F7. Machbar aber nicht so einfach!
Moin, für sowas musst du schon einen kräftigeren DSP-Hybriden wie Blackfin oder OMAP hernehmen. Mit dem BF561 EZKIT geht in/out gleichzeitig, aber DMA musste beherrschen. Mit der STM32 family wirst du ganz schön in strampeln kommen.
Was wäre denn eigentlich das Gegenstück zum TVP51515 ? Also der „passende“ D/A Wandler? Bezüglich der A/D wurde ja auch angesprochen das ich bis zu 4 Quellen habe. Wenn ich die alle über einen A/D multiplexe, dann habe ich sogar max. nur jedes vierte Bild der Quelle zur Verfügung.
:
Bearbeitet durch User
Olli Z. schrieb: > Bezüglich der A/D wurde ja auch angesprochen das ich bis zu 4 Quellen > habe. Wenn ich die alle über einen A/D multiplexe, dann habe ich sogar > max. nur jedes vierte Bild der Quelle zur Verfügung. Nein. Deine Videoquellen sind asynchron. Dein Grabber muss also im worst case einen ganzen Frame minus einem Pixel (auch die Austastlücken zählen als Pixel) warten, bis er den nächsten Frameanfang bekommt. Vorausgesetzt, die Synchronisation klappt innerhalb eines Frames. Oft braucht es mehrere Frames, bis die Synchronisation steht. Jeder achte Frame wäre also realistischer, aber auch schon gut. Ich würde also 4 ADCs laufen lassen. Der hier http://www.analog.com/en/products/audio-video/video-decoders/adv7181d.html hat tatsächlich 4 ADCs eingebaut, nicht nur einen Multiplexer mit einem einzelnen ADC. Damit müsste das Umschalten maximal schnell gehen. Ansonsten halt vier einzelne davon nehmen http://www.analog.com/en/products/audio-video/video-decoders/adv7280a.html und parallel ins FPGA füttern. Ohne wirds eh nicht gehen, denn Du musst mit jedem Pixelclock Daten entgegen nehmen und ausgeben: konstant, präzise und ununterbrochen, und mit 27MHz bzw 27 MByte/s. Zum Ausgeben wäre dann so etwas angebracht: http://www.analog.com/en/products/audio-video/video-encoders/adv7390.html fchk
Wegen diesen 4 Eingängen, braucht man da wirklich 5 Framebuffer? Reicht nicht auch einer in den man alle 4 Bilder schreibt? Olli Z. schrieb: > Ich würde gern > eine Schaltung aufbauen die in der Lage ist das Bildsignal von vier > Videoquellen auf einen Videoausgang abzubilden, so wie man das von > Sicherheitskameras kennt. Ich verstehe das so, dass jedes Bild in einem Viertel vom Ausgabebild dargestellt wird. Also erfasst man die 4 Quellen und schreibt direkt in den Ausgabe Framebuffer. Ja, man muss dann an 4 Stellen gleichzeitig schreiben und an einer lesen. Das geht wenn der Speicher höher taktet. Ich würde einen FPGA und ein externes SRAM verwenden.
Das klingt alles sehr vernünftig und nachvollziehbar. Ja, es sollen vier kleine Bilder auf einem dargestellt werden, so wie ich es eingangs beschrieben hatte. Die Sache mit dem ADV7181 käme mir sehr entgegen, den kenne ich zumindest und weiss wo er verbaut ist. Leider nicht ganz leicht zu beschaffen diese ICs. Ebenso der ADV7390. Was den FPGA angeht bin ich völlig ahnungslos. Zwar werden für solche Anwendungen immer auch irgendwo Entwicklungsboards angeboten, die sind aber für Privatanwender teils unerschwinglich teuer (300-600€). Vielleicht einen Tipp welchen FPGA es sein könnte und wenn jemand eine günstige Einkaufquelle für Boards kennt... :-) Der FPGA allein macht ja nix, den muss man programmieren. Also wird da wenigstens noch ein Flash und natürlich SDRAM erforderlich sein. Oder wäre es einfacher, sinnvoller gleich einen Mini-PC dafür zu nutzen, also sowas wie ein Raspberry? Ich habe im Zusammenhang mit dem TVP5151 zumindest schonmal Anwendungen im Netz dazu gefunden. Und so ein Raspy sollte doch genug Power dafür haben? Und um die 50,- € bekomme ich vermutlich grade mal die Bauteile. Nur so als Idee. Ich lasse mich aber auch gern von ner FPGA-Lösung überzeugen, wenn es mir denn möglich wär sowas umzusetzen...
Den Xilinx Spartan 6 gibt es bis zum XC6SLX9 noch als TQFP144 zum selber löten. Der wird auch noch vom kostenlosen Webpack unterstützt. Du wirst externes RAM brauchen. Ein Pi macht das ganze nicht einfacher. Du wirst dann die Inputs über CSI2 einlesen müssen, und für diese serielle Hochgeschwindigkeitsverbindung wirst Du Dir die geeignete Mestechnik nicht leisten können. Außerdem ist der Standard nicht öffentlich, und der PI-Treiber womöglich ein Binärblob, das Du nicht ändern können wirst. Und selbst wenn Du es ändern könntest - wieviel Linux Kernelprogrammierung hast Du bereits gemacht? Außerdem hat der Pi nur einen CSI Port, Du willst aber 4 davon haben. So ein nVidia Tegra wäre eine geeignete Plattform, aber so hoch wirst Du wahrscheinlich nicht einsteigen wollen, und einfacher wirds damit nicht. Die erzielbaren Ergebnisse werden nur besser. fchk
Moin, Oops, du willst ja 4 Videos gleichzeitig nehmen, kleinschrumpeln, Graphik ueberlagern und wieder ausgeben. Irgendwie hatte ich noch den Analogschalter ausm anderen Thread im Kopp... Das verkompliziert's ganz ordentlich. Also da ist defintitv nix mehr mit Olli Z. schrieb: > Für ein kleines Projekt, aber vor allem um was zu lernen, Klein ist da nix mehr, hoechstens noch die Erfolgsaussichten ;-) Wie georg angemerkt hat, muessen da irgendwie die Videos auf eine gemeinsame Zeitbasis gebracht werden. Wegen dem "kleinschrumpeln" muss auch noch getiefpassgefiltert und/oder gedeinterlaced werden, sonst siehts arg grauslich aus. Das sind alles dicke Bretter, in die grosse Loecher gebohrt werden muessen. Also FPGA geht zwar (FPGA geht fast immer irgendwie) ist aber, wenn man da noch nix gemacht hat, illusorisch. RasPi oder andere Boards sind auch eher ungeeignet, die muessten dann irgendwie passende Interfaces haben und auch noch die entsprechende HW dahinter und die entsprechenden Treiber/Doku. Haben sie normalerweise nicht. Am ehesten evtl. noch Boards mit Handychips drauf - gibt da so Dinger mit Qualcomm Snapdragon, die haben iirc bis zu 3 (Kamera)interfaces. Aber das ist dann MIPI-CSI, kein BT.656 - also auch Riesengewurschtel. Von Intersil gibts den TW2851, der macht vermutlich genau alles das, was du willst, in einem Chip. Wuerd' ich zwar auch nicht als Einsteigerprojekt empfehlen, aber zu dem gibts wenigstens ein Datenblatt mit >4 Seiten. Das kannste dir mal unters Kopfkissen legen. HiSilicon hat sicher auch sowas im Angebot, aber da siehts traditionell mau aus mit Infos. Gruss WK
Ich muss zugeben das ich die Dimension unterschätzt habe. Sind denn solche Kameraüberwachungssysteme wirklich auch so komplex aufgebaut? Hab mir laienhaft vorgestellt pro Kanal einen Framebuffer zu befüttern, gleich in verkleinerter Version und daraus das Zielbild zu generieren. Quasi alles asynchron. Das größte Problem, neben den vier parallelen Quellen ist ja wohl die Synchronisation selbiger. Der TW2851 wär wirklich ein guter Chip dafür und laut der Website mit $25 auch nich recht preiswert. Leider, wieder mal, nirgendwo zu bekommmen. Allerdings, ein 352 Pin BGA ist auch nicht wirklich was für den Privatbereich... ;-) Wie wäre denn z.B. dieser Chip hier https://www.intersil.com/en/products/end-market-specific/automotive-ics/video-decoders/ISL79988.html Der ISL79988 ist sogar für Automotive Anwendung gedacht, hat vier Eingänge und Wandler und liefert BT.656 am Ausgang. Ist in einem beherrschbaren QFN48 Gehäuse und von Farnell für 14€ zu haben. Aktuell sehe ich da kein Land. Um überhaupt irgendwie weiter zu kommen würde ich mit dem einfachen Teil beginnen wollen, der FBAS Ausgabe vom uC. Das sollte ein STM32ja noch hinbekommen, zusammen mit einem der genannten D/A Chips.
:
Bearbeitet durch User
Moin, Olli Z. schrieb: > Ich muss zugeben das ich die Dimension unterschätzt habe. > Sind denn solche Kameraüberwachungssysteme wirklich auch so komplex > aufgebaut? Naja, mit so Chips wie dem TW2851 ist's dann nicht mehr so komplex. Und zu Zeiten, als es solche Chips noch nicht gab, war Ueberwachungtechnik natuerlich auch deutlich teurer und/oder schlechter. Also z.b. Schwarzweiss, "VHS-Longplay"-Qualitaet, etc. > Hab mir laienhaft vorgestellt pro Kanal einen Framebuffer zu > befüttern, gleich in verkleinerter Version und daraus das Zielbild zu > generieren. Quasi alles asynchron. > Das größte Problem, neben den vier parallelen Quellen ist ja wohl die > Synchronisation selbiger. Bei der Synchronisation laeufts halt drauf raus, dass manchmal ein Bild weggeschmissen werden muss und manchmal ein Bild doppelt gezeigt werden muss. Sollte das schon zu ruckelig sein, gehts auch besser, aber mit noch viel mehr Aufwand. Auch das Verkleinern ist, wenns danach irgendwie noch gut aussehen soll, etwas tricky. Du kannst nicht einfach z.B. jedes 2. Pixel weglassen, sondern du musst das Videosignal erst in X und Y Richtung tiefpassfiltern und dann Pixel weglassen. Das ist halt einfach eine Riesenrechnerei, die am besten mit speziell dafuer zugeschnittener Hardware geht. > Der TW2851 wär wirklich ein guter Chip dafür und laut der Website mit > $25 auch nich recht preiswert. Leider, wieder mal, nirgendwo zu > bekommmen. Allerdings, ein 352 Pin BGA ist auch nicht wirklich was für > den Privatbereich... ;-) Tja. Klingt aber noch nach einem harmlosen BGA mit vielleicht 1mm Pitch. > Wie wäre denn z.B. dieser Chip hier > https://www.intersil.com/en/products/end-market-sp... > Der ISL79988 ist sogar für Automotive Anwendung gedacht, hat vier > Eingänge und Wandler und liefert BT.656 am Ausgang. Ist in einem > beherrschbaren QFN48 Gehäuse und von Farnell für 14€ zu haben. Ja, der hat halt ausser einem streng geheimen Datenblatt noch 4 Video-ADCs eingebaut; und verwurstet deren Ausgangssignale auf einen einzigen Videobus. Dieses 656 mit 108MHz Clock ist, mein' ich, so eine Ueberwachungstechnikchipspezialitaet. In der Originalspec ist da iirc nix davon vorgesehen. Da gibts nur 1x Video mit 27MHz parallel oder 270Mhz seriell. Wenn du den Chip einsetzt, dann musst du halt danach die Signale wieder irgendwie auseinanderklabustern, einzeln kleinschrumpeln (="dezimieren"), dann an der richtigen Stelle in einen Framebuffer schreiben, Graphik drueberlegen, wieder auslesen und PAL-encodieren...Schon fertig ;-) > Aktuell sehe ich da kein Land. Ja. isso. Sind halt sehr dicke Bretter zu bohren. Wird mit DVI,HDMI, DisplayPort auch nicht mehr besser, sondern nur unangenehmer... > Um überhaupt irgendwie weiter zu kommen > würde ich mit dem einfachen Teil beginnen wollen, der FBAS Ausgabe vom > uC. Das sollte ein STM32ja noch hinbekommen, zusammen mit einem der > genannten D/A Chips. Die reine Ausgabe ist einfacher, weil du dann den Takt vorgeben kannst. Farbe machts wieder schwieriger... Vor ca. 25 Jahren hab' ich mal ueber den PC-Printerport auf ein R2R Netzwerk als DAC versucht, Videosignale zu erzeugen. Naja; fuer ne Grautreppe hats gereicht... Gruss WK
Olli Z. schrieb: > Aktuell sehe ich da kein Land. Um überhaupt irgendwie weiter zu kommen > würde ich mit dem einfachen Teil beginnen wollen, der FBAS Ausgabe vom > uC. Das sollte ein STM32ja noch hinbekommen, zusammen mit einem der > genannten D/A Chips. Kannst Du machen, aber dann wirds scheiße. Bedenke: Der Video-Encoder will alle 37ns (Kehrwert von 27 MHz) ein Datenwort sehen, und zwar exakt alle 37ns, und nicht ungefähr. Wenn Du das hinbekommen solltest, wird Dein STM32 zu 100% mit der Bildausgabe beschäftigt sein. Da darf dann auch kein Interrupt oder so dazwischen kommen. Wie Du unschwer erkennen kannst, hast Du Dich damit in eine 1A Sackgasse manöveriert. Wenn Du die Chance haben willst, eine zu haben, dann nimm einen Typ mit LCD-Interface und nutze das. Damit wird die Bildausgabe an Hardware ausgelagert. Der Prozessor wird zwar langsamer, weil er jetzt ja nicht mehr ständig aufs RAM zugreifen kann, aber er steht noch zur Verfügung. So, dann gehts weiter: Skalieren auf dem STM32 in Software kannst Du knicken. Das muss externe Hardware machen. Das Reinschreiben ins Videoram muss Hardware machen. Wenn Dein STM32 einen parallelen Camera-Bus hat, dann bekommst Du einen Videostream rein ins System. Einen (1). STM32 ist die falsche Hardware für sowas. Zumindestens dann, wenn Du ordentliche Ergebnisse haben willst und das ganze mehr als nur Selbstzweck sein soll. fchk PS: Das hier wäre das geeignete Spielzeug für Dich: https://auvidea.com/j100/
:
Bearbeitet durch User
So ganz stimmt das aber nicht. 37ns (Wert habe ich nicht geprüft) sind zwar nicht einfach aber bedenke der STM32 sollte da überhaupt nichts mit der CPU machen. Das muss alles über Timer, DMA und zB. SPI laufen, sonst ist der wirklich nur am rechenen. Wie schon gesagt für den AVR gibt es genug Beispiele und der ist nicht gerade der super schnellste. Für die Ausgabe sehe ich keine Probleme. Beim Einlesen gibt es entweder entsprechende ADC oder wenn der STM schnell genug ist auch sein Interner ADC. 8Bit sollten da reichen. Die Synkronisation würde ich in Hardware machen, also für Zeilen Anfang und Bild Anfang. Diese Informationen gibt man auf einen Timer der dann Takt & ADC & DMA steuert. Wenn man es schaffen könnte die Bildinformationen nun sauber (Adressen Sprung bei Zeilen Start) in den Ausgabe Speicher rein schreiben könnte wäre man fast fertig. Das könnte aber leicht flackern, für absolut saubere Bilder muss man mit mehr Speicher arbeiten und das Kopieren der CPU oder wenn der DMA noch Zeit hat den Überlassen. Nachdem ich darüber nach gedacht habe, glaube ich das ein M4 das packen sollte, beweisen werde ich das jetzt nicht, weil dann müsste ich ja dieses Projekt parallel auch machen. Ich empfehle einfach mit dem STM32 und der Ausgabe mal anfangen und sich langsam ran zu tasten. Da werden sich dann noch genug Fragen und Probleme Zeigen. VG Uli
Danke Uli, wieder etwas Mut gemacht :-) Ich glaube wenn ich für die Ausgabe einen „beliebigen“ DAC aussuche, welcher BT.626 versteht, sollte das doch ok sein?! Kennt da jemand einen der direkt von einem externen RAM liest? Ich denke ich sollte den Framebuffer nicht im RAM des STM32 umsetzen...
Olli Z. schrieb: > Danke Uli, wieder etwas Mut gemacht :-) > Ich glaube wenn ich für die Ausgabe einen „beliebigen“ DAC aussuche, > welcher BT.626 versteht, sollte das doch ok sein?! Nimm den eingebauten TFT-Controller! 3 einfache DACs, notfalls mit Widerständen, und Du hast analoges RGB für SCART oder VGA. > Kennt da jemand einen der direkt von einem externen RAM liest? Ich denke > ich sollte den Framebuffer nicht im RAM des STM32 umsetzen... So etwas gibts nicht in einem Stück. fchk
Moin, o_O, das wird wohl eine schwierigere Geburt... Erstmal empfehl' ich dringenst als Feierabendlektuere das: Repetitorium Fernsehtechnik von Rohde und Schwarz Olli Z. schrieb: > Ich glaube wenn ich für die Ausgabe einen „beliebigen“ DAC aussuche, > welcher BT.626 versteht, sollte das doch ok sein?! Es ist wurscht, ob der DENC (digital encoder) jetzt von Philips, NXP, Intersil, oder sonstwem ist. Das Videointerface ist immer ziemlich gleich und will mit exakt 27MHz 8 bit Daten haben. Mit sinnvollem Inhalt. Initialisierung so eines DENCs ist dann chipspezifisch. Ueblicherweise haben die einen I2C Bus und zig Register, mit denen man dann allen moeglichen Krempel einstellen kann, z.b. PAL, NTSC, SECAM mit den jeweiligen Geschmacksrichtungen, Position/Laenge des Bursts, Videopegel, Testbild, was an den diversen Ausgaengen fuer Signale rauskommen sollen, RGB, YC, FBAS... Aber du brauchst dann immer einen sinnvollen Datenstrom, der mit exakt 27MByte/sec in den Chip reingeht. Kein Verschnaufen, weil grad' vertikale Austastluecke, RAM-Refresh, CPU Zugriff ist oder der Hund die Daten gefressen hat. Immer 27 MByte/sec. > Kennt da jemand einen der direkt von einem externen RAM liest? Nur als komplexeres IC, wie eben den TW2851 oder aehnlich komplexe SoCs; die haben aber, wenn sie noch nicht abgekuendigt sind, derweilen viel eher einen HDMI Ausgang. > Ich denke > ich sollte den Framebuffer nicht im RAM des STM32 umsetzen... Es ist dem DENC voellig wurscht woher die Daten kommen. Sie muessen nur andauernd kommen. mit exakt 27 MByte/sec (erwaehnte ich das schonmal?) Hoechstwahrscheinlich wird's ziemlich unmoeglich sein, aus einem STM32 einen solchen konstanten Datenstrom rauszukriegen, wenn er nicht ein dafuer gemachtes Interface hat. SPI ist zu langsam und muss wahrscheinlich immer mal wieder "verschnaufen". Wenn man jetzt keinen solchen BT656 fressenden DENC nimmt, sondern z.B. einen "dummen" DAC, dann ist man nicht mehr so fix an die 27MHz gebunden, sondern kann irgendeinen anderen Takt und auch eine andere Bitbreite nehmen. Aber dann muss man sich halt selber um die korrekte Erzeugung von Austastluecken, Vor/Nachtrabanten und Syncpulsen kuemmern. Wenns Bunt sein soll, auch noch Bursts und Chromasignale... Natuerlich kann man tricksen. So funktionieren eben die AVR-(Test)bildgeneratoren oder die Videoausgabe der alten Sinclair ZX8[01] Rechner. Aber: Dazu muss man ziemlich ausgefuchst sein, sattelfest in den Normen und wissen, was es fuer Folgen hat, von den Normen abzuweichen, wo man das kann und wo besser nicht. MAn muss sehr exakt wissen, wie die CPU Befehle abarbeitet und was nebenher noch so passiert. Und ueblicherweise braucht man immer noch ein bisschen Hilfshardware, sei's nur zum Pegelwandeln oder Syncsignaleinbau. Potentiell eignen sich fuer sowas dann auch primitive CPUs besser. Also CPUs ohne Cache, ohne out-of-order-execution, ohne SDRAM-Controller, ohne branch prediction, ... Weil all diese Gimmicks aktueller CPUs das Zeitverhalten nicht mehr vernuenftig kalkulierbar machen. Die CPU macht dann auch nix anderes mehr als das bekloppte Bild auszugeben. Hat schon seinen Grund, warum es schon seit grauster Rechnervorzeit immer spezielle Videoausgabehardware gab und das nur in ganz eigenartigen Ausnahmen die CPU macht. Gruss WK
Moin, Frank K. schrieb: > Nimm den eingebauten TFT-Controller! 3 einfache DACs, notfalls mit > Widerständen, und Du hast analoges RGB für SCART oder VGA. Ja, wenn sowas eingebaut ist, ist das ein guter Anfang. Wenn RGB OK ist, musst du nur noch gucken, wie du dir die Syncsignale basteln kannst und ob du ein passendes Timing (15.625kHz/50Hz,...) hinkriegst. Wenn du das RGB wieder zu PAL machen willst, fangen die Schmerzen schon wieder an. Einfache, analoge PAL-Encoder duerften alle schon laengst abgekuendigt sein... Gruss WK
Ich dachte es soll FBAS raus kommen. Alles andere ist schwerer zu machen, wenn man nicht gerade die passende Hardware im Chip hat. Alles lesen und aufschreiben wo was dran soll und schauen ob die Hardware reicht. Es gibt nette 8Bit ADCs extra für Video und da must Du halt auch schauen wie man die anschliesst. UND dann kannst Du anfangen mal was umzusetzen! Auch wenn ich glaube das es gehen sollte, solltest DU aber damit rechnen das Du scheiterst mit einem STM32. VG Uli
Moin, Wenn man mal was ganz abgefahrenes macht - also so richtig krass - und mal nach stm32 und pal googled... Da hat natuerlich schon mal wer was gebastelt. Nur "PAL" ist halt bissl irrefuehrend, denn da gibts nur schwarz weiss, kein Chroma at all, keine Graustufen. Anscheinend muss die SPI-HW entgegen meiner Vermutungen nicht verschnaufen, also kann man damit dauerhaft Bitmuster ausgeben. Und irgendwie dazu ueber GPIOs was syncsignalartiges. Nur ist man damit vom Originalprojektplan doch schon so ein bisschen abgekommen :-) Gruss WK
Wandlung monochrom nach USB: https://github.com/iliasam/STM32F4_UVC_Camera https://www.youtube.com/watch?v=V_uk3eTgr50 http://www.stmcu.org/module/forum/thread-614342-1-1.html Generatoren findet man einfacher.
Dergute W. schrieb: > Und > zu Zeiten, als es solche Chips noch nicht gab, war Ueberwachungtechnik > natuerlich auch deutlich teurer und/oder schlechter. Also z.b. > Schwarzweiss, "VHS-Longplay"-Qualitaet, etc. Macht man ja auch heute nicht mehr. Man nehme 4 Webcams, die ONVIF und/oder RTSP können, hängt sie ins Netzwerk und guckt mit z.B. dem ONVIF Device Manager oder schlimmstenfalls VLC. Die Hardware mit den 4 Framebuffern usw. gehört heute zum alten Eisen, zumal PAL CCTV Kameras zunehmend ausser Mode kommen.
Mit dem Hinweis das ich mit meiner NTSC (PAL wäre nur "Beifang") FBAS-Lösung nicht ganz am Puls der Zeit bin hab ihr natürlich recht. Aber das ist für mich schon eine große Nummer und HDMI oder was weiss ich noch alles, ist bestimmt nicht trivialer in der Umsetzung... Zudem mache ich das ja für ein ganz bestimmtes "Anzeigegerät" und das kann nunmal nur FBAS, auch wenn intern natürlich BT.626 fährt und dafür einen ADV7181 drin hat. Aber da hätte ich jetzt gar keine Idee wie ich DIREKT an diesen Bus ankoppeln sollte. Die Idee dazu hatte ich schonmal, denn ich würde die Kamerabilder ja lieber per LVDS direkt digital zum Display senden, als die einmal nach Analog und zurück zu wandeln.
Ich habe schon mal beruflich einen(!) Imager an einen STM32F746 angeschlossen und darauf ein Overlay gezeichnet und das ganze als PAL ausgegeben. Der Controller hat ein LCD-Interface, dem man das Timing beibringen kann. Allerdings benutzen wir RGB, denn eine Anforderung waren transparente Overlays und das kann er bei RGB in Hardware. Als DAC gibts zB den ADV7393, der kann RGB. Das ist auch schon der nächste Punkt: Dieses YUV in der Videowelt kommt als YUV422 daher, d.h. Y1 U12 Y2 V12 . Zwei Pixel haben eigenständige Helligkeit (Y), aber sie teilen sich die Farbinformation (U und V). Das führt dazu, dass wenn man zB einen Pixel zeichnen möchte, dann kann man nicht einfach wie bei RGB den Pixelwert in den Speicher schreiben, sondern man muss das Doppelpixel lesen, das U und V neu berechnen, Y setzen und das ganze zurückschreiben. Alternativ natürlich immer 2 Pixel auf einmal schreiben, womit man dann halt eine halbierte Auflösung fürs Overlay hat. Das mag für ein privates Projekt gehen, bei mir war das nicht erwünscht. Will man 4 Videobilder skalieren, dann muss man die skalierten Bilder natürlich auch wieder in dieses Format bringen. Insgesamt denke ich auch nicht, dass der Controller das kann. Das macht zuviel Last auf die Busse und die CPU. Zum Raspberry PI: Es gibt ja USB-Framegrabber für wenig Geld, aber ich weiß nicht, in welchem Format die das Bild übertragen. Diese 4x27MB/s gehen sicher nicht über den USB2 des RPi, aber vieleicht können sie die Auflösung reduzieren oder Jpeg übertragen oder so.
... wer will noch "analoges Video" nutzen ... wenn es "überall" diese IP-Kameras gibt ... damit wird dann die ganze Bilddarstellung und Barbeitung auf einem PC realisiert ...
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.