Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu
Übertragen und hinterher wieder zu trennen.
Dabei ist mir der Datendurchsatz und die stätige Zuverlässigkeit dieser
Verbindung sehr wichtig.
Ich will auf den MAC Controller und TCP/IP-Stack verzichten und Steuere
den PHY direkt an (Ich Glaub das ist besser für einen konstanten
Datenstrom). Nur mir fällt jetzt kein praktikabler Weg für die
Datenübertragung zwischen Datenstrom und PHY ein. Ein µC währe mir am
liebsten(Daten müssen noch "zusammen geschnitten" werden) bloß habe ich
bisher nur Erfahrung bei der PIC16F Serie Gesammelt. Wie würden eure
Lösungsansätze aussehen? gibt es vielleicht schon fertige IC die das
schaffen?
Danke.
Ich habe mir das so vorgestellt das ich erstmal 64bit Daten Aufnehme und
sie dann Sende. Da die Daten isochron ankommen müssen diese
hinterher(beim decodieren) auch wieder so rauskommen. Dazwischen will
ich erstmal den Datendurchsatz schaffen.
Die Idee mit dem Phy finde ich gut. So setzt Du auf bewährte Technologie
auf. Diese Dinger anzusteuern kann nicht allzu schwer sein. Soweit ich
weiß braucht man dazu ein SPI oder I²C Interface zur Konfiguration,
sowie Rx und Tx Leitungen für die Daten.
Ich würde mich allerdings über die zu erwartende Fehlerrate informieren.
Als PHY verwende ich momentan den DP83848CVV der kommt auch ohne SPI
oder I2C aus. Nur hat der 4 TX Pins an denen ich 6 Datenströme seriell
anbinden muss. Zu dem muss auch die Taktrate kompatibel gehalten werden.
Ankommen tuen die Daten mit 6x12.288Mbps die müssen dann auf 4x25Mbps
sinnvoll aufgeteilt werden. Zudem muss der PHY regelmäßig Disabled
werden damit der Empfänger sich wieder neu synchronisieren kann.
Meineserachtens währe für diese Aufgabe ein µC am besten geeignet. Bloß
habe ich bisher keinen finden können der die Daten so schnell
verarbeiten kann. Der müsste dann so ungefähr 200MHz CPU tackt haben um
den PHY schell genug seine Daten zu liefern Während er Weiterhin welche
aufnimmt. Wichtig ist auch wie ich den µC mit dem PHY synchronisiere da
er mir ja ein tackt vorgibt.
Sind die 12Mb Datenströme zueinander taktsynchron?
Bestehen die Datenströme aus Rohdaten, d.h. ein reiner Bitmultiplex ist
ausreichend, weil ein irgendwie darin enthaltenes Framing im Multiplex
mit übertragen wird?
@ Martin Elend (iiimaddiniii)
>Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu>Übertragen und hinterher wieder zu trennen.
Klingt nach 100 Mbit Ethernet.
>Ich will auf den MAC Controller und TCP/IP-Stack verzichten und Steuere>den PHY direkt an (Ich Glaub das ist besser für einen konstanten>Datenstrom).
Glauben heißt nicht wissen. Als unterste Schicht solltest du direktes
Ethernet mit seinen Frames nutzen, dafür ist es gebaut und
milliardenfach bewährt. Was man darüber für eine Protokoll setzt, ist
diskussionsfähig. Dr einfachste Ansatz ist die Daten direkt in die
Ethernetfragmes zu packen und gut. Etwas aufwändiger, wenn gleich schon
deutlich leistungsfähiger ist es, UDP zu nutzen, dann kommt man sogar
durch die unendlichen Weiten des Internet, wenn das nötig ist.
> Nur mir fällt jetzt kein praktikabler Weg für die>Datenübertragung zwischen Datenstrom und PHY ein.
Erfinde das Rad nicht neu und informiere dich erstmal über bestehende
Verfahren, bevor du, gerade mit deinem Kenntnisstand, was
selbstgestricktes machen wilst. Derartige Datentunnel gint es schon
lange in allen möglichen Konstellationenen.
> Ein µC währe mir am>liebsten(Daten müssen noch "zusammen geschnitten" werden)
Na dann mal viel Spass bei 80 Mbit/s. Da sind selbst größere 32 Bit CPUs
gut beschäftigt.
> bloß habe ich>bisher nur Erfahrung bei der PIC16F Serie Gesammelt.
Von Dreirad gleich in die Formel 1? Ob das sinnvoll ist?
> Wie würden eure>Lösungsansätze aussehen? gibt es vielleicht schon fertige IC die das>schaffen?
Was sind denn das für Datenströme? I2S?
@Jonas Biensack
Das wäre zwar einfacher aber der PHY gibt mir fest vor das es
4x25Mbps(TXD0..3) sein müssen. Ich fände es auch besser eigene
Datenraten festlegen zu können. Ich kenne leider auch keine andere
Schnittstelle die 80Mbps FullDuplex auf 50m länge unterstützt. Also wenn
keiner einen kompatiblen PHY kennt und auch keine andere Schnittstelle
die den Datendurchsatz auf der länge schafft muss ich die Daten
konvertieren. Die frage ist nur wie.
@A. K.
Die 12Mbps Datenströme sind tacktsyncron. Ja ein Bitmultiplex würde gut
laufen, aber leider nur auf kurzer Distanz ohne speziellen Treiber. Als
Datenleitung steht auf jeden Fall ein 50m cat5 LAN Kabel Fest das ich
doppelt nutze.
@Falk Brunner
Ja Ich muss zugeben ist schon ein "kleiner" Sprung den ich da mache. Das
die meisten CPUs zu langsam sind habe ich auch schon festgestellt.
Kennst du denn alternativen zu µC. Die Daten kommen von Optischen
Toslink Empfänger die ein ADAT Signal führen.
Jetzt zum Ethernet:
Ich benötige ein sehr konstanten Datenstrom da ich keine großen Latenzen
haben will. Mein Gedanke war, dass wenn ein CRC im Ethernet Frame
auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch.
Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet,
ist eine Direkte Verbindung Zwischen sender und Empfänger.
@ Martin Elend (iiimaddiniii)
>Ja Ich muss zugeben ist schon ein "kleiner" Sprung den ich da mache. Das
One smal setp for man, one giant leap for mankind . . . ;-)
>die meisten CPUs zu langsam sind habe ich auch schon festgestellt.>Kennst du denn alternativen zu µC. Die Daten kommen von Optischen>Toslink Empfänger die ein ADAT Signal führen.
Aha. Hmmm. Es muss auf jeden Fall einer sein, der das ADAT Signal mit
einem dafür speziallisierten Interface einlesen kann. Dann die Daten fix
in einen Ethernet-Frame packen und fertig. Das Ganze mit einem kleinen
FIFO entkoppelt. Da es ja ein sychroner Datenstrom mit eigener
Taktquelle ist, darf man sich hier mit dem Thema Taktrückgewinnung, PLL
und plesiochrone System beschäftigen. D.h., in deinem Ethernet, das
nicht synchron zu deinen Daten ist, musst du Lücken in den Daten
vorsehen, die je nach Frequnzabweichung mal größer oder kleiner werden
(Stopfbits, bzw. Stopfbytes). Aus diesen Informationen musst du am
Empfänger dann wieder mittels (digitaler) PLL den ADAT Takt gewinnen.
Alles in allem nix für Anfänger, das ist schon was für die hohen
Semester.
>Ich benötige ein sehr konstanten Datenstrom da ich keine großen Latenzen>haben will.
Naja, dann könnte man es anders machen, wenn gleich das auch viel
Aufwand bedeutet. Man baut einen klassischen Multiplexer auf Bitebene.
Dessen Takt wird mittels PLL fest an den Eingangstakt angebunden, z.B.
x5. Dann muss der Datenstrom noch brauchbar kodiert werden, z.B. 8B10B
und los gehts.
Auch nix, was man mal nebenbei macht.
Hmm, da fällt mir was ein. Man könnte einen CameraLink Tranceiver
misbrauchen, die multiplexen 28 Bit auf 3 Doppeladern, Plug & Play. Aber
dann sind 24 Bit ungenutzt. Auch nicht so schön.
Oder man baut sowas im Kleinformat nach, nur 1 Datenleitung und 1
Taktleitung. Das vereinfacht den Empfänger. Hmm, sowas hab ich mal vor
langer Zeit gebaut, einen High Speed UART. Könnte man hier auch machen.
Je 4 Bit + Start + Stop in Datenwort packen und mit x6 Takt versenden.
Für den Takt könnte man auf DDR Übertragung zurückgreifen, um die
Taktfrequenz zu halbieren. Der Empfänger ist sehr einfach aufgebaut.
Hmmm, das könnte man relativ leicht in einen etwas größeren CPLD packen.
Aber auch das ist Arbeit und deutlich über PIC16 Niveau ;-)
> Mein Gedanke war, dass wenn ein CRC im Ethernet Frame>auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch.
Daran musst du dich gewöhnen, wenn du es schnell und einfach haben
willst. Wenn Übertragungsfehler nicht nur erkannt, sondern auch
KORRIGIERT werden sollen, brauchst du FEC (forward error correction).
>Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet,>ist eine Direkte Verbindung Zwischen sender und Empfänger.
Ethernet ist ja auch ein Netzwerkstandard un keine ultrasimple Punkt zu
Punkt Verbindung.
Falk Brunner schrieb:> @ Martin Elend (iiimaddiniii)>>>Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu>>Übertragen und hinterher wieder zu trennen.>> Klingt nach 100 Mbit Ethernet.>
Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung.
Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes
und Leerräume zwischen den Paketen kommen...
Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen,
vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen.
Irgendwie hört sich das ganze noch einem "Hobbyprojekt" an.
Beschreibe doch mal bitte was das ganze denn werden soll wenn es fertig
ist. Evt. können wir dann auch noch bessere Tipps geben, als nur 80MB/s
zu übertragen.
@ Phantomix Ximotnahp (phantomix)
>Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung.
Nö.
>Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes>und Leerräume zwischen den Paketen kommen...
Schon mal geschaut, wie groß die sind?
http://de.wikipedia.org/wiki/Ethernet#IEEE_802.3_Tagged_MAC_Frame
Ethernet header sind 26 Byte + 4 Byte CRC, Inter-Frame-Spacing sind
minimal 12 Byte
http://de.wikipedia.org/wiki/Inter_Frame_Spacing
Macht in Summe 42 Byte. Wenn man 1000 Bytes/ Frame überträgt, sind das
gerade mal 4% Overhead.
>Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen,>vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen.
Nicht, wenn man eine Punkt zu Punkt Verbindung hat, dier braucht man
nahezu 0 Reserve, weil niemand anderes dazwischenfunken kann.
Martin Elend schrieb:> Die 12Mbps Datenströme sind tacktsyncron. Ja ein Bitmultiplex würde gut> laufen, aber leider nur auf kurzer Distanz ohne speziellen Treiber. Als> Datenleitung steht auf jeden Fall ein 50m cat5 LAN Kabel Fest das ich> doppelt nutze.
Das eigentliche Problem ist also die Reichweite der physikalischen
Signale und jedwedes durch Ethernet-PHY erzwungene Framing
verkompliziert die Sache erheblich, weil erst dadurch überhaupt eine
Taktratenanpassung und Pufferung erforderlich wird. Eigentlich benötigst
du also eine Bit-Modulation mit Taktrückgewinnung und passende
Transceiver.
Zu den Transceivern fallen mir dazu als Roh-Idee die SFPs aus dem
Netzwerkbereich ein, die zwar meist für Fiber bekannt sind, aber auch
für Kupfer/RJ45 exitieren. Deren elektrisches Interface ist ein reiner
serieller Bitstream:
http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver
Falk Brunner schrieb:> @ Phantomix Ximotnahp (phantomix)>>>Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung.>> Nö.
Doch.
>>Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes>>und Leerräume zwischen den Paketen kommen...>> Schon mal geschaut, wie groß die sind?
...
> Macht in Summe 42 Byte. Wenn man 1000 Bytes/ Frame überträgt, sind das> gerade mal 4% Overhead.
Er redet von 64 Bytes sammeln und dann übertragen. Damit wären das 64 +
42 = 106 Bytes gesamt oder eine Bruttodatenrate von 132 MBit/s.
Vielleicht kann er gar nicht warten bis 1000 Bytes voll sind weil dann
die Latenz zu groß ist o.ä.
Falk Brunner schrieb:> @ Phantomix Ximotnahp (phantomix)>>Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen,>>vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen.>> Nicht, wenn man eine Punkt zu Punkt Verbindung hat, dier braucht man> nahezu 0 Reserve, weil niemand anderes dazwischenfunken kann.
Vielleicht dazu noch:
Ich sage nicht, dass es nicht geht, nur dass es kein schöner Ansatz ist,
von vorn herein seinen Übertragungskanal aufs letzte Bit auszureizen.
Wenn man also die Chance hat sowas richtig zu planen, lässt man da
genügend Luft nach oben. Auch wenn das ein Gigabitkabel statt 100 MBit
bedeutet.
Martin Elend schrieb:> Mein Gedanke war, dass wenn ein CRC im Ethernet Frame> auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch.> Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet,> ist eine Direkte Verbindung Zwischen sender und Empfänger.
Ethernet zwingt niemanden, irgendwelche Pakete zu wiederholen. Das muß
die höhere Schicht schon selber machen, wenn sie das will (TCP nimmt man
dafür gerne).
Ethernet selbst wiederholt Pakete nur bei Kollisionen, also auf einem
halbduplex-Medium. Man kann einem Ethernet-Chip einreden, ein CAT5-Kabel
sei halbduplex, aber man kann das auch bleibenlassen.
Normalerweise hängt der Ethernet-Sender eine 32-bit-CRC an, aber das
kann man abschalten.
Normalerweise prüft der Ethernet-Empfänger die CRC und ignoriert das
Paket, wenn sie nicht stimmt, aber dieses Verhalten kann man abschalten.
Üblicherweise schreibt man vorne im Ethernet-Paket die Empfänger- und
Absenderadresse rein; moderne Ethernet-Chips können das automatisch.
Aber das kann man abschalten bzw. bleibenlassen.
Normalerweise prüft der Ethernet-Empfänger anhand der Adresse vorne, ob
das Paket für ihn ist, und ignoriert es andernfalls. Aber auch dieses
Verhalten läßt sich abschalten ("promiscuous mode").
Wenn sich also beide Enden das Kabels einig sind, kann das Ethernetpaket
recht effizient aufgebaut sein: Präambel + SFD + Nutzdaten + interframe
gap, macht also 20 Byte "Verpackung", d.h. ab 80 Byte Nutzdaten pro
Paket geht die Rechnung auf. Etwas längere Pakete sind natürlich ratsam,
wegen Toleranzen bei den Taktfrequenzen, aber wegen der Latenz will man
die natürlich so klein wie möglich haben; da kann schon 80 Byte zu viel
sein, zumal die Ethernet Pakete ja sowohl beim Sender als auch beim
Empfänger je einmal komplett im RAM liegen müssen.
Wie immer, die Loesung kommt vor der Aufgabe... Lass uns mal wissen, was
das Ganze soll. Allenfalls kann man auch einen SERDES nehmen, der kann
zB 64bit auf's mal serialisieren, und deserialisieren. Sonst kann man
sich selbst einen SERDES mit je einem FPGA basteln,
Ich wuerd auch SERDES verwenden. Ein CAT6 Kabel hat 4 Aderpaare. Eins
davon fuer den Clock. Dann 3 fuer synchrone Daten mit 30MBit oder so.
Das kleinste FPGA sollte das koennen.
Falk Brunner schrieb:> Ethernet ist ja auch ein Netzwerkstandard un keine ultrasimple Punkt zu> Punkt Verbindung.
Deshalb will ich auch kein Ethernet verwenden sondern nur die Hardware
um die Daten über ein Cat5 Kabel zu senden. Dann brauch ich mir auch
keine sorgen um die Hardware-Übertragung machen.
@Phantomix Ximotnahp
Ich verwende kein Ethernet da es in diesem Fall kein nutzen hat:
Falk Brunner schrieb:> Ethernet ist ja auch ein Netzwerkstandard und keine ultrasimple Punkt zu> Punkt Verbindung.
Ich will nur die Hardware verwenden da diese über lange Distanzen immer
noch gut lauft. Dann habe ich nur noch 2Byte Overhead vom Frame start
und Frame End(macht der PHY schon intern). Zur not könnte ich von der
einen LAN Leitung auch alle 4 Aderpaare nutzen und zwei Verbindungen
aufbauen(obwohl ich mir die für eventuelle Erweiterungen vorbehalten
wollte.
@Markus Müller+Martin schrieb:> Di willst das hier haben:>> http://appsys.ch/products/34-digitalaudio/55-adx32badx64b
Es Geht darum ein "Digitales Audio Multicore" zu erstellen welches ich
zum Abmischen benutzen will. Das alles möglichst mit kleiner Latenz(max
100µs).
Ja im Prinzip will ich eine ähnliche Funktion erzielen, nur ist mir das
keine 558 Euro wert und ich kann noch einiges im Bezug auf
Datenübertragung lernen.
@Dumpfer Nilp (Gast)
Deine Idee ist ähnlich der von Falk Brunner:
> Naja, dann könnte man es anders machen, wenn gleich das auch viel> Aufwand bedeutet. Man baut einen klassischen Multiplexer auf Bitebene.> Dessen Takt wird mittels PLL fest an den Eingangstakt angebunden, z.B.> x5. Dann muss der Datenstrom noch brauchbar kodiert werden, z.B. 8B10B> und los gehts.> Auch nix, was man mal nebenbei macht.
Nur muss ich mich dann auch noch um die zuverlässige Hardware
Übertragung kümmern.
Ich klaube ich werde mir wohl mittels FPGA einen FIFO bauen der auch für
den richtigen Datenfluss sorgt. Muss mich in das Thema jetzt erstmal
richtig einlesen.
Am einfachsten dürfte es sein einen optischen Transceiver zu benutzen.
Die findet man auf BASE-FX-karten und sind standadisiert. Arbeiten mit
ECL und können je nach Fabrikat mit bis zu 250 MHz Bittakt arbeiten.
Wenn die Ferrulen i.O. sind, gibt es praktisch keine Bitfehler.
Also könnte ein CPLD oder FPGA deine ADAT-Ströme zu einem
einkanal-Bitstrom muxen. Dafür musst du aller Wahrscheinlichkeit nach
trotzdem puffern.
Mit Lichtleiter-Kabel möchte ich nicht so gerne arbeiten da die ziemlich
empfindlich sind und schnell kaputt gehen wenn ein par Leute drauf
treten.
Zu dem Finde ich ist das schon ein bisschen überdimensioniert. Dass ich
puffern muss ist mir schon klar nur will ich den Puffer so klein wie
möglich halten.
