und wieso gibt es so unglaublich viele Standards? Manchmal bin ich echt genervt, wenn ich mir ein IC rausgesucht habe und dann stunden damit verbringe bis ich es endlich mal angesteuert bekomme, weil IC A wieder völlig anders anzusteuern ist als IC B
Peter Pander schrieb: > und wieso gibt es so unglaublich viele Standards? > Manchmal bin ich echt genervt, wenn ich mir ein IC rausgesucht habe und > dann stunden damit verbringe bis ich es endlich mal angesteuert bekomme, > weil IC A wieder völlig anders anzusteuern ist als IC B Ich hoffe die "dann stunden damit verbringe" bezieht sich nicht auf iic oder spi. Beide sind ja ziemlich klar definiert und meist nimmt einem eine Hardwarekomponente den Protokoll-Aufwand ab. IIC - 400kHz max., aber viele Geräte auf 2+1 Kabeln SPI - mehrere Geräte nur über zusätzliche CE-Pins möglich, Geschwindigkeit weit über 10 MHz möglich mit Fullduplex
:
Bearbeitet durch User
Dennis H. schrieb: > weit über 10 MHz möglich mit Fullduplex Schnell ist ja ganz toll, aber meist nicht nötig, und das dämliche "Erst 16 Bits raus (achja, die 16 die du da bekommst darfst du wegwerfen da steht eh nur Müll drin) dann 16 Bits rein (dabei aber bitte 16 Bits mitschicken, die je nach Chip egal, definiert oder der nächste Befehl sein müssen)" nervt total. Es hängt ganz vom Chip ab. Datenmassen in ein Flash macht man per SPI, für normale IO & RTC ist I²C einfacher.
Peter Pander schrieb: > Arbeitet ihr lieber mit SPI oder I2C Bauteilen? I2C ist nett, weil man nur drei Leitungen benötigt. Ich habe neulich einen Aufbau gemacht, wo ich ein LCD parallel ansteuere, weil es weniger Programplatz braucht. Ein Bastelprojekt, dessen Konzept ich noch nicht vollständig auf dem Papier habe, wird I2C und SPI haben: Der geeignete A/D-Wandler hat I2C, aber die SD-Karte muß per SPI angefahren werden. Beim Display kann ich mir I2C / SPI aussuchen, da ich aber sowieso I2C im System habe, spart mir das gegenüber SPI einen Port ein. Auch, wenn Du es vielleicht nicht hören willst: "Es kommt drauf an"!
Manfred schrieb: > I2C ist nett, weil man nur drei Leitungen benötigt. Ich erinnere mich schwach, dass es nur 2 sind, scl und sda. Nachteil bei I2C... wenn sich die Staemachine aufhängen, zb bei einem Brown Out dann hängen sind, es gibt keinen Reset Mechanismus.
Peter Pander schrieb: > Manchmal bin ich echt genervt, wenn ich mir ein IC rausgesucht habe und > dann stunden damit verbringe bis ich es endlich mal angesteuert bekomme, > weil IC A wieder völlig anders anzusteuern ist als IC B Ich weiss ja nicht wie alt du bist aber I2C entstand als ich noch im Abitur war. Und die SPI gab es schon als ich noch in flüssiger Form im Sack meines Vater war. Und davor die UART auch noch .... alles hat seinen Sinn und Zweck und ist millionenfach bewährt eingebaut worden. Ach ja.. Ethernet, DSL, VDSL, ... es gibt noch viel mehr :-)
Peter Pander schrieb: > und wieso gibt es so unglaublich viele Standards? Wieso, wieviele gibt es denn? Oder findest Du schon 2 viel? Peter Pander schrieb: > Manchmal bin ich echt genervt, wenn ich mir ein IC rausgesucht habe und > dann stunden damit verbringe bis ich es endlich mal angesteuert bekomme, > weil IC A wieder völlig anders anzusteuern ist als IC B Dann hast Du vermutlich 2 verschiedene ICs. Wieder ein Thread für die Tonne, aber es ist ja Freitag.
Peter Pander schrieb: > und wieso gibt es so unglaublich viele Standards? Im Betreff nennst du zwei. Zwei ist nicht "viele". Im Prinzip wurde die Frage schon oft gestellt und auch beantwortet (IIRC von Linus Torvalds). Es gibt so viele Standards, damit sich jeder einen aussuchen kann, der ihm gefällt. > Manchmal bin ich echt genervt, wenn ich mir ein IC rausgesucht habe > und dann stunden damit verbringe bis ich es endlich mal angesteuert > bekomme, weil IC A wieder völlig anders anzusteuern ist als IC B Das klingt für mich eher nach "unfähig, ein Datenblatt zu lesen" als nach "es gibt zu viele Standards!!!1!elf". Zumal ja gerade die beiden genannten derart kanonisch sind, daß sie entweder schon per Hardware, spätestens jedoch von einer Standard-Library implementiert werden. Dein "Problem" läuft am Ende also darauf hinaus, zwischen einem roten und einem blauen Lego-Stein auszuwählen. Soll ich dir die Nachbarskinder (Zwillinge, 6 Jahre alt) zur Hilfe schicken?
Mal ne Geschichte... Vor 20 Jahren sass ich in einem dunklen Büro der damaligen Firma NEC, heute Renesas und schrieb Prime Cells in VHDL. Nach aufwendigen Tests im Pattern Generator und einer Testbed Umgebung landete das dann in den Chips und wurd millionenfach auf Wafern fabriziert. Bevor Chips in Serie gehen werden diese erstmal einmal auf Herz und Nieren als Modelle geprüft und auch die Nullserie als Silizium wird nochmal geprüft. I2C muss man damals lizensieren von Philips, es war ein sog. Hard Macro. D.h. wir bekamen nur das was Place & Route erzeugte, die Netzliste aber nicht den Source Code. Die I2C prime Cell ist eine Status Maschine, die im Kreis läuft, in jedem Chips steckt eine, vom EEPROM bis zum Gyro Sensor. Das klappt auch alles solange prima, wie da was rein kommt vom Master keine Fehler enthält! Aber wehe, wehe wenn da mal ein Taklt fehlte! Oder ein fieser Brown-Out den Slave in einen "Dazwischen-Zustand" brachte. Dann kam die SM durcheinander und fand nie wieder synchron zum Master. Microchip und auch ARM hatten mächtig Probleme damit, die Prime Cell des ARM Cortex war lange buggy, man konnte besser i2c als Code schreiben, als die eingebaute Hardware benutzen. Denn der i2C Standard kennt keinen Bus Reset. Und so ist das bis heute. In der Not brachten die Firmen dann solche Saetze auf den Markt: If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks. If not, then use the HW reset or cycle power to clear the bus. The master I2C must be able to generate this “bus clear” sequence Auf deutsch: Der Slave besitzt die Frechheit die Data Line nicht los zu lassen, obwohl er dem Master gehorchen muss! Klappte aber oft auch nicht, bei einem E2PROPM nützt das gar nichts. "Cycle Power" heisst nix anderes als ein/aus.. besonders gut bei Systemen,die Safe-On sein müssen :-) In meinem späteren Beruf habe ich I2C in sicherheistgerichteter Hardware nicht zugelassen, bzw nur wenn ein Watchdog drüber wacht und einen Kaltstart ermöglicht. Darum mag ich I2c nicht sonderlich, jeder Kopter fliegt aber damit, da seine Sensoren I2C verwenden. Wieviele schon abgestürzt sind, weil keine Daten mehr kamen weiss ich aber nicht.
Angehängte Dateien:
Dennis H. schrieb: > SPI - mehrere Geräte nur über zusätzliche CE-Pins möglich, > Geschwindigkeit weit über 10 MHz möglich mit Fullduplex Naja es gibt auch noch die Variante mehrere Slaves zu kaskadieren, die SPI Schnittstelle ist vergleichbar mit einem Schieberegister, erfordert dann nur einen Slave Select für alle Slaves.
René F. schrieb: > SPI Schnittstelle ist vergleichbar mit einem Schieberegister Genau genommen ist es die Schnittstelle um Schieberegister anzusteuern. Nur dass man darauf basierend später dann komplexere Funktionalität realisiert hat. Die devices waren also da und spi wurde nachträglich dafür entwickelt. Darum ist z.b. sampeln auf rising oder falling clock möglich. Im Gegensatz zu i2c, wo die devices zusammen mit der Schnittstelle entwickelt wurden.
@Rene im Screenshot als Bezeichner Master, Slave und SS, darf man das heute noch ?
> In meinem späteren Beruf habe ich I2C in sicherheistgerichteter Hardware > nicht zugelassen, bzw nur wenn ein Watchdog drüber wacht und einen > Kaltstart ermöglicht. Das sehe ich genauso. I2C ist unbrauchbar fuer alles was SIL ist, aber auch Geraete die 24/7 laufen muessen und erst recht wenn da was wichtiges von abhaengt. Das betrifft durchaus nicht nur die Industrie. Es waer z.B ziemlich doof die Temperaturregelung seines Aquariums damit zu machen. Das wird zwar lange funktionieren, aber irgendwann haengt sich der Bus dann doch weg. Das ist natuerlich etwas anderes bei einem TV. Sollte der alle zwei Jahre mal spinnen schaltet ihn der Besitzer einfach einmal aus und wieder ein und alles ist vergessen. Mittlerweile gibt es aber wohl auch I2C Devices die haben einen Mindesttakt und reseten sich selber und es waer natuerlich auch denkbar einen Sensor bei einem Problem die Betriebsspannung weg zu schalten. Und Potentialtrennung fuer I2C war auch lange Zeit eher doof zu machen, da gibt es aber mittlerweile ICs die das koennen. Olaf
Christian J. schrieb: > If the data line (SDA) is stuck LOW, the master should send nine clock > pulses. The device that held the bus LOW should release it sometime > within those nine clocks. If not, then use the HW reset or cycle power > to clear the bus. The master I2C must be able to generate this “bus > clear” sequence Genau diese Kacke. Und das ist bei modernen Bausteinen immer noch so. Ich bevorzuge ganz klar SPI. Gefühlt ist SPI eher "stateless" und I2C ist "stateful". Und es ist immer problematisch, wenn man erahnen muss, in welchem Zustand sich irgendwas Entferntes befindet...
schön das es nach ein paar dummen Kommentaren, die ja hier Gang und Gäbe sind, sich doch noch eine interessante sachliche Diskussion entwickelt. Schade das immer so viele Pappnasen in diesem Forum unterwegs sind, die sich nicht einfach enthalten können wenn sie nichts sinnvolles beizutragen haben.
Ich versuche alles mit I2C zu machen, auch wenn ich es immer noch Konfus finde wie bei den EEPROMs Nach Start und Addresse nochmal ein Start nötig ist Mit SPI, der Wahl von Taktflanken und dem hin und her Basteln daß man das richtige Bit an der richtigen Stelle vom Empfangsregister hat habe ich ehr abschreckende Erfahrungen gemacht
Christian J. schrieb: > In meinem späteren Beruf habe ich I2C in sicherheistgerichteter Hardware > nicht zugelassen, bzw nur wenn ein Watchdog drüber wacht und einen > Kaltstart ermöglicht. > > Darum mag ich I2c nicht sonderlich, jeder Kopter fliegt aber damit, da > seine Sensoren I2C verwenden. Wieviele schon abgestürzt sind, weil keine > Daten mehr kamen weiss ich aber nicht. Und wenn man die Entstehungsgeschichte von I2C kennt (Vereinfachung der Verkabelung in damals noch weitestgehend analogen Fernsehgeräten als Fernsteuerungen für Lautstärke, Helligkeit und Kanalwahl möglich wurde) ist eigentlich nichts mehr hinzuzufügen. Selbst heute haben Hersteller von I2C-Krempel immer noch Probleme diesen so zu implementieren das problemlos funktioniert (ST mit seinen ToF-Sensoren ist so ein Kandidat). Leider haben manche HW-Entwickler das mit dem Kaltstart nach wie vor nicht verstanden.
Christian J. schrieb: > Dann kam die SM durcheinander und fand nie wieder synchron zum Master. > Microchip und auch ARM hatten mächtig Probleme damit, die Prime Cell des > ARM Cortex war lange buggy, man konnte besser i2c als Code schreiben, > als die eingebaute Hardware benutzen. Denn der i2C Standard kennt keinen > Bus Reset. Und so ist das bis heute. Es gibt ja mit I3C den Nachfolger von I2C, und in der Version I3C v1.1 gibt es auch den Slave Reset.
oh, super, wieder was neues...lol.. Und vermutlich ist es nicht kompatibel?
oh ok, es scheint kompatibel zu sein:-) https://evision-webshop.de/I2C-vs-I3C-Protokoll-Analysatoren-Unterschiede-und-Aehnlichkeiten
> Und wenn man die Entstehungsgeschichte von I2C kennt (Vereinfachung der > Verkabelung in damals noch weitestgehend analogen Fernsehgeräten als Die kennen wir doch alle. :-) Ich schaetze das der Bus erstmals in grosser Ausbreitung in Video2000 Recordern eingesetzt wurde. Allerdings hat sich seit damals auch ein bisschen was verbessert. Schaut euch mal verschieden alte Datenblaetter des LM75 an. Ihr koennt da sehen das da ploetzlich immer neue tolle Features auftauchen weil man wohl dazugelernt hat. Fuer normale Bastelaktionen ist I2C schon okay. Man kann ja auch einiges ausgleichen wenn man die Probleme kennt. Aber halt nicht fuer Sachen wo Fehler teuer sind oder den Goldfisch umbringen. .-) Die Flankenproblematik von SPI ist natuerlich auch korrekt. Wie ich ja schon sagte das ist eigentlich garkein Bus im Sinne von genormt und perfekt dokumentiert. Jeder Hersteller macht da seine eigene Suppe, man muss genau schauen alles richtig zu konfigurieren und ich hatte auch schonmal eine Kombination wo ich mich gefragt hab ob das wirklich 100% kompatibel zu bekommen ist. Aber ALLES ist besser als 1-Wire. :-D Olaf
Der LM75 ist in gutes Beispiel für mein Eingangsposting..ist das nicht dieser Temperaturfühler bei dem man die Bits erst spiegeln muss oder sowas?! Wieso wird so etwas gemacht? Gibt es da Einsatzbereiche wo das Sinn macht?
> Der LM75 ist in gutes Beispiel für mein Eingangsposting..ist das nicht > dieser Temperaturfühler bei dem man die Bits erst spiegeln muss oder > sowas?! Also ich musste da noch nix spiegeln. Aber das ist ein guter Baustein an dem du die schlechten Eigenschaften von I2C in der Praxis erforschen kannst. :) Olaf
Rudolph R. schrieb: > +1 für SPI, simpel, schnell und robust. +1 für SPI, oder halt mit einem FET VCC für die I2C Slaves kurz wegnehmen. Macht der externe Reset Chip so nebenbei mit... Butzo
Ich bevorzuge SPI. Jetzt aber weg mit dem Troll.
Ich habe mir mal den Spass gemacht und nach einem SPI Temperatur-Sensor gesucht. Mouser hat sowas, nach Preis sortiert sind die ersten in der Liste TC72 von Microchip. Habe ich noch nie benutzt. nach Datenblatt: - SPI bis 7,5MHz - Chip-Select ist High-Activ - SPI Mode 0 oder 2 - multi-byte Lesen geht, Adresse wird decrementiert Code: io_init() // CS pin auf Ausgang und low setzen spi_init() // SPI einstellen auf Master, Mode 0, 4MHz, Pins konfigurieren Sensor auf einschalten und immer wieder messen konfigurieren: AVR: PORTA |= (1<<PA5); /* CE high, TC72 selected */ SPDR = 0x80; /* write to address zero of TC72 */ while(!(SPSR & (1<<SPIF))); SPDR = 0x00; /* disable One-Shot and Shutdown */ while(!(SPSR & (1<<SPIF))); PORTA &= ~(1<<PA5); /* CE low, TC72 de-selected */ ATSAM SERCOM: PORT->Group[0].OUTSET.reg = PORT_PA05; SERCOM0->SPI.DATA.reg = 0x80; while((SERCOM0->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0); (void) SERCOM0->SPI.DATA.reg; /* dummy read-access to clear SERCOM_SPI_INTFLAG_RXC */ SERCOM0->SPI.DATA.reg = 0x00; while((SERCOM0->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0); (void) SERCOM0->SPI.DATA.reg; PORT->Group[0].OUTCLR.reg = PORT_PA05; Irgendwann mal messen in der Hauptschleife: AVR: PORTA |= (1<<PA5); SPDR = 0x02; /* read from address 2 of TC72 */ while(!(SPSR & (1<<SPIF))); SPDR = 0x00; /* send dummy byte */ while(!(SPSR & (1<<SPIF))); temperature_high_byte = SPDR; SPDR = 0x00; /* send dummy byte */ while(!(SPSR & (1<<SPIF))); temperature_low_byte = SPDR; PORTA &= ~(1<<PA5); ATSAM SERCOM: PORT->Group[0].OUTSET.reg = PORT_PA05; SERCOM0->SPI.DATA.reg = 0x02; while((SERCOM0->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0); (void) SERCOM0->SPI.DATA.reg; SERCOM0->SPI.DATA.reg = 0x00; while((SERCOM0->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0); temperature_high_byte = SERCOM0->SPI.DATA.reg; SERCOM0->SPI.DATA.reg = 0x00; while((SERCOM0->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0); temperature_low_byte = SERCOM0->SPI.DATA.reg; PORT->Group[0].OUTCLR.reg = PORT_PA05; Selbst wenn in der Trocken-Übung ein Fehler steckt, mehr wird das nicht. Bei 4MHz SPI dauert das Lesen der Temperatur so <8µs, da kann man ohne Probleme in einer Busy-Loop drauf warten. Das macht auch nichts wenn das durch einen Interrupt unterbrochen wird. So, und jetzt zeig doch mal einer den vollständigen Code um einen I2C Sensor auszulesen. Ja, initialisieren mal aussen vor, das habe beide und normalerweise nur einmal. Edit: erst dran gedacht, am Ende doch MSB und LSB verdreht...
:
Bearbeitet durch User
Peter Pander schrieb: > und wieso gibt es so unglaublich viele Standards? Warum gibt es so viele unterschiedliche Brotsorten? Kann man nicht einfach ein Einheitsbrot festlegen?
Sven P. schrieb: > Genau diese Kacke. Und das ist bei modernen Bausteinen immer noch so. Das ist noch immer so, weil sich der Standard nicht geändert hat! Es gibt da wohl etwas wie einen Extended Standard (bitte nicht drauf festnageln, ist alles lange her) aber der ist eben nicht das was eingebaut wird. I2C kann sich aufhängen, weil Sychronität zwischen Master und Slave erwartet wird. Das sieht man sehr schön an I2C des Cortex M3, wo sog. Events den Bus begleiten. Bleiben diese aus stimmt was nicht. Er hat aber ein Reset Bit drin, also der ARM. Nur leider der Slave nicht, denn der weiss mit Reset gar nichts an zu fangen, weil 2 Drähte das nunmal nicht erlauben, er gar nicht weiss wo der Master grad ist.
Es ist wie so oft: Das in Hardware aufwendigere (SPI, mehr Leitungen je nach Slaves) benötigt weniger Software-Aufwand und umgekehrt (I2C). So kann sich doch jeder das gerade passende aussuchen.
Nach meiner Erfahrung sind viele Displays mit I2C wesentlich einfacher anzusteuern als per SPI. Ich habe hier gerade ein NHD 0420 OLED, Da muss man bei SPI eine Übertragung immer erst mit einem 10Bit Wort starten und danach mit 8Bit weiter machen. Dazu habe ich ein EA OLED mit SPI und I2C. Da kann man zwar immer SPI mit 8 Bit Worten machen, dafür muss nach dem ersten 8 Bit Wort (5 Einsen + R/C,W.. Bit) jedes Datenbyte auf zwei 8 Bit Worte aufteilen (je vier Bit). Grauenhaft, für DMA muss man dann die Daten erst nochmal extra aufbereiten. Klar, in VHDL und mit ein paar Gattern ist sowas kein Problem, aber wenn man einen uC hat nervt sowas nur. Hardwareentwickler sollten wirklich dazu gezwungen werden ihren Kram hinterher auch mal mit den Möglichkeiten üblicher MCs anzuprogrammieren. Per I2C Schnittstelle sind die EA Displays hingegen recht effizient anzusprechen.
Ich habe lange Jahre Geräte der Unterhaltungselektronik entwickelt. Bei den Single-Chip-Prozessoren damals waren I/O Ports knapp, weil damit Schalter und Signale abgefragt und manchmal auch noch LED-Anzeigen (im Multiplex) direkt angesteuert werden mussten. Da war der I²C-Bus ein Segen, zumal die I/O-Pins der Prozessoren bidirektional (wired-OR) betreibbar waren. Da merkte man, dass der Erfinder Philips auch aus der Unterhaltungselektonik kam. Mit anderen Anwendungsbereichen ändern sich natürlich die Schwerpunkte und damit auch die Standards. Und das betrifft auch die möglichen Geschwindigkeiten. Dann kann man zumindest die Zeitbedingungen nicht mehr kompatibel halten und was taugt ein Standard, wenn die Geräte, die diesen formal erfüllen dann doch nicht mehr einfach ausgetauscht werden können? Christian J. schrieb: > Vor 20 Jahren sass ich in einem dunklen Büro der damaligen Firma NEC, > heute Renesas und schrieb Prime Cells in VHDL. Um fast die Zeit saß ich da wohl auch (in Düsseldorf) und entwarf mit einem Kollegen ein ASIC-Design und simulierte die Ergebnisse auf einer Daisy-Workstation (und spätere Simulation mit Maestro). Unser Betreuer damals hieß Michael M.. Die Welt ist klein.
Ich bin noch nie in der glücklichen Lage gewesen, mir das aussuchen zu können. Es stimmt, oft hat man beide zur Verfügung, aber spätestens beim dritten IC ist Schluss mit lustig und es steht nur noch der andere Bus zur Verfügung. Da bei uns sehr oft mit Batterie betriebene Schaltungen entworfen werden, habe ich auch, wegen der Pull-Up Widerstände, eine Allergie gegen diese Art der Verbindungen entwickelt.
> Nach meiner Erfahrung sind viele Displays mit I2C wesentlich einfacher > anzusteuern als per SPI. Also meine Erfahrung ist genau anderes rum. Schon alleine deshalb weil man bei Displays oft auch Wert auf eine hohe Datenuebertragungsrate legt und haeufige Adressbytes da doof sind. Auch kann man SPI mit 50Mhz betreiben wenn einem danach ist und es der Displaycontroller kann. > Ich habe hier gerade ein NHD 0420 OLED, Da muss > man bei SPI eine Übertragung immer erst mit einem 10Bit Wort starten und > danach mit 8Bit weiter machen. Ich kenne dein Display jetzt nicht. Aber klingt mir wie eine absurde Ausnahme und ich habe schon dutzende Displaycontroller programmiert. Olaf
Sebastian S. schrieb: > Da bei uns sehr oft mit Batterie betriebene Schaltungen entworfen > werden, habe ich auch, wegen der Pull-Up Widerstände, eine Allergie > gegen diese Art der Verbindungen entwickelt. Pullups+OpenDrain tuen nicht weh. Jedenfalls nicht mehr als PushPull. Sprich: du hast keine Ahnung von dem, was du tust.
Ich als echter Anfänger in Sachen Programmieren habe gerade mal nach kleinen breakout boards für development boards gesucht, die SPI unterstützen, um mich mit der SPI Schnittstelle mehr vertraut zu machen. Die Mehrzahl an Suchtreffern bietet Sensoren mit I2C Schnittstelle an. ? Ist das nur eine gefühlte Wahrnehmung oder ist I2C mehr verbreitet im Vergleich zu SPI? Gruß,
Alex schrieb: > breakout boards ... > Ist das nur eine gefühlte Wahrnehmung oder ist I2C mehr verbreitet im > Vergleich zu SPI? SPI macht bei shields oder boards weniger Sinn: Du brauchst für mehrere auch mehrere CS. Plus ggf verschiedene Modi. Bei I2C reichen 4 kaskadierbare Anschlüsse und fertig. Dann kannst Du n verschiedene Boards anschließen.
Olaf schrieb: >> Nach meiner Erfahrung sind viele Displays mit I2C wesentlich einfacher >> anzusteuern als per SPI. > > Also meine Erfahrung ist genau anderes rum. Schon alleine deshalb weil > man bei Displays oft auch Wert auf eine hohe Datenuebertragungsrate legt > und haeufige Adressbytes da doof sind. Auch kann man SPI mit 50Mhz > betreiben wenn einem danach ist und es der Displaycontroller kann. Naja, für 4x20 Zeichen ist 50 MHz meiner Meinung nach ein bischen übertrieben. Mit Grafikdisplays habe ich noch nicht gearbeitet, da machen 50Mhz wohl Sinn. Bei dem EA Displays muss man bei I2C auch nur einmal ein Addressbyte schreiben. Danach kann man die Daten für den gesamten RAM am Stück runterschreiben. Andreas
Christian J. schrieb: > Ich erinnere mich schwach, dass es nur 2 sind, scl und sda. Drum steht ein paar Posts drüber auch 2+1, der Strom muss ja auch zurück :)
Alex schrieb: > Ist das nur eine gefühlte Wahrnehmung oder ist I2C mehr verbreitet im > Vergleich zu SPI? In Geräten der Unterhaltungselektronik war (ist) I²C ideal. Da hatte man einen kleinen 1-Chip-Prozessor und an dem hing (im Fall eines Fernsehers) die Fernbedienung, ein kleines EEPROM für Sender und Parameter, die PLL des Tuners, die Audio-Verarbeitung (Klang, Lautstärke, Balance), der Videotext-Decoder, die Quellenumschaltung, das (kleine) Display, eine Echtzeituhr, ..... Und das Ganze brauchte gerade mal gerade 2 Pins. Da blieben noch genug Pins für die Abfrage von Schaltsignalen (SCART-Schnittstelle), die Auswertung der Sync-Impulse (nach längerer Zeit ohne Sender schaltet der Fernseher aus)und alle möglichen anderen Spielereien übrig. Besser war das nicht zu lösen und so liefen die Bauteile in extremen Stückzahlen. Klar, wer unter "Display" nicht nur eine Zeit- und Kanalanzeige versteht, sondern da detailreiche schnell wechselnde Bilder darstellen will, braucht höhere Datenraten - und die kann I²C nicht liefern. (Man darf halt einen LKW nicht mit einem Formel 1 Rennwagen vergleichen, selbst wenn die Motorleistung durchaus vergleichbar sein kann.)
dabei sind beide nicht standardisiert sondern nur Lösungen unterschiedlicher Hersteller. SPI von Motorola I2C von Philips (lustigerweise beide heute NXP) Deshalb findet man bei anderen Herstellern oft Module die zwar SPI oder I2C können, aber der Name taucht dort gar nicht auf. Es sind einfach zwei Beispiele der massenhaft existierenden seriellen Kommunikation. Haben halt ähnliche Ziele und Einsatzzwecke und sind auch zur selben Zeit entstanden.
Tipps schrieb: > Christian J. schrieb: >> Ich erinnere mich schwach, dass es nur 2 sind, scl und sda. > > Drum steht ein paar Posts drüber auch 2+1, > der Strom muss ja auch zurück :) Christian hat, vollkommen zu recht, meine Aussage >> I2C ist nett, weil man nur drei Leitungen benötigt. korrigiert, I2C hat nur zwei Datenleitungen. Natürlich "muss der Strom ja auch zurück" - aber GND hat man sowieso am IC. Aber, bevor Strom zurück kommt, muß der auch geliefert werden, also brauchen wir auch noch die Versorgungsspannung :-) Ändert nichts an der Anzahl der Datenleitungen : SPI mit DataIn, DataOut, CLocK und ChipSelect macht vier. I2C SDA und SCL macht zwei. Günni schrieb: > Klar, wer unter "Display" nicht nur eine Zeit- und Kanalanzeige > versteht, sondern da detailreiche schnell wechselnde Bilder darstellen > will, braucht höhere Datenraten - und die kann I²C nicht liefern. Schnell wechselnd heißt Fernsehen gucken, das macht man weder mit SPI noch mit I2C. Es gibt dennoch hinreichend viele Anwendungen für Grafikdisplays, wo man nur relativ langsam aktualisieren muß. Gucke Dir z.B. die Bastelprojekte Thermometer mit Nokia-Display an, da hat man jede Menge Zeit, die Grafik zu aktualisieren. Es gibt keine Pauschalantwort, die Art der Schnittstelle ist immer von der individuellen Anwendung abhängig.
Nützliches zu I2C Design: https://www.embedded.com/inter-ic-i2c-bus-design-and-test-for-embedded-systems-part-1/ https://www.embedded.com/i2c-bus-design-and-test-for-embedded-systems-part-2/ https://www.eetimes.com/design-calculations-for-robust-i2c-communications/ https://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/ https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/ https://www.eenewsembedded.com/news/designing-robust-fully-isolated-data-power-i2cpmbus-data-interfaces https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiXmsX71pjqAhVM_J4KHWZ_D744FBAWMAl6BAgIEAE&url=https%3A%2F%2Fntrs.nasa.gov%2Farchive%2Fnasa%2Fcasi.ntrs.nasa.gov%2F20000053469.pdf&usg=AOvVaw1BkEgXnLZdw6QIFXK9T_wB
I2C ist rock solid, wenn man es richtig macht. In den alten Phillips 8051-ern wurde es z.B. richtig implementiert. In einem Gerät habe ich die bekannten P80C652 als Multimaster eingesetzt. Das Gerät lief auf Anhieb 24/7 ohne Reset durch. Und auch der Nachfolger mit Flash P89C668 lief einwandfrei. Der Ärger begann erst dann, als NXP den ganzen bewährten Philips 8051-Krempel eingestampft hatte. Ich hab dann versucht, auf AVR umzustellen. Deren I2C ist leider vollkommen buggy, z.B. werden Timings nicht eingehalten. Statt der 4,7µs werden bei Arbitrationsverlust nur kurze Spikes erzeugt. Das verwirrt nicht nur die anderen Teilnehmer, sondern auch die Statemaschine im AVR selbst. https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Tekmos hat mal einen Nachbau des P89C668 rausgebracht, den TK89C668. Ich hab ihn mal in ne alte Platine gesteckt. Dessen I2C ist aber völlig unbrauchbar. Man fragt sich ernsthaft, was ist bloß so schwer daran, die I2C-Spezifikation von Philips sauber zu implementieren.
> I2C ist rock solid, wenn man es richtig macht.
Du hast das Problem nicht verstanden. I2C ist broken by Standard.
Durch ein gutes Hardwaredesign kannst du lediglich die
Wahrscheinlichkeit ihres Auftretens vermindern und durch ein gutes
Softwaredesign kannst du ein Teil der Problem wenn sie auftreten,
abfangen falls du eine Anwendung hast die damit klar kommt das du den
Bus resettest. Aber es bleiben dann immer noch Probleme uebrig die sich
nur durch abschalten loesen lassen.
Olaf
Lest mal dies hier: https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf Und beachtet besonders diesen Satz: Note that while this method is very effective, it may not be possible to clear a hung bus on every manufacturer’s device all the time. Olaf
Olaf schrieb: > it may not be possible to clear a hung bus on every > manufacturer’s device all the time. Hast Du auch mal konkrete Bezeichnungen von solchen I2C-ICs, die den Standard verletzen? Daß ein Reset eines gerade aktiven Masters den adressierten Slave mit SDA = 0 verlassen kann, ist bekannt. Da hilft dann das 9 * SCL takten. In meiner Anwendung kann dieser Fall allerdings nicht auftreten. Alle Teilnehmer sind MCs. Und die Haupt-CPU macht im Init ein Reset aller Module, d.h. deren I2C wird hochohmig. Die Modul-CPUs warten dann mindestens ein Paket der Haupt-CPU ab, ehe sie senden dürfen. Der große Vorteil des Multimaster-I2C ist, daß die Module selbstständig senden dürfen, d.h. die Haupt-CPU sie nicht ständig abfragen muß. Erst mit dem Einsatz der AVRs war eine zusätzliche Fehlerbehandlung notwendig. Per Pin-change und Timerinterrupt wird geprüft, ob SDA oder SCL eine bestimmte Zeit auf low bleiben. Zusätzlich wird geprüft, ob eine Sendeanforderung anliegt, d.h. das STA-Bit wurde gesetzt, aber der AVR hat sich intern verklemmt und sendet trotz freiem I2C-Bus kein Start. Die AT89C51 mit I2C sind ähnlich buggy, wie die AVRs. Da hat wohl die 8051-Abteilung von den AVRs abgeguckt. Hätten sie mal lieber von Philips abgeguckt.
:
Bearbeitet durch User
> Hast Du auch mal konkrete Bezeichnungen von solchen I2C-ICs, die den > Standard verletzen? Jedes. Weil sie nicht wie SMB einen 35ms Timeout und eine minimal Taktfrequenz haben. Es geht nicht um den Normalbetrieb. Stell dir vor du hast mal einen kleinen Peak auf SCK weil gerade Gewitter war. Oder ueberleg dir warum sie das bei SMB wohl eingebaut haben. .-) Oder kuck mal hier: https://www.thierry-lequeu.fr/data/LM75.pdf zitat seite6: The LM75B also has a bus fault timeout feature. If the SDA line is held low for longer than tTIMEOUT (75 ms minimum to 325 ms maximum) the LM75B will reset to the IDLE state (SDA set to high impedance) and wait for a new start condition. Das haben keineswegs alle LM75, erst recht nicht von allen Herstellern. Schon garnicht irgendwelche anderen I2C-Ics. Was glaubst du wohl warum wurde das irgendwann eingebaut? > Die AT89C51 mit I2C sind ähnlich buggy, wie die AVRs. Da hat wohl die > 8051-Abteilung von den AVRs abgeguckt. Jaja laber rabarber. Es ist vollkommen unbestritten das einzelne Implementation von I2C mal mehr oder weniger gut gelungen sind. Das hat aber nichts mit dem Grundproblem zutun. Olaf
Peter D. schrieb: > I2C ist rock solid, wenn man es richtig macht. Ja, aus der Softwaresicht möglicherweise. Wenn aber jetzt EMV ins Spiel kommt und der Slave auf einmal sehr kurze Takte sieht, wo der Master keine geschrieben hat wirds lustig. Im blödesten Fall hängt sich der Slave weg und blockiert den Bus. Und die Software kann dann NICHTS machen um das zu beheben. Zum Glück hatten die von mir eingebauten ICs einen Reseteingang, der auch bis zum Master angeschlossen war..... Das zumindest ist bei SPI besser. Wenn das CS (ChipSelect) inaktiv wird, so ist der Bus wieder nutzbar. Und der Slave auch, der fängt mit dem nächsten aktivieren des CS wieder sauber von Vorne an. Prometheus
I2C oder SPI? Raider oder Twix? First World Problems!
Falk B. schrieb: > I2C oder SPI? > Raider oder Twix? Raider = Twix (Vom Inhalt her zumindest) I2C != SPI
Jemand schrieb: > Ja, aus der Softwaresicht möglicherweise. Wenn aber jetzt EMV ins Spiel > kommt und der Slave auf einmal sehr kurze Takte sieht, wo der Master > keine geschrieben hat wirds lustig. Im blödesten Fall hängt sich der > Slave weg und blockiert den Bus. Und die Software kann dann NICHTS > machen um das zu beheben. Moment, warum "hängt sich der Slave weg"? Was soll das bedeuten? Im schlimmsten Fall erkennt der Slave eine Startbedingung und nachfolgende Takte und wartet mitten im Byte. Oder die Störung trat während einer Übertragung auf und der Slave erkennt zu viele oder zu wenig Takte und hängt dann ebenfalls mitten im Byte. Na und? Wenn der Master merkt dass der Slave nicht mehr reagiert kann er mit max. 9 Clockimpulsen, den Slave da raus holen. Wenn der Slave gerade sendet reicht dazu ein NO ACK nach jedem Takt. Wenn er empfängt muss man nur takten. Ansonsten reicht eine zusätzliche STOP Bedingung auch aus. Das muss der Master natürlich softwaremäßig drauf haben aber das wars auch. > Das zumindest ist bei SPI besser. Wenn das CS (ChipSelect) inaktiv wird, > so ist der Bus wieder nutzbar. Und der Slave auch, der fängt mit dem > nächsten aktivieren des CS wieder sauber von Vorne an. Ach ich denke er "hängt sich weg". Warum reagiert er dann auf CS? Vielleicht solltest du das von dir angenommen Verhalten mal sauber definieren. Wenn er auf CS reagiert, reagiert ein I2C Slave auch auf zusätzliche Takte und die STOP Bedingung nach einer Störung.
:
Bearbeitet durch User
Am dummen I2C Slaves habe ich bisher EEPROMs 24C02..24C512 und IO-Ports PCF8574/A benutzt. Keinem mußte ich jemals den Saft abdrehen, um sie zu resetten. Die AN-686 ist eh absoluter Quatsch. Den VCC-Pin auf GND zu ziehen, kann dem IC erst recht schaden. Man müßte zuvor SDA und SCL vom Master als I2C disablen, als IO-Pin enablen und auf Low setzen. Ansonsten bekämen die I2C-Pins eine Spannung >VCC, was verboten ist. Mit etwas Glück zündet dann intern ein parasitärer Thyristor. Das wird aber nirgends erwähnt. Man sieht, der Autor wollte nur den Switch-IC verkaufen und hat sich dafür was aus den Fingern gesogen.
> Na und? Wenn der Master merkt dass der Slave nicht mehr reagiert kann er
Es gibt auch I2C-Bausteine die ziehen SCL auf Low. Dann war es das mit
dem Trick zur Wiederbelebung.
Olaf
Olaf schrieb: >> Na und? Wenn der Master merkt dass der Slave nicht mehr reagiert kann er > > Es gibt auch I2C-Bausteine die ziehen SCL auf Low. Dann war es das mit > dem Trick zur Wiederbelebung. Du meinst clock stretching? Allerdings tun sie das nur eine bestimmte Zeit lang, um zu signalisieren dass sie beschäftigt sind. Wenn du davon ausgehst dass jeder Baustein jederzeit komplett durchdrehen kann, spielt es keine Rolle ob du I2C oder SPI einsetzt. Viel wahrscheinlicher ist allerdings dass eben durch EMV Taktimpulse erzeugt oder verschluckt werden. Und dagegen kann man was tun.
Cyblord -. schrieb: > Viel wahrscheinlicher ist allerdings dass eben durch EMV Taktimpulse > erzeugt oder verschluckt werden. Und dagegen kann man was tun. Das Problem ist mir bei SPI auch oft aufgefallen. Die Slaves sind oft sauschnell, da nützt es auch nichts, wenn der Master langsamer taktet. Obendrein kann man bei SPI nicht feststellen, ob so ein Fehler auftritt. Bei I2C ist dann das ACK/NACK asynchron, d.h. der Master sieht das NACK und weiß, da ist was faul. Obendrein haben die I2C-ICs in der Regel Filter eingebaut, die schnelle Störungen unterdücken. I2C ist daher deutlich unkritischer. Bei SPI habe ich mal RC-Tiefpässe und 74HC14 als Filter nachgerüstet, um die Störungen in den Griff zu bekommen.
Peter D. schrieb: > Bei SPI habe ich mal RC-Tiefpässe und 74HC14 als Filter nachgerüstet, um > die Störungen in den Griff zu bekommen. Höchstens bei Speed weit jenseits aller I2C Träume. Ansonsten ist SPI wesentlich unkritischer und auch softwaretechnisch einfacher zu handhaben.
Mark schrieb: > Höchstens bei Speed weit jenseits aller I2C Träume. Die Geschwindigkeit ist vollkommen egal. Kritisch ist die höchste Freqeunz des Slave, bei der er noch Störflanken als Taktflanke erkennt. Einen 100MHz seriellen Flash kannst Du nicht auf eine 2. Platine führen, auch wenn Du ihn nur mit 1MHz ausliest.
Mark schrieb: > Peter D. schrieb: >> Bei SPI habe ich mal RC-Tiefpässe und 74HC14 als Filter nachgerüstet, um >> die Störungen in den Griff zu bekommen. > > Höchstens bei Speed weit jenseits aller I2C Träume. Ansonsten ist SPI > wesentlich unkritischer und auch softwaretechnisch einfacher zu > handhaben. Das stimmt schon, aber I2C kommt halt mit zwei Leitungen aus. SPI braucht 3+n bei n slaves. Natürlich ist der SW Aufwand höher. Nur in Bezug auf "hängenbleiben" sehe ich kein kritischen Unterschiede.
Peter D. schrieb: > die I2C-Pins eine Spannung >VCC, was verboten ist. Nein umgekehrt. Es ist sogar definitiv in der I²C Spec vorgeschrieben, dass I²C Pins den Bus nicht stören dürfen, auch wenn der betreffende Baustein nicht versorgt ist. Zumindest ab FAST. Das sich viele ICs gerade an diesen Passus nicht halten, ist leider ein häufiges Problem. Auch das manche Bausteine den I²C Bus killen wenn ihr eigener interner Clock noch nicht richtig läuft. Auch hier, nicht ein Problem des Busses und der Spec an sich, sondern der mangelhaften Umsetzung in diversen Bausteinen. Wenn man bei SPI problemlos eigene CS Leitungen pro Baustein spendieren kann, kann man sicher auch eine Reset Leitung für alle I²C Teilnehmer einbauen wenn man Angst hat die Chips sonst nicht mehr zum leben erwecken zu können. Btw. ein Spike auf SPI führt auch zu Fehlverhalten der Schaltung. Ein fehlendes ACK bemerkt man in der SW oft schneller und kann reagieren drauf. Aber wie schon oft in diesem Thread angeführt, alles hat sein Vor- aber auch Nachteile.
> Aber wie schon oft in diesem Thread angeführt, alles hat sein Vor- aber > auch Nachteile. Yep. Man muss sich ueber die Vor und Nachteile im klaren sein und dann kann man beides passend einsetzen. Ausserdem wird bei den meisten Bastlern hier das Problem vor der Tastatur sitzen. Zum Beispiel wenn es solche Programmzeilen gibt: tue dieses; while(i2c_ready()==true); --> Man muss hier immer ein Timeout haben! tue jenes; Olaf
Andi B. schrieb: > Ein fehlendes ACK bemerkt man in der SW oft schneller und kann > drauf reagieren. Nicht in Wirklichkeit. Ich hab hier im Forum noch keinen I2C Code gesehen, bei dem das ACK/NAK jemals ausgewertet wurde. Als Fehlerbeschreibung kam nur "ich bekomme immer 0xFF vom Bus" MfG Klaus
Klaus schrieb: > Andi B. schrieb: >> Ein fehlendes ACK bemerkt man in der SW oft schneller und kann >> drauf reagieren. > > Nicht in Wirklichkeit. Ich hab hier im Forum noch keinen I2C Code > gesehen, bei dem das ACK/NAK jemals ausgewertet wurde. Als > Fehlerbeschreibung kam nur "ich bekomme immer 0xFF vom Bus" > > MfG Klaus Das ist aber nicht die Schuld des Busses oder dessen Spezifikation, sondern der Qualität der SW welche darüber was zu steuern versucht. Das ein ACK/NAK ein Vorteil sein kann, dürfte unbestritten sein.
Peter D. schrieb: > Am dummen I2C Slaves habe ich bisher EEPROMs 24C02..24C512 und IO-Ports > PCF8574/A benutzt. Keinem mußte ich jemals den Saft abdrehen, um sie zu > resetten. stimmt, aber man kann denen ja den Saft abdrehen für einen PoR, soviel wie die benötigen kann das auch ein AVR aus einem Port liefern. I2C ist deutlich entspannter.
> stimmt, aber man kann denen ja den Saft abdrehen
DAs ist natuerlich auch eine Frage der Statistik. Ein EEPROM wird man
wohl beim einschalten einmal lesen und dann vielleicht wenn sich mal ein
Wert geaendert hat. Das ist was anderes wie AD-Wandler oder Display. Da
werden Probleme dann erheblich seltener auftreten.
Olaf
Dennis H. schrieb: > IIC - 400kHz max., aber viele Geräte auf 2+1 Kabeln Stimmt nicht. Es gibt IO, die 1,7 MHz bzw. 3,4 MHz schaffen. Aber sowieso, SPI ist schneller. Schon selbst die Notwendigkeit, immer Slaveadresse zu senden (und wenn man lesen will, dann sogar zweimal! ) bremst I2C enorm. Also, je nachdem. Wenn auf einer Platine schon sowieso ein paar SPI-Chips stehen, dann ist logisch, auch alles andere möglichst mit SPI zu machen. Wenn aber Geschwindigkeit nicht von Bedeutung und einige Chips, die nur für I2C vorhanden sind, dann natürlich I2C. Ich habe meine Spielzeug-Platine mit SPI gemacht, damit alle internen Geräte möglichst schnell bedient werden und möglichst weniger von CPU-Zeit verbrauchen. Für eine Platine mit Uhr, die für genau definierten Zwecke gemacht wurde und keine offene Architektur hat, habe ich I2C gewählt: DS3231 kostet in China deutlich billiger als DS3234. Andi B. schrieb: > Wenn man bei SPI problemlos eigene CS Leitungen pro Baustein spendieren > kann 3*HC138 und wir haben mit 4 Pins (außer SPI selbst) schon 24 IC bedient. Wenn wir aber ähnlich wie bei I2C vor dem Austausch immer Slave-Adresse senden, dann kann zusätzliche Aufwand nur 4*HC138 + 1*HC595 sein, dann für 24 IC brauchen wir nur 1 Pin zusätzlich (Adr/Data Umschalten)! Trotzdem kann SPI auch dann deutlich schneller arbeiten als I2C. Noch Vorteil für SPI: man kann zusätzlichen IO mit Logik machen (Z.B. HC 165 und HC 595), das macht Datenaustausch noch schneller als mit besonderen IO-Chips. Für I2C kenne ich so einfachen Lösungen nicht.
:
Bearbeitet durch User
Klaus schrieb: > Ich hab hier im Forum noch keinen I2C Code > gesehen, bei dem das ACK/NAK jemals ausgewertet wurde. Dann hast du meine Codes nicht angeschaut. Ich werte die Antworten IMMER aus. Als Entwickler von Enterprise Backend Anwendungen weiß ich, dass ordentliche Fehlerbehandlung noch wichtiger ist, als die vom Kunden geforderte Funktion des Programms. Fehler sind nämlich erst dann schlimm, wenn man sie a) Nicht nachvollziehen kann b) Nicht erklären kann c) Demzufolge nicht zeitgerecht beheben kann
Gibt es eigentlich DDR-SPI ? Gruß Dennis
Dennis H. schrieb: > Gibt es eigentlich DDR-SPI ? Edit, es gibt NOR Flash Bausteine mit DDR, zum Beispiel den IS25LP256D.
:
Bearbeitet durch User
Rudolph R. schrieb: > Dennis H. schrieb: >> Gibt es eigentlich DDR-SPI ? > > Edit, es gibt NOR Flash Bausteine mit DDR, zum Beispiel den IS25LP256D. Danke. Sieht interessant aus. Ein aufgebohrter QSPI. Bei SPI ist bei dem NOR kein DDR möglich.
Stefan ⛄ F. schrieb: > Dann hast du meine Codes nicht angeschaut. Ich werte die Antworten > IMMER aus. Dann bitte ich dich ausdrücklich um Entschuldigung. Aber mein überwältigender Eindruck ist ein anderer. MfG Klaus
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.