Arbeitet ihr lieber mit SPI oder I2C Bauteilen?

https://xkcd.com/927/

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.

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.

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

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.

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.

> 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.

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.

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

> 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

Falk B. schrieb:
> I2C oder SPI?
> Raider oder Twix?

Raider = Twix (Vom Inhalt her zumindest)
I2C != SPI

> 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

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.

> 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

> 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

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

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