www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Bilder im FPGA speichern


Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen.

Ich hab momentan leichte Schwierigkeiten, mir das Richtige Ev. board von 
Xilinx auszuwählen.
Folgendes möchte ich machen:
Ich bekomme von einem uC, wahrscheinlich über RS-232 RGB-Bilder 
zugeschickt. Diese Bild-Daten möchte ich auf dem FPGA abspeichern, um 
Sie im FPGA mittels PAL-Encoder als FBAS Signal umzuwandlen. Das FBAS 
Signal wir anschließend über ein Video DAC an ein LCD Didplay mit 
Composite Anschluss gesendet.

Mein Problem ist gerade, dass ich nun nicht genau weiß, welches 
Evaluation Board von Xilinx ich da nun verwenden muss. Ich gehe momentan 
davon aus, dass ich immer ein Bild abspeicher (max. 640x480). Die 
Auflösung steht noch nicht ganz fest.

Das ist so meine Grundüberlegung. Vielleicht geht es ja auch etwas 
unkomplizierter!?

Ich bin für jede Hilfe dankbar.

Vielen Dank im Voraus.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie Du es erklärt hast, brauchst Du ein FPGA mit genug Speicher. Ich 
kenne mich bei Xilinx nicht gut aus. Aber Lattice hat da einige ganz 
nette im Angebot. Die ECP2/M.
Was soll denn das geben?

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch einfach nen externen Ram. Ist auch weit billiger als sich nen 
stärkeren FPGA zu leisten. Noch dazu ist Speicher im FPGA ohnehin ein 
sehr beschränktes Gut. Noch dazu braucht deine Anwendung wahrscheinlich 
nicht besonders viel Ressourcen.
Soweit ich weiß haben die meisten Evals ohnehin nen Ram mit drauf.

Ach ja bei 640*480*3*8 Bit kommt schon ganz schön was zusammen.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie, "Was soll das denn geben?" Ich muss RGB in Composite umwandeln. Ich 
habe zwei Ansätze:
1. Encoder mittels FPGA erstellen
2. FPGA nur als Bildspeicher und mit nem IC den Encoder realisieren

Bin quasi parallel auch auf der Suche nach IC's die einen RGB to Pal 
Encoder darstellen. Aber welcher ist der Richtige?! Gibts da eventuell 
einen Tip von einem Kenner?

Veieln Dank für die Antwort

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>FPGA nur als Bildspeicher und mit nem IC den Encoder realisieren
Ach ich würd den FPGA gleich nur als Deko draufpappen.. Ne echt FPGAs 
sind auch weit günstiger als jeder Speicher. So manche billige Mp3 
Player .. nein lassen wir das lieber ;)

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Wie, "Was soll das denn geben?" Ich muss RGB in Composite umwandeln. Ich

Das Zauberwort heißt Colour Space Converter, dazu findest du was in der 
Xilinx App-Note 930, den mußt/solltest du mit nem FPGA machen.

Bildspeicher mit externem RAM.

Ein geeignetes Brett könnte das Spartan 3 A EvBoard sein (150 USD), das 
hat einen Riesen-SDRAM.

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Wandlung YCrYCb zu FBAS mußt du dann noch mit einem externen Stein 
machen, die gibt es zuhauf bei AD, NXP, TI....

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@berndg

Wozu brauch ich denn den Colour Space Converter? Wenn ich RGB Daten 
habe, und diese dann an einen externen PAL-Encoder (der RGB als Input 
hat)sende , wozu brauch ich dann den Colour Space Converter???#

Und schon einmal vielen Dank für die vielen und schnelle Antworten!!!

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich bekomme von einem uC, wahrscheinlich über RS-232 RGB-Bilder
  zugeschickt. Diese Bild-Daten möchte ich auf dem FPGA abspeichern, um
  Sie im FPGA mittels PAL-Encoder als FBAS Signal umzuwandlen.

