Forum: FPGA, VHDL & Co. Einfacher Feldbus für kleine FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michi (uart14k4)


Lesenswert?

Wir haben eine Maschinensteuerung in der Firma die wurde vor 20 Jahren 
selbst entwickelt und auf FPGAs realisiert. Funktioniert bisher ohne 
Probleme. Teil davon ist eine Art von selbst entwickelter Feldbus der 
allerdings nur zwei Teilnehmer hat: Master + Slave

Der Master sendet Positionssollwerte an den Slave. Jetzt soll es eine 
Achse mehr sein, also noch ein Slave also ein zusätzlicher 
Busteilnehmer. Eigentlich ist es auch einfach per FW Update möglich das 
Busprotokoll zu ändern, sodass nachhher auch die alten Maschinen mit der 
neuen FW laufen können.

Jetzt sind aber manche FPGAs sehr klein: Altera Cyclone 2 mit 5kLE. Also 
muss es einfach sein. Mein Gedanke war wir machen etwas vom Prinzip 
ähnliches wie EtherCAT, also der Frame läuft seriell durch alle 
Teilnehmer durch und geht wieder zum Master retour. Jeder Teilnehmer hat 
aber nur einen Rx+Tx also nicht zwei wie bei EtherCAT.

Die Teilnehmer wären daher in einem logischen Ring verschaltet. Dieser 
kann mit T-Stücken erweitert werden:

     MASTER >----------> SLAVE 1
            <---   ----<
                | |
                |  ----> SLAVE2
                 ------<

Signalübertragung geht differentiell über Übertrager mit 13.3Mbps mit 
einem 3b/4b Code um Takrückgewinnung und Gleichanteilsfreiheit zu 
ermöglichen.

Leitungscodes für 3 Bit Daten wären:

    0     0011
    1     0110
    2     0111 oder 1000
    3     1001
    4     1011 oder 0100
    5     1100
    6     1101 oder 0010
    7     1110 oder 0001
    IDLE  0101
    START 1010

Ein Frame wird also so übertragen:
IDLE - START - FRAME - IDLE

Am Ende des Frames gibt es einen CRC und 0-2 Padding Bytes damit die 
Anzahl Bit durch 3 teilbar sind. Sonst besteht ein Frame aus beliebig 
vielen Paketen im Format

Adresse (16 Bit), Länge (16 Bit), Daten (Länge*8 Bit)

Jeder Slave kann auf eine oder mehrere Adressen ansprechen (Adressen 
sind im Slave gesetzt). Findet er ein Paket das ihm gehört liest er die 
Daten (meistens Sollwerte) und kann sie durch eigene Daten (z.B. 
Istwerte) ersetzen.

Ich denke das lässt sich relativ schlank in den bestehenden FPGAs 
realisieren und wir können damit den Bus der alten Maschinen erweiterbar 
machen. Was haltet ihr davon bzw. habt ihr eine bessere Idee? CAN 
scheidet aus weil zu langsam (10Mbps sollten es werden) und zu 
störanfällig (nicht galvanisch getrennt). EtherCAT scheidet aus weil die 
IP zu gross für den FPGA ist und jeder Teilnehmer 2 Rx+Tx Paare benötigt 
und nur eines vorhanden ist.

von Vancouver (vancouver)


Lesenswert?

Klingt erstmal alles ganz vernünftig. Aber ein FW-Update brauchst du 
doch auf jeden Fall, weil jeder FPGA in der Daisychain in der Lage sein 
muss, die für ihn bestimmten Daten zu erkennen und den Rest zu 
ignorieren, was bei einer PTP-Verbindung nicht notwendig ist. Passt 
diese Erweiterung denn in die kleinen FPGAs hinein?

von Klakx -. (klakx)


Lesenswert?

Füllst du die Leitung permanent mit IDLE?
Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich 
die CDR auf den anderen Slave synchronisieren.

Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben.

von Bernd G. (Gast)


Lesenswert?

Die entscheidenden Fragen sind:

-wie lang soll das sein ?
-wie gestoert ist die Leitung?

