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
> 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.
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
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...
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
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
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.
Habt ihr ein Beispiel für einen FPGA und ein SRAM? Muss nicht unbedingt low cost sein. Nur low Size.
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?
Wenn du bga löten kannst, dann würde ich dir cellular sram empfehlen, wegen wenig Platz und der einfachen Ansteuerbarkeit, sowie Burstmöglichkeit.
> 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.
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
> 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.
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
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.
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
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)
> 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.
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.
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
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
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_Gate_Array#Innere_Struktur 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).
> 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.
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
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
> 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.
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
> 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.
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
Schau dir mal die Digikey Preise an, sind meistens besser als Farnell.
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
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
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-VIDEO-SK-UNI-G.htm Die Idee von Arndt find ich auch super. Das wäre ein guter Lösungsansatz.
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
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/boards/daughtercards.htm 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%2526CID%253D0%2526CAT%253D%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html?manu=Xilinx
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/developmenthardware/fpgafspcboards/mico32dspdevelopmentboard.cfm 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
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.