mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Videosignalverarbeitung mit STM32


Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :-)

Autor: Loth (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Loth (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: 2⁵ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/d...) 
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.

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
> kopiert dann die Helligkeitsinformationen

Naja, ist eher ein addieren, am besten mit Sättigung.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: georg (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/vide...

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/vide...

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/vide...

fchk

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: fchk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-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.

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
Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Externe RAM zugriffe sind etwas langsamer!

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.