Ich würde einfach ein Bit als Teilnehmerkennung 0/1 hinzufügen und das 
Korrekturbit im Leitungs-Code anpassen. Wäre dann ein 4/5. Noch besser, 
man setzt das Korrekturbit komplementär und nutzt 4/6. Die Bits dann 
z.B. an Position 1 und 4 -> 2,3 sowie 5,6 wären dann die alten Bits.
Man könnte auch die Bits vorn an stellen und illegale Codes 11 und 00 
nehmen, dann wäre das der Synch-Marker und die Synchs würden sich um 2 
bits von den legalen Codes unterscheiden.

Brauchst halt 20Mbps.

von Michi (uart14k4)


Lesenswert?

Vancouver schrieb:
> Klingt erstmal alles ganz vernünftig. Aber ein FW-Update brauchst du
> doch auf jeden Fall, weil jeder FPGA in der Daisychain in der Lage sein
> muss, die für ihn bestimmten Daten zu erkennen und den Rest zu
> ignorieren, was bei einer PTP-Verbindung nicht notwendig ist. Passt
> diese Erweiterung denn in die kleinen FPGAs hinein?

Ja, ein FW Update wird zwingend sein, ausser jemand möchte auf dem alten 
Stand bleiben. FW Update Funktion gibt es aber bereits. Ob es noch Platz 
hat muss ich noch ausprobieren, der kleine FPGA steuert zwei DC-Motoren 
und liest deren Encoder ein. Da sollten die 5kLE dem Gefühl nach 
reichen.





Klakx -. schrieb:
> Füllst du die Leitung permanent mit IDLE?
> Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich
> die CDR auf den anderen Slave synchronisieren.
>
> Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben.

Ja, zwischen den Frames wird die Leitung mit IDLE gefüllt. Alle 1ms 
sendet der Master einen Frame. Wenn ein Slave keinen Link am Rx erkennt 
sendet er selbst am Tx einen Frame mit seiner ID damit der Master eine 
Fehlermeldung anzeigen kann wo der Unterbruch zu suchen ist. Beide 
Slaves können ja schon zur selben Zeit treiben, jede Leitung ist ja 
immer noch ein Punkt-zu-Punkt Link. Der Ring ergibt sich erst durch die 
Daisy-Chain. Damit sollte auch nur der Abstand zwischen zwei Teilnehmern 
physikalisch begrenzt sein. Danach wird das Signal ja wieder 
aufbereitet. Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded 
twisted pair.



Bernd schrieb:
> Die entscheidenden Fragen sind:
>
> -wie lang soll das sein ?
> -wie gestoert ist die Leitung?
>

Es sollte sicher bis 10m funktionieren, bisher sind die Leitungen max. 
5m lang. Störungen gibt es vor allem durch ESD vom Bearbeitungsprozess. 
Ist zwar alles geerdet aber die bisherige nicht isolierte differentielle 
Übertragung stösst schon manchmal an ihre Grenzen. Daher würde ich mit 
der Umstellung gleich einen DC-freien Code wählen und in die neuen 
Maschinen Übertrager einbauen.

> Ich würde einfach ein Bit als Teilnehmerkennung 0/1 hinzufügen und das
> Korrekturbit im Leitungs-Code anpassen. Wäre dann ein 4/5. Noch besser,
> man setzt das Korrekturbit komplementär und nutzt 4/6. Die Bits dann
> z.B. an Position 1 und 4 -> 2,3 sowie 5,6 wären dann die alten Bits.
> Man könnte auch die Bits vorn an stellen und illegale Codes 11 und 00
> nehmen, dann wäre das der Synch-Marker und die Synchs würden sich um 2
> bits von den legalen Codes unterscheiden.
>
> Brauchst halt 20Mbps.

Das verstehe ich nicht ganz. Teilnehmerkennung hätte ich absichtlich 
nicht vorgesehen sondern alles über einen globalen Adressraum gemacht. 
Ein Frame enthält ja immer Daten für mehrere Frames bzw. wird von 
mehreren Frames als Antwortkuvert genutzt.

von Christoph Z. (christophz)


Lesenswert?

Vancouver schrieb:
> Klingt erstmal alles ganz vernünftig.

Ja, finde ich auch. Sich auf 3b/4b zu beschränken ist etwas 
unkonventionell aber ist sicher viel kleiner als volles 8b/10b.

Der Rest ist ja dann nur noch ein register file und ein CRC.

