mikrocontroller.net

Forum: FPGA, VHDL & Co. Bildverbesserung Bildsensor


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte die parallelen Bilddaten (10bit), die von einem CMOS 
Bildsensor kommen und anschließend von einem Arm ausgewertet werden, 
zuvor durch einen FPGA leiten.

Der FPGA soll zunächst eine einfache Offsetkorrektur durchführen. Später 
vielleicht die ein oder andere simple Vorverarbeitung.

Da wie immer wenig Platz ist, kann ich mir keinen externen Speicher 
leisten.
Der FPGA sollte auch möglichst klein und "einfach" sein. Neben ein paar 
Schaltaufgaben (durchschleifen von IO's) hat er keine weiteren Aufgaben.

Er sollte nur möglichst viel Platz (Gates) für zwischengespeicherte 
Bilder haben. Außerden wäre es toll, wenn ich die Infos (1Bild) für die 
Offsetkorrektur im Flash ablegen könnte.

Könnt Ihr mir einen FPGA empfelen?

Danke schon mal!

Gruß Christian

Autor: Maik H. (littlechip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auflösung?

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VGA 640x480 GRAYSCALE

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der FPGA soll zunächst eine einfache Offsetkorrektur durchführen. Später
> vielleicht die ein oder andere simple Vorverarbeitung.

Wenn du die Schaltung so auslegst, dass der Arm auch Daten an den FPGA 
senden kann, dann wird daraus ein Ko-Prozessor statt nur 
Vorverarbeitung. Da kannst du sicher mehr rausholen.

> Er sollte nur möglichst viel Platz (Gates) für zwischengespeicherte
> Bilder haben.

Kannst du das etwas näher ausführen? Vor allem, ob du jetzt viel 
Speicherplatz haben willst oder viele Gates.

> Außerden wäre es toll, wenn ich die Infos (1Bild) für die
> Offsetkorrektur im Flash ablegen könnte.

Bedenke, dass das Schreiben (genauer das Löschen) im Flash langsam geht. 
Am besten, du schreibst mal, welche Bildrate du dir vorstellst.

> VGA 640x480 GRAYSCALE

Der Vollständigkeit halber: Ich nehme an, 8-bit Grayscale. Das wären 
dann 640x480x1 = 307200 Bytes.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal vielen Dank für Eure Antworten.

Ich habe mit FPGAs noch keine Erfahrung. Deshalb bin ich schon bei der 
Auswahl im Moment überfordert.

Zunächst soll der FPGA einfach zwischen den ARM und den CMOS Sensor 
geklemmt werden und alle Signale durchschleifen (SPI/I2C, DATEN, VSYNC, 
HSYNC,...).

Da der FPGA anhand der Signale mitbekommt wann ein Bild aufgenommen 
wird, soll er auch gleich noch die Steuerung der Beleuchtung übernhemen.

Die Kommunikation zwischen FPGA und ARM könnte z.B. über SPI laufen.

Wenn das Durchschleifen der Bilddaten funktioniert, dann will ich im 
FPGA ein Dunkelbild des Sensors ablegen. D.h. Bild in völliger 
Dunkelheit aufnehmen und "fest" im FPGA ablegen. Anschließend soll von 
jedem aufgenommenen Bild das Dunkelbild abgezogen werden. Eventuell 
sollte noch etwas Platz sein um noch ein paar andere Bilder im FPGA 
abzulegen.

Die Pixelclock des Sensors beträgt 80Mhz. Im Moment betreibe ich den 
Sensor mit 60Mhz. Vielleicht schaffe ich die 80 ja noch.

Ich dachte Gates = int. Speicher für Bilder . Sorry wenn ich mich geirrt 
habe.

Da wenig Platz ist, wäre für mich noch wichtig, dass der FPGA relativ 
kompakt ist. Ich schätze ich brauche ca. 20 Leitungen zum Sensor und ca. 
20 zum ARM. Eine UASRT, SPI, I2C Schnittstelle am Arm zum Datenaustausch 
ist vorhanden. Allerdings möchte ich für die Bilddaten schon das 
parallele Interface nutzen.

Der Sensor arbeitet mit 2,5V Logic. Damit muss der FPGA natürlich 
zurecht kommen.

Könnt Ihr mir einen FPGA empfehlen? Wie gesagt überfordert mich das 
Angebot etwas. Möglichst klein, einfach und mit viel Platz zum 
Zwischenspeichern von Bilddaten. (Vermutlich habe ich damit schon einen 
Widerspruch formuliert)

Danke nochmal.

Gruß Christian

Autor: The Imager (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das komplette Bild im FPGA zwischen zu speichern ist relativ sinnfrei. 
Dafür empfehle ich dir ein externes SRAM (sehr leicht anzusteuern, aber 
teuer) oder ein DDR2 (komplex, aber günstig).

Ein FPGA aus der Spartan-3 oder Cyclone-II/III Reihe wird's wohl tun. 
Dazu eben noch ein Speicherbaustein.

Wie viele FPS fährst du denn? 80MHz bei 640x480 ist ja nicht ohne...

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Moment läuft das Ding mit ca. 195 fps. Für einen weiteren 
Speicherbaustein habe ich leider keinen Platz.  An den Speicherbus des 
Arms kann ich mich leider nicht ohne weiteres anhängen.

Gibt es denn keine Möglichkeit das eine Bild für die Offsetkorrektur im 
FPGA abzulegen? (640x480x10bit)

Gruß Christian

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LowCost-FPGAs in Deiner "Wunsch"-Größe bieten nicht ausreichend
integrierten Speicher. Du solltest dir mal ein paar FPGA-Datenblätter 
von A,X,L anschauen.

Gruß,
SuperWilly

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon, aber dazu braucht es eben relativ große FPGA und die sind 
wieder teuer. Ein großes FPGA ist sicher auch größer als ein kleines und 
ein BGA Ram. Wenn es nicht unbedingt DDR2 sein muss, findet man mit 
SDRAM einen akzeptablen Kompromiss aus Komplexität, Geschwindigkeit und 
Kosten.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr ein Beispiel für einen FPGA und ein SRAM? Muss nicht unbedingt 
low cost sein. Nur low Size.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gib uns mal ein paar mehr Informationen:
- Welche Größe ist möglich?
- Könnt ihr BGA-Gehäuse verwenden?
- Wie komplex soll die Bildverarbeitung sein?

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du bga löten kannst, dann würde ich dir cellular sram empfehlen,
wegen wenig Platz und der einfachen Ansteuerbarkeit, sowie 
Burstmöglichkeit.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe mit FPGAs noch keine Erfahrung. Deshalb bin ich schon bei der
> Auswahl im Moment überfordert.

Dann empfehle ich dir dringend, mit einem einfacheren Projekt 
anzufangen, besonders wenn du es eilig hast. Das kostet im Endeffekt 
weniger Zeit.

> Habt ihr ein Beispiel für einen FPGA und ein SRAM? Muss nicht unbedingt
> low cost sein. Nur low Size.

Dann kommst du vielleicht mit einem "großen" FPGA im kleinen Package 
(ohne ext. SRAM) aus. Das spart Platz, wird aber nicht ganz billig. Je 
nach Wahl kann der dann auch einiges an Verarbeitung machen. Gib am 
besten mal konkret an, wieviel Platz auf dem Board vorhanden ist.

> Die Kommunikation zwischen FPGA und ARM könnte z.B. über SPI laufen.

Da hast du im FPGA freie Hand, also nimm für die Kommunikation das, was 
im ARM am einfachsten ist (solange es nicht zu viele Pins braucht, denn 
das kostet wieder Platz).

> Eventuell sollte noch etwas Platz sein um noch ein paar andere
> Bilder im FPGA abzulegen.

Das braucht auf jeden Fall für FPGA-Verhältnisse viel Speicher.

> Ich dachte Gates = int. Speicher für Bilder . Sorry wenn ich mich geirrt
> habe.

Nein. Gates = Logikressourcen = LUTs, die auch für Distributed RAM 
genutzt werden können. Daneben gibt es noch Flipflops und Block-RAM. 
(Die Begriffe kommen aus der Xilinx-Welt, aber bei A gibts die meines 
Wissens auch, sie heißen nur anders). Die 3 Speicherarten unterscheiden 
sich vor allem in Größe und möglichen Zugriffsarten. Für die Sache mit 
dem Dunkelbild gehen prinzipiell alle 3, abgesehen von der Größe. 
Daneben gibt es dann die Lösungen mit einem separaten RAM-Chip.

> Da wenig Platz ist, wäre für mich noch wichtig, dass der FPGA relativ
> kompakt ist.

Bei FPGAs sind die Fähigkeiten (LUTs, Flipflops, BlockRAM usw.) zum Teil 
vom Package (Größe/Pinzahl) unabhängig. Deshalb könnte wie gesagt ein 
größer FPGA im kleinen Package dir weiterhelfen; alternativ ein kleiner 
FPGA und ein externer RAM.

> Der Sensor arbeitet mit 2,5V Logic. Damit muss der FPGA natürlich
> zurecht kommen.

Das sollte kein Problem sein (würd ich nur sicherheitshalber vor der 
endgültigen Entscheidung noch mal prüfen). Allterdings kann der FPGA die 
Spannung nur Bank-weise einstellen, d.h. falls der Arm mit anderen 
Spannungen arbeitet sind zwangsweise einige Pins vergeudet und du musst 
schauen, dass die übrigen noch reichen.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

vielen Dank für die zahlreichen Antworten.

Was ich genau mit dem FPGA machen will weiß ich noch nicht. Sicher ist 
aber folgender Ablauf:

1. Nur Signale durchschleifen.
2. Dunkelbildkorrektur
3. Weitere Spielerreien mit Bildverarbeitung

Für 2. muss auf jeden Fall das Dunkelbild 640x480x10bit im FPGA 
hinterlegt werden.

Für 3. habe ich Dinge wie z.B. die Berechnung der Gesamthelligkeit, oder 
eine Überlagerung des aktuellen Bildes mit den letzten 10 Bildern im 
Kopf. Vermutlich werden die Bilder mit einer kleineren Auflösung (Hälfte 
oder 1/4) als 640x480x10bit erfasst. D.h. ich brauche nicht für 10 
Vollbilder Platz. 10 ist auch nur ein Beispiel. Wenn ich mal soweit bin, 
dann nehme ich was ich kriegen kann.

Die Platine ist ca. 70x70mm groß. Die Oberseite ist bereits komplett 
voll mit der ARM Logic und der Spannungsversorgung. Auf der Unterseite 
sitzt bis jetzt nur der CMOS Sensor (mehr oder weniger mittig) mit einer 
Größe von ca. 15x15mm. D.h. Es bleibt um den Sensor ca. 29x70mm Platz. 
Zur Not könnte ich auch noch eine weitere Platine für den FPGA 
hinzufügen. Das möchte ich aber eigentlich vermeiten, da dies Nachteile 
für die optische Abbildung bedeuten würde.

Die Lösung einen großen FPGA im kleinen Gehäuse zu nehmen interessiert 
mich. Was bedeutet teuer? 50€ bei Einzelstücken lässt sich verkraften.

BGA sollte kein großes Problem sein. Irgendwann muss man es ja mal 
lernen. Die Reworkstation dafür habe ich. Mit den Temperaturkennlinien 
muss ich mich noch beschäftigen. Totzdem habe ich das Gefühl, dass bei 
Reparaturen nicht BGA etwas angenehmer ist.

Ich habe bei Farnell nach "cellular sram" gesucht. Leider ohne Erfolg, 
aber  bis jetzt auch noch mit wenig Muse. Was versteht man unter 
Burstmöglichkeit?

Vielen Dank noch mal.

Gruß Christian

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Lösung einen großen FPGA im kleinen Gehäuse zu nehmen interessiert
> mich. Was bedeutet teuer? 50€ bei Einzelstücken lässt sich verkraften.

Mal als Beispiel für den Xilinx Virtex-4:

2 RAM-Block fasst 2 KByte (Parity-Bits nicht mitgerechnet), ein Bild ca. 
300 KByte, also 150 Blocks pro Bild. Die kleinsten Vertreter, die soviel 
haben, sind XC4VLX60, XC4VSX25, und XC4VFX60. Der 2. davon hat auch 
besonders viele DSP-Blöcke, was für Bildverarbeitung interessant sein 
könnte. Diese Chips sind quadratisch mit 27 mm Kantenlänge - schau mal, 
ob das passt. Wie es mit den Kosten aussieht kann ich leider nicht 
sagen, aber ich bin auch nicht sicher, ob die so im Laden verkauft 
werden.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Z.B. der XC4VFX60 kostet ab 700 Euro aufwärts.
Der billigste aus dem Sortiment von Xilinx & Lattice mit ausreichend 
Speicher müsste der LFE2M50E-6FN484C sein, den gibt es ab etwa 140 Euro, 
hier ist dann aber die Logik völlig überdimensioniert für dein Vorhaben.

4MBit SRAM mit 100 MHz und einen kleinen FPGA gibts aber schon für unter 
50 Euro

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dich mal bei Digikey um, einen Spartan 3 E/A/AN , wobei
der Memory-Generator die Serie A/AN nicht voll unterstützt.
Tip, größe so um 200-250k also 3s200 oder 3s250.

Sram, kommt auch als BGA, zusammen wird es dich nicht mehr als 20 Euro 
kosten.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow die Preise überraschen mich doch ein wenig. Da lohnt es sich ja doch 
zu versuchen ein SRAM unterzubringen. 27x27mm sollte gehen. Habt Ihr ein 
konkretes Beispiel für einen SRAM Baustein? Vorallem die Größe. 
Irgendwie habe ich durch Euch das Gefühl bekommen, dass sich ein 
etxerner Speicher lohnt.

Gruß Christian

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Such am besten mal bei farnell oder ähnlichen nach sram, die gibts dann 
in Größen von 1/2/4/8/16 MBit. Für deine Anforderungen bieten sich dann 
wohl Modelle mit 16Bit Datenbreite (32 gibt es auch, wenn dein gewählter 
FPGA genug Pins übrig hat) und 100MHz an. Gehäuse und Bauform dann je 
nach deinen Anforderungen.

Xilinx Spartan FPGAs sind hier soetwas wie Standard bei niedrigen 
Anforderungen, aber mit 80 MHz schon fast an ihrer Grenze (es geht 
sicher mehr, nur da muss man dann genau wissen was man tut). Die Lattice 
ECP Serie ist da deutlich leistungsfähiger - ich weiß allerdings gerade 
nicht, wie es da mit freien Entwicklungstools aussieht. Im allgemeinen 
sollte man natürlich bei einem Hersteller bleiben, das spart Zeit.

Eine Größe von 20k LUT sollte völlig ausreichend sein. (chris schrieb 
oben 200k, meinte aber Gates)

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 27x27mm sollte gehen.

Das war für den einen FPGA mit genug RAM drin. Reine RAM Bausteine sind 
kleiner, aber dann musst du ja einen kleinen FPGA und einen RAM 
unterbringen. Kann dann aber natürlich auch ein sehr kleiner FPGA sein.

Für den Speicher hab ich ohne lange Suche einen SDRAM mit 512k*16 Bits, 
6x8 mm BGA bei Farnell gefunden. Da solltest du dich aber erstmal sehr 
viel genauer umsehen und eine fundierte Entscheidung treffen.

Für einen relativ kleinen FPGA (für heutige Verhältnisse) hab ich mir 
mal den Spartan-3 angesehen. Die gehen ab 16x16 mm VTQFP los.

Fazit: Kleiner FPGA + kleiner Speicher kommt dich vom Platz her 
wahrscheinlich billiger als ein großer FPGA.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Vergiss bei der Platzberechnung nicht die Leitungen und den 
Kleinkram (z.B. Kondensatoren). Gerade bei getrenntem FPGA/Speicher 
müssen die beiden ja auch verbunden werden.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, vielen Dank!

Ich werde mal in der Richtung SRAM + Spartan suchen.

Wisst Ihr, ob es irgendwo ein für mich gut passendes Entwicklungskit, 
Schaltungsbeispiele und Tutorial gibt?
Quasi als Vorlage. Besonders wegen dem umliegenden Kleinkram.

Wie ist das mit dem Programmspeicher. Macht es bei meiner Anwendung Sinn 
den Programmcode und das Dunkelbild bei jedem Start in den FPGA zu 
kopieren, oder gibts da was besseres?

Viele Grüße,
Christian

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Wenn ich bei Farnell suche, dann finde ich folgendes:

XILINX - XC3S100E-4TQG144C - FPGA,SPARTAN-3E,2150CELLS, 144TQFP
Frequenz:572MHz

Jan M. schreibt, dass die Spartans mit 80Mhz schon fast an ihrer Grenze 
sind. Wie ist dann die bei Farnell angegebene Frequenz zu verstehen?

Außerdem verstehe ich den Unterschied zwischen Gates  LUTs  Cells noch 
nicht ganz.

Gruß Christian

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frequenz mit der du dein FPGA betreiben kannst hängt stark von der 
inneren "Schaltung" ab. Die Spartans sind da nicht die schnellsten. 
Einfache Zähler laufen beispielsweise mit 160 Mhz. Mit einer CPU landest 
du dann bei 40 Mhz. Komplexere Schaltungen eventuell noch langsamer. 
Dann gibt es aber auch Tricks (z.B. Parallelverarbeitung/Pipelining) mit 
denen man die Arbeitsfrequenz wieder erhöhen kann.

> Außerdem verstehe ich den Unterschied zwischen Gates  LUTs  Cells noch
> nicht ganz.

Die kleinste Einheit mit der du etwas anfangen kannst sind die LUTs. 
Diese werden wieder zu größeren Einheiten (Slice/CLB) zusammengefasst.

http://de.wikipedia.org/wiki/Field_Programmable_Ga...

Genauere Auskunft gibt dir das Datenblatt des Herstellers.

Die Anzahl Gates kannst du eigentlich ignorieren. Die errechnet sich 
(sehr optimistisch) nach der Anzahl der Transistoren die mit dem FPGA 
ersetzen könnte. Wichtig ist die vorhandenen LUTs, Blockrams, 
Multiplier, DSP-Blöcke usw. (alles je nach Anwendungszweck).

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie ist das mit dem Programmspeicher. Macht es bei meiner Anwendung Sinn
> den Programmcode und das Dunkelbild bei jedem Start in den FPGA zu
> kopieren, oder gibts da was besseres?

Den "Programmcode" (FPGA-Konfiguration) musst du beim Start neu laden, 
wenn du keinen Non-Volatile-FPGA hast. Das braucht aber einen weiteren 
externen Chip für das Config-ROM. Es gibt auch FPGAs mit internem 
Config-ROM, so dass kein weiterer Chip nötig ist. Ich meine, die 
Spartan-3N wären so welche (N für nonvolatile).

Das Dunkelbild würde ich auf jeden Fall bei jedem Start neu aufnehmen. 
Erstens brauchst du dann keinen Nonvolatile-Speicher dafür, und zweitens 
könnte sich das Dunkelbild ändern... und jetzt sag nicht, nein es ändert 
sich nicht, mit solchen Annahmen bin ich oft genug auf die Schnauze 
geflogen ;)

> Jan M. schreibt, dass die Spartans mit 80Mhz schon fast an ihrer Grenze
> sind. Wie ist dann die bei Farnell angegebene Frequenz zu verstehen?

Wie Mike schon sagte, hängt die maximale Frequenz von der Konfiguration 
("Programm") ab. Da du scheinbar ein blutiger Anfänger bist, würde ich 
eher mal von 40 MHz ausgehen. Letztendlich hängt diese Frequenz (wie 
auch die endgültige Performance, was ja nicht dasselbe ist) davon ab, 
wie gut du die Konfiguration optimieren kannst.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also die 80Mhz will ich schon erreichen. Darum bin ich jetzt etwas 
verunsichert, ob ich es mit einem Spartan probieren soll.

Hauptsächlich wird der FPGA mit dem durchschleifen von Signalen und den 
dazuaddieren von Werten auf den 10-Bit Datenbus beschäftigt sein.

Kennt ihr noch einen Chip mit dem ich bei schlechterer Programmierung 
nicht gleich an der Leistunsgrenze bin?

Alle gängigen Kameras haben das Dunkelbild einmal fest einprogrammiert. 
Sonst müsste man die Kamera ja jedes mal beim Start abdecken. 
Hauptsächlich werden damit die statischen Verstärkungsfehler der 
einzelnen Pixel eliminiert. Es gibt noch Verfahren, die die externe 
Temperatur zusätzlich berücksichtigen.

Trotzdem könnte ich natürlich das Dunkelbild im Flash des ARMs speichern 
und jedes mal beim booten in den FPGA kopieren.

Wieviele Kleinteile baucht es denn außenrum? Wo kann ich denn ein 
Schaltungsbeispiel finden?

Vielen Dank!
Gruß Christian

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe oft mit genau solchen Problemstellungen zu tun und ich denke, 
dass gerade bei einem 640x480 Bild (Graustufen) man mit nur einem FPGA 
zurechtkommen könnte (ohne SRAM). Ist zwar ein Krampf aber es müsste 
gehen.

Zunächst müsste man wissen, wie die Bilder beschaffen sind oder genauer 
genauer gesagt die Sensoren. Die defekten Pixeln muss man ja so oder so 
irgendwo hinterlegen (EEPROM). Das restliche Bild (Referenzbild) würde 
ich mit z.B. RLE codieren.

Theoretisch müsste man nur die Differenzen zwischen den Pixeln 
hinterlegen. Erfahrungsgemäß unterscheiden diese sich um wenige Bits -- 
die werden dann auch im interenen FPGA-Speicher hinterlegt.

Andere Möglichkeit ist einfach eine Zeile abzuspeichern 
(Schwarz/WEiß-Vergleich), daraus hast Du eine Kennlinie, die Du auf das 
ganze Bild anwendest.

Das sind nur Ideen ;-) Wenn man beliebig rumspinnt kommt man vielleicht 
sogar mit einem CPLD aus ;-))