Hmm, sozusagen deine eigenen Worte. :-)

Aber du hast völlig recht, du kannst den ganzen Prozess natürlich auch 
in RGB machen und am Ende mit einem geeigneten PAL-Encoder zu FBAS 
zurückwandeln. Mir ist jezt allerdings  nicht geläufig, welcher Encoder
RGB zu FBAS macht. Der SAA 7103 macht das, aber nur für 600 x 800 
Bilder.

Nachsehen.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibt es wohl einige.
Im welchem Speicher würde ich denn das Bild abspeichern???
Das FPGA besitz so einieg Speichergruppen. Ich hab mir mal das 
Datenbaltt vom Spartan 1600E angeschaut. Da steht: 64 MByte (512Mbit) of 
DDR SDRAM, x16 ata interface, 100+MHz
Was bedeutet das alles überhaupt genau. Ziemlich verwirrend. Ich würde 
jetzt denke, das dieser Speicher zum Bild hoinzterlegen (sagen wir mal 
640x320) ausreichen würde. Oder bin ihc einfach zu doof?!

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm einen externen RAM, der vom FPGA angesteuert wird, sonst wird die 
Sache zu aufwendig! Dann reicht auch ein kleiner FPGA zur Steuerung z.B.
XC 3 S 200 oder max. XC 3 S 400, würde ich meinen.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem externen RAM habe ich auch schon überlegt gehabt. Das soll wohl 
aber etwas kompliziert sein. ICh werde aufjedenfall ein Xilinx 
Evaluation Board benutzen. Zur ZEit gibt es bei mir ein Spartan3, 3E und 
1600E. WEnn die Bildauflösung doch noch höher sein muss wollte ich 
eventuell auf ein Virtex 4 oder 5 umsteien. Das enstcheidet sich aber 
erst in den kommenden zwei Wochen. Ich gehe aber ersteinmal von einer 
Bildauflösung 640x320 aus.

Warum reicht den der SDRAM vom 1600E nicht aus???

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hab ich jetzt was durcheinander gebracht :-(
Nimm das 1600E, da ist genug Overkill drin :-).

Gruß Bernd

Autor: Artur Funk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Mit dem externen RAM habe ich auch schon überlegt gehabt. Das soll wohl
>> aber etwas kompliziert sein.

Nein ist es nicht, wenn du z.B. einen SPI Flash Speicher verwendest. Die 
Ansteuerung dafür zu coden kostet dich evtl ein Tag. Zu dem sind die 
IC's recht schnell (70 Mbit/s sind oft locker drin). Und so ein 32 MB 
SPI Flash kostet auch nicht die welt.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetz  hab ich für heute ersteinmal genug Info von euch bekommen. 
Jetzt werd ich mir noch ein zwei geeignete IC PAL Encoder auswhälen und 
mal schauen,wie das alles so zusammen passt.

Vielen Dank ersteinmal für die tolle Hilfe.

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh mal bei Xilinx oder Silica nach, bei denen gibt es 
Video-Ansteckplatten für den Hirose-Steckverbinder am Board (Wenn dein 
Chef das Geld rausrückt).

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da es zu meiner Diplomarebit gehört, muss ic hda schon einiges an Arebit 
reinstecken. Aber trotzdem noch  mal eine Frage.Oder auch zwei

Es wurde ja im Forum schoeinmal über einen Tesbildgenerator gesprochen. 
Ähnlich ist meine Aufagbe ja auch.
Ich bekomme von einem uC (Testbilder)Bilder und muss sie auf einem 
Display mit Composite Anschluss  drastellen.
Fest steht wohl, dass ich ein FPGA Spartan 1600E benutze und einen 
RGB-PAL Encoder (Bsp. MC1377).
1. Wie übertrage ich am betsen die Bilder vom uC auf das FPGA?
2. WEnn ich das FPGA als Bildspeicher verwende müssen die Daten ja an 
den IC geschickt werden. Welche übertragungsvariante verwende ich am 
betsen dafür?

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum reicht den der SDRAM vom 1600E nicht aus???