Michi schrieb:
> Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded
> twisted pair.

Michi schrieb:
> Ist zwar alles geerdet aber die bisherige nicht isolierte differentielle
> Übertragung stösst schon manchmal an ihre Grenzen. Daher würde ich mit
> der Umstellung gleich einen DC-freien Code wählen und in die neuen
> Maschinen Übertrager einbauen.

Was setzt ihr da den bisher ein? Vielleicht lässt sich da ja ohne all zu 
grossen Umbau weiter nutzen.

In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140 
A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485 
Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair. 
Natürlich weiter wenns langsamer ist.

Mit einem isolierten RS485 Tranceiver von NVE: 
https://www.nve.com/webstore/catalog/product_info.php?products_id=427

Michi schrieb:
> Am Ende des Frames gibt es einen CRC und 0-2 Padding Bytes damit die
> Anzahl Bit durch 3 teilbar sind. Sonst besteht ein Frame aus beliebig
> vielen Paketen im Format

Vielleicht hilft es dir ein CRC zu wählen, das nicht 8 oder 16 bit ist 
sondern 6 bit oder so. Coopman hat da ein gutes Vergleichspaper dazu.

von Bernd G. (Gast)


Lesenswert?

Christoph Z. schrieb:
> 3b/4b zu beschränken ist etwas unkonventionell aber ist sicher
> viel kleiner als volles 8b/10b.
???

3/4 ist schlechter als 8/10, weil man 80% /75% Bruttodaten übertragen 
muss.

von Michi (uart14k4)


Lesenswert?

Vielen Dank allen schon mal für die konstruktiven Kommentare! Es scheint 
ich habe mal keinen offensichtlichen Denkfehler und werde es wohl 
ausprobieren. Die Alternative ist nur alles von Grund auf neu zu machen 
und auf EtherCAT zu wechseln. Die Kompatibilität wäre dann dahin dafür 
stünde dann die Tür zu FSoE offen und in Zukunft könnte man auch Safety 
integrieren. Aber der Zertifizierungsaufwand schreckt mich ab und ohne 
FSoE hat EtherCAT nur noch den Vorteil, dass man Standardkomponenten 
integrieren kann. Also lieber abwärtskompatibel als standardkonform.

Christoph Z. schrieb:
> Was setzt ihr da den bisher ein? Vielleicht lässt sich da ja ohne all zu
> grossen Umbau weiter nutzen.

Bisher gibt es zusätzlich zu Rx/Tx noch einen Clk. Dieser läuft aber nur 
mit 1/20 der Bitrate, also mit 500kHz. Die 20 Bit zwischen 2 steigenden 
Flanken sind ein Frame. Der Slave muss immer mit 1 Bit Verzögerung 
antworten. Laufzeitverzögerungen sind statisch korrigiert. Es ist also 
eher etwas wie SPI. Die Clockleitung würde ich gerne loswerden weil die 
Synchronisation von Clock und Daten über mehrere Meter unzuverlässig 
erscheint. Mit mehreren Teilnehmern dann sowieso. Gibt also leider nicht 
viel, das man mitnehmen kann. Das gute ist, dass ein Grossteil der FW 
auf einem separaten uC des Master läuft und ich nur den FPGA Teil ändern 
würde und das Interface zum uC nicht anpassen müsste. Dafür natürlich 
alle FPGAs.


Christoph Z. schrieb:
> In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140
> A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485
> Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair.
> Natürlich weiter wenns langsamer ist.
>
> Mit einem isolierten RS485 Tranceiver von NVE:
> https://www.nve.com/webstore/catalog/product_info.php?products_id=427
>

Das Ding klingt interessant. Hast du den RS485 mit mehreren Teilnehmern 
oder nur PTP betrieben?


Christoph Z. schrieb:
> Vielleicht hilft es dir ein CRC zu wählen, das nicht 8 oder 16 bit ist
> sondern 6 bit oder so. Coopman hat da ein gutes Vergleichspaper dazu.

