Welcher ARM für simplen FrameGrabber?

[toemchen]

Hallo,

ich möchte für ein Meßsystem das Signal eines S/W-Videokameramoduls framegrabben. Das ist von der Geschwindigkeit her schon anspruchsvoll: Ich rechne mit gut 2 Megasamples pro Sekunde. Bei jedem zweiten Frame muß zusätzlich on-the-fly eine Dunkelbild-Differenz gemacht werden.

Geht das, welchen ARM brauche ich? Muß ich Assembler, oder ginge auch C? Gerne würde ich bei Atmel bleiben (Entwicklungsumgebung schon vorhanden), da gibt es aber anscheinend wenig Entwicklerboards. Mit dem Philips-ARM gibt es von embedded-artists ein interessantes Platinchen für 39€. Ob nun ARM7, ARM9 oder ARM11, da habe ich echt keine Ahnung. Es soll schon günstig sein, und wirklich nur auf diese Aufgabe zugeschnitten.

Nun die Details:

Kamera hat 352x288. Bin aber pro Zeile auch mit ca. 150 statt 352 Samples zufrieden. Ich glaube, bei einem analogen S/W-Videosignal kann man undersampeln. Dann ergibt sich ein Speicherbedarf von ca. 43kByte pro Bild. Bei 50Hz Halbbildwiederholrate, 288 Zeilen und 150 Samples ergibt sich 2,16MS/s, oder 0,46us pro Sample. Oder ist da noch ein Rechenfehler? z.B. Halbbild hat nur 144 Zeilen?

Der 8Bit-Wert würde von einem Flash-Wandler parallel an einem Port des ARMs zur Verfügung stehen. Der Flash-Wandler braucht sicher ein Triggersignal oder so. Der Beginn eines Bildes und jeder Zeile würde von einem speziellen Chip zu kurzen TTL-Signalen aufbereitet werden, die man auf Interrupt- oder Porteingänge legen kann.

In einem zweiten Durchlauf muß dann bei jedem Pixel sofort der vorherige Wert aus dem Speicher abgezogen werden, und dann die Differenz im Speicher abgelegt werden. Wenn man zuerst zwei Bilder sampelt und danach die Differenzbildung macht, wird der Speicherbedarf größer als 64kB - und bis jetzt habe ich nur ARMs mit bis zu 64kB gesehen.

Nach diesen zwei Sample-Durchläufen kann sich der ARM dann viel Zeit für Verarbeitung genehmigen (0,1s? Ist das viel?), bis er erneut zwei Frames holt.

Wäre schön, wenn ich meinen Bedarf durch Eure Antworten besser eingrenzen könnte.

Gruß
Tom.

[ogni42]

Erst mal: Du musst Dir überlegen, ob das Differenzbild auf Basis der Differenz zweier Halbbilder sinnvoll ist, da unterschiedliche Bereiche einer Szene abgebildet werden, nicht nur zeitlich, sondern auch räumlich. Ggfs. ist das ja in dieser Anwendung gewollt.

Allerdings: IIRC gibt es Kameras, die nur einen Frame immer wiederholen (auch in der Interlace-Darstellung). Das stammt noch aus der Zeit, als die CCDs mächtig teuer waren. Genaueres findet sich aber in der Doku des CCDs. Bei CMOS sollte das eigentlich nicht der Fall sein. Ins Datenblatt schauen hilft aber immer.

Ansonsten ist das bei der Auflösung kein Problem. Allerdings gibt es so etwas schon als Hardware in Form der C3088, bzw. mit einem ARM Chip als CMUCam2.

[toemchen]

Das mit den Halbbildern hab ich mir noch gar nicht so genau überlegt. Ideal wäre es, wenn hintereinander beide Halbbilder ausgelesen werden und gleich interlaced in den Speicher abgelegt werden. Dann ist der spätere Zugriff für die Auswertung einfacher. Vertikal will ich schon die volle Auflösung. (Und danach natürlich nochmal zwei Halbbilder mit der Differenzbildung. Also zwei volle Frames.)

Es soll ein ganz einfaches CMOS-Kameramodul für ca. 12€ verwendet werden.

C3088: Kostet doch 55€, und den verarbeitenden ARM brauche ich trotzdem. Der Wandler kostet gerade mal 4€. CMUCam2 umprogrammieren wäre eine Möglichkeit, aber das Ding hat auch seinen Preis.

[ogni42]

Ja, der Preis klingt gut, aber:
Beim Auslesen musst Du mit HSync und VSync synchronisieren. Auch dafür braucht's einen Chip, der Dir die Signale aus dem (F)BAS strippt. Kostet allerdings ebenfalls nicht die Welt.

