Hallo Leute,
ich möchte einen CCD-Sensor mit einem Mikrocontroller auslesen um die
Daten
dann über Gigabit an meinen PC zu senden.
Ich habe mir schon die Finger wund gegoogelt und finde einfach kein
Projekt
der sich mit Gigabit Modulen beschäftigt, bzw ich finde keine Gigabit
Module zum kaufen.
Ich stelle mir das wier hier vor
(http://www.micro4you.com/store/ENC28J60-Ethernet-Module/prod_78.html)
nur mit 1000BaseT statt 10BaseT.
Wäre schön wenn mir da jemand Links oder Quellen geben könnte.
Ich danke im Voraus für alle Beiträge.
Gruß
Frank
Leider gibt es meines Wissens keine Module für GbE. Das liegt offenbar
schon an den sehr hohen Anforderungen, denn mit einem Microcontroller
kommt man da nicht weit. Im Normalfall ist da ein FPGA nötig, um die
Daten überhaupt so schnell verarbeiten zu können. Wir haben das für ein
Projekt mal begonnen, aber aus Aufwand-Gründen dann abgebrochen. Eine
zuverlässige, schnelle und flexible Implementierung von UDP/IP oder
TCP/IP ist relativ aufwendig. Wir hatten das mit dem Virtex 4 FX von
Xilinx probiert. Der hat einen GbE MAC und einen PPC Prozessor on Board.
Muss es denn unbedingt GbE sein? USB 2.0 HighSpeed reicht nicht?
Das Problem dürfte schlicht die hohe Datenrate sein. Es nützt ja nichts,
auf der Leitung 1000 MBit zu haben und diese Daten dann nicht in den
Controller zu bekommen. Man muss die ja dann auch noch verarbeiten. Mit
SPI ist da nichts zu machen, PCI hat dann schon eine ganze Menge
Anschlüsse.
Deswegen reicht 100 MBit in den meisten Fällen eben aus. Mehr kannst Du
eh nicht verarbeiten. Wenn Du einen Micro hast (da reden wir dann schon
mal von eine Intel Atom oder ähnlichem), der 1 GBit/s senden kann, ist
so ein Modul Dein kleinstes Problem. Dann packst Du das Gigabit
Interface mit auf Dein xx Lagen Multilayer.
Die Anwendung spricht aber eher dafür, dass 100 MBit völlig ausreicht.
Gruss
Axel
Selbst im PC ist Gigabit-Ethernet nicht gerade die leichteste Übung.
Da werden Betriebssystemarchitekturen benutzt, die mit "zero copy"
arbeiten, d. h. die Stelle im Speicher, an der der Ethernetadapter
den Rahmen empfangen und per DMA hinterlegt hat, ist am Ende die
gleiche Stelle, die auch die Applikation benutzt, um ihn zu lesen.
Meinst Du die Lisa? Der Würfel-Mac kam '84 heraus und hatte gnadenlose
128 kiB RAM, aber nichts, was man heute als Netzwerkinterface bezeichnen
wollen würde.
Wo soll da "zero-copy" durchgeführt worden sein?
Lisa, hm. Ich kenne mich nur mit dem Mac aus, auch wenn Teile des MacOS
aus der Lisa übernommen wurden.
Beschrieben ist das Ganze in den dicken Wälzern, die man mittlerweile
runterladen kann. Ich hatte die damals noch für viel Geld in Papier
kaufen müssen. AppleTalk-Buch beschreibt alles haargenau. Bereits der
erste Mac hatte LocalTalk - was das machte.
Yep, aber was nützt ein superschnelles Interface zum
Ethernet-Controller, wenn der Core zu langsam ist und keine vernünftige
Datenrate hinbekommt.
Andererseits dürfte es schon schwierig sein, bei Controllern mit
hinreichend Schmackes im Core ein halbwegs aktuelles Exemplar zu
kriegen, das noch kein Ethernet mit an Bord hat.
Das Problem bei den Gigabitnetzwerken ist die hohe Datenrate. So gibt es
z.B. auch keine Tokenring-Netzwerke mehr, da es an den Knotenpunkten
immer zu Datenstaus kam und eine Drosselug der Übertragungsfrequenzen
nötig war, um die Kommunikation aufrechtzuerhalten. Solche Probleme
traten früher meisst dann auf, wenn Druckauftraege an Netzwerkdrucker
gesendet wurden oder intervallgeschachtelte HDD-Spiegelungen zur
Datensicherung erfolgen. Darum ging man schon beim Übergang vom 80486
zum Pentium I dazu über, als neuen Standard das Ethernet zu etablieren
und Randerscheinungen wie das Tokenring-Verfahren zu vergessen. Zunächst
begann man mit Datenübertragungsraten von etwa 10MBit am Anfang der
90er. Mit zunehmender Frequenzsteigerung kam man im Laufe der Zeit auf
Datenübertragungsrten von 100MBit, manchmal auch 200MBit, je nach
gewählter interner Taktung. Aber für Hobbyanwendungen wie Deine
beschriebene gewünschte Funktion war zu Beginn noch kaum etwas zu haben.
Man musste früher am besten Netzwerkkarten kaufn und die Teile dort
draufgebauten Komponenten verwenden. Erst Mitte 2005 überhaupt sind
Ethernet-Komponenten auch für den Hobbybereich verfügbar, vorher war das
Ethernet nicht mal Industriestandard, dort verwendete man - wenn
überhaupt neben Telefonleitungen - nur serielle Datenleitungen wie
RS232, falls Dir das ein Begriff ist. Die Entwicklung der
Computerkomponenten geht also in der Regel immer schneller als die
Verfügbarkeit von Bastlerbauteilen für Hobbyelektriker, um die modernen
Arten der Kommunikation nutzen zu können.
Ein Lösungsvorschlag wäre also folgender, wenn Du Deine Komponente in
ein Gigabit-Lan einspeisen willst - nimm bereits bewährte
100MBit-Komponenten und kaufe als Zwischenkommunikationseinheit ein
billiges Gigabit-Switch z.B. von Reichelt
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=ECA2;GROUPID=4302;ARTICLE=48869;START=0;SORT=artnr;OFFSET=16;SID=28cHg9nqwQARwAAGdAThs325133190f194595169026fc62dc16d3
.
Das zusätzliche Switch gestattet Dir dann eine Verbindung zur
Gigabitverkabelung, ohne dass Du die übrigen Komponenten Deines
Netzwerkes verlangsamst, denn das Gigabit-Switch tastet in 100MBit-Raten
Dein angeschlossenes Gerät auf der einen Seite ab und speist die
Ergebnisse in passender Gigabit-Taktung in das Gigabit-Lan dann ein,
somit brauchst Du Dir darüber keine Gedanken mehr zu machen.
Carsten S. schrieb:
> Seit wann ist Ethernet das nonplusultra?
Seit viele adäquatere und technisch bessere Lösungen mit dem eine
Grössenordnung günstigeren Preis von Lösungen auf Basis Ethernet
konkurrieren.
A. K. schrieb:
> Seit viele adäquatere und technisch bessere Lösungen mit dem eine> Grössenordnung günstigeren Preis von Lösungen auf Basis Ethernet> konkurrieren.>
was sind denn bessere Lösungen als Ethernet? Usb etwa ...
lachlachlach...
Für Storage beispielsweise Fibre Channel. Da aber in der Entwicklung von
Ethernet viel mehr Geld steckt, geht die Tendenz dahin, Ethernet als
Basis zu verwenden. Sei es über TCP/IP (iSCSI), sei es direkter (FCoE).
Bei High-Performance-Clustern ist es ähnlich. Ethernet ist anderen
Lösungen zur Rechnerkopplung unterlegen, aber sehr viel billiger.
Anderes Beispiel mit kleineren Raten: Telefonie&Co. TCP/IP wie auch
Ethernet sind dafür grässlich schlecht geeignet. Dennoch findet man
beides auch dort mittlerweile an allen Ecken und Enden, im DSL
mittendrin, oben drauf als VOIP, in Standleitungsnetzen als Interface,
oben drauf zum Tunneln klassischer ISDN-Standleitungen, ...
Hallo Jungs,
vielen Dank für die Antworten.
Das scheint doch aufwändiger zu sein als angenommen. Ich werde erstmal
auf ein 100Mbit/s Modul zurückgreifen oder gleich mit dem Grasshopper
experimentieren, der hat glaube ich die 100Mbit/s auf dem Chip.
Nochmals vielen Dank für die Antworten
Frank
...sofern doch noch irgendwo Infomaterial zu einem Gigabit Ethernet
Modul auftaucht, bitte posten.
Das Problem mit dem Gigabit Ethernet ist in der Tat, die Daten auf den
Bus zu bekommen. Erst muss man mal einen Controller haben, der es
beinhaltet. Ein AVR32UC3 gehoert zB nicht dazu. Macht ja auch nur
lumpige 90 MIPS und hat dabei ein 100MBit Interface. Ein naechster, der
AVR32AP7000 hat 2 100MBit Interfaces, was als genuegend fuer 150MHz mit
210 MIPS gesehen wird. Moeglicherweise gibt's mal etwas mit 1GBit. Zu
diesen Controllern gibt's dann ein Linux und Treiber. Das war's dann
auch mit Echtzeit. Alternativ kann man ohne Betriebssytem was mit ASM
zusammelkloppen, nachdem man sich die Standardwerke bezueglich Ethernet
und Packeten reingezogen hat.
Machen koennte man Vieles, aber wie oben schon gefragt wurde:
Kommen denn tatsaechlich soviele Daten, dass Gigabit noetig ist?
Wenn nicht, warum soll es dann Gigabit sein?
Gast
> Ich wage auch zu bezweifeln, dass aus einem CCD-Sensor soviele Daten> herauskommen.
Och das kann man schon provozieren. Nehmen wir mal unkomprimiertes
1080p50 an, dann bekommt man da
1
1080 Zeilen *1920 Pixel/Zeile *50/s ≈ 99MPixel/s
Wenn man dann noch adäquat (nicht) komprimiert, z.b. in RGB32, dann geht
das auch nicht mehr durch Gigabit Ethernet durch.
Ob man sowas mit einem handelsüblichen Mikrocontroller verarbeiten will
ist aber eine ganz andere Frage ;-)
Nix für ungut
Abdul K. schrieb:
> Eine normale Festplatte kann den Datenstrom gar nicht kontinuierlich> speichern.
ich weiss ja nicht was du unter aktuellen festplatten verseht aber jeder
aktuelle ( > 500GB ) kann über 100Mbyte/s schreiben. Auserdem gibt es ja
auch noch Raid-Controller da sind auch 300Mbyte/s nicht das Problem.
Eine Frage des CCD. Bei lumpigen 4000x2500 (10Mega) pixeln zu 1 Hz ist
man bei 10MSample zu 3x8bit, macht 30MByte. Nun gibt es Leute, die
empfinden ein Video mit 1Hz als etwas lahm, und dann geht die Datenrate
eben hoch. Will damit sagen, mit einer CCD kann man nahezu beliebige
Datenmengen produzieren. Ein Kompressor ist etwas Ergibiges und etwas
beliebig Aufwendiges.
Peter schrieb:
> Abdul K. schrieb:>> Eine normale Festplatte kann den Datenstrom gar nicht kontinuierlich>> speichern.>> ich weiss ja nicht was du unter aktuellen festplatten verseht aber jeder> aktuelle ( > 500GB ) kann über 100Mbyte/s schreiben. Auserdem gibt es ja> auch noch Raid-Controller da sind auch 300Mbyte/s nicht das Problem.
Ich ging vom normalen PC aus mit SATA 150 oder 300MBit/sec. Klar, hier
fahren natürlich alle RAID mit Linux auf 8-Core. Ich halt nicht und die
Leute die ich kenne, auch nicht.
Anzahl Blaetter eines Purzelbaumes schrieb:
> Eine Frage des CCD. Bei lumpigen 4000x2500 (10Mega) pixeln zu 1 Hz ist> man bei 10MSample zu 3x8bit, macht 30MByte. Nun gibt es Leute, die> empfinden ein Video mit 1Hz als etwas lahm, und dann geht die Datenrate> eben hoch. Will damit sagen, mit einer CCD kann man nahezu beliebige> Datenmengen produzieren. Ein Kompressor ist etwas Ergibiges und etwas> beliebig Aufwendiges.
Ich bekomme vorassichtlich nächste Woche meinen 12 MPixel Image-Sensor
mit 60 frames und koste gut 280 Euro.
Das währen theortisch 2,1 GByte/Sekunden
ABER (!!!) dise Image-Sensoren übertragen die Daten nicht wie normale
Image-Sensoren die Du einfach im Microcontrolelr (z.B. Atmel
AT91SAM9263) Interface anschließt.
Du bekommst von diesen Image-Sensoren "lossless-compressed data
streeems" und mußt dementsprechend auch die API der Hersteller
verwenden.
Danach bekomste bei einer 12 MPixel und 60 fps gut 180 MByte/Sekunde
Ohne PCIe 4x oder 8x geht da garnichts mehr und die Vorbearbeitung des
Datenstreams wird auf den PCIe Karten sowieso durch einen DSP erledigt
Grüße
Michelle