Danke für den Tipp! Der FRAME kann bei 10Mbps und 1ms Buszyklus bis zu 
10kb gross sein. Also fast so gross wie ein Ethernet Frame mit seinen 
1500 Byte. Dachte daher an 32 Bit CRC, die fallen im Verhältnis zu 10kb 
nicht ins Gewicht und ermöglichen nach 
https://users.ece.cmu.edu/~koopman/crc/ eine Hammingdistanz von 6. 
Soweit ich es sehe braucht es im FPGA für den CRC einfach nur ein 
entsprechend langes Register + XOR. Das scheint mir auch bei 32 Bit 
nicht schlimm. Oder habe ich etwas übersehen was für ein kürzeres 
Polynom sprechen würde?

von J. S. (engineer) Benutzerseite


Lesenswert?

Michi schrieb:
> mit der Umstellung gleich einen DC-freien Code wählen
> und in die neuen Maschinen Übertrager einbauen.

Für solchen einen Zweck und zwar wirklich für exakt so einen Zweck habe 
ich einem ehemaligen Kunden vor nunmehr über 25 Jahren schon S/PDIF 
empfohlen. Das kann man mit Microcontrollern bewerkstelligen, weil es 
dafür fertige Audio-Chips zum "Pfennig"-Preis gibt. Ja, damals hatten 
wir noch Mark und Pfennig :-)  Ich würde das auch heute noch empfehlen 
und und ich sage das als FPGA-Entwickler, der einst Controller und Chips 
aus seinen privaten Design rausgeworfen hat und es mit eigenem 
VHDL-S/PDIF macht. :-)

Christoph Z. schrieb:
> In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140
> A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485
> Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair.
Genau so eine Anwendung war das. Hochdreckiges Maschinenumfeld. Man hat 
erst gestutzt, als ich mit einer "Audioschnittstelle" angekommen bin, 
hat es dann aber getestet und bejaht, u.a. auch aus Kostengründen. Das 
empfohlene S/PDIF gibt es als optisch und AES/EBU mit RS422. Dafür gibt 
es Treiber, Koppler und Chips zu (inzwischen) "Cent"-Preisen. Die sind 
nochmal billiger, als damals.

Optisch kann man ein 96kHz-S/PDIF ohne weiteres 20m optisch führen, wenn 
man nicht gerade die allerbilligsten PolyProp-Pseudolichtleiter benutzt. 
Mit einer richtigen Glasfaser sind da GB möglich. Elektrisch über RS422 
sind 50m by 192kHz typisch. Das sind 12,8 MBit brutto. Auch in 
Hochstromumgebungen kann man das sicher machen, weil der verwendete Code 
sehr eng bandbegrenzt ist.

Der Nachteil ist nur, dass das Protokoll offen liegt. Man muss also mit 
der USER-Schicht sichern. Aber es soll ja ohnehin eine Sicherungsschicht 
hinein, dann kann man es auch user-codieren. Ich würde das mal für 
384kHz durchrechnen und ausprobieren. Da sind ca. 18Mbps Nutzdaten 
möglich und die Module gibt es für 5,99 zu kaufen. Beschickt mit I2S und 
einem simplen Schieberegister. Es braucht nicht einmal einen FPGA. Am 
Ausgang kann man immer noch einen 485-Bus aufbauen, wenn man will.

Zwischen 2 FPGAs habe ich das als Pseudo-S/PDIF mit FPGA Core auch schon 
bis knapp an 1 Gb betrieben. 300Msps Nutzdaten. Der 1b2b-BMC ist derart 
gut zu sampeln und zu rekonstruieren, dass du den praktisch nicht stören 
kannst. In einer Testanwendung lagen direkt neben der Datenleitung 
mehrere Kabel, in denen >1kA Pulsströme flossen und zu hörbaren 
Schwingungen der Gehäusewand führten. Bei einem längeren Leitungscode 
muss man mit dem Spektrum aufpassen, wo man landet.

Wenn man das so baut, ist die CDR super einfach und sicher und man 
braucht auch keinen CRC mehr zu Rekonstruktion, sondern nur noch als 
Prüfcode.

von Christoph Z. (christophz)


Lesenswert?

Bernd schrieb:
> Christoph Z. schrieb:
>> 3b/4b zu beschränken ist etwas unkonventionell aber ist sicher
>> viel kleiner als volles 8b/10b.
> ???
>
> 3/4 ist schlechter als 8/10, weil man 80% /75% Bruttodaten übertragen
> muss.

Ich meinte kleiner im Sinne von weniger Logikelemente im FPGA.

