warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? Kann man die Daten nicht einfach schneller schicken?
schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? Das kommt 1. von der Physik und 2. von Festlegungen. > Kann man die Daten nicht einfach schneller schicken? Kannst du schon. Dann funktionieren sie halt nicht mehr, weil die Timing-Spec der angeschlossenen Bauteile verletzt wird.
:
Bearbeitet durch Moderator
Ist das eine ernste Frage oder willst du nur trollen?
Warum dauert eine Reise zum Mars so lange? Kann man nicht einfach schneller fliegen?
Dietrich L. schrieb: > Ist das eine ernste Frage oder willst du nur trollen? Ganz offensichtlich Zweiteres. Wird dann halt zeitnah gelöscht.
:
Bearbeitet durch Moderator
Nunja. Die Daten müssen ja auch her- und weggeschafft sowie ausgewertet werden. Und beliebig schnell geht nicht, weil auch die Signalqualität (Flanken,...) nicht bessert wird
Also ich erkenne hier (noch) kein Troll-Potential. Es ist eine berechtigte, wenn auch unfreundlich hingerotzte Frage wenn man sich mit Elektronik nicht so gut auskennt.
Klaus schrieb: > Warum dauert eine Reise zum Mars so lange? Kann man nicht einfach > schneller fliegen? Ja, aber nicht mit dem ÖPNV;-) schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit > begrenzt? > Kann man die Daten nicht einfach schneller schicken? Sind andere Protokolle unlimitiert?
Jörg R. schrieb: > Sind andere Protokolle unlimitiert? Ist in diesem Universum überhaupt irgendetwas unendlich?
EAF schrieb: > Ist in diesem Universum überhaupt irgendetwas unendlich? "Zwei Dinge sind unendlich ..." https://www.forum-einstein.org/zitate.html (drittes Zitat von unten)
Ben B. schrieb: > Also ich erkenne hier (noch) kein Troll-Potential. schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? Diese Frage wäre tatsächlich noch nicht trollfähig, falls er wissen will, was da so alles die Geschwindigkeit begrenzt. > Kann man die Daten nicht einfach schneller schicken? Dieser Teil riecht aber schon trollig.
Beitrag #6961134 wurde von einem Moderator gelöscht.
Hallo, rein prinzipiell, durch das Protokoll, ist i2c nicht begrenzt. Die Begrenzung erfolgt durch die angeschlossenen Elemente, die in ihrer Geschwindigkeit begrenzt sind. Wenn du also auf zwei schnellen Mikrokontrollern das i2c-Protokoll "von Hand" implementierst, kannst du es auch schneller laufen lassen. Langsamer geht ja auch. Bernd
Ist ein Kompromiss aus Geschwindigkeit und Kosten. Spi und i2c sind für bezahlbare Geräte konzipiert. Für 50 cent Chips und einfache Leiterplatten, die der Praktikant layouten kann. Natürlich kannst du die Daten schneller schicken. Brauchst halt Chips und Leiterplatten, die mit kürzeren Signalen und steileren Flanken zurecht kommen. Das kostet dann halt das 10 oder 1000 fache. Aber warum willst du das machen? Gibt ja Protokolle und Chips, die für höhere Übertragungsraten besser geeignet sind.
schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? > Kann man die Daten nicht einfach schneller schicken? "Es gibt 2 Dinge die unendlich sich. Das Universum und die Dummheit der Menschen. Beim 1. bin ich mir aber nicht ganz sicher." Albert Einstein
Jörg R. schrieb: > Klaus schrieb: >> Warum dauert eine Reise zum Mars so lange? Kann man nicht einfach >> schneller fliegen? > > Ja, aber nicht mit dem ÖPNV;-) Das müsste schon ein (Ö)PFV sein ;) MfG, Arno
SPI ist nicht begrenzt weil nicht standardisiert. Es ist einfach nur in Silizium gegossene Möglichkeit, Schieberegister mit Clock und Daten ein und auszulesen. Das geht so schnell, wie es Deine Schaltung hergibt. I2C ist ein von Philips (heute NXP) spezifiziertes Verfahren. Es ist maximal so schnell, wie spezifiziert. Wenn Du es schneller machst, ist es eben kein I2C mehr. Bei der Reichweite gibt es Grenzen: Durch die spezifizierten Bauteile (maximale Kapazität, Pull-Up, etc.), Signallaufzeit etc. Wenn ein Signal 2µs braucht, kannst Du nicht mit 1 MHz kommunizieren, wenigstens nicht mit Clock von der einen und Daten von der anderen Seite. Es Spricht aber nichts dagegen, bei genügend kleiner Baudrate, über beliebige Strecken zu kommunizieren. Auch eine Umsetzung über Funk, Ethernet oder Postboten ist prinzipiell möglich, bis zum Mond, wenn es sein muss.
OK gibt es zb transceiver die schnell reagieren und die Daten schnell empfangen und senden dann auch schnell auswerten lassen dahinter? Kann man nicht ein paar Codierungen hinzufügen damit die Signale nicht allzu schlecht sind? Und evtl. Differentielle Signale schicken? Würde mich einfach interessieren ob das geht
Also wenn man mal Oszi-Bilder vom PCI-Bus gesehen hat, muß man sich schon wundern, daß das überhaupt funktioniert. Von daher ginge bei I2C/TWI schon noch was und 1 oder 2MHz meine ich schon gesehen zu haben.
Schmal z schrieb: > Würde mich einfach interessieren ob das geht Das hilft nicht gegen Signallaufzeiten
Warum ist VGA in der Auflösung beschränkt? Damals haben die Leute bei BNC aufgehört. Glaub es gibt keinen VGA Montior der SMA-Buchsen hat.
Moin, Schmal z schrieb: > OK gibt es zb transceiver die schnell reagieren und die Daten schnell > empfangen und senden dann auch schnell auswerten lassen dahinter? Ja, gibts. z.b. SDI ging mit 270MBit/sec los; derweilen gibt's 12Gbit/sec. Und wenn Ethernet in diesen Datenraten nicht schon langsam guenstiger wuerde, dann wuerde es wahrscheinlich irgendwann noch schnelleres SDI geben, denn wer will schon 4k glotzen, wo doch 16k viel knackigere Bilder liefern kann. Es wird halt mit steigender Frequenz immer unangenehmer, die Dreckeffekte irgendwie im Griff zu haben... Gruss WK
Schmal z schrieb: > Kann man nicht ein paar Codierungen hinzufügen damit die Signale nicht > allzu schlecht sind? Klar kann man das, wird auch gemacht. Aber dann ist es kein I²C und auch kein SPI mehr, sondern z.B. Ethernet oder PCI Express.
Harry schrieb: > Also wenn man mal Oszi-Bilder vom PCI-Bus gesehen hat, muß man sich > schon wundern, daß das überhaupt funktioniert. Von daher ginge bei > I2C/TWI schon noch was und 1 oder 2MHz meine ich schon gesehen zu haben. I2C mit 400 KHz ist fast bei allen Bauteilen schon möglich. Und manche Hersteller bieten auch 1MHz an. https://www.i2c-bus.org/fast-mode-plus/
PittyJ schrieb: > I2C mit 400 KHz ist fast bei allen Bauteilen schon möglich. > Und manche Hersteller bieten auch 1MHz an. Ja. Man muss da halt bloß aufpassen, was langsamere Busteilnehmer tuen. Das kann durchaus für "überraschende" Effekte sorgen... Sprich: der Bus darf nur maximal so schnell betrieben werden, wie der langsamste Busteilnehmer vorgibt.
Mensch: Warum ist Licht eigentlich in seiner Geschwindigkeit begrenzt? Gott: Hör auf zu trollen!
>> Kann man die Daten nicht einfach schneller schicken? > Dieser Teil riecht aber schon trollig. Naja... wieso? Es ist die einfachste logische Lösung wenn irgendwas zu langsam ist und in vielen Fällen wurde das ja auch so gemacht. Also mit besserer Technik das gleiche Protokoll, nur schneller bis man an neue Grenzen stieß. Diese Grenzen zu erklären wäre dann wieso es nicht "einfach" geht bzw. nicht bis ins Unendliche geht. Das wird dann philosophisch, aber nicht trollig.
Moin, Was noch nicht beleuchtet wurde: Warum sollten i2c oder spi ueberhaupt schneller sein? Wenn der Oppa vor der Glotze denkt: Der Nachrichtensprecher nuschelt schon wieder so, ich mach mal lauter, dann muss das garnicht in µs oder gar ns passieren, das reicht in zig ms locker. Und genau aus dieser und aehnlich gelagerten Problemstellung resultierte der i2c Bus. Auch z.b. Temperaturen aendern sich physikalisch bedingt auch nur recht langsam, und man braucht's nicht unbedingt mit z.b. 1024bit Aufloesung. Eine MAC-Adresse oder sonstige Seriennummer pressiert auch nicht besonders, etc. bla. Also warum sollten solche Busse ueberhaupt schneller sein? Braucht schlicht keiner. Bzw: Die, die meinen es unbedingt zu brauchen, haben mit grosser Wahrscheinlichkeit keine Ahnung was sie da tun (Aehnlich wie beim Einsatz von Digitalpotis). Gruss WK
Die Antwort liegt in einem einzelnen griechischern Buchstaben: τ und das wird in Klasse 8 oder 9 gelehrt, auch an der Real- und Mittelschule: https://did.physik.lmu.de/lehrerbildung/lehrerbildung_lmu/video/e-lehre/das-elektische-feld/kondensator-multimeter/index.html
schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? > Kann man die Daten nicht einfach schneller schicken? I²C: Weil es für die Geschwindigkeiten definiert wurde, die derzeit erhältlich sind. Mit einem FPGA wird man sicherlich wesentlich höhere Geschwindigkeiten mit dem selben Protokoll erreichen können, ist dann aber nicht mehr kompatibel. Dieser Bus ist ursprünglich dazu gedacht gewesen, um z.B. die Lautstärke in einem Fernseher vom Prozessor an die Audioeinheit weiter zu geben. Oder die Empfangsfrequenz. Oder Helligkeit. Also nichts, was besonders schnell sein muss. Zur übertragung von Datenmengen war er niemals gedacht. SPI: Hat keine definierte Grenze. Habe ich auch schon mit einigen 100MHz gesehen. SD-Karten sind auch SPI. Norbert schrieb im Beitrag #6961134: > Da verweise ich gerne mal auf die ungeheure Cleverness der > Corona-Spaziergänger. Na, so richtig clever ist es auch nicht, die Sorgen dieser Menschen komplett zu ignorieren, wie auch immer diese gelagert sind, und gar nicht darauf einzugehen und die Leute gedanklich abzuholen. Das ist nie eine gute Idee. Arno schrieb: > Das müsste schon ein (Ö)PFV sein ;) Wieso? Der Mars ist doch einer der nächsten!? Da sind wir ja noch nicht mal aus unserem Sonnensystem raus. Gruß Jobst
:
Bearbeitet durch User
Beitrag #6961474 wurde von einem Moderator gelöscht.
schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? > Kann man die Daten nicht einfach schneller schicken? Wenn du nen ASIC dahinter hast, der bis zu 20 MHz frisst, kannst du das machen, ja. BTDT
Stefan ⛄ F. schrieb: > Klar kann man das, wird auch gemacht. Aber dann ist es kein I²C und auch > kein SPI mehr, sondern z.B. Ethernet oder PCI Express. ja ok ... xD habe mir einfach gedacht man kann mit passenden pcs und pma einfach ein bekanntes Protokoll schneller machen ohne ein neues Protokoll zu verwenden. Messtechnikprofi schrieb: > Wenn du nen ASIC dahinter hast, der bis zu 20 MHz frisst, kannst du das > machen, ja. BTDT Jobst M. schrieb: > Mit einem FPGA wird man sicherlich wesentlich höhere Geschwindigkeiten > mit dem selben Protokoll erreichen können, ist dann aber nicht mehr > kompatibel. ja mit passender Gegenstelle finde ich das einfach interessant. Fpgakuechle K. schrieb: > Die Antwort liegt in einem einzelnen griechischern Buchstaben: τ was lädt sich da eigentlich auf? Was ist eigentlich mit i3c?
Beitrag #6961771 wurde von einem Moderator gelöscht.
I2C und SPI sind synchron. Und damit darf die Signallaufzeit nicht viel mehr sein als die halbe Taktperiode. Wir reden da von 3ns pro m, aber da kommen noch Delays im Slave dazu. Kommt man mit den Taktraten in den Bereich der Signallaufzeiten, muss man Leitungstheorie beherrschen und berücksichtigen. Das ist aber nur eine Begrenzung für SPI, es gibt noch andere. Damit man Synchronisationsprobleme bekommt, sind wir auf Leiterplatten bei 100MHz und mehr, aber bei Kabeln kommt man schnell in zweistellige ns Laufzeit. Bei I2C ist es noch viel schlimmer. Die Signale sind open drain, also müssen Kapazitäten am Bus über die Pullups geladen werden. Und das heißt es ist eine Zeitkonstante mit R*C im Spiel. Bei I2C ist die Zeitkonstante schon bei 10pF und 2k bei 200ns. Jetzt sind 10pF aber sehr wenig, und wenn Kabel im Spiel sind, reden wir von 100pF/m und mehr. Schon wenn RC die halbe Taktperiode ist, wird man ziemliche Probleme bekommen. Das sind die berühmten I2C Haifischflossen, die man hier im Forum immer sieht ;-) Übrigens ist der wackelige High-State auch der Grund, warum I2C so störempfindlich ist.
vielen Dank :D auf open drain habe ich nie wirklich geachtet. will ich mir mal genauer anschauen. warum nimmt man denn open drain, gibt es nichts besseres?
schmalz schrieb: > warum nimmt man denn open drain, gibt es nichts besseres? Natürlich gibt es was "Besseres", nur ist das dann ein anderer Bus. Und worum es eigentlich geht: es gibt nichts Billigeres, das ähnlich kollisionsfest und unzerstörbar und skalierbar ist wie ein Pullup und ein paar Schalter nach GND.
schmalz schrieb: > warum nimmt man denn open drain, gibt es nichts besseres? Das hat große Vorteile: Open-drain-Ausgängen kann man einfach verbinden, ohne dass es zu Kurzschlüssen kommen kann (wire-or). Weil jeder Teilnehmer nur den Pullup gegen GND ziehen kann. Außerdem sind interessante Spezialitäten wie clock-stretching möglich (wir alle lieben es!). Bidirektional geht natürlich auch anders: man kann ein Chipselect verwenden, nur dann brauchts eben 3 Leitungen. Und das ist ja gerade der Witz bei I2C. Man braucht nur SCL und SDA für viele Teilnehmer an einem Bus. I2C ist super, um IC auf der Leiterplatte zu verbinden, die wenig Daten austauschen müssen. Daher der Name. Und das ist ein sehr häufiges Problem. I2C eignet sich wegen der Beschränkugen eben genau nicht für Kommunikation über lange Kabel oder große Datenmengen. Dafür gibt es bessere Systeme. Warum gibte es wohl soviele Systeme? Eben genau, weil jedes auf einen Zweck zugeschnitten ist.
Name: schrieb: > I2C eignet sich wegen der Beschränkugen eben genau nicht für > Kommunikation über lange Kabel oder große Datenmengen. Ich meine damit, es ist eine Beschränkung für Kommunikation über Kabel. Es gibt durchaus I2C-ähnlich Busse oder I2C über Kabel, was aber mit erheblichen Einschränkungen verbunden ist. Manchmal ist Einfachheit aber wichtiger als Datenrate. DDC wäre ein Beispiel dafür.
Name: schrieb: > Es gibt durchaus I2C-ähnlich Busse oder I2C über Kabel > DDC wäre ein Beispiel dafür. Die Jahrzehnte lang verwendete PS/2 Tastatur auch...
schmalz schrieb: > warum sind i2c und spi eigentlich in ihrer Geschwindigkeit begrenzt? > Kann man die Daten nicht einfach schneller schicken? Na klar, man kann Daten auch bedeutend schneller schicken. LVDS macht es vor. Aber das ist dann eben LVDS und nicht I2C. Ich geb dir mal nen technischen Hinweis: Beim I2C wird der Highpegel mit Hochzieh-Widerständen gemacht. Und das Datensignal darf sich nur während des Low-Zustandes des Taktsignals ändern, sonst gilt das Ganze nicht als Datenübertragung, sondern als Start- bzw. Stop- Kondition. Folglich muß man zwischen den Flanken der Daten und des Taktes genügend Zeit geben, damit alle am Bus hängenden Chips das sauber unterscheiden können. Und nun denke dir mal ein wenig Leitungskapazität hinzu und rechne dir aus, wieviel Zeit du dann bereits für die Flanken benötigst. Klaro? W.S.
EAF schrieb: > Ist in diesem Universum überhaupt irgendetwas unendlich? die menschliche Dummheit :-)
Moin, W.S. schrieb: > Klaro? Ich wuerd' mal LVDS nicht mit I2C vergleichen, denn das waere wie Aepfel und Birnen. LVDS kannst du eher mit z.b. open Collector vergleichen. I2C ist bisschen mehr als die Pegel/Impedanzverhaeltnisse auf der Leitung. Gruss WK
schmalz schrieb: > warum nimmt man denn open drain, gibt es nichts besseres? Deine Definition von "besser" ist offenbar "schneller" – leider gibt es noch zahlreiche weitere Parameter bzw. Variablen, die es bei der Entwicklung eines technischen Systems zu berücksichtigen gilt. Wie oben schon beschrieben, wurde z. B. I2C für die preisgünstige, einfache Kommunikation mehrerer ICs auf einer Leiterplatte, z. B. in Fernsehern, entwickelt – die verfügbaren Übertragungsgeschwindigkeiten reichen dafür offensichtlich aus, und er ist wie gesagt billig und einfach integrierbar. Wenn du andere Anforderungen an deinen Bus hast, z. B. schneller sein musst oder längere Strecken überbrücken musst, ist I2C schlicht die falsche Wahl. TL;DR: Ja, natürlich gibt es "Besseres" in Sachen Geschwindigkeit – es ist nur die Frage, ob du das brauchst und ob du mit den anderen Nachteilen der Alternativtechnologie leben kannst – oder konkret ist die Frage, was du überhaupt brauchst.
schmalz schrieb: > warum nimmt man denn open drain, gibt es nichts besseres? open Drain erlaubt mehrere Sender auf einer Leitung. Uart oder SPI sind entweder unidirektional oder werden durch parallel CS-Leitungen gesteuert, die die Anzahl der Leitungen erhöhen. Bei I2C kannst Du ein Dutzend unterschiedliche Devices an 2 Leitungen kloppen. (Und immer beachten: Bei I2C treibt auch der Slave die Clock (Clock-Stretching). Daten und Clk werden also von allen Teilnehmern angesteuert)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.