Hallo FPGA Fans, ich habe eine CMOS Kamera. Diese erzeugt ein Bild mit 640x480 Punkten. Jeder Pixel 12 Bit. Für meine Berechnung bin ich davon ausgegangen das jeder Pixel mit 2 Bytes abgespeichert wird. Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das 640x480x2x100 = 61,44MByte Der Speicher muss so groß sein das maximal 2 Bilder reinpassen. Demnach muss der Speicher 640x480x2 = 614,4kByte groß sein. Da ich sehr scnell zum Ergebnis kommen muss, schließe ich erst mal die DDR aus, da diese für die Umsetzung zu vielZeit benötigen. Ich hatte so an einen FIFO von Cypress gedacht, doch als ich dann den Preis sah (mehere 100€) viel ich fast vom Hocker. Der Block RAM im FPGA ist leider etwas gering um 1 Bild zwischen zu speichern. Jedoch ist der Block RAM sehr einfach anzusteuern. Gibt es so einen Speicher nicht auch für extern nur halt etwas größer?
Wie sieht es denn aus mit Compact Flash oder diesen ganzen Handy Flash Speichern sind diese schnell genug?
Was spricht denn gegen klassischen SDRAM. Bei 100MHz angebunden sind laecherliche 64MB/s kein thema.
Für SDRAM benötigt man doch ein SDRAM Controler oder sehe ich das falsch?. Ich möchte einfach die Adresse und Daten anlegen und dann werden die Daten dort gespeichert oder von dort gelesen. Beim SDRAM muss man doch die Speicher refreshen. Ich habe gerade Ferroelektrischen RAM gefunden nur ist dieser mit maximal 20MHz zu langsam.
Der magnetorestistiver RAM ist leider auch zu langsam ca 28MHz
Nichflüchtiger SRAM von Cypress ist schon 50MHz schnell. Jedoch wird der Speicher schon sehr teuer
Klassisches S-RAM, z.B. 4 Bausteine mit 8 Bit Busbreite parallel. Macht dann ca 16MByte/s oder 62ns Zugriffszeit. Sollte doch handelsüblich sein.
@Martin: Schau Dir mal QDR-SRAM an. Ist im Vergleich zum SDRAM teurer, hat aber definierte Latenzen und Datenraten. Duke
Ich hatte noch etwas vergessen :-) Ich bekomme die Daten vom Bildsensor (12Bit) mit einem 72,5MHz Takt. Daher fallen die langsamen Baustein weg :-) Daher müssen die Bausteine schon mindestens 72MHz könnne. Da ich die Daten auch noch auslesen muss :-) müssen die Speicherbausteine noch schneller sein. Ich gelaube ich komme um so einen DDR Speichercontroller nicht vorbei. :-((
Ich würde 3 x 256kx16 statisches RAM mit 10ns nehmen. Zusammen mit (schnellen) Adressdekodern/Zählern sollten 10 € dafür reichen.
Haste mal so ein Beispiel für statischen RAM mit 10ns?
Digikey hätte in 10ns z.b. IS61WV5128BLL-10BLI IS61LV5128AL-10TLI IS61WV10248BLL-10TLI IS61WV51216BLL-10TLI IDT71V424S10YG8 IDT71V424S10YG8 IDT71V424S10YG8 CY7C1049DV33-10VXI IDT71V424S10YG IDT71V424S10PHG CY7C1049DV33-10ZSXI CY7C1051DV33-10BAXI IDT71V424L10PHG CY7C1059DV33-10ZSXI
Samsung K6R4016 oder auch IS61WV25616BLL-10TL, ....
So ein Quad Data Rate SRAM sieht schon sehr interessant aus CY7C1314KV18-250BZC Das Datenbaltt muss ich mir noch mal in Ruhe durchlesen :-)
Martin schrieb: > Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das > 640x480x2x100 = 61,44MByte Speichert die Kamera wirklich RAW-Bilder weg? Oder wird vielleicht schon komprimiert? Gib mal den Link zu der Kamera bekannt. Wo ist denn Dein Interface-Punkt?
Martin schrieb: > Das Datenbaltt muss ich mir noch mal in Ruhe durchlesen :-) Die gibt's bestimmt auch im DIL-Gehäuse!
Das ist eine Kamera von Aptina. Es werden die Rohdaten 12Bit parallel rausgegeben.
>Die Leerzeilen verschlechtern aber die Zugriffszeit ;-)
schon klar, aber das hätte länger gedauert als die Suche +
kopieren und hier einfügen
>Die Leerzeilen verschlechtern aber die Zugriffszeit ;-)
schon klar, aber das entfernen hätte länger gedauert als die
Suche + kopieren und hier einfügen
So ein statischer SRAM ist schon eine wirklich gute Alternative. Gibt es Diesen auch als Dual SRAM der möglichst wenig Leitungen benötigt?
Ich hab mal einen 40MHz 8Bit Stream auf ein damals noch langsameres SDRAM Speichermodul geschrieben. Das mit dem Refresh ist kein Problem. Den kann man auch mit den 27MHz machen. Ich weiß noch, dass man das Timing etwas geschickt sortieren musste. Aber dann ging es. Ok man braucht ein CPLD (oder FPGA) dafür. Achja ... ich hatte die 8 Bit auf alle 64Bit verteilt. Dann war es also, als ob man mit nur 5MHz auf das SDRAM schreibt.
möglich http://www.digikey.de/product-search/de?lang=de&site=de&KeyWords=sram+10+ns dann -> Speicher und mal schauen was es so alles gibt ..
Muss man diese statische RAMs eigentlich refreshen oder sind die USERFREUNDLICH
Martin schrieb: > statische RAMs eigentlich refreshen Na komm' schon, warum heissen die wohl "statisch"???
Vielen Dank für die Infos :-) Das hat mir schon mal weiter geholfen. Jetzt muss ich mir noch das richtige Modell aussuchen.
>Für SDRAM benötigt man doch ein SDRAM Controler oder sehe ich das >falsch?. >Ich möchte einfach die Adresse und Daten anlegen und dann werden die >Daten dort gespeichert oder von dort gelesen. Beim SDRAM muss man doch >die Speicher refreshen. Aber dafür hast du doch den FPGA. Das macht die State-Machine für die Ram-Bausteine und die Refresh-Zyklen. Es braucht da keinen Controller dafür. Den Core für Rams kannst du kaufen, es gibt auch offene Implementierungen. Und meinen eigenen hatte ich in weniger als zwei Wochen geschrieben. (und eine Menge dabei gelernt)
Martin schrieb: > Das ist eine Kamera von Aptina. Es werden die Rohdaten 12Bit parallel > > rausgegeben. Und warum reduzierst Du die nicht wie bei DVI zu 3 Bytes je Doppelbild? Das geht mit einem simplen FiFo 2 Worte a 12 auf 24 und ausgangsseitig ein 8 Bit Anschluss. Wenn man das verdoppelt kommt man auf eine Rate von 4 Worten bei 16 Bit = 2 SRAMs parallel. 4 Worte sind 25 Hz. Bei 640x480 ein Klacks. Noch einfacher 3 RAMs für je 2x4 Bit sequentiell , also Nibble 1 von Wert 1 + Nibble 2 von Wert 2 Nibble 1 von Wert 1 + Nibble 2 von Wert 2 Nibble 1 von Wert 1 + Nibble 2 von Wert 2
@ Michael Das habe ich nicht ganz verstanden. Du machst aus 2 Bilder 1 Bild?
An einen DDR RAM Controller wollte ich mich nocht nicht wagen. Da dies alles schnell fertig werden muss, wollte ich lieber einen statischen RAM verwenden. Ich hoffe mal das diese auch noch 4 Jahre zur Verfügung stehen. Von welcher FIRMA sollte man denn den statischen RAM kaufen? Nicht das dieser in 2 Wochen abgekündigt wird.
Soll dies ein Produkt werden, oder ist es ein Hobby- oder Forschungsprojekt? Willst Du einmal ein paar Bilder raus holen oder kontinuierlich Bilder aufsammeln?
Martin schrieb: > Von welcher FIRMA sollte man denn den statischen RAM kaufen? Nicht das > dieser in 2 Wochen abgekündigt wird. Cypress und IDT bauen ihr zeug sehr lange. Wir habern IDT FIFOs im Einsatz, das sind seit 2004 die gleichen. Ich würde darauf achten, dass es eine Bauform und Anschlussbelegung ist, die es auch bei anderen Herstellern gibt, so kannst du notfalls ausweichen.
Es soll ein Produkt werden. Die Bilddatenstream soll kontinuierlich kommen nach Möglichkeit zwischen 50 bis 100 Bilder pro Sekunde. Ich habe mir folgendes überlegt. Ich werde 2 statische RAMs verbauen. Die Kamera ist momentan direkt mit dem FPGA verbunden. Die Bilder werde ich immer abwechselnd in die RAMs schreiben. Also das 1. Bild in den SRAM und das 2. Bild in den anderen SRAM. Wenn ich das 2. Bild im 2 SRAM abspeicher werde ich das 1. Bild aus dem 1. SRAM auslesen und übertragen. Demnach benötige ich 32 Datenleitungen und insgesamt 38 Adressleitugnen. Das sind natürlich schon recht viele Leitungen. Mit einem DDR3 Speicher wäre dies sicherlich viel kompakter und preiswerter, aber ich muss momentan schnell zum Ziel kommen.
Martin schrieb: > Wenn ich das 2. Bild im 2 SRAM abspeicher werde ich das 1. Bild aus dem > 1. SRAM auslesen und übertragen. Der Vollständigkeit halber, um ein ganzes Bild zu bekommen, wie das System aussehen soll: Wie und wohin werden die Daten übertragen? Wohl doch nicht mit USB 2.0 HS zu einem PC? Und vielleicht auch: Was wird dann damit auf dem PC gemacht?
Martin schrieb: > Ich bekomme die Daten vom Bildsensor (12Bit) mit einem 72,5MHz Takt. > Daher fallen die langsamen Baustein weg :-) Schalte 4 Stück im Zeit-Interleave. Dann brauchst du nur noch 20 MHz Speichertakt.
Für kontinuierlich würd ich aber einen FIFO nehmen, da geht das viel besser zu streamen. Oder einen FIFO-Wrapper für einen SDRAM Controller. Ist aber schon was für Experten dann. Und wo soll das dann hin? In den PC? Da brauchst du mindestens Gigabit Ethernet, oder USB 3.0. USB 3 würde sich da wegen UVC anbieten. Das geht mit dem neuen FX3 von Cypress sehr gut. Der hat auch ziemlich viel interne DMA Puffer, da könnte der FIFO kleiner ausfallen...
Martin schrieb: > Michael > Das habe ich nicht ganz verstanden. Du machst aus 2 Bilder 1 Bild? Punkt, nicht Bild. Du bekommst 3 Nibbles (4 Bits) je Punkt. Du kannst 2 Punkte A,B so ordnen: AAAAAAAA AAAABBBB BBBBBBBB oder so ordnen: AAAA BBBB AAAA BBBB AAAA BBBB CCCC DDDD CCCC DDDD CCCC DDDD Du sammels als 2x2 Punkte und speichers jeweils 3 nibble in 3 verschiedene RAMs AAAACCCC + BBBBDDDD + AAAACCCC + BBBBDDDD + AAAACCCC + BBBBDDDD Die 12 A sind jeweils 12 Bit, die 12 B auch. Ich habe sie jetzt nicht nummeriert. Der Vorteil dieser Method ist, dass man bei Auslesen die Möglichkeite hat, nur ein einziges RAM zu durchsuchen, um mit einer Leseoperation im Nachhinein die höchsten Nibbles von gleich 2 Punkten einzulesen, um ein vereinfachtes Vorabbild zu bilden oder ein Histogramm zu entwickeln. So was musste ich mal machen. Ansonsten schreibst Du einfach wie in der Empfehlung 1 jeweils 2 Punkte auf 3 Bytes. Geht mit einem 24:8 Fifo am einfachsten.
Ich habe gesehen das die meisten SRAMs die für mich in Frage komme asynchrone SRAMs sind. Demnach gibt es dort keine Clock Leitung. Ich habe bis jetzt immer nur mit synchronen Speichern gearbeitet. Wie kann man sich das bei asynchronen SRAMs vorstellen? Ich die Adressleitungen, Datenleitungen und WR Leitungen. Wenn ich die Daten und die Adresse angelegt habe, dann setze ich die WR Leitung und die Daten werden übernommen. Wenn ich jedoch gleichen einen ganzen Stream aus mehreren 100 Bytes in SRAM schreiben möchte dann lasse ich die Schreibleitung aktiviert und änder die Daten und die Adressleitung. Dadurch werden die Daten in die nächste Adresse geschrieben. Bei FPGA benutzt man dann so einen 100MHz oder 200MHz Takt um die neuen Daten und Adressen zu erzeugen. Muss man bei den asynchronen SRAMs besser wenn man zuerst die Adresse erhöte und dann die Daten ändert, so das die Daten an der alten Adresse nicht ausversehen überschrieben werden?
Die FIFOs von Cypress sind sehr interessant. Jedoch kosten die größeren FIFOs bereits 1000€ :-) und das ist deutlich zu teuer :-)
Momentan würde ich diesen Baustein bevorzugen: IS61WV51216BLL-10TLI
Mal als kleine Anregung: Bei mir in der Arbeit wird ein 5 Megapixel Farbchip verbaut. Der besitzt einen Farbfilter und hat somit "nur" 8 Bit Helligkeitsinformation pro Pixel. Hinterher wird mittels einer Bayer-Konvertierung das Bild auf 24 Bit Farbtiefe hochgerechnet. Das ist ein Vorgehen, dass nicht umsonst von vielen praktiziert wird.
Martin schrieb: > Wenn ich jedoch gleichen einen ganzen Stream aus mehreren 100 Bytes in > SRAM schreiben möchte dann lasse ich die Schreibleitung aktiviert und > änder die Daten und die Adressleitung. Dadurch werden die Daten in die > nächste Adresse geschrieben. Bei aktivem WR dürfen sich üblicherweise die Adressen nicht ändern. Also: Bei permanent aktivem CS die Adressen anlegen, dann in beliebiger Reihefolge WR und Daten anlegen, dann WR wegnehmen. Timing beachten.
Also muss man immer einen WR PULSE erzeugen. Ich werde mir das Datenblatt noch mal durchlesen. Der Baustein besitzt schon mal ein TSOPII Gehäuse und es sind 1000 Stück bei Digikey verfügbar.
"Warum denn in die Ferne schweifen, wenn das Gute liegt so nah." http://www.schukat.com/schukat/schukat_cms_de.nsf/index/CMSDF15D356B046D53BC1256D550038A9E0?OpenDocument&wg=Y8376&refDoc=CMSF9DC7BDB79B07DCFC12570C70035E16C Nur 256kx16 aber auch ein anderer Preis. Ohne separate Logik läuft sowieso nichts! Martin Schwaikert schrieb: > Das ist ein Vorgehen, dass nicht umsonst .. Und was kostet es ?
Ein IDT 72T18125 kann dein gesamtes Bild auf einmal aufnehmen (512k x 18Bit). Ist ein schneller synchroner FIFO. Klar, kostet dann natürlich bissl was, bei Digikey reichlich 100€. Kann aber dann auch synchron mit deinem 62MHz bedeient werden. Aber musst du denn ein gesamtes Bild speichern, wenn das PC-Interface schnell genug ist? Dann reciht ja vielleicht auch ein halbes oder ein viertel.... Soll das überhaupt direkt zum PC? Oder brauchst du zwischendrin wahlfreien Zugriff auf die Bilddaten?
Christian R. schrieb: > Ein IDT 72T18125 kann dein gesamtes Bild auf einmal aufnehmen (512k x > 18Bit). Ist ein schneller synchroner FIFO. Klar, kostet dann natürlich > bissl was, bei Digikey reichlich 100€. Das finde ich für eine Serie viel zu teuer. Second Source ist wohl auch nicht. Dann doch lieber TSOPII-44 SRAMs.
Martin schrieb: > Bei FPGA benutzt man dann so einen 100MHz oder 200MHz Takt um die neuen > > Daten und Adressen zu erzeugen. Muss man bei den asynchronen SRAMs > > besser wenn man zuerst die Adresse erhöte und dann die Daten ändert, so > > das die Daten an der alten Adresse nicht ausversehen überschrieben > > werden? Das gibt grossen Matsch, weil Du niemals Adress- und Datenleitungen gleichzeitig ändern kannst. Nur bei bestimmten DV_systemen macht man das so. Diese Takten alles ein und anylisieren Adressleitungsänderungen, um sich selber eine WE zu erzeugen. Du musst das WE immer zu stabilen Zeiten anlegen. Das WE ist dann sozusagen der Takt. Das geht im FPGA ganz einfach, wenn Du die Frequenz des FPGAs genau an das Maximum des RAMs anpasst und das WE und die ADressen und Daten alle mit diesem Takt registrierst. Dabei musst du dann nur per Delay das WE entsprechend verchieben. Synchron geht das dann wiederum sehr gut, wenn du genau den doppelten Takt benutzt und das WE einmal negiert mit einem clock toogle verundest und eintaktest: Im FPGA: CLK _____``````_____``````_____``````_____``````_____`````` ADR 000000XXX1111111111111111111XXX2222222222222222222XXX3333 DAT zeitlich so gültig, wie die ADR DE ___________```````````___________```````````___________`````` Am Port ADR 000000000000000011111111111111111111112222222222222222222 DAT wie oben die Adressen DE _________________``````________________``````________________ RAM sieht : 111111 222222
@ Christian R. Diesen FIFO habe bereits auch schon gesehen, jedoch ist die Verfügbarkeit sehr schlecht zum gibt es wie bereits erwähnt keine second source das ist mir zu heiß. Ich benötige ein ganzes Bild, da die Kamera synchron mit unseren Messsystem laufen soll. Die Daten übertrage ich per Camera Link. Ich will die Daten hinten an den anderen Messstream dranhängen. Somit habe ich 2 Bilder. Da ich nicht sicherstellen kann das beide 1. Zeilen zugleich aufgenommen werden können muss ich das CMOS Bild zwischenspeichern. Da ich auch noch nicht weiß wie lange die Belichtungszeit sein muss gehe ich erst mal davon aus das ich 1 Bild zwischenspeichern muss.
Die SRAMS habe wirklich einen großen Vorteil Sie sind sehr einfach anzusteuern genau das habe ich mir auch so gedacht. Jetzt muss ich noch mal am FPGA checken welche I/O Port Spannungen ich verwende. Schon mal vielen Dank für Eure sehr hilfreichen Bemühungen :-)
Martin schrieb: > Hallo FPGA Fans, > > ich habe eine CMOS Kamera. Diese erzeugt ein Bild mit 640x480 Punkten. > Jeder Pixel 12 Bit. Für meine Berechnung bin ich davon ausgegangen das > jeder Pixel mit 2 Bytes abgespeichert wird. > > Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das > 640x480x2x100 = 61,44MByte > Also deine Kameravorgaben lassen einiges ausser betracht: -CMOS rauscht stark, die unteren beiden bits kann man daher wegwerfen ohnen Qualitätsverlust. -die bist pro Pixel sind Helligkeitsinfo, keine Farbe (R-Kanal, Grün-Kanal, Blau-Kanal). für ein farbbild musst du entsprechend dem Bayer-Mosaic die fehlenden Kanäle aus den nachbarpixeln interpolieren. -Für 100 fps müsst die Kamera mit 1/100 belichten und während der Belichtung das vorhegehende Bild in den RAM pappen. Kann dein Sensor dies gleichzeitig? Ist deine Szene so lichtreich das mit 1/100 nicht unterbelichtet wird? -Das menschliche Auge nimmt mit 25 fps ruckelfreie Bewegung dar, wozu 100 fps? Also bei der Festlegung der Bild-rate solltest du genau abprüfen was geht und was gebraucht wird. 100 fps sind da recht anspruchsvoll, realistisch wären da 25 fps. belichrungszeiten 1/10 - 1/25 und länger sind für Innenaufnahmen eher die Regel als 1/100 und kürzer. Hinsichtlich des mangels an embedded FPGA-Mem, lohnt es sich bei allen FPGA-Herstellern in den datenblättern zu schauen. Altera aht da zuweilen deutliche größere Blöcke als Xilinx, der fusion von Actel hat sogar Flash on Chip. Moderne SDRAM's machen ihren Refresh selber, das ist nicht das problem. Und mit etwas planung greift man auf ein Speicherbereich hinzu, der nicht gerade aufgefrischt wird. Die Softcore-memorycontroller sind in der Regel recht gut. problematisch ist das baorddesign und die schnellen SDRAMS sauber an den FPGA zu bekommen. -> SRAM ist eine gute Zwischenlösung um erst mal einen prototypen für die Bildverarbeitung zu bauen, tendendiell solltest du in Richtung SDRAM (DDR2) entwickeln. MfG,
Es soll ja auch erst eine schnelle Zwischenlösung werden. Es ist schon geplant auf DDR3 und einen Spartan 6 umzusteigen. Das mit der Belichtung ist kein Problem. Wir verwenden schon eine gekaufte USB Kamera die so ca zwischen 25 und 40 Bilder pro Sekunde kann. Jedoch werden die Bilder per USB 2.0 übertragen und es befindet sich kein Speicher auf dem Board, so das auch mal Bilder verloren gehen. So das man keinen kontinuierlichen Bilddatenstrom hat. Es gibt auch genügend Anwendungen wo man mehr als 25 Bilder pro Sekunde benötigt. Mir ist bewust das dies nur die Rohdaten sind und das man am PC ein Farbbild erzeugen muss. Ich hatte zuvor Kontakt mit dem Kamera Support aufgenommen und mir die Framerate bestätigen lassen. Die Kamera soll so um die 87 Frames bei 640x480 schaffen. Zudem ist die Empfindlichkeit deutlich besser als bei der anderen Kamera. Und der Preis war auch nicht gerade besonders günstig
Es sind zwar schon viele Posts und ich hab auch nicht alle überflogen, aber dadurch das es nur ums zwischenspeichern geht wäre ein SDRAM vllt wirklich das Mittel der Wahl. Einen "Controller" brauchen so gesehen alle RAMs. Zumindest eine Ablaufsteuerung um die Signale entsprechend Wackeln zu lassen damit man auf der einen Seite die Daten rein, und auf der anderen Seite die Daten rausschaufeln kann. SRAM wäre sicher möglich, und auch das einfachste, aber da sind die Preise eben vergleichsweise "hoch" für die Kapazitäten. SDRAM hat mit dem Page-Burst-Mode auch noch die schöne Eigenschaft das man eine ganze Seite bequem ein/auslesen kann und mit jedem Takt ein neues Datenwort schreiben/lesen kann.
Fritz Jaeger schrieb: > -CMOS rauscht stark, die unteren beiden bits kann man daher wegwerfen Kann er so einfach nicht. Erstens kann das Rauschen geeignet prozessiert werden und zweitens wird durch das Runden ein höherer digitaler noise injiziert. Weiter kann man davon ausgehen, dass das Bild gfs schon vorverarbeitet ist, da irgend ein Chip den CameraLink realisieren muss und die meistens auch schon Vorverarbeitung machen. Selbst wenn, die Rohdaten rauskommen ist es so, dass die Pixel ein fixed pattern noise haben, das korrigiert werden muss und damit verschiebt sich nochmal das Rauschniveuu. Eine sinnvolle Datenreduktion kann bei einem Bild immer erst erfolgen, wenn die gain-offeset-correction druch ist, defektive Pixel erstezt wurden und ein Rauschfilter drübergelaufen ist, der auf die optische Auflösung angepasst wurde. Dann könnte man das Bild gfs noch logarithmieren, um Bits einzusparen oder eine autoadaptive Helligkeitskorrektur vornehmen. > -Für 100 fps müsst die Kamera mit 1/100 belichten nicht unbedingt, z.B. wenn Zwischenbildgewinnung betrieben wird, um Überläufe zu vermeiden oder mit Überlappung gefahren wird, um die Auflösung zu verbessern. > Das menschliche Auge nimmt mit 25 fps ruckelfreie Bewegung dar Das ist erstens kein Kriterium für die Bildverarbeitung, denn schnell bewegende Objekte müssen im Industrie- und Militärbereich durchaus sehr viel schneller aufgelöst werden, um z.B. Bewegungen zu messen oder eine Autostabilisation zu ermöglichen. Zudem ist das auch nicht ganz richtig interpretiert: "Kein Ruckeln wahrnehmen" heisst nur, dass man dem Bild nicht ansehen kann, dass es kein echtes flüssiges Bild ist, z.B. bei einem Kameraschwenk. Wenn sich schnell bewegende Objekte im Bild befinden, kann man das sehr wohl sehen, dass es ein zeitlich limiertes Bild ist, weil die Bewegung zeitlich abschnittweise verschmiert ist, während das Auge in Realität dem Objekt gut folgen würde und eine sehr geringe Relativbewegung und damit eine schärfere Abildung hätte. Das lässt sich leicht beim Tennis verifizieren, wo man als Zuschauer sehr schnell den Ball nicht fokussieren kann, während das real sehr wohl möglich ist. Um ein bewegtes Objekt relativ mit maximaler Schärfe auf dem Schirm abzubilden, muss die frame rate so hoch sein, dass sich das Objekt nur um ca. einen halben Bildpunkt je frame verschiebt, wenn es statisch so scharf abgebildet wird. Wenn die Grösse und Optik es zulassen, dass ein Gegenstand im Bereich von einem Bildpixel scharf berandet ist, darf es sich bei 60Hz nur um 30 pixel in der Sekunde verschieben, bevor das Auge bei projizierten Bildern den Unterschied auf wahrnehmen kann. Bei Computer-TFT ist es etwas unkritischer, weil die zeitlich sehr verschmieren und der Abbildung nicht hinterher kommen. Da liege dann ohnehin Einschränkungen vor, die früher limitieren, was die Darstellung angeht. Bei der Aufnahme ist es aber so, dass man durch die Bildrasterung eine Bewegung zeitlich "sampelt" und da gilt indirekt auch so eine Art Nyquist. Bewegungen im Bereich von fs/4 sind nicht mehr gut- und die über fs/2 überhaupt nicht mehr korrekt zu messen. Umgekehrt gibt es das in der Betrachtung der horizontalen Auflösung auch, wenn man als fs die H-Freq nimmt: Bewegungen deutlich kleiner, als 1 Pixel sind nicht in einem Bild zu messen sondern brauchen mehrere Bilder.
>Mit einem DDR3 Speicher wäre dies sicherlich viel kompakter und >preiswerter, aber ich muss momentan schnell zum Ziel kommen. Wer sagt denn, dass die Inbetriebnahme eines DDR3-Speichers mit eintsprechendem IP-Core soviel länger dauert? Außerdem bist du dann für die Zukunft gewappnet. Schau dir doch mal, was dein FPGA-Hersteller für IP-Cores anbietet ...
Stachele schrieb: > Wer sagt denn, dass die Inbetriebnahme eines DDR3-Speichers mit > > eintsprechendem IP-Core soviel länger dauert? 99% der FPGA-Designer werden das behaupten.
Moin, habe hier nen VGA-Sensor (Aptina) an nem Spartan6 mit DDR, die skizzierten Bildraten ins DDR sind problemlos zu schaffen. Den DDR-Core muss man nur noch mit LogiCore generieren, alles deutlich einfacher als bei älteren Spartan-Familien. Um die Daten schlussendlich wegzukriegen: Stichwort MJPEG encoder. Zumindest die DCT kann man ins FPGA auslagern, den Rest (Verschicken) macht man besser über einen DMA und embedded-Linux-fähigen Chip. Gruss, - Strubi
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.