> Bisher gibt es zusätzlich zu Rx/Tx noch einen Clk. Dieser läuft aber nur
> mit 1/20 der Bitrate, also mit 500kHz.

Ich meine was nutzt ihr auf Layer 0, also für diese erwähnte 
differenzielle Übertragung. Ist das schon RS485/RS422 oder was anderes?

> Das Ding klingt interessant. Hast du den RS485 mit mehreren Teilnehmern
> oder nur PTP betrieben?

Das war mit bis zu 20 Clients. Aber nur Broadcast, also es gibt einen 
der sendet Reglersollwerte die alle anderen brauchen.

Alles andere, Parameter, Zustand, Firmwareupdate etc. läuft über 
EtherCAT aber wir brauchten halt 12.5 us Zykluszeit und noch viel 
weniger Verzögerung. EtherCAT ist gut und schnell aber irgendwann ist da 
halt auch Schluss :-)

> Oder habe ich etwas übersehen was für ein kürzeres
> Polynom sprechen würde?

Nein, hast du schon alles richtig verstanden. Der Hinweis war gemeint, 
dass das Runden auf 3 bits vielleicht Effizienter wird mit einem Polynom 
das nicht n*8 bit lang ist (Vielleicht 6 bit oder 15 bit oder so). War 
nur so eine Idee.

von Bruno V. (bruno_v)


Lesenswert?

Michi schrieb:
> Der Ring ergibt sich erst durch die Daisy-Chain.

serielle Daisy Chain ist bewährt und robust. Ein früher Vertreter ist 
https://de.wikipedia.org/wiki/Interbus. Prinzipiell muss man überlegen, 
ob man direkt Bit für Bit (mit einem internen Clock Verzögerung) 
weiterleitet oder ob man Byte- oder Block-weise weiterleiten möchte um 
ggf. Bytes zu verändern (Bspw. für eine automatische Adressierung).

Der Sinn Deiner "Clock" erschließt sich mir noch nicht, vielleicht habe 
ich was überlesen. Den Bit-Takt gewinnt man aus den Flanken (notfalls 
mit Bit-Stuffing), den Telegramm-Beginn mit speziellen Pattern und den 
Pattern-Beginn durch geeignete und genügende Idlepattern, gefolgt von 
einem geeigneten Startpattern (wie bei Dir). Die (bei Dir m.E. nicht 
notwendige) Clock wird prinzipiell nicht schlechter, weil sie ja ebenso 
durchs FPGA durchgeleitet/aufbereitet würde.

Gruß

von Michi (uart14k4)


Lesenswert?

J. S. schrieb:
> Für solchen einen Zweck und zwar wirklich für exakt so einen Zweck habe
> ich einem ehemaligen Kunden vor nunmehr über 25 Jahren schon S/PDIF
> empfohlen. Das kann man mit Microcontrollern bewerkstelligen, weil es
> dafür fertige Audio-Chips zum "Pfennig"-Preis gibt. Ja, damals hatten
> wir noch Mark und Pfennig :-)  Ich würde das auch heute noch empfehlen
> und und ich sage das als FPGA-Entwickler, der einst Controller und Chips
> aus seinen privaten Design rausgeworfen hat und es mit eigenem
> VHDL-S/PDIF macht. :-)

Das 1b/2b BMC klingt auch interessant. Dann bräuchte ich zwar 20Mbps 
aber vielleicht ist die hohe Flankenrate ein Vorteil bei der 
Taktrückgewinnung und natürlich nicht der lästige Faktor 3.

Muss mal schauen welche ICs es damit gibt. Vieles scheint schon älter zu 
sein. Aber der FPGA ist ja vorhanden also wäre es auch kein Problem das 
selbst zu implementieren.


Christoph Z. schrieb:
> Ich meine was nutzt ihr auf Layer 0, also für diese erwähnte
> differenzielle Übertragung. Ist das schon RS485/RS422 oder was anderes?

Habe das Schema gerade nicht da aber es ist ein einfacher 
Differentialtreiber wie der SN65LVDS1. Die Leitung ist aber immer 
getrieben also nicht wie bei RS485 teils hochohmig.

