Archiv verlassen und diese Seite im Standarddesign anzeigen : ARM vs FPGA
Hi Leute,
In meinem nächsten (Langzeit-) Projekt möchte ich Kamera-Daten (doppelte Hd-Auflösung, 2560×720 bei 60fps) manipulieren. Mit "manipulieren" meine ich vorerst nur so etwas wie Filter anwenden, oder Kantenfindung und natürlich komprimieren, später vielleicht aber auch aufwendigere Dinge wie Color-Segmentation o.Ä.
Das schreit natürlich nach einem sehr leistungsfähigen Controller.
Meine Frage ist daher: Soll ich einen FPGA oder einen ARM-Prozessor verwenden (einarbeiten müsste ich mich in beide).
Ich hoffe es kann mir jemand helfen meine Vorteil/Nachteil Liste zu ergänzen:
Vorteile FPGA:
1) echt-parallele Verarbeitung
2) Algorithmus wird praktisch in Hardware realisiert -> schnell
Nachteile FPGA:
1) neu zu lernende Sprache (VHDL)
2) teuer (darum werd ich wohl ohnehin nicht herumkommen)
3) geringe Taktfrequenz (laut Mikrocontroller.net 300-600MHz [ist das überhaupt aussagekräftig?])
Vorteile ARM:
1) relativ einfach in C zu programmieren (es könnte z.b der Linux-Kernel compiliert werden)
2) günstiger
3) hohe Taktfrequenz (je nach Modell natürlich)
Nachteile ARM:
1) kein echtes parallel processing
LG XBert
BlackDevil
18.03.2010, 13:27
Ein ARM mit Realzeit Betriebssystem ist schon nicht langsam. Mit einem Embedded Linux hast du da ggf. auch vorteile.
Und unterschätz das Platinen Layout bei solch hohen Frequenzen nicht. Vor allendingen wenn du über 600MHz und in die Ghz Region gehst
Bei meinem ersten Prototypen werde ich ein fertiges Board verwenden. Insofern ist mir das Layout vorerst egal.
Allerdings ist mein Endziel natürlich ein eigen designtes Board, das möglichst klein werden soll.
Und damit ist natürlich auch wichtig welcher Controller mit weniger externen Komponenten auskommt.
Ich frage mich im Moment aber auch wie portable VHDL ist??
Denn wenn ich drauf kommen sollte, dass mir die Rechenleistung des FPGA nicht reicht, wäre ich nicht sehr erfreut alles von Grund auf neu machen zu müssen nur um einen schnelleren Controller verwenden zu können.
LG
Vor einigen Jahren war in der C`t ein Bericht über eine Software welche
aus C-Code einen Code für FPGA`s erzeugt hat. Denmach reicht es also
wenn man mit C klarkommt. Wie solche Software jetzt heißt und was diese
kostet? Ich könnte mir aber vorstellen das die FPGA Hersteller da mehr
wissen.....die wollen Verkaufen. :-)
Gruß Richard
rideyourstyle
18.03.2010, 17:18
Wie wärs mit einem DSP? Ich denke für das Bearbetein von Videodaten ist das die beste Variante. (Speicher, Rechnengeschwindigkeit, Libs?)
Es würde auch ARM mit FPGA in einem Chip geben. FPGA- Teil für schnelle Rechnungen und ARM fürs "einfache" Programmieren :-|
Besserwessi
18.03.2010, 18:23
Eine ARM CPU wird dafür zu langsam sein. Das klingt nach einer Aufgabe für eine großes / schnellers FPGA, einen high-end DSP (mehrere Kerne), oder auch eine Kombination. Mit nur einem ARM sollte man es leichter angehen (z.B. VAG Auflösung bei 25 fps).
Das sind dann mal locker 110 Megabyte / Sekunde?¿
Das nenn ich ehrgeizig mit ARM .... nee, das wird mit
FPGA einfacher. Bin auch grad an so ner Geschichte dran,
allerdings kleinere Auflösung und FPGA ...
Parallel die Daten rein und direkt durch in DRAM, bei Frame Ende
Daten durchshiften und Sobel per Byteshifts, Daten wieder raus
in anderen Rambereich, dann einfach per µC durch den FPGA
durch auf den höheren RAM-Bereich zugreifen.
Es mag auch anders gehen, aber n ARM7 oder ARM9 halt ich
für wenig wahrscheinlich das der die IO-Operationen schafft.
Die Rechenoperationen kann gehen, aber es müssen ja auch Ports
gelesen bzw. geschrieben werden ...
Ich habe gerade vor kurzen eine Videoüberwachung in betrieb
genommen, 16 Kameras (pro Karte) mit 50 F/s + Audio. Wobei sich
die Kameras die Zeit teilen, es sind also je nach Kamera Anzahl auch
höhere Farmraraten möglich.....Ich habe allerdings nicht darauf geachtet
was für Chips dort verwendet wurden, und wahrscheinlich sind die auch
abgeschliffen? Aber die Leistung ist schon echt guuuuut. Ich vermute
das da auch FPG`s eingesetzt sind, die Chips sind enorm Groß was eine
hohe Anzahl von Elementen/Transistoren vermuten Lässt.
Gruß Richard
Wie wärs mit einem DSP?
Welchen?? ich kenne nur solche, die das Bild komprimieren und weitergeben.
Das sind dann mal locker 110 Megabyte / Sekunde?¿
Nur wenn 1 Pixel = 1 Byte sind. Ich rechne eher mit 12-14Bit pro Pixel -> und daher eher mit 200Mb/s.
Das wird vermutlich eine Riesenaufgabe das über USB 2.0 zu bringen.....
Ich fürchte ebenfalls, dass ich einen USB 3.0 Controller brauche, weil eventuell die Kompression(ohne zu großem Verlust) nicht gut genug ist, und bei USB 2.0 maximal 500mA Strom gezogen werden dürfen, aber alleine vom Sensor schon 600mA gebraucht werden. (man könnte aber auch die Stromversorgung von 2 USB 2.0 Ports verwenden, oder eben einen USB 3.0 Port)
Aber eure Antworten bestärken meine Vermutung, dass es wohl nur mit einem FPGA funktionieren könnte;
LG
Besserwessi
18.03.2010, 21:12
Wenn es ein DSP sein sollte, dann ungefähr so etwas.
http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html
oder ein größerer Bruder, wenn mehr gemacht werden soll.
Die Programmierung ist aber auch beim DSP nicht einfach.
Danke für den Link, allerdings würde ich bei meinem ersten Prototypen gerne ein fertiges Board verwenden.
Ich hab noch ein beeindruckendes Projekt gefunden, dass dem was ich vorhabe recht ähnlich ist: http://thomaspfeifer.net/fpga_dsp_bildverarbeitung.htm
LG
rideyourstyle
18.03.2010, 21:25
Woher hast du eigentlich so eine Kamera bzw Datenquelle? Wenn man fragen darf????
Haben tu ich sie noch nicht, aber ich plane 2 von diesen zu verwenden:
MT9M033 (http://www.aptina.com/products/image_sensors/mt9m033c12stc/) von Aptina.
Vorteile FPGA:
1) echt-parallele Verarbeitung
2) Algorithmus wird praktisch in Hardware realisiert -> schnell
Nachteile FPGA:
1) neu zu lernende Sprache (VHDL)
2) teuer (darum werd ich wohl ohnehin nicht herumkommen)Passt soweit
3) geringe Taktfrequenz (laut Mikrocontroller.net 300-600MHz [ist das überhaupt aussagekräftig?])Ehrlich, du hast keine Vorstellung davon wie brutal schnell ein mit 300MHz getakteter FPGA sein kann ;-)
Ein DSP könnte tatsächlich eine gute Alternative sein, denn schneller als mit einem ARM bist du damit allemal, aber gerade bei Bildverarbeitung vermutlich noch langsamer als ein FPGA.
Mein Vorschlag: nimm doch beides!
Also FPGA + ARM oder FPGA + DSP, natürlich jeweils über eine oder mehrere möglichst schnelle Schnittstellen verbunden (z.B. ein paralleles Speicherinterface das man so hoch taktet wie es der DSP bzw. ARM eben zulässt). Die Videodaten gibst du dem FPGA zu fressen, und dann kannst du immernoch entscheiden wie du die Aufgabenverteilung machst.
Ehrlich, du hast keine Vorstellung davon wie brutal schnell ein mit 300MHz getakteter FPGA sein kann ;-)
Da hast du sogar recht :D
Mein Vorschlag: nimm doch beides!
Also FPGA + ARM oder FPGA + DSP, natürlich jeweils über eine oder mehrere möglichst schnelle Schnittstellen verbunden (z.B. ein paralleles Speicherinterface das man so hoch taktet wie es der DSP bzw. ARM eben zulässt). Die Videodaten gibst du dem FPGA zu fressen, und dann kannst du immernoch entscheiden wie du die Aufgabenverteilung machst.
Was genau ist der Vorteil dabei gegenüber einer reinen FPGA-Lösung??
Ich sehe nur einen "Nachteil" durch mehr Bauteile -> größeres Board.
Ich hab jetzt mal ein bisschen herumgesucht und ein Board gefunden und wollte euch nun fragen was ihr davon haltet.
Das (http://www.cesys.com/fpga/spartan/efm01_de.html) Board gefällt mir gut, da es schon den USB-Controller drauf hat und sehr klein ist(auch der Preis ist mit 150€ in Ordnung). Allerdings müsste man vermutlich noch ein bisschen RAM dazu geben.
LG
Der Vorteil ist hauptsächlich die größere Flexibilität...
Der FPGA ist das Arbeitstier, und übernimmt mit seiner brachialen Rechenleistung alle Low-Level Aufgaben (also die Bildverarbeitung).
Der DSP hingegen verwaltet die ganze Geschichte, bietet eine Schnittstelle um die Algorithmen auf dem FPGA zu konfigurieren, und kann ggf. die vom FPGA gelieferten Daten weiterverarbeiten.
Mag sein daß ich da auch beruflich etwas vorbelastet bin, unsere Systeme sind nämlich ganz ähnlich aufgebaut (ein starker FPGA für die 1. Stufe der Datenverarbeitung und -reduktion, und ein DSP der die Zwischenergebnisse mit "intelligenteren" Algorithmen auswertet). Ein gutes Beispiel ist aber auch das von dir selbst verlinkte Projekt von Thomas Pfeifer, der den FPGA ebenfalls für die Low-Level Bildverarbeitung nutzt, Dinge wie z.B. Objekterkennung aber dem DSP überlässt.
OK, das macht natürlich Sinn.
Letzten Endes können die aufwändigen Berechnungen auch auf einem PC ausgeführt werden (oder für eine embedded-Lösung auch auf einer anderen Recheneinheit [z.b einen ARM oder DSP]).
Das Hauptziel ist vorerst nur die Steuerungsplatine, um das ganze dann quasi als Stereo-Webcam mit optionaler rectification, und anschließende Komprimierung des Bildes zu betreiben.
Und jetzt kommt auch vermutlich meine letzte Frage im Moment:
Ist das mit dem von mir vorgeschlagenen Board möglich????
LG
Öha, heftige Kamera, die schiebt aber seriell oder parallel die Daten raus, von USB hab ich da nix gesehen ... kann aber auch überlesen haben.
Parallel wär am einfachsten für die Übertragung in FPGA
Data Format: Serial (HiSPi), parallel (12- or 14-bit)
Ich weiß zwar nicht was HiSPi heißt (google weiß es scheinbar auch nicht), aber die Bilddaten werden parallel übertragen, mit I²C Port zur Steuerung.
USB ist nicht beim Sensor dabei sondern bei dem FPGA-Board: KLICK (http://www.cesys.com/fpga/spartan/efm01_de.html)
LG
...
Nachteile FPGA:
1) neu zu lernende Sprache (VHDL)...
Hi ,
warum willst Du nicht in #C (System C) Programmieren ?
Das wäre einfacher und auch schneller zu lernen als reines VHDL
Gruss
Artur
Es war nicht so gemeint das ich keine neue Sprache lernen will, sondern eher so, dass es mehr Zeitaufwand ist das zusätzlich noch zu lernen.
SystemC kannte ich bis zu deinem Beitrag ehrllich gesagt nicht :)
BlackDevil
19.03.2010, 21:58
Ich hätte gern mal ein Beispiel für einen FPGA/ARM Prozessor Bastard :)
Ich würde dir für solch ein Projekt auch eher zu einem FPGA raten da du hier wirklich alles Parallel ablaufen lassen kannst. Wenn du aber noch keine Erfahrung mit VHDL hast würde ich mir erstmal nach nem Develloper Kit gucken um erste erfahrungen in VHDL zu sammeln. Da du bei VHDL ein ganz anderer denkprozess ist wie bei C oder sonstigen Programmiersprachen. Wenn du dich weiter mit FPGAs beschäftigst kannst du dir Vllt. auch mal SoftCores wie den Leon, NIOS II oder OpenRisc anschauen...
als günstigen Einstieg in VHDL würde sich z.B. das Pollin CPLD-Board eignen.
Ist recht günstig das Ding und zum Verheizen allemal gut
BlackDevil
20.03.2010, 10:21
Oder ein FPGA Board von Digilent
Danke für die Tipps, aber woran erkenne ich die Rechenpower eines FPGA??
Bei AVRs oder ARMs ist es ja die mehr oder weniger die Taktfrequenz.
Und nachdem es doch recht große Preispannen bei FPGAs gibt weiß ich nicht für welchen ich mich entscheiden soll.
LG
BlackDevil
20.03.2010, 11:51
Soweit ich das gesehen habe unterscheiden die sich in erster Linie in
- Taktrate
- Anzahl Versorgugsspannung
- Bauform
- Anzahl möglicher Verknüpfungen (je mehr desto teurer)
Die Geschwindigkeit eines FPGAs hängt eigntl nur davon ab wie schnell die Gatter innen drin sind. Ich denke das ist auch noch ausschlaggebend für den PReis
Ein FPGA / CPLD rechnet zunächst mal garnicht,
sondern verknüpft Gatter zu Funktionen oder Funktionsgruppen.
Aus Deinem VHDL wird praktisch nur ein Verknüpfungsplan
erstellt. Je nach Komplexität durchläuft ergo Dein Signal
diverse Gatter um am anderen Ende wieder raus zu kommen.
Wie schnell das geschieht hängt von den Gatterlaufzeiten
des jeweiligen FPGA / CPLD ab und wie viele dieser Einheiten
durchlaufen werden müssen.
Auch hier gilt, je schlechter das Script, je langsamer die Kiste,
wie bei µC auch.
Man kann auch Funktionen erzeugen die mit Quarz synchron laufen.
hab mir das
"Lehrbuch Digitaltechnik"
Eine Einführung mit VHDL
von Jürgen Reichardt
besorgt, ist für den Einstieg recht brauchbar
http://www.amazon.de/Lehrbuch-Digitaltechnik-Eine-Einf%C3%BChrung-VHDL/dp/3486589083/ref=sr_1_1?ie=UTF8&s=books&qid=1269100276&sr=8-1
auch gut:
http://www2.informatik.uni-jena.de/~doersing/lehre/ps/ps_ws02/fpga.pdf
... bei FPGAs gibt weiß ich nicht für welchen ich mich entscheiden soll.
LG
Das kanns du im Augenblick ja auch gar nicht - so geht auch keiner an ein Projekt ran - Du musst/ solltest als erstes ein Pflichtenheft erstellen danach gehts ans Grobe Konzept dann kommt VHDL/SystemC/Verilog oder was auch immer.
Erst danach in den SimulationsTools kannst sehen was du so an Gattern Verbraten hast.
Das was Du vorhast , wenn ich das so Richtig verstanden habe, ist ein ziemlich "Grosser" Brocken. Da beissen sich sogar die Experten sich die Zähne aus.
Schreib Dir selber auf was du vorhast und dann bemühe mal die Tante Google - CPLD's->vergiss es , ARM-> die grösseren FPGA's haben auch schon welche drin , DSP's-> könnte ein Teil deine Probs lösen.
Wenn du genauere Beratung möchtest 150€/stunde , weil das was du vorhast nur noch Kommerziellen hintergrund haben kann, oder eine Schnapps-Idee (ohne jemals realisierbar zu sein) ist.
Warum ? - weil du etwas vorhast was ein Team aus 15-20 Leuten ca 2 Jahre beschäftigen würde.
@Vitis: Danke für die Links, ich werd mich am Montag nochmal in der Bibliothek umsehen ob ich da was finde.
@Artur: Danke für die motivierenden Worte :)
Ich weiß genau was du meinst. Wenn einfach irgendjemand daherkommt und sagt er versucht alleine die Chinesische Mauer zu bauen, würde ich ihm auch den Vogel zeigen.
...,weil das was du vorhast nur noch Kommerziellen hintergrund haben kann, oder eine Schnapps-Idee (ohne jemals realisierbar zu sein) ist.Kommerzielle Hintergedanken habe ich eigentlich nicht. Vielleicht stimmt das mit der Schnapps-Idee ja, aber meine Hauptmotivation ist etwas neues lernen zu wollen. Und dabei tu ich mir einfacher wenn ich ein Ziel vor Augen (wohl eher am Horizont ;)) habe. Ich bin aber der Meinung, dass es nicht so schwer sein kann ein paar (millionen) Pixel herumzuschaufeln, und einen Mittelwert zu berechnen (Vielleicht täusche ich mich aber auch komplett).
Mein "Plan" sieht folgendermaßen aus:
1) Algorithmen in Pseudo-Code schreiben die die Hauptaufgaben ausführen (herumschaufeln bzw interpolieren, und das möglichst parallel)
2) VHDL lernen und dabei versuchen meinen Pseudo-Code umzusetzen und Routinen implementieren um die I/O Aufgaben zu erledigen.
[3) Wenn ich der Meinung bin, dass es für mich schaffbar is mehr zu machen (komplexere Aufgaben), dann werd ich das probieren]
Natürlich ist der 2te Schritt ein bisschen naiv, da soweit ich das verstanden habe, der Code letzten Endes in Kombinationen von einfachen Gatter-Operationen umgesetzt werden muss.
LG
BlackDevil
20.03.2010, 18:06
Dann kauf dir bei Digilent ein Spartan3 Board oder wart Spartan6 Boards ab, schau bei Xilinx nach Eva Boards da gibts die ab 50$ und lern VHDL. VHDL ist ämlich was völlig anderes von der PRogrammierart her als das herkömmliche C das man kennt.
Dann fang an mit Hello World, einem Counter, PWM, kommunizier mit einem Atmega (oder PIC oder welchem auch immer) über USART, I2C und SPI, schließ ein LCD an und mach eine einfache Textausgabe, lies aus einer Textdatei auf einer SD Karte und gib das auf einem LCD aus, gib MP3 wieder und dann versuch dich an Bildverarbeitung.
Zumindest ist das mein angegangener Weg. Bildverarbeitung ist nämlich nicht einfach, weder für dich noch für den zukünftigen Prozessor. Es gibt allemöglichen Algorithmen für Kantenerkennung und Co, da braucht man das Rad nicht zwei mal erfinden. Es ist dennoch alles andere als Einfach.
weil du etwas vorhast was ein Team aus 15-20 Leuten ca 2 Jahre beschäftigen würde.Also wenn ich das richtig sehe soll am Ende so etwas wie eine Webcam stehen, nur eben mit hoher Auflösung und ein bischen eingebauter Bildverarbeitung. Wenn man damit 15 Leute 2 Jahre beschäftigen kann, dann sind die entweder faul oder unfähig.
Ich stelle mal die Behauptung auf, daß man das Ganze mit nur 4 fähigen Entwicklern in etwa einem Jahr fertigstellen kann (wenn alle Vollzeit an diesem Projekt arbeiten). Man braucht einen für die Elektronik, einen für den FPGA, einen für den DSP und einen für die PC-Software (wobei z.B. der Elektroniker auch nur am Anfang benötigt wird, denn sobald Schaltung und Layout entworfen, und die Platinen bestückt und getestet sind, hat er idealerweise nichts mehr zu tun).
Bitte gerne ... :)
Was die Machbarkeit des Projektes angeht:
http://www.youtube.com/watch?v=RFz_CQuMPjk
> Ich bin aber der Meinung, dass es nicht so schwer sein kann ein paar
> (millionen) Pixel herumzuschaufeln
Wobei da der Faktor Zeit noch ins Spiel kommt :) Terrabyte/Sekunde ist schon ne Hausnummer ;)
Bei "großen" Projekten ist halt wichtig "dran" zu bleiben, hab grad n Projekt nach
4 Jahren "abgeschlossen" ... nächste Woche gibts nen Händedruck mit der Kanzlerin dafür ;)
Die Konkurrenten haben mir wiederholt gesagt: "des geht net, des kann nit gehe" ...
Ergebnis:
http://www.hoerner-electronics.net/images/photoalbum/album_3/ivif2010_gold_4c.jpg
Also ... Anfangen
http://www.nst-grafikdesign.de/web-content/bilder/Verkehrszeichen_Baustelle2.GIF
Also wenn ich das richtig sehe soll am Ende so etwas wie eine Webcam stehen, nur eben mit hoher Auflösung und ein bischen eingebauter Bildverarbeitung.
Du siehst das richtig (nur das es weder mein W-Lan noch mein I-Net schaffen diese Datenmengen in der Zeit zu transportieren).
@Vitis: Gratuliere zu deinem Erfolg. Darf man Fragen was das Projekt war??
Ich hoffe ich komme nie in die Situation mich mit einem Politiker treffen zu müssen, da ich im Allgemeinen nicht viel von denen halte. Aber das ist ein anderes Thema ;)
Ich werd mich in nächster Zeit ein mal in die Materie einarbeiten, und dann weiter sehen. Danke für die große Hilfe.
LG
P.S.: ich werd mich einfach an meine Signatur halten
BlackDevil
21.03.2010, 10:11
Hast du schon eine Idee wie die Daten transportiert werden (Kamera => FPGA)?
Ja klar, war dieses Projekt hier:
http://www.hoerner-electronics.net/download/pdf/Flyer_Fermcon_Piccolo.PDF
Das FPGA nah an die Kamera und parallel die Daten rein, ist am Einfachsten denke ich
Hast du schon eine Idee wie die Daten transportiert werden (Kamera => FPGA)?Da er sich wohl schon für eine bestimmte Kamera entschieden hat, ergibt sich das eigentlich mehr oder weniger von allein. Falls mehrere mögliche Schnittstellen zur Verfügung stehen, und alle rein hardwaremässig verwendbar wären (Anzahl benötigter Pins etc.), sollte man sich natürlich für die entscheiden die sich FPGA-seitig am einfachsten implementieren lässt.
[quote]...
Ich stelle mal die Behauptung auf, daß man das Ganze mit nur 4 fähigen Entwicklern in etwa einem Jahr fertigstellen kann (wenn alle Vollzeit an diesem Projekt arbeiten). Man braucht einen für die Elektronik, einen für den FPGA, einen für den DSP und einen für die PC-Software (wobei z.B. der Elektroniker auch nur am Anfang benötigt wird, denn sobald Schaltung und Layout entworfen, und die Platinen bestückt und getestet sind, hat er idealerweise nichts mehr zu tun).
Sagte ein NICHTS-Ahnender Amateur - der wohl keine Ahnung von der Materie (Bildverarbeitung/FPGA-progs/...../.....) und FPGA's hat.
Ein FPGA ohne das richtige "Futter" ist nur ein Dummer Silizium-Baustein - Auf das FUTTER kommt es an.
Hast du Dir schon mal die "Traum"-Auflösung Angeschaut ? und dann noch in Echtzeit und nach Möglichkeit das alles nur mit einem FPGA ?
Sagte ein NICHTS-Ahnender Amateur - der wohl keine Ahnung von der Materie (Bildverarbeitung/FPGA-progs/...../.....) und FPGA's hat.Nein, das sagte ein Firmwareentwickler der schon an wesentlich komplexeren Projekten gearbeitet hat, bei denen es darum geht mit einem oder mehreren FPGAs, einem DSP und einem PC relativ aufwändige Signalverarbeitung bei sehr hohen Geschwindigkeiten durchzuführen. Ich weiss also ganz genau wovon ich rede, da ich jeden Tag beruflich mit solchen Problemen zu tun habe. Ach, und wie der Zufall so will bestand meine Diplomarbeit zu ca. 95% aus Bildverarbeitung (das allerdings auf dem PC, bei niedriger Geschwindigkeit).
Zugegeben, meine Kompetenz hört an der Schnittstelle zwischen DSP und FPGA auf, aber ich sehe ja jeden Tag aufs neue was unsere FPGAs leisten müssen, und verglichen damit wirkt diese Aufgabe beinahe trivial.
Hast du Dir schon mal die "Traum"-Auflösung Angeschaut ? und dann noch in Echtzeit und nach Möglichkeit das alles nur mit einem FPGA ?Auflösung und Framerate sind relativ hoch, das bestreite ich garnicht. Aber der FPGA hat - von der bloßen Datenrate abgesehen - keine besonders anspruchsvollen Aufgaben zu lösen. Das Schlimmste wären wohl noch die evtl. benötigten Kompressionsalgorithmen.
Zudem war zwar zu Beginn des threads eine FPGA-only Lösung angedacht, aber ich denke doch daß sich inzwischen eher eine Kombination aus FPGA und DSP herauskristalisiert hat.
BlackDevil
21.03.2010, 14:15
Also Bildverarbeitung nur mit FPGA is möglich... Und bei der Übertragung hatte ich an LVDS gedacht, immerhin kann man die Kamera ja nich sooooo ah an den FPGA packen
Auflösung und Framerate sind relativ hoch, das bestreite ich garnicht. Aber der FPGA hat - von der bloßen Datenrate abgesehen - keine besonders anspruchsvollen Aufgaben zu lösen. Das Schlimmste wären wohl noch die evtl. benötigten Kompressionsalgorithmen.
Der Meinung bin ich als FPGA-Anfänger auch, wobei ich die Kompression wenn es sein muss auch einem DSP überlassen würde.
Zudem war zwar zu Beginn des threads eine FPGA-only Lösung angedacht, aber ich denke doch daß sich inzwischen eher eine Kombination aus FPGA und DSP herauskristalisiert hat.
Wie gesagt, ich möchte das "umsortieren" der Pixel auf dem FPGA realisieren, die Kompression kann auch auf einem DSP stattfinden und die aufwendigen Berechnungen auf einem PC (wie bei einer handelsüblichen Webcam)
Und bei der Übertragung hatte ich an LVDS gedacht, immerhin kann man die Kamera ja nich sooooo ah an den FPGA packen Blöde Frage: warum?? wegen unterschiedlicher Spannung?
LG
BlackDevil
21.03.2010, 16:54
Weil damit Datenraten von mehreren Gbit erreicht und teilweise 166MP/sec übertragen werden ... Ist eigentlich gängig Videodaten damit zu übertragen
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.