Falls(!) die CMOS Kamera die Bilder interlaced liefert, kannst Du mit HSync und VSync gesteuert beim Ablegen der Pixel durch den Speicher wandern. Die Clock für den ADC liefert i.d.R der Sync-Chip (Philips stellt die m.W. her, den Chip gibt's bei reichelt, leider fällt mir die Typbezeichnung nicht mehr ein).

Bei einem Full-Frame (= zwei Halbbilder) brauchst Du schon bei 352/2 * 288 einen 64k großen Speicher. Die Subtraktion kannst Du ja in-place durchführen, musst dann aber auf Bereichsüberläufe achten.

[toemchen]

Wupps, konzentrierte Information. Danke für Deine Teilnahme.

Ich kann die CMOS-Kamera ja direkt an den Fernseher anschließen, dann wirds schon interlaced sein.

Das mit dem Sync-Chip wußte ich schon, der heißt LM1881N und kostet so 3-4€. Der gibt außer VSync und HSync auch ein Signal für Odd/Even-Halbbild aus.

Einen Pixelsync in der Zeile gibt es meines Wissens nicht, man hat nur Hsync für den Beginn der Zeile zur Verfügung und muß ab da den Flash-A/D für jedes Pixel selbst triggern. Vor allem natürlich, wenn ich horizontal nur jedes zweite Pixel erwischen will.

352 / 2 * 288 sind bei mir 50688, also müßte ich mit 64k Speicher zurechtkommen. Aber mal was anderes: Wie ist denn der Speicher überhaupt organisiert? Ist ja ein 32bit-Controller, hat dann das RAM auch nur 16k Speicherplätze á 32 Bit? Ach, ich hab einfach noch keine Ahnung von diesen Controllern.

Überläufe: Vielleicht kann man beim ersten Durchlauf noch einen Offset dazuaddieren, so daß kein Überlauf vorkommen kann? Notfalls gleich das LSB und alle Bits eins verschieben. Verschenkt man natürlich die halbe Graustufen-Auflösung. Oder reicht die Zeit pro Pixel on-the-fly für eine Entscheidung, bei einem drohenden Überlauf statt der Differenz Null abzuspeichern?

Hier noch, was ich überhaupt vorhabe:
www.robofriend.de/laserscanner.htm
Und meine Vorbilder/Informationsquellen:
http://b-duschinger.homepage.t-online.de/index.html
http://www.users.uswest.net/~kmaxon/...e/art9_137.htm

Gruß
Tom.

[ogni42]

Wenn der Chip keine Pixelclock ausgibt, könntest Du noch eine PLL dazu nehmen, die Dir die PCLK generiert. So bekommst Du schärfere Bilder.

Bei der Speicherorganisation der ARMe bin ich leider überfragt, sollte aber im Datenblatt stehen.

Bitschieben wird Dir nichts bringen, da 15-16 genauso -1 ergibt wie 7-8. Du muss schon das Ergebnis anschauen und im Falle eines Bereichsüberlaufes begrenzen. Bei der Geschwindigkeits des ARM ist das aber kein Problem, denke ich.

[toemchen]

Also ich muß zugeben, ich hab mir das Thema PAL-Videosignal und Sync-Signale noch nicht genau genug angeschaut. Der LM1881N genereriert folgende Ausgangssignale: VSync, Burst, Odd/Even und Composite Sync - letzteres scheint doch ein Pixelclock zu sein. Und ich dachte immer, ab jedem Zeilensync wäre so ein Videosignal nur noch ein Analog-Gewusel bis zum nächsten Zeilensync.

Das mit dem Bitschieben hatte ich so gedacht: Beim Dunkelbild LSB fallen lassen, nach rechts schieben und ein MSB mit Null auffüllen. Beim Signalbild dasselbe, aber MSB mit 1 auffüllen. Dann MUSS doch Signalbild minus Dunkelbild immer ok sein. Aber mit halber Graustufenauflösung.
Die zweite Möglichkeit mit Bereichsbegrenzung ist also schon besser, wenn die Rechenzeit ausreicht.

Jetzt muß ich mir doch die ARM-Datenblätter anschauen... Es sind halt so viele. ARM7, ARM9, ARM11, Hersteller Philips, Atmel, weitere... Ich blick da nicht durch. Ich fange mal mit Atmel an und versuche herauszufinden, was ARM7 - 9 - 11 bedeutet.

Ich überlege mittlerweile, ob ich überhaupt ein solches Modul wie http://www.embeddedartists.com/produ...2106_rs232.php nehmen soll. Ich muß ohnehin eine Platine mit dem Flash-Wandler und dem Syncgenerator machen, da kann ich eigentlich auch einen ARM direkt draufmachen. Einiges an Peripherie braucht er aber anscheinend schon...

[ogni42]

Nee, CSync ist das gemischte H/V-Sync Signal, V-Sync und C-Sync sind die Signale, mit denen Du die Steuerung der Zeilenläufe machst, Odd/Even sagt Dir, welches Halbbild gerade aktiv ist.

Deine Überlegung ist insofern richtig, dass dann kein Überlauf mehr Auftreten kann (theoretisch). Aber Du verdrehst die Daten völlig, so dass das Ergebnis nicht mehr das Gewünschte ist.

Auf mikrocontroller.net gibt es, glaube ich, ein gutes Intro zum Arm.

[toemchen]

Mittlerweile hab ich ein bißchen geschmökert...

Noch kurz zum Überlauf. Ich meine, die Graustufenauflösung durch Weglassen des untersten Bits auf 128 vergröbern, und das oberste Bit quasi als Offset beim Dunkelbild weglassen, und beim Signalbild setzen. Dann kann die Differenz nur zwischen 1 und 128 liegen. Soo verdreht sind die Daten dann auch nicht. Aber das sind Details.

Wichtig ist mir, welcher Prozessor?
Nach einigem Herumgelese stelle ich fest, hobbymäßig sind vor allem der Philips LPC21.. und der Atmel AT91.. verbreitet, beides sind ARM7. Was drüber liegt, brauche ich wohl nicht.
Viel wurde über die Geschwindigkeit diskutiert.
Ich glaube, die höchste Geschwindigkeit brauche ich beim Sampeln, aber gerade da sinds wohl nur ein paar Port- und Speicherzugriffe und da ist der Geschwindigkeitsvorteil eines ARM gar nicht so groß.
Bin daher am Überlegen, ob ich vielleicht auch mit einem ATMega64 zurechtkomme. Der wäre halt geradeaus 8Bit und bei meiner Anwendung, wo es nur große Mengen an 8bit-Daten herumzuschieben, bestenfalls zu vergleichen und aufzusummieren gilt, vielleicht sogar besser geeignet. Allerdings ist er fast teurer als der ARM, und einen externen Speicher muß ich auch dazufrickeln, was die Platine wieder aufwendiger macht.

Vielleicht muß man sich mal darüber klarwerden, was ich mit den gesampelten Bildern machen will.

Weiter oben im Thread habe ich schon einen Link auf meine Anwendung gegeben, es geht also im Prinzip darum, das Differenzbild Spalte (!) für Spalte durchzugehen und den hellsten Punkt zu suchen.

Vielleicht gibt es aber pfiffigere Verfahren als die sture Suche nach dem Maximum - zum Beispiel Mustervergleich mit einem einige Pixel breiten Peak. Das könnte dann fehlertoleranter bei einer Spalte mit verrauschten Daten und einem sehr schwach ausgeprägten hellsten Pixel sein. Oder man macht eine Plausibilitätskontrolle mit den benachbarten Spalten, wo ist dort der hellste Punkt? Diese Ideen vergrößern natürlich den Rechenaufwand.

Danach werden dann den hellsten Punkten anhand eines einmal aufgenommenen Kennfelds Entfernungen zugewiesen. Das erscheint mir einfacher als das herumjonglieren mit trigonometischen Funktionen. Und zuletzt steht ein Entfernungsprofil im Speicher, das über UART übertragen werden kann.

Das habe ich jetzt mal so explizit geschrieben, damit man den Rechenaufwand abschätzen kann.

Übrigens: Über das Videosignal habe ich mich bei Wikipedia schlau gemacht. Es ist schon so, ein S/W-Videosignal ist ab dem HSync nur noch ein analoger Verlauf der Grauwerte. Man kann also mit einem freilaufenden Algorithmus sampeln und muß eben über NOPs oder kleine NOP-Schleifen den Pixelclock anpassen, sowie die Pixel mitzählen. Man muß doch auch mit einem ARM ein ganz hartes Timing des Programmablaufs hinbringen, oder?

[ogni42]

Für Dich wäre der Mega162 interessant, da der ein externes Speicherinterface besitzt, an dem Du sehr einfach SRAM anschließen kannst. Und in 16k Flash geht schon einiges rein. Alternativ gehen auch der ATMega64 und 128 (auf AVRFreaks gibt's dazu ein schönes Auswhltool)

Über den Algorithmus muss ich erst mal nachdenken....

Das, was Du auf wikipedia gelesen hast ist richtig, stimmt aber so nur für eine analoge Aufnahmequelle. Dein Bild ist aber schon ortsdiskret (im CCD bzw. CMOS) und wieder nur in ein analoges, ortskontinuierliches gewandelt worden. Zum Testen ist das sicher nicht von Belang, zum genauen Messen allerdings sehr.