Bruno V. schrieb:
> Der Sinn Deiner "Clock" erschließt sich mir noch nicht, vielleicht habe
> ich was überlesen. Den Bit-Takt gewinnt man aus den Flanken (notfalls
> mit Bit-Stuffing), den Telegramm-Beginn mit speziellen Pattern und den
> Pattern-Beginn durch geeignete und genügende Idlepattern, gefolgt von
> einem geeigneten Startpattern (wie bei Dir). Die (bei Dir m.E. nicht
> notwendige) Clock wird prinzipiell nicht schlechter, weil sie ja ebenso
> durchs FPGA durchgeleitet/aufbereitet würde.

Die Clock ist wohl historisch. War wohl mal als reines SPI gedacht und 
hat dann nicht funktioniert und so kam es dann. Es gibt auch noch eine 
CS Leitung. Ich würde all das in Zukunft weglassen und den Takt 
rückgewinnen.

von Jörg (zwischenfrequenz)


Lesenswert?

J. S. schrieb:
> Da sind ca. 18Mbps Nutzdaten
> möglich und die Module gibt es für 5,99 zu kaufen. Beschickt mit I2S und
> einem simplen Schieberegister. Es braucht nicht einmal einen FPGA. Am
> Ausgang kann man immer noch einen 485-Bus aufbauen, wenn man will.

Hallo,

hast Du ein Beispiel für so ein Modul? Irgendwie habe ich nicht die 
richtigen Suchworte gefunden, aber die Idee gefällt mir für Anwendungen 
wo man Entkopplung möchte aber SFPs ein bisschen übertrieben wären.

von Klakx -. (klakx)


Lesenswert?

Michi schrieb:
> Klakx -. schrieb:
>> Füllst du die Leitung permanent mit IDLE?
>> Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich
>> die CDR auf den anderen Slave synchronisieren.
>>
>> Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben.
>
> Ja, zwischen den Frames wird die Leitung mit IDLE gefüllt. Alle 1ms
> sendet der Master einen Frame. Wenn ein Slave keinen Link am Rx erkennt
> sendet er selbst am Tx einen Frame mit seiner ID damit der Master eine
> Fehlermeldung anzeigen kann wo der Unterbruch zu suchen ist. Beide
> Slaves können ja schon zur selben Zeit treiben, jede Leitung ist ja
> immer noch ein Punkt-zu-Punkt Link. Der Ring ergibt sich erst durch die
> Daisy-Chain. Damit sollte auch nur der Abstand zwischen zwei Teilnehmern
> physikalisch begrenzt sein. Danach wird das Signal ja wieder
> aufbereitet. Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded
> twisted pair.

Tut mir leid, aber ich versteh das Konzept nicht mehr. Oben sieht die 
Zeichnung wie ein geteilter Kanal aus. Jetzt sagst du, dass du eine P2P 
Verbindung zu jedem Slave hast. Dagegen spricht, dass du o.g. nur ein 
TX+RX hast:

Michi schrieb:
> Jeder Teilnehmer hat
> aber nur einen Rx+Tx also nicht zwei wie bei EtherCAT.

Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain? Eine 
bessere Zeichnung könnte helfen deine Topologie zu verstehen.

von Bernd G. (Gast)


Lesenswert?

Klakx -. schrieb:
> Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain?

Time Slot System?

von J. S. (engineer) Benutzerseite


Lesenswert?

Jörg schrieb:
> hast Du ein Beispiel für so ein Modul?

Schau mal I2S <-> S/PDIF Interface auf EBAY. Ich hatte da mal welche 
gekauft, dann später vom Händler eine größere Stückzahl für einen Kunden 
direkt bezogen.  Als Einzelteil mit Steuern liegen die heute etwa beim 
Doppelten.  Suche mal nach ES9032 et al. / Ganz komfortabel "DIR9001".

Du brauchst allerdings nur den Chip.   Andererseits lässt sich S/PDIF 
auch gut aus dem PC heraus testen: PCM2702 USB IF  zu 7,99  oder ES 
9038, oder direkt in Analog pcm5102

von Bruno V. (bruno_v)


Lesenswert?

Klakx -. schrieb:
> Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain?

Beides (wie zur Empfangskontrolle auch üblich):

Michi schrieb:
> Der Ring ergibt sich erst durch die Daisy-Chain.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.