"RGB"-Signal - USB - Adapter - Aufwand

>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

>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 :)

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.

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.

>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.

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.

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.

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?