Hallo liebe Community, ich würde gerne das Bild eines portablen Geräts auf den PC übertragen. Eignen sich dafür nur FGPAs mit SRAM, wo das Bild reinkopiert wird oder gibt es noch andere Wege? Welche FGPAs würdet ihr mir empfehlen? Da ich so etwas noch nie gemacht habe, wäre ich euch für jede Antwort dankbar. Liebe Grüße
> ich würde gerne das Bild eines portablen Geräts auf den PC übertragen. Ein Bild von einem Gerät könntest du z.B. über einen Fotoapparat, eine Webcam oder einen Scanner auf den PC bringen... :-/ > ich würde gerne das Bild eines portablen Geräts auf den PC übertragen. Also, nochmal von vorn: was für ein Gerät? welches Übertragungsprotokoll? warum gerade ein FPGA?
Ist es denn soviel verlangt, eine Frage präzise zu formulieren?
Ich möchte ans RGB-Signal, mit dem FGPA skalieren und per USB auf PC übertragen. Es handelt sich um ein Gerät wie ein Nintendo DS, der von Haus aus keine Möglichkeit bietet das Bild auf einen PC zu übertragen. Ich wollte mit meiner undeutlichen Frage nur meine Unwissenheit verbergen, aber habe am Ende wohl viel zu viele wichtigen Informationen vergessen dabeizuschreiben. Entschuldigung.
Wie waere es mit eine ganz normalen Video-Capture-Karte - die haben ueblicherweise einen Eingang fuer Fernsehsignale. Selberbauen - vor allem als blutiger Anfaenger! - ist ziemlich aussichtslos.
Eben. USB Frame Grabber für 15€. Dafür bekommst du bei einer FPGA Lösung nicht mal alle nötigen Schaltregler für das Board.
snes schrieb: > Ich möchte ans RGB-Signal, mit dem FGPA skalieren und per USB auf PC > übertragen. RGB nach PC, dafür gibt es die bereits erwähnten Video-Karten, nur... > Es handelt sich um ein Gerät wie ein Nintendo DS, der von > Haus aus keine Möglichkeit bietet das Bild auf einen PC zu übertragen. ... hat ein solches Gerät nirgends eine RGB-Schnittstelle. Dort werden die Daten ans Display digital übertragen. D.h. es müssten erst mal die entsprechenden Signale abgegrifffen und danach noch deserialisiert/decodiert werden. Wenn das passiert ist, muss dann wieder ein PC-taugliches Format hergestellt und dorthin übertragen werden. Am ehesten könnte ich mir vorstellen, dass ein FPGA diese Daten decodiert und z.B. als FBAS- oder VGA-Signal an eine Capture-Karte sendet. Sieh dir mal das an: http://home.comcast.net/~olimar/DS/jumbotron/
Vielen Dank für eure Beiträge! Ich merke schon, dass es ziemlich schwer für einen Anfänger ist, aber ich brauche immer irgendetwas Praktisches was ich wirklich umsetzen möchte, um mit etwas anzufangen. Was heisst "deserialisieren"? Jumbotron(?) vom Link schreibt ja etwas von RGB, DCLK1 und GSP1, die er abgreift. Handelt es sich bei RGB nicht jeweils um 5-Bit, die für die Farbintensität der jeweiligen Farbe übertragen werden? Wo ist der Haken bei einer direkten Übertragung, wobei man dem PC am Ende die Arbeit überläßt, die ankommenden Daten in ein Bild umzusetzen? Da ich wirklich keine Ahnung von der Thematik habe und nur Mutmaßungen mache, würde ich mich sehr freuen, wenn ihr mir Literaturvorschläge machen könntet.
snes schrieb: > Da ich wirklich keine Ahnung von der Thematik habe und nur Mutmaßungen > mache, würde ich mich sehr freuen, wenn ihr mir Literaturvorschläge > machen könntet. Dann ein guter Rat: Lass es. So ein Projekt ist Welten von deinem Wissen und Können entfernt. Ich sehe leider jeden Tag Leute, die entweder sich selbst und ihr können maßlos überschätzen oder sich irgend etwas einfach als viel einfacher vorstellen als es in Wirklichkeit ist.
Michael, ich bin hier im Forum, damit ich ein paar Tipps kriege, wie ich mir das Wissen aneignen kann. Ich kenne dich nicht, aber nach deiner Aussage konntest du das alles schon von Geburt an oder stirbst dumm.
Ich hätte vielleicht sagen sollen: "Es ist im Moment Welten von deinem Wissen und können entfernt". Selbstverständlich kannst du alles dazu notwendige lernen. Nur: Du musst dir zunächst einmal die absoluten Grundlagen aneignen. In der Schule versucht auch niemand den Schülern die Differentalrechnung beizubringen, wenn die Grundrechenarten noch nicht mal richtig angewendet werden können. Alleine die Programmierung eines FPGAs ist schon alles andere als trivial. Von den übrigen bei diesem Projekt auftretenden Problemen einmal abgesehen. Klar ist das alles lern- und machbar, aber es ist auf jeden Fall Lernstoff für Jahre.
Michael, deine Aussagen haben zwar alle nichts mit meinen Fragen zu tun gehabt, aber ich bin immer wieder erstaunt, dass manche Leute einen besser zu kennen scheinen, als man sich selbst kennt. Ich nehm's dir nicht übel, wenn du aufgrund von Erfahrungen oder deiner eigenen Lerngeschwindigkeit voreilige Schlüsse über mich ziehst, aber ich würde trotzdem nochmal die anderen User bitten mir Literaturtipps zu geben.
Naja, dann fang doch einfach an. Hol dir ein FPGA Board und lass ein paar LEDs leuchten. Wenn du das kannst meld dich wieder. Vielleicht schreiben ja mal ein paar der Profis hier ob sie sowas könnten und wie lange sie gebraucht haben um sich das Wissen anzueignen. Ich schätze mal 1-2 Hobby-Jahre wenn Elektronikgrundkenntnisse da sind. Wenn du dich jeden Abend 2-3 Stunden hinsetzt vielleicht schneller aber die Zeit hat man ja meist nicht.
> Hol dir ein FPGA Board und lass ein paar LEDs leuchten. Das wäre schon mal ein guter Anfang, denn so ein Board wird in dem GB-Projekt auch verwendet. Und dann kaufst du dir gleich noch ein Buch zum Thema. Auf gut deutsch wäre das Reichardt/Schwarz "VHDL-Synthese". Mit mehr englischer Sprachgewalt liest sich auch Ashenden "Designers Guide to VHDL" flüssig. Siehe auch Beitrag "VHDL-Buch f. Einsteiger" > Vielleicht schreiben ja mal ein paar der Profis hier ob sie sowas > könnten und wie lange sie gebraucht haben um sich das Wissen anzueignen. > Ich schätze mal 1-2 Hobby-Jahre wenn Elektronikgrundkenntnisse da sind. Nicht ganz abwegig, weil ja auch noch immer wieder was anderes dazwischenkommt. Und es gilt, gleich mehrere Sachen parallel zu lernen: FPGAs und VHDL. Ein FPGA kann mehr als VHDL beschreiben kann, und VHDL kann mehr beschreiben, als in ein FPGA abgebildet werden kann. Und die Schnittmenge muss man erst mal herausfinden.
@snes auch ohne das Detailwissen über FPGA's hast du doch mit sicherheit ein Konzept. Wie und Wo willst du die Daten abgreifen ? Etwa direkt am Display ? Und was soll der I2C Bus ? Irgendwie hab ich dein Konzept nicht verstanden. Das Buch "VHDL-Synthese" ist mittlerweile so etwas wie ein Standart Werk für Anfänger. Wenn du dich mit FPGA's beschäftigen willst, ist das wirklich zu empfehlen. Prinzipiell sollte das, was du vorhast möglich sein. Bei deinem Wissensstand würde ich aber minimum 1 Jahr Zeit dafür einplanen. Ob es dir die Zeit wert ist, musst du natürlich selbst wissen. Vielleicht kommst du mit einem Anderen Konzept schneller ans Ziel. >Was heisst "deserialisieren"? Einen Seriellen Datenstrom auf einen Parallelen Datenstrom umwandeln. >Handelt es sich bei RGB nicht jeweils um 5-Bit RGB ist erst mal nur die Abkürzung für Rot Grün Blau und sagt nichts über das verwendete Interface aus.
snes schrieb: > ich bin hier im Forum, damit ich ein paar Tipps kriege, wie ich mir das > Wissen aneignen kann. Studiere Informatik.
Hmm ob das Informatikstudium dann so viel bringt? Aus eigener Erfahrung kann ich sagen, dass man DAS in dieser Form so nicht lernen wird. Klar, nach dem Studium und 1-2 Jahren Praxiserfahrung in diesen Hardwarebereichen wird man das Projekt wohl so langsam hinkriegen :) Nur denke ich, dass es auch OHNE Studium in 1-2 Jahren machbar sein sollte. snes: Erarbeite dir das Protokoll deiner Signalquelle. Dann überlegst du dir, was deine Rahmenbedingungen für die Übertragung an den PC sind, d.h. was willst du eigentlich. Dann suchst du dir eine Schnittstelle aus, die: a) die geforderten Rahmenbedingungen erfüllt b) eventuell ausnutzbare Ähnlichkeiten zur Signalquelle hat c) für die man gut entwickeln kann Wenn du DAS geschafft hast, liegt vor dir ein Plan, den man stückchenweise umsetzen kann. Dazu brauchst du dann hier auch keine Hilfe mehr vermutlich, ansonsten frag :)
> Hmm ob das Informatikstudium dann so viel bringt? Aus eigener Erfahrung > kann ich sagen, dass man DAS in dieser Form so nicht lernen wird. Für die Hardwarebeschreibung hilft ein Informatikstudium nicht weiter, genausogut könntest du dafür BWL studieren. Wenn du schöne Bilanzen oder Java- (Perl, C#, C++, Pascal, wasauchimmer...) Programme schreiben kannst, bist du in etwa genau gleich weit weg von der Denkweise, die du für eine erfolgreiche VHDL-Beschreibung brauchst. Nur weil die Syntaxelemente von C in etwa so ähnlich wie welche von VHDL aussehen, tun sie noch lange nicht das selbe. Eine simple for-Schleife in VHDL wiederholt z.B. die Erzeugung von Hardwarekomponenten. Und aufpassen: VHDL ist nicht gleich FPGA!!! Du mußt für eine problemlose Verwendung eines FPGAs das Datenblatt dieses Bausteins lesen und verstehen können. Und da steht einiges drin. Sehr vieles davon wird nicht mit VHDL, sondern mit der Toolchain gemacht (z.B. die Pinzuordnung als das einfachste der einfachen Beispiele).
>Für die Hardwarebeschreibung hilft ein Informatikstudium nicht weiter RICHTIG! ;-) Es ist in den meisten Fällen sogar eher hinderlich, da die "Denke" eine ganz andere ist. Auch mein Tipp an dieser Stelle: Besorg dir ein günstiges FPGA-Board oder noch besser für den Anfang ein CPLD-Board und fang mal ganz klein damit an indem du z.B. eine LED blinken lässt, oder danach vielleicht mal einen PWM bastelst, mit dem du die Helligkeit einer LED zwischen zwei Werten umschalten kannst. Es gibt auch jede Menge online Literatur und Tutorials.. einfach mal ein bisschen googlen
Angehängte Dateien:
-
rot.jpg
56 KB
lkmiller, habe mir auf deinen Rat hin das Buch "VHDL-Synthese" gekauft. Bin zwar erst beim 3. Kapitel, aber ich denke, dass das Buch sehr gut fürs Eigenstudium geeignet ist. Ich plane aber nebenbei ein paar Kurse in diesem Bereich zu belegen (und in ein paar Monaten werde ich ja sehen wie lange ich brauche). Michael, möchte die Daten direkt vom Board abgreifen - 18 pins parallel. Der Nintendo DS verarbeitet für jede Farbe des RGB-Spektrums jedoch nur 5 und einen 6. bei Rot für "Alpha", also insgesammt 16-bit(A RRRRR GGGGG BBBBB). Habe zur Veranschaulichung die Stellen für die Farbe Rot markiert und als Bild angehängt. Zum Glück ist alles gut beschriftet. "VHDL-Synthese" scheint wirklich gut und trotz aller Theorie praxisorientiert zu sein. Ich kann damit denke ich eine Menge anfangen. Der Multiplexer am Anfang ist mir zumindest schonmal klar und auch die Syntax scheint sehr C-orientiert zu sein. "Designers Guide to VHDL" habe ich noch nicht bestellt, da ich erstmal "VHDL-Synthese" durchlesen möchte. Bis dahin werdet ihr sicher im Forum wieder von mir hören.
>möchte die Daten direkt vom Board abgreifen - 18 pins parallel. Der >Nintendo DS verarbeitet für jede Farbe des RGB-Spektrums jedoch nur 5 >und einen 6. bei Rot für "Alpha", also insgesammt 16-bit und was ist mit den Pinnen 17 und 18 ? was meinst du mit Alpha ? Ich hoffe du weisst wenigstens wie das Datensignal aufgebaut ist. Mit den Farbwerten alleine ist es ja auch nicht getan. Irgendwoher brauchst du ja auch einen Takt.
Auf einer Internetseite steht auch noch, dass man LDR/LDG/LDB 0-5 für die Farbewerte abgreifen muss. http://draculaojisan.blog8.fc2.com/blog-entry-440.html Da dort jedoch nicht genau beschrieben wird, wie sich aus DCLK2、LS2 und GSP2 genau vsync/hsync ergibt und ich nicht plane irgendwelchen Code aus dem Internet für mein Vorhaben zu benutzen, werde ich mich wohl an die Informationen der Jumbotronseite halten. (GSP1 wird als Vsync-Signal abgegriffen und Hsync lässt sich durchs Zählen von DCLK1 bestimmen.) Dadurch sollte man mit weniger Mühe ein geeignets CSync-Signal erzeugen können. Mit "Alpha" meinte ich einen binären Alphakanal, der bestimmt, ob eine Farbe transparent ist. So benutzt man z.B. bei der NDS-Programmierung 15-Bits für die Farben und 1-Bit als Alhakanal. Ich habe jedoch nicht daran gedacht, dass der Nintendo DS in der Lage ist 262.144 Farben (2^18) auszugeben, wodurch sich dann natürlich alle Pins erklären.
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.