Wie wäre es mal mit einer einfachen Überschlagsrechnung:

Auflösung 640x480=307200 Bildpunkte

XC3S1600E hat intern 663552 Bit Blockram. Das reicht für ganze 2 Bit 
"Farbtiefe" pro Pixel.

> SPI Pixeltakt 70 Mbit/s

307200 Bildpunkte 25x pro Sekunde wiederholen:

307200x25=7680000 mal pro Sekunde ein Pixel auslesen (Austastlücken u.ä. 
lasse ich mal großzügigerweise weg)

Das würde für 8 Bit Farbtiefe reichen. Der SPI-Flash sollte allerdings 
noch groß genug sein.

Du wirst also um ein FPGA mit externem Speicher nicht herumkommen.

> 64 MByte (512Mbit) of DDR SDRAM

Die kannst du dafür benutzen. Das ist ein einzelner RAM der an das FPGA 
angeschlossen ist. Einen passenden Controller kannst du dir mit dem MIG 
generieren lassen.

Autor: chilipower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lo Me
> Da es zu meiner Diplomarebit gehört, muss ic hda schon einiges an Arebit
> reinstecken. Aber trotzdem noch  mal eine Frage.Oder auch zwei

Welches Fach studierst du denn?

Autor: Gabriel Wegscheider (gagosoft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite auch mit FPGA & Video; allerdings empfange ich ein BT656 
Videosignal von einem VideoADC. Um realistische Testbilder für die 
Simulation zu bekommen hab ich die Bilder aus der Kamera über den FPGA 
in einen SRAM (extern) geschrieben und dann als BMP durch die serielle 
Leitung gequetscht. Du könntest das ja umgekehrt machen.
PC/µC sendet ein BMP an den FPGA, der decodiert es und legt es im SRAM 
ab. Wenn dieser Vorgang abgeschlossen ist, kannst Du das Bild einfach 
aus dem Speicher über den FPGA zum VideoDAC schicken.
Als Hardware könntest Du das RetroComputingBaseboard von Trenz 
Elektronik nehmen. Bei uns sind das die Studenten-FPGA-Boards auf der 
Uni. Und der Preis ist auch nicht schlimm.
Ich habe Privat das FPGA-Modul und ein Pinheaderboard. Also da ist zwar 
keine Peripherie drann dafür sind 4x40PinHeader drauf.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wär's mit einem PAL-Encoder-Core?

http://www.pcb-dev.com/index.php?option=com_conten...

Solang es sich bei deiner Diplomarbeit um nicht-kommerzielle Nutzung 
handelt, kannst du den verwenden.

Mfg
Thomas Pototschnig

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas

Danke, aber ich denke mal, das das Projekt irgend wann mal 
kommerzialisiert wird. D.h. einfach dein Projket übernehemn geht also 
nicht. ICh wollte den PAL Encoder mittels IC (ev. MC1377) realisieren. 
Mit dem FPGA  möchte ich die Bilddaten vom uC zwischen speichern. Jetzt 
mal ne Frage zu deinem Projekt.
Wie bekommt dein Board die Bilddaten (RGB...?)?
Worüber sendest du die Daten vom uC zum Graf.Board?


DAnke

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibts verschiedene Möglichkeiten - entweder über SPI (was aber 
langsam und auf keinen Fall echtzeitfähig ist) oder man macht sich die 
Arbeit ein paralleles Interface zu implementieren, das in den 
Speicherbus eingebunden ist.

Bei meiner Lösung gibt es 2 Busse mit max 30MB/s (immer 16Bit Daten!), 
wovon einer dafür verwendet wird die Bilddaten aus einem externen SRAM 
auszulesen, der Andere wird dafür verwendet um die Bilddaten ins SRAM zu 
schreiben. Das ganze wird von einer Speichersteuerung gesteuert, die 
dann das SRAM mit 60MB/s anspricht. Gibt also weder Wartezeiten, noch 
Konflikte beim Lesen/Schreiben. Die SPI-Schnittstelle sitzt nur davor 
und erzeugt 16Bit parallele Daten und gibt einen Schreibimpuls aus.

Hier sieht man noch ein Blockschaltbild wie das aussieht:
http://www.opencores.org/projects.cgi/web/graphiti/overview

Mfg
Thomas Pototschnig

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Wenn ich das richtig verstehe, liest du in einem Speicher die Daten 
vom uC ein, schiebst sie an das nächste weiter um sie aus dem zweiten 
RAM wieder auszulesen???

Ich habe momentan einfach ein Problem, wie ich die Bilddaten, sagen wir 
mal  RGB mit 640x320 Auflösung, am betsen vom uC zum FPGA (RAM) 
übertrage um sie anschlließen sinnvoll in einem RAM abzuspeichern.
Muss ich wirklich jeden Pixel (640x320) für jeden Farbanteil, also 3x 
(R, G u. B)speichern? Oder gibt es da irgendwie eine Platzsparende 
möglichkeit???

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lo Me wrote:
> Ok. Wenn ich das richtig verstehe, liest du in einem Speicher die Daten
> vom uC ein, schiebst sie an das nächste weiter um sie aus dem zweiten
> RAM wieder auszulesen???

Jo, ein Microcontroller wäre viel zu langsam soviel Bilddaten in 
echtzeit zur Verfügung zu stellen. Jede Grafikkarte hat doch auch einen 
Bildschirm-Speicher, das ist kein Unterschied ...

> Ich habe momentan einfach ein Problem, wie ich die Bilddaten, sagen wir
> mal  RGB mit 640x320 Auflösung, am betsen vom uC zum FPGA (RAM)
> übertrage um sie anschlließen sinnvoll in einem RAM abzuspeichern.
> Muss ich wirklich jeden Pixel (640x320) für jeden Farbanteil, also 3x
> (R, G u. B)speichern? Oder gibt es da irgendwie eine Platzsparende
> möglichkeit???

Kommt drauf an was du für ein RGB-Format hast. Bei RGB 5:6:5 benötigst 
du 2Byte pro Pixel. Wenn es schnell gehen muss ist eine gute Lösung den 
FPGA in den Speicherbereich des Controllers einzubinden. So ist es ja 
auch bei jeder Grafikkarte beim PC ... Man kann über Speicheradressen 
auf den Bildschirmspeicher zugreifen.

Mfg
Thomas Pototschnig

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus?
Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan 
sieht es so aus, dass ich die Bilddaten von einem uC bekomme. Die wollte 
ich dann auf dem Ev. Board ein einem SRAM zwischen speichern um sie 
dann, entweder über VGA-Schnittstelle des Boards wieder auszugeben oder 
an den IC PAL-Encoder weiter sende.

Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den 
notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann 
jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich 
davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also 
1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00 
Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am 
betsen abspeichern???

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lo Me wrote:
> Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus?
> Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan
> sieht es so aus, dass ich die Bilddaten von einem uC bekomme. Die wollte
> ich dann auf dem Ev. Board ein einem SRAM zwischen speichern um sie
> dann, entweder über VGA-Schnittstelle des Boards wieder auszugeben oder
> an den IC PAL-Encoder weiter sende.

Tut er auch nicht, bei mir ist das SRAM extern als zwei 512k*8 mit 10ns 
Zugriffszeit realisiert.

> Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den
> notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann
> jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich
> davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also
> 1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00
> Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am
> betsen abspeichern???

Du verdrehst Bits und Bytes aber ganz schön ... Stell deine Frage bitte 
nochmal neu ;-)

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SOrry, ok noch einmal.
Also ich habe mir das so vorgestellt, dass ich den Speicherbereich je 
nach Auflösung festlege. Nehmen wir 640x320 Pixel an. D.h. ich hätte ein 
Register mit der Größe von 320 Zeilen und 640 Spalten. Für jedes Pixel 
muss ihc ja den jeweiligen Farbwert speichern. Keine Ahnung ob 5:6:5 
oder...? Was ist den meistens so der Standard?
Jetzt muss ich ja irgendwie meinen Farbwert Rot, Grün und Blau in den 
festgelegten Speicherbereich hinterlegen.
Bedeutet das jetzt, dass ich für jeden Farbwert einen Speicherbereich 
von 640x320 festlegen muss?

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lo Me wrote:
> SOrry, ok noch einmal.
> Also ich habe mir das so vorgestellt, dass ich den Speicherbereich je
> nach Auflösung festlege. Nehmen wir 640x320 Pixel an. D.h. ich hätte ein
> Register mit der Größe von 320 Zeilen und 640 Spalten. Für jedes Pixel
> muss ihc ja den jeweiligen Farbwert speichern. Keine Ahnung ob 5:6:5
> oder...? Was ist den meistens so der Standard?
> Jetzt muss ich ja irgendwie meinen Farbwert Rot, Grün und Blau in den
> festgelegten Speicherbereich hinterlegen.
> Bedeutet das jetzt, dass ich für jeden Farbwert einen Speicherbereich
> von 640x320 festlegen muss?

