Tach,
Mir kam so eine Idee, die ich spontan interessant fand,
erstmal ohne konkrete Anwendung, eher als Denkmodell:
I2C-Bus Signale (SCL/SCK) können kombinatorisch genau 4 Zustände
annehmen,
soweit klar.
Wäre es nicht möglich alle SCK+SCL Kombinationen mittel paar Bauteilen
in
4 Spannungszustände z.B. 0V - 1.5V - 3V - 5V zu wandeln,
damit das ganze dann über NUR EINE Leitung übertragen werden kann?
Auf der anderen Seite natürlich eine Rückwandlung, um wieder SCK/SCL zu
erhalten.
Falls es mit überschaubarem Aufwand gelingt könnte ich mir durchaus
Anwendungen dafür vorstellen.
Nur mal so als Idee, was haltet Ihr davon?
Irgendwie möglich wäre es sicherlich. Aber ich glaube kaum, dass die
Signalübertragung besser wäre. Und wenn schon analog, dann nicht mit
Spannung, sondern mit Strom. Siehe 4-20mA Systeme.
Moin,
I2C Überleger schrieb:> was haltet Ihr davon?
Wenig bis nix. I2C ist eh schon unangenehm, weil bidirektional und
open-collector/drain-gedoens, der eine mag' die Flanken nicht zu
schnell, der andere nicht zu langsam, die Pullups haben die lustigsten
Groessen und Spannungen zu denen sie pullen, und dann noch extra Faxen,
nur um eine popelige Leitung einzusparen? Nee, da bohr ich mir doch
lieber ein Loch ins Knie.
Gruss
WK
1. Wenn ich schon eine Hin/Rückwandlung brauche nehm ich doch gleich
D/A-Ausgang auf A/D Eingang.
Für die eine Leitung Ersparnis wär das sonst ein ganz schöner Aufwand.
2. A/D und D/A Wandler müssten bei entsprechender Datenfrequenz schon
ziemlich schnell arbeiten.
3. Die Auswertung softwareseitig erfordert mehr Ressourcen.
3.. Bei 3V hast Du schon nicht mehr so schöne Spannungshübe
(Störsicherheit).
4. Das Ganze funktioniert zunächst nur in eine, nicht aber in zwei
Richtungen wie bei I2C.
Alles in allem: Schnapsidee :-)
I2C Überleger schrieb:> Nur mal so als Idee, was haltet Ihr davon?
Beim I2C liegt der Clock so, dass während der positiven Phase die Daten
stabil sind. Hast du dir überlegt, wie du das in deiner Kodierung
unterbringst. Außerdem müssen so Dinge wie Clock-Streching, Ack oder
sogar Daten vom Slave rüber kommen, während der Master den Clock auf die
Leitung legt.
Mir scheint, du musst die Idee noch etwas ausarbeiten.
Dergute W. schrieb:> Nee, da bohr ich mir doch> lieber ein Loch ins Knie.
Ich denke, das fasst die Idee ganz gut zusammen. Kann man schon
vermutlich irgendwie machen, aber wozu soll das gut sein?
I2C Überleger schrieb:> I2C-Bus Signale (SCL/SCK) können kombinatorisch genau 4 Zustände> annehmen,> soweit klar.
Das ist, vielleicht nicht für jeden ersichtlich, aber ganz klar falsch,
weil Du nicht berücksichtigst, wer wann welche Signale setzt, und wie
sie sich gegenseitig beeinflussen können. Schon mal was von (ganz böse)
Clockstreching gehört?
I2C Überleger schrieb:> Nur mal so als Idee, was haltet Ihr davon?
Wenn es Dir -- unabhängig von I2C -- um Datenübertragung
über nur ein Adernpaar geht: Mal MFM angucken.
Alex G. schrieb:>> Wenn es Dir -- unabhängig von I2C -- um Datenübertragung>> über nur ein Adernpaar geht: Mal MFM angucken.> Ähm, ginge es etwas genauer?
Klar. Als Startpunkt:
https://de.wikipedia.org/wiki/Modified_Frequency_Modulation> Das einzige im Elektronikbereich das ich unter diesem> Begriff finden konnte ist das heir: [...]
Ja, schon die richtige Richtung.
Ich hatte das Gefühl, dass es dem TO primär um die
Möglichkeit ging, Takt und Daten auf einer Leitung zu
übertragen. Das geht mit MFM ziemlich einfach; eine
Flanke in der Mitte der Bitzelle steht für eine "1",
eine Flanke am Ende der Bitzelle für eine "0". Pegel
ist egal --> Invertierung spielt keine Rolle; es zählen
nur die Flanken.
Es können nur Pulse von einer, eineinhalb und zwei
Bitzellenlängen auftreten; 2*T tritt nur bei der Folge
"101" auf, was man zum Synchronisieren verwenden kann.
Die Runs dürfen nicht zu lang werden, weil sich "0"-Runs
und "1"-Runs nur in der Phasenlage unterscheiden.
MFM ist insofern lukrativ, weil man theoretisch 2bit/Hz
Bandbreite übertragen kann; ein Kanal mit 1MHz Bandbreite
kann also 2MBit/s übertragen.
Der Code ist m.W. gleichstromfrei, kann also über einen
Übertrager geschickt werden.
HTH
Possetitjel schrieb:> Alex G. schrieb:>>>> Wenn es Dir -- unabhängig von I2C -- um Datenübertragung>>> über nur ein Adernpaar geht: Mal MFM angucken.>> Ähm, ginge es etwas genauer?>> Klar. Als Startpunkt:> https://de.wikipedia.org/wiki/Modified_Frequency_Modulation
Ah okey, war das Richtige. Da es um Festplatten ging, war ich etwas
verwirrrt.
Possetitjel schrieb:>> Ich hatte das Gefühl, dass es dem TO primär um die> Möglichkeit ging, Takt und Daten auf einer Leitung zu> übertragen. Das geht mit MFM ziemlich einfach; eine> Flanke in der Mitte der Bitzelle steht für eine "1",> eine Flanke am Ende der Bitzelle für eine "0". Pegel> ist egal --> Invertierung spielt keine Rolle; es zählen> nur die Flanken.> Es können nur Pulse von einer, eineinhalb und zwei> Bitzellenlängen auftreten; 2*T tritt nur bei der Folge> "101" auf, was man zum Synchronisieren verwenden kann.> Die Runs dürfen nicht zu lang werden, weil sich "0"-Runs> und "1"-Runs nur in der Phasenlage unterscheiden.>> MFM ist insofern lukrativ, weil man theoretisch 2bit/Hz> Bandbreite übertragen kann; ein Kanal mit 1MHz Bandbreite> kann also 2MBit/s übertragen.> Der Code ist m.W. gleichstromfrei, kann also über einen> Übertrager geschickt werden.>> HTH
Interessant!
Denke verbreiteter ist allerdings das schon erwähnte 1-wire Protokoll.
Possetitjel schrieb:> Möglichkeit ging, Takt und Daten auf einer Leitung zu> übertragen. Das geht mit MFM ziemlich einfach
Ja, und auch die restlichen Vorteile, die du beschreibst, sind alle
zutreffend. Du hast sogar den größten Nachteil erwähnt, leider aber
nicht kenntlich gemacht, dass es sich um einen Nachteil handelt und wie
groß dieser ist. Nämlich:
> es zählen> nur die Flanken.
Das ist schlecht, denn es bedeutet, das jede Störflanke die Nachricht
zerstört, jedenfalls so lange man nicht entsprechende Gegenmaßnahmen
unternimmt. Solche sind durchaus möglich und können auch sehr wirksam
sein, treiben aber leider auch den empfängerseitigen Aufwand erheblich
in die Höhe.
In der wirksamsten Form läuft es auf eine Art PLL und Überabtastung
hinaus. Kitzlig ist dabei das Verhalten der PLL. Einerseits darf sie nur
relativ lose gekoppelt sein, um asynchrone Störungen möglichst gut
"ausblenden" zu können, andererseits ist aber eine möglichst starre
Kopplung anzustreben, damit sie sich schnell auf das Nutzsignal
synchronisieren kann. Hier steht also der übliche Spagat zwischen
widerstreitenden Anforderungen an.
Leider führt dieser Spagat regelmäßig dazu, dass dem MFM-Signal ein
ausreichend langer Sync-Header voranzustellen ist, wie man leicht an so
ziemlich allen praxisrelevanten Anwendungen dieser Kodierung erkennen
kann.