Grüße,

Kest

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> also die 80Mhz will ich schon erreichen. Darum bin ich jetzt etwas
> verunsichert, ob ich es mit einem Spartan probieren soll.
>
> Hauptsächlich wird der FPGA mit dem durchschleifen von Signalen und den
> dazuaddieren von Werten auf den 10-Bit Datenbus beschäftigt sein.

Die 80 MHz kann ein Spartan bei richtiger Programmierung und bei der 
Aufgabe auf jeden Fall.

> Kennt ihr noch einen Chip mit dem ich bei schlechterer Programmierung
> nicht gleich an der Leistunsgrenze bin?

Ich nicht. Ich würde statt dessen die Bildrate runterdrehen, so dass der 
FPGA weniger leisten muss. Wenn du mehr Erfahrung hast, dann kann es 
schneller werden.

> Trotzdem könnte ich natürlich das Dunkelbild im Flash des ARMs speichern
> und jedes mal beim booten in den FPGA kopieren.

Wenn das Dunkelbild da rein passt, dann mach das. Bedenke, dass es um 
ca. 300 kB geht.

> Wieviele Kleinteile baucht es denn außenrum?

Am besten, du suchst dir (beispielhaft) einen FPGA aus und schaust mal 
ins Datenblatt. Denk auch an den zusätzlichen Platz für 10 (?) 
Hochfrequenz-Leiterbahnen (80 MHz sind ja nicht ohne).