Äääh ... 5:6:5 ist zB ein Standard für RGB16 bit ... rot:5bit, 
grün:6bit, blau:5bit.

Wenn du 640x320 RGB 16bit hast, benötigst du 640*320*2Byte 
Speicherplatz.

Mfg
Thomas Pototschnig

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie würde ich die 640x320*2Byte am besten im SRAM speichern.
Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus?

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lo Me wrote:
> Und wie würde ich die 640x320*2Byte am besten im SRAM speichern.
> Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus?

Die Pixel hintereinander im RAM? Wie sonst?

Autor: chilipower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und wie würde ich die 640x320*2Byte am besten im SRAM speichern.
>Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus?

Na am Besten verkehrt herum. Wenn du sie vorwärts einspeicherst, kannst 
sie hinter rückwärts besser auslesen.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das weiß ich. Da habe ich mich wohl nicht richtig ausgedrückt.Ich 
habe ja für jedes Pixel 3 Farbwerte. Jeder Farbwert hat R=5Bit, G=6bit 
und Blau=5bit wenn wir eine Farbtiefe von 16 Bit habe. Richtig? In 
meiner Überlegung muss ich für jedes Pixel 16Bit speichern. Wenn ich nun 
auf meinem Evaluation Board nen 64 MByte (51Mbit) DDR SDRAM mit x16Data 
habe, hat jede Speicheradresse 16Bit? Würde ich dann in jede Adresse 
gemeinsam meine RGB WErte speichern??? ICh weiß, doof e Fragen, aber 
irgendwie stehe ich heute voll aufm Schlauch!!!

