Servus! Erstmal: ich hoffe, ich bin hier richtig, wenn nicht: sorry :) Um es kurz zu fassen, folgende Situtation: ich habe ein Projektaufbau, bei dem ein Farb-Display (320x240) mit dem im Bild angehängten Signalen angesteuert wird. Wie zu sehen ist kommen einfach getaktet durch CLK die Signale für ein Pixel rein, wobei die Farbwerte (R, G und B) parallel übergeben werden. Ich möchte nun etwas besteln, womit ich dieses "RGB" Signal abgreifen kann und am besten per USB oder einer anderen Schnittstelle zu einem PC übertragen kann. Die Steuer-Signale kann ich ignorieren (sind für Dimmung, An/Aus, etc.). Ich habe schon etwas Erfahrung im Programmieren von FPGAs und auch im Erstellen von Layouts mit ICs wie z.B. Atmel AVR, allerdings meist weniger komplex, Schrittmotor-Synchronisation etc. Software-seitig (die Software am PC, die aus z.B. dem USB-Signal das Bild zusammenfriemelt und speichert) sollte kein Problem sein, damit habe ich Erfahrung. USB als Schnittstelle zum PC würde ich vorziehen, da es da schon diverse ICs mit Treibern gibt, die daraus für den Rechner einfach einen COM/Seriellen Port machen, was denk ich reichen würde. Nun meine Fragen: - wie würded ihr das umstetzen (Prototyp!): - ein kleines FPG-Board, evtl. schon mit USB-ICs o.Ä.? - eins/zwei Atmel (1er USB, einer "Converter") + evtl. Speicher falls nötig, dazu ein Layout bastel und auf ein Leiterboard klatschen - wie schätzt Ihr den Aufwand ein? etwas Erfahrung mit allem ist vorhanden, aber nicht extremst vertieft. - gibt es was Ähnliches schon? - Zeitaufwand? Ich hoffe, Ihr könnt mir hier weiter helfen. Ich hätter gerne Lust, das umzusetzen und mich darüber mehr in die Materie zu vertiefen. Vielen Dank Thomas
Angehängte Dateien:
-
if.png
35 KB
>USB als Schnittstelle zum PC würde ich vorziehen, da es da schon diverse >ICs mit Treibern gibt, die daraus für den Rechner einfach einen >COM/Seriellen Port machen, was denk ich reichen würde. 320 x 240 x 3 Farben x 60Hz x 10 = 138.24MBit/s Das macht kein COM Port.
> 320 x 240 x 3 Farben x 60Hz x 10 = 138.24MBit/s
Wo kommt die 10 her?
>Wo kommt die 10 her?
1 Startbit + 8 Datenbits + 1 Stopbit
Thomas schrieb: > Ich möchte nun etwas besteln, womit ich dieses "RGB" Signal abgreifen > kann und am besten per USB oder einer anderen Schnittstelle zu einem PC > übertragen kann. Schau dir mal Softwarelösungen wie z.B. (Tight-)VNC oder sonstige "Fernverwaltungssysteme" (wie z.B. Back Orifice) an. Der von dir getriebene Aufwand lohnt nicht wirklich, es sei denn du schickst dein 24Bit-RGB-Signal auf DACs(R2R geht vielleicht) und greifst das mit einem KVM-Umschalter ab, der seinerseits einen VNC- oder Sonstwas-Server aufmacht, auf den du dann per Ethernet zugreifen kannst. mfg mf PS: Der Umweg über Analogsignale wäre für mich jedenfalls nicht akzeptabel. Falls du etwas für ein System suchst, das nur "Kommandozeile" kann, also keine GUI wie Windows oder Xserver oder wasauchimmer anbietet, kann man das problemlos per telnet-server, comport oder sonstwie viel besser fernsteuern/fernwarten.
>Der von dir getriebene Aufwand lohnt nicht wirklich, es sei denn du >schickst dein 24Bit-RGB-Signal auf DACs(R2R geht vielleicht) und greifst >das mit einem KVM-Umschalter ab, der seinerseits einen VNC- oder >Sonstwas-Server aufmacht, auf den du dann per Ethernet zugreifen kannst. Ich würde einfach eine USB Kamera vor das Display pappen;)
@holger: sorry, ganz vergessen: das Bild muss nicht in Echtzeit durchgereich werden, es werden eher so zw. 4-10 Bilder/sec oder eine Art "on Demand". Auf das (statische) Bild soll dann eine Mustererkennung und/oder OCR angewand werden. @Mini Float: das hört sich in der Tat aufwendig an, allerdings wollte ich es so einfach wie möglich halten. eine Server-Client umsetzung hatte ich eigentlich nicht vor. trotzdem danke.
holger schrieb: > Ich würde einfach eine USB Kamera vor das Display pappen;) Das ist zurzeit der Fall, nur leider ist die Kamera nicht wirklich ausreichend gut, z.B. eine Pixelvergleich machen zu können.
>@holger: sorry, ganz vergessen: das Bild muss nicht in Echtzeit >durchgereich werden, es werden eher so zw. 4-10 Bilder/sec oder eine Art >"on Demand". Auf das (statische) Bild soll dann eine Mustererkennung >und/oder OCR angewand werden. Na dann ist eine USB Kamera doch bestens dafür geeignet. 320 x 240 x 3 x 4 x 10 = 9.2MBit/s Dafür reicht kein COM und USB 1.1 auch nicht.
holger schrieb: >>@holger: sorry, ganz vergessen: das Bild muss nicht in Echtzeit >>durchgereich werden, es werden eher so zw. 4-10 Bilder/sec oder eine Art >>"on Demand". Auf das (statische) Bild soll dann eine Mustererkennung >>und/oder OCR angewand werden. > > Na dann ist eine USB Kamera doch bestens dafür geeignet. > > 320 x 240 x 3 x 4 x 10 = 9.2MBit/s > > Dafür reicht kein COM und USB 1.1 auch nicht. wie geschrieben, kamera ist für diverse Aufgaben suboptimal. deswegen ja das vorhaben. allerdings sehe ich das gerade leider so etwas auseinandernder bröckeln :)
Das sollte mit einem kleinen FPGA und einem USB 2.0 HighSpeed Controller sehr simpel sein. Der FPGA speichert die 24 Bit in einen FIFO, der auf der Schreib-Seite 32 Bit Breite hat, auf der Lese-Seite 8 Bit. Dann list du die Daten mit einem USB Controller aus, zum Beispiel dem Cypress FX2 im Slave FIFO Modus oder dem FT2232H. Fertig ist der Lack. Mit einem entsprechend tiefem FIFO könntest du sicherlich sogar die reichlich 13MB/s bei vollen 60Hz streamen. Musst nur auf der Schreiben-Seite die Sync-Signale irgendwie noch mit berücksichtigen. Vielleicht gleich in die übrig bleibenden 8 Bit rein schreiben und dann am PC auswerten. Da hast du gleich wieder die Sync-Signale.
wenn man die Bilder vorher komprimiert, braucht man nicht so viel übertragen.
Christian R. schrieb: > Das sollte mit einem kleinen FPGA und einem USB 2.0 HighSpeed Controller > sehr simpel sein. Der FPGA speichert die 24 Bit in einen FIFO, der auf > der Schreib-Seite 32 Bit Breite hat, auf der Lese-Seite 8 Bit. Dann list > du die Daten mit einem USB Controller aus, zum Beispiel dem Cypress FX2 > im Slave FIFO Modus oder dem FT2232H. Fertig ist der Lack. Mit einem > entsprechend tiefem FIFO könntest du sicherlich sogar die reichlich > 13MB/s bei vollen 60Hz streamen. Musst nur auf der Schreiben-Seite die > Sync-Signale irgendwie noch mit berücksichtigen. Vielleicht gleich in > die übrig bleibenden 8 Bit rein schreiben und dann am PC auswerten. Da > hast du gleich wieder die Sync-Signale. Genau sowas habe ich mir auch gedacht. Dazu habe ich schon etwas im Netz gesucht, nach einer Art kostnegünstigen Entwickler-board mit einem kleinen FPGA und USB 2.0 Controller. Du kennst nicht zufälligerweise eines? Eine andere Richtung: ich habe im Netz folgendes gefunden: http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=116&title=V2DIP1 ... ich kenne mich nicht wirklich mit FTDI etc. aus, aber nach dem, was ich darüber gelesen habe, sollte soetwas doch auch mit solch einem Modul möglch sein. Für mich hört sicher der VNC2 (http://www.ftdichip.com/Products/VNC2.htm) nach einem programmierbaren USB2.0 Controller inkl. Speicher und FIFO-Schnittstelle an, dazu gibts noch ne ToolChain. Oder irre ich mich da? Jemand shcon Erfahrung damit? Danke nochmal für die Hilfe.
slw schrieb: > wenn man die Bilder vorher komprimiert, braucht man nicht so viel > übertragen. Ja wenn es wirklich ein FPGA wird, wäre zumindest eine RLE, abhängig von der Leistung und den Ressourcen des FPGa sogar mehr drin.
Thomas schrieb: > Auf das (statische) Bild soll dann eine Mustererkennung > und/oder OCR angewand werden. Thomas schrieb: > Ja wenn es wirklich ein FPGA wird, wäre zumindest eine RLE, abhängig von > der Leistung und den Ressourcen des FPGa sogar mehr drin. RLE ist bei den vollen 24bit aussichtslos. Wenn man nur 12Bit, also von den 3x 8Bit nur das obere Nibble hernimmt, Könnte da mehr gehen. Oder vom FPGA die Eingangsdaten auf 256 Graustufen umkodieren lassen. Evalboard: Altera DE2 Board, allerdings nicht ganz so günstig. Dafür hat man eine Plattform, auf der einiges her geht. Mit den Boards lässt sich echt schön arbeiten, hab ich an der Uni in einem Praktikum verwenden dürfen. Vllt. lach ich mir so eines mal zum rumprobieren an. mfg mf
Mini Float schrieb: > Thomas schrieb: >> Auf das (statische) Bild soll dann eine Mustererkennung >> und/oder OCR angewand werden. > > Thomas schrieb: >> Ja wenn es wirklich ein FPGA wird, wäre zumindest eine RLE, abhängig von >> der Leistung und den Ressourcen des FPGa sogar mehr drin. > > RLE ist bei den vollen 24bit aussichtslos. Wenn man nur 12Bit, also von > den 3x 8Bit nur das obere Nibble hernimmt, Könnte da mehr gehen. Oder > vom FPGA die Eingangsdaten auf 256 Graustufen umkodieren lassen. > > Evalboard: Altera DE2 Board, allerdings nicht ganz so günstig. Dafür hat > man eine Plattform, auf der einiges her geht. > Mit den Boards lässt sich echt schön arbeiten, hab ich an der Uni in > einem Praktikum verwenden dürfen. Vllt. lach ich mir so eines mal zum > rumprobieren an. > > mfg mf Mit unter anderem dem DE2 von Altera hatte ich wärend meiner Diplomarbeit zu tun, die waren wirklich recht angenehm. Nur leider ist es diesmal ein mehr oder weniger privates Projekt und uns stehen nicht all zu viele Mittel bereit. Aber: falls, die Sache mit dem VNC2 nicht das Richtige ist, was haltet ihr davon: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_50&products_id=62 ? Sowas sollte doch ausreichen, oder? dazu gibt es noch ein Träger-board für die Entwicklungsphase, und wenn ich es irgendwann mal in ein hübsche Box packen will, kann man sich dazu stecker basteln. gruß Thomas
Mal ne ganz blöde Frage: Was ist auf dem Display eigentlich drauf das es sich lohnt mehrere Hundert Euro in Hardware und hunderte Stunden Arbeit zu investieren?
holger schrieb: > Mal ne ganz blöde Frage: > > Was ist auf dem Display eigentlich drauf das es sich lohnt > mehrere Hundert Euro in Hardware und hunderte Stunden Arbeit > zu investieren? Szenario ist, dass das Display sicherheitsrelevante Informationen in einer x-beliebigen Situtation für einen Nutzer darstellt. Um nun bei der Entwicklung solch eines sicherheitsrelevanten Stücks Hardware schon in der Entwicklungsphase Fehler zu finden und zu beheben, soll durch automatisierte Tests die Hardware in diverse definierte (Fehler-)Zustände gebracht werden, und die Ausgabe auf dem Display kontrolliert werden. Damit sich nicht jemande 24h am Tag hinsetzen muss, um sich das Display anzuschauen, soll das Bild abgefasst werden und per Mustererkennung/OCR oder sonstwelche Bildverarbeitung die Information ausgewertet und mit dem definierten Zustand verglichen werden. In unseren Köpfen jedenfalls klingt das Prinzip dieses "RGB-zu-USB-Wandlers", natürlich an die in anderen Umfängeund und Umgebungen, also nach einer interessanten und evtl. auch mal sich lohnenden Angelegenheit :) Allerdings treibt uns zur Zeit in erster Linie an, mal solch ein Projekt umzusetzen und ein Display, welches mit den Erzeugniss eines anderen Projektes betrieben wird, so abzugreifen.
Thomas schrieb: > @holger: sorry, ganz vergessen: das Bild muss nicht in Echtzeit > durchgereich werden, es werden eher so zw. 4-10 Bilder/sec oder eine Art > "on Demand". Auf das (statische) Bild soll dann eine Mustererkennung > und/oder OCR angewand werden. Wenn es nicht Echtzeit sein muss, mach doch folgendes: - Implementiere einen Zeilen und Spaltenzähler auf dem FPGA - Sende vom PC die Nummer der zu lesenden Zeile - auf dem FPGA: Wenn die zu lesende Zeile da ist, ins interne RAM lesen; dafür sollte auch das Blockram reichen. Dann Signal an den PC und die gegrabbte Zeile zum PC senden. - PC sendet die nächste zu lesende Zeile - das sollte dann nicht die folgende sein, sondern n+4 oder so, je nachdem, wie schnell die Übertragung ist. Bei n+1 müsstest Du sonst immer den nächsten Frame abwarten und bräuchtest bei 240 Zeilen 240 Frames, d.h. 4 Sekunden, wobei das meiste Wartezeit ist. Mit dieser Methode sollte das ganze leistungsmäßig unkritisch werden und die Hardware-Anforderungen gering halten. fchk
>Szenario ist, dass das Display sicherheitsrelevante Informationen in >einer x-beliebigen Situtation für einen Nutzer darstellt. Sowas dachte ich mir schon. >Um nun bei der >Entwicklung solch eines sicherheitsrelevanten Stücks Hardware schon in >der Entwicklungsphase Fehler zu finden und zu beheben, soll durch >automatisierte Tests die Hardware in diverse definierte >(Fehler-)Zustände gebracht werden, und die Ausgabe auf dem Display >kontrolliert werden. Und woher weiss du dann das das was du an das Display sendest auch ankommt? Du kannst mitsniffen am LCD Port, aber woher weisst du das das Display auch noch was anzeigt? Nimm ne Kamera.
Was spricht dagegen, das Display mit einer einfachen USB-Kamera zu filmen? Bei der geringen Auflösung dürfte kaum Information verloren gehen, so eine Kamera kostet praktisch nichts und Bildauswertungssoftware, die Bewegtbilder solcher Kameras auswertet, existiert auch.
Boards mit FPGA und USB 2.0 gibts beispielsweise hier: http://www.ztex.de/usb-fpga-1/index.d.html erhältlich glaub bei Trenz. Der VNC2 von FTDI ist doch ein Host Controller, oder?
Wie gesagt, zur Zeit arbeiten wir mit Kameras, haben schon diverse ausprobiert, Leihgaben vom Institut. Das Problem ist aber, dass wir für die verschiedenen Szenarien/Tests/Hardware immer gleiche Bedingungen schaffen wollen und das ganze evtl. auch im Feld eingesetzt werden soll. Eine Kamera bedeutet da einen recht hohen Konfigurationsaufwand und eine zu starke Abhängigkeit von der Umgebung (idealerweise immer dunkel, farb-und geometsiche Verzeichnung durch die Linsen etc.). Außerdem soll es auch möglich sein, Pictogramme oder Bilder, die teil der sicherheitsrelevanten Information sind, pixelgenau zu suchen bzw. zu vergleichen. Und Kameras, die so hochauflösend genug sind, damit auch bei etwas Entfernung noch nahezu Pixelgenaue Bilder zustande kommen, mit Objektive, die nahezu keine Störing mit reinbringen, kosten eine ganzen Batzen Geld. Wir WOLLEN gerade eine Alternative zu Kameras finden. Ich werd mich heute mal mit dem VNC2-Zeux auseinandersetzen und wenn das nicht das Richtige ist, mal zusehen, dass ich irgendo nen günstigen FGPA-USB-Aufbau herbekomme, oder nen Entwicklerboard. Wenn noch jemand dazu nen Ideechen hat, immer her damit :)
Christian R. schrieb: > Boards mit FPGA und USB 2.0 gibts beispielsweise hier: > http://www.ztex.de/usb-fpga-1/index.d.html erhältlich glaub bei Trenz. > Der VNC2 von FTDI ist doch ein Host Controller, oder? Zum VNC2 FTDI: ganz ehrlich ... ich weiß nicht wirklich was das Ding ist und was es kann bzw. ob es geeignet ist, sah nur interessant aus (und günstig). Wird, bei deine Reaktion, aber anscheinend nicht das Richtige sein. Danke für den Hinweise zu ZTEX, diese (http://www.ztex.de/usb-fpga-1/usb-fpga-1.11.d.html) Board sieht recht interressant aus, hat aber leider einen kleinen Haken: es benötigt eine externe Stromversorgung und kann nicht einfach per USB betrieben werden. Man kann zwar ein zusätzliches Versorgerboard basteln, aber trotzdem wäre dann eine extra z.B. 5V Versorgung für diese nötig. Das schränkt den Einsatz der Gerätschaft wieder etwas ein. Oder irre ich? Aber für einen Prototyp evtl. sogar ein Kandidat.
Ah, der VNC-II kann auch Device. Naja, aber mit FullSpeed kommst du nicht weit. Wegen USB-powered Board schau mal hier: http://www.cesys.com/fpga/spartan/efm01_de.html
Christian R. schrieb: > Ah, der VNC-II kann auch Device. Naja, aber mit FullSpeed kommst du > nicht weit. > > Wegen USB-powered Board schau mal hier: > http://www.cesys.com/fpga/spartan/efm01_de.html Danke, das sieht genau richtig aus. Werde mir das mal genauer anschauen und evtl. damit einen Prototypen basteln.
Ich würde das dann so machen, dass der PC über USB den FPGA veranlasst, ein komplettes Bild in den FIFO zu laden. Halt ein Startsignal und dann wartet der FPGA auf das nächste Data Enable Signal, speichert alle Pixel ab, bis es wieder weg geht. Dann hast du ein komplettes Bild im Speicher. Musst aber eben schon sofort nach dem Startsignal anfangen mit auslesen, sonst ist der Speicher voll. 320x240x2 wären 150 BlockRAM Blöcke zu je 1k*16. Der S3500 hat aber nur 28 oder sowas.
Wenn ich mir diesen hier (http://apple.clickandbuild.com/cnb/shop/ftdichip?productID=129&op=catalogue-product_info-null&prodCategoryID=5) anschaue, der sollte doch auch gehen, oder? Vorteil: dazu gibt es schon D2XX Treiber, sodass ich nicht über einen COM-Port sondern mit einer DLL direkt mit dem Gerät kommunizieren kann. Sehe ich das richtig?
Ja, siehst du richtig. Damit gehts natürlich genauso. Mit dem Cypress FX2 kann man aber natürlich auch mit einer DLL sprechen. Der FT2232H hat gegenüber den Cypress den Vorteil, dass man keine Firmware auf den USB Controller bringen muss. Das Board wäre also noch besser geeignet um schnell ans Ziel zu kommen.
Christian R. schrieb: > Ja, siehst du richtig. Damit gehts natürlich genauso. Mit dem Cypress > FX2 kann man aber natürlich auch mit einer DLL sprechen. Der FT2232H hat > gegenüber den Cypress den Vorteil, dass man keine Firmware auf den USB > Controller bringen muss. Das Board wäre also noch besser geeignet um > schnell ans Ziel zu kommen. Sehr gut, dann wird es wohl dieser. Vielen Dank für dein hilfreichen Beiträge. Gruß Thomas
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.