> Alle gängigen Kameras haben das Dunkelbild einmal fest einprogrammiert.
> Sonst müsste man die Kamera ja jedes mal beim Start abdecken.

Das wäre die Alternative.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar. Hab mal wieder ne Menge gelernt.

Was hat es eigentich mit den DSP Blöcken auf sich?
Könnte mir das beim rechnen nicht enorm helfen? Oder haben das wieder 
nur die Großen FPGAs

Gruß Christian

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was hat es eigentich mit den DSP Blöcken auf sich?
> Könnte mir das beim rechnen nicht enorm helfen?

Das sind spezielle "hard cores" für DSP-Aufgaben. Wenn deine 
Bildverarbeitungsaufgaben (passende) DSP-Aufgaben mit einschließen, dann 
sind die schneller und platzsparender als wenn du dasselbe mit normalen 
FGPA-Ressourcen (z.B. LUTs) machst.

Beispielhaft aus dem Virtex-4 Datenblatt:

The DSP48 slices support many independent functions, including 
multiplier, multiplier-
accumulator (MACC), multiplier followed by an adder, three-input adder, 
barrel shifter,
wide bus multiplexers, magnitude comparator, or wide counter. The 
architecture also
supports connecting multiple DSP48 slices to form wide math functions, 
DSP filters, and
complex arithmetic without the use of general FPGA fabric.

> Oder haben das wieder nur die Großen FPGAs

Das haben vor allem die neuen, und u.U. von denen nur ausgewählte. Die 
Größe hat weniger mit dem "ob" als mit dem "wie viele" zu tun.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich dann werde ich mir mal den Spartan 3A DSP und ein externes SRAM 
mal genauer ansehen. Hoffentlich bekommt man den noch etwas gümstiger 
als bei Farnell (112€)

Gruß Christian

Autor: Chris S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal die Digikey Preise an, sind meistens besser als Farnell.

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei allen Anwendungen mit Bildsensoren und FPGAs ist das vorhanden RAM 
fast immer der Schlüsselfaktor.

Wenn eine reine Offsetkorrektur (Dunkelbild) gemacht werden muss, ist 
zuerst zu unterscheiden, ob dieses Dunkelbild bei jeder Gerätebenutzung 
dynamisch erstellt wird oder einmal für jeden Bildsensor erfasst und 
anschließend in ein FPGA/Flash/RAM abgelegt wird. Allerdings sollte man 
berücksichtigen, dass die Dunkelbilder stark temperaturabhängig sind und 
oft mit zusätzlichem Rauschen überlagert sind.

Der Platzbedarf ist NICHT 640x480x10 Bit, da ein Dunkelbild i.d.R. 
kleine Pixelwerte enthält. Gespeichert werden sollte der mittlere 
Dunkelwert (Offset) des Bildes sowie die jeweilige Differenz der 
Pixelwerte zu diesem Offset. Signed 8 Bit sollten hier ausreichend sein. 
Bei guten Sensoren reichen auch signed 4Bit. Im 8 Bit Fall werden 
demnach 640x480x 8 Bit = 2457600 Bit benötigt.

Folgende FPGAs (jeweils das kleinste geeignete FPGA der jeweiligen 
Serie) von folgenden Herstellern (alphabetisch) könnte genutzt werden (8 
Bit Fall):

Altera:
EP2S60 (Stratix II)
EP3C80 (Cyclone III)
EP3SL110 (Stratix III)

Lattice:
ECP2M50 (ECP2M)

Xilinx:
4VLX60 (Virtex 4LX)
4VSX35 (Virtex 4SX)
4VFX40 (Virtex 4FX)
5VLX85 (Virtex 5LX)

Alle der o.g. FPGAs haben i.d.R. genügend Resourcen für Logik und 
DSP-Aufgaben. Ein Preisvergleich lohnt sich auf jeden Fall. Ich 
persönlich habe gute Erfahrungen mit dem ECP2M50 Baustein gemacht (aber 
auch alle anderen Bausteine sind extrem leistungsfähig). Einige der oben 
gelisteten Bausteine sollten auf jeden Fall <100EUR kosten. Hier kann 
ich auch nur raten mit den jeweiligen Distributoren direkt zu sprechen. 
Oft gibt es große Unterschiede zwischen den Preisen im Netz und in der 
Realität ;-)

Was natürlich auch geht (wenn genügend Platz ist), ist es ein kleines 
kostengünstiges FPGA (<10EUR) und ein ASRAM (~4MBit <10EUR, beim ASRAM 
benötigt man keine zusätzliche RAM-Controller Logik) zu benutzen.

Kostengünstige Serien der FPGA Hersteller sind:

Altera:
Cyclone II
Cyclone III

Lattice:
XP2
ECP2

Xilinx:
Spartan3
Spartan3A
Spartan3E

Mein persönlicher Favorit ist der XP2, da ich dann kein zusätzliches 
Config-Flash brauche und mein Code dadurch auch nicht kopierbar ist.

Viel Erfolg und viele Grüße
Arndt

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

die Idee das Dunkelbild mit 4 bis 8 Bit signed Variablen ausgehend vom 
Mittelwert zu berechnen ist super!

Gibt es ein Buch oder ähnliches in dem man soetwas nachlesen kann. So 
einfach es ist, wäre ich vermutlich trotzdem nicht so schnell darauf 
gekommen.

Ich bin mittlerweile davon überzeugt, dass meine Schaltung mit einem 
zusätzlichen Speicher deutlich flexibler ist.
Gerne würde ich auch den FPGA ein paar Mittelwerte von Teilbildern 
ausrechnen lassen.

Ich hatte deshalb an einen Spartan 3 Adsp mit externem SRAM gedacht. 
Hast Du da auch eine Empfehlung? Bzw. einen besseren Vorschlag? Ein 
DevBoard auf dem die Bauteile vorhanden sind wäre auch nicht schlecht. 
Eventuell kann ich im FPGA auch noch ein bisschen rechnen bevor das 
nächste Bild kommt.

Ein ConfigRam brauche ich glaube ich nicht, da ich vorhabe das FPGA 
Programm zur Laufzeit aus dem angeschlossenen ARM zu kopieren. 
Allerdings habe ich noch keine Idee wie das funktionieren kann. 
Vermutlich über SPI.

Ist es bei Offsetkorrekturen nicht üblich einen Gesamtfaktor für die 
Temperatur mit einzuarbeiten und diese fortlaufend zu messen?

Gruß Christian

Autor: Gerd N. (mrgne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub Spartan 3A DSP ist kein schlechter Ansatz wenn man nicht auf 
Spartan6 warten will. Es gibt ein Video Starter Kit von Xilinx. Ich 
glaub aber das das ein wenig übertrieben wäre. Allerdings sind die 3A 
DSP auch nicht so ganz billig was ich weis.

http://www.xilinx.com/products/devkits/DO-S3ADSP-V...

Die Idee von Arndt find ich auch super. Das wäre ein guter 
Lösungsansatz.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip suche ich ja "nur" ein FPGA Developmentboard mit externem 
SRAM. Das Videokit für 1500$ ist da auf jeden Fall etwas oversized.

Gibt es soetwas nicht für ca. 200€ ?

Gruß Christian

Autor: Gerd N. (mrgne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Spartan 3 Starter Kits gibts auch Daughter Cards mit 512K Sram 
wenn das reicht und falls man sie bekommt.

http://www.xilinx.com/products/boards/DO-SPAR3-DK/...

Ansonsten die ML5xx von Xilinx haben alle ZBT SRAM drauf.

Vielleicht findest ja hier auch was.

http://www.em.avnet.com/evk/home/0,1719,RID%253D0%...

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

die großen Boards von Avent und Xilinx sind nicht schlecht, da diese 
wirklich alle erdenklichen Schnittstellen enthalten. Denn wenn man 
ersteinmal angefangen hat Blut zu lecken, dann fehlt garantiert 
irgendeine Schnittstelle oder Speicher. Soweit ich das übersehen kann, 
kommt man mit diesem Videokit so schnell nicht an eine Grenze, auch ein 
Bildsensor ist mit dabei.

Auch ein sehr schönes Board ist auch das Board von Lattice mit dem 
ECP2-50:
http://www.latticesemi.com/products/developmenthar...

Das enthält auch alle erforderlichen Komponenten, sowohl SRAM, wie auch 
einen DDR SO-DIMM Steckplatz. Das Board liegt bei $795.00

--

Noch einige Sätze zur Temperaturkompensation.
Der beobachtbare Offset bei einer erhöhten Temperatur setzt sich aus 
verschiedenen Anteilen zusammen. Im Pixel sind das die Leckströme der 
Dioden und die Offsets der Schwellenspannungen der Transistoren. Beide 
Komponenten haben ein anderes Bildungsgesetz. Die Leckströme verdoppeln 
sich z.B. alle ~9°C. Nach der Pixelelektronik kommt meistens eine 
CDS-Stufe mit Operationsverstärker, diese sind meistens sehr gut 
auskompensiert, weisen aber dennoch einen gewissen Temperaturoffset auf. 
Mit anderen Worten der beobachtbare Temperaturoffset ist ein Gemisch aus 
verschiedenen Signalkomponenten, die sich außerdem von Pixel zu Pixel 
leicht unterscheiden.

Demzufolge gibt es auch sehr viele unterschiedliche (und teure) Ansätze 
der Temperaturkompensation. Der einfachste Fall ist die Kompensation 0. 
Ordnung, eine reine Offsetkompensation (wie weiter oben schon 
angedeutet). Das Temperaturverhalten kann man dann näherungsweise durch 
einen Polynom oder verschiedene Splines beschreiben. Diese beziehen sich 
dann auf den weiter o.g. mittleren Offset.

Viele Bildsensoren machen das z.T. automatisch. Dazu gibt es sog. 
Schwarzzeilen und Schwarzspalten. In diesen wird der mittlere Offset 
gemessen und danach der analoge Korrekturwert an den Eingang der 
CDS-Stufe gelegt und abgezogen.

Hochwertige Kameras machen dagegen zwei Aufnahmen. Eine mit Belichtung 
und eine Aufnahme mit geschlossenem mechanischen Shutter und identischer 
Belichtungszeit...

Viele Grüße
Arndt

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.