Autor: Gabriel Wegscheider (gagosoft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lo Me wrote:
> Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus?
Davon gehe ich auch aus.
> Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan
> sieht es so aus, dass ich die Bilddaten von einem uC bekomme.
Wie bekommst Du Deine Bilddaten in den µC? erzeugt dieser die Bilder?
Wenn der µC die Bilder erzeugt, dann kannst Du ja den µC im FPGA 
unterbringen.
Für den VideoDAC wirst Du idealerweise BT656 verwenden. BT656 ist eine 
4:2:2 Y+Cr/Y+Cb codierung. Also für 2 Pixel hast Du 2*8Bit Y Werte, 
einen Cr und einen Cb Wert mit je 8Bit. Wobei Du (meist) zwei 
verschiedene Busbreiten zur Auswahl hast:
8Bit:   Y Cr Y Cb, Y Cr Y Cb, Y Cr Y Cb, ....
16Bit:  Y  Y  Y  Y
        Cr Cb Cr Cb ....
Des weiteren hast Du AV-Codes im Datenstrom.
8Bit hat den Vorteil, weniger Leitungen zu benötigen wobei die DotClock 
bei 27Mhz ist , 16 Bit hingegen kommt mit 13,5 Mhz DotClock aus.

Viele VideoADC können allerdings auch RGB, hier hast Du allerdinge im 
Allgemeinen einen höheren Speicherverbrauch. Und Du musst die 
SyncSignale extra aufbereiten (im BT656 können sie im Datenstrom 
eingebettet sein)

>
> Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den
> notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann
> jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich
> davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also
> 1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00
> Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am
> betsen abspeichern???
Wenn Du RGB abspeichern willst, würde ich BMP als Format wählen. Ein 
einfaches Format, das auch im Simulator leicht zu verifizieren (und dort 
auch einfach in ein File zu schreiben) ist.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ehmm DDR ram ?? Bei deinem aktuellen kenntnisstand würde
ich das stark bezweifeln dass du das angesteuert bekommst
(macht auch nicht wirklich sinn für die Anwendung).

Nimm ein asynchrones SRAM mit kleiner  Zugriffszeit (10ns oder so).

Ich befürchte aber fast du bist selbst mit dem Controller dafür
(Zeitmultiplex lesen/schreiben wie oben erwähnt) schon überfordert...

Und da es zu deiner Diplomarbeit gehört solltest du mal ein bisschen die 
Grundlagen
recherchieren! (Farbformate, verschiedene Speicher, ..)
Musst doch eh nen Grundlagen Kapitel schreiben ;)

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gabriel

Moin. ALso die Bilder sind auf dem uC hinterlegt. Hast du zufällig einen 
Video DAC im Kopf, der Y+Cr/Y+Cb als Inout besitzt? Ich hatte mir den 
MC1377 ausgewählt, der allerdings nur RGB Inout hat.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht das ganze noch mal überdenken ob an der Stelle wirklich ein 
FPGA sinnvoll ist? Hast du noch irgendetwas anderes was von einem 
übernommen werden muß oder sinnvoll von ihm übernommen wird?

Das ganze Bild im FPGA zu speichern ist nicht praktikabel, externer 
Speicher muß eh her. Wenn die Bilder von einem uC stammen und auch noch 
mittels RS232 übertragen werden ist deine Eingangsdatenraten doch 
ziemlich winzig. Der FPGA hat letztlich kaum was zu tun.
Gerade bei deinem Kenntnisstand: Wie wäre es mit einer Lösung aus CPLD + 
SRAM + Video Encoder? (evt. noch + uC) Dein eigentliches Problem ist die 
Ausgangsdatenrate, dafür musst du aber im Grunde bloss die Adressen für 
das SRAM passend generieren. Da die Eingangsdaten auch nur langsam 
reinkommen, reicht es dir wohl auch wenn du bloss während H/V Sync in 
SRAM schreibst, ein richtiges Multiplexing brauchst du daher wohl nicht 
mal.

Autor: Lo Me (lome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte an ein FPGA weil ich hier ein FPGA Spartan 3E 
ENtwicklungsboard zur verfügung habe. Was allerdings wohl Problematisch 
ist, das die vorhandene VGA Schnittstelle nur 8 verschiedene Farben 
darstellen kann, weil auf dem Board kein VideoDAC vorhanden ist.
Ich hatte mir überlegt gehabt, die Bilddaten über VGA SChnittstelle auf 
einen IC (MC1377...) der die VGA Signale (RGB) zu Composite umwandelt.
Aber die Farbtiefe wird wohl etwas zu gering!

Autor: Human Amdjadi (hiwa1980)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die schwarz/weiß bilder?
Müssen die format-Infos in der header des Bildes mitgespeichert werden?
wie viele Bytes sollen insgesamt gespeichert werden?

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.