Forum: Mikrocontroller und Digitale Elektronik Arbeitet ihr lieber mit SPI oder I2C Bauteilen?


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 Peter Pander (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
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

von Jemand (Gast)


Angehängte Dateien:

Bewertung
14 lesenswert
nicht lesenswert

von Dennis H. (c-logic)


Bewertung
7 lesenswert
nicht lesenswert
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
von Jens M. (schuchkleisser)


Bewertung
-7 lesenswert
nicht lesenswert
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.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"!

von Christian J. (Firma: privat) (christianj)


Bewertung
7 lesenswert
nicht lesenswert
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.

von Christian J. (Firma: privat) (christianj)


Bewertung
3 lesenswert
nicht lesenswert
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 :-)

von Freitagstrollerkenner (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
5 lesenswert
nicht lesenswert
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?

von Christian J. (Firma: privat) (christianj)


Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von René F. (therfd)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
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.

von FSJW (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
@Rene

im Screenshot als Bezeichner Master, Slave und SS, darf man das heute 
noch ?

von Olaf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> 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

von Sven P. (haku) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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...

von Peter Pander (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bitklopfer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von MiWi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter Pander (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
oh, super, wieder was neues...lol..
Und vermutlich ist es nicht kompatibel?

von Peter Pander (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Rudolph R. (rudolph)


Bewertung
6 lesenswert
nicht lesenswert
+1 für SPI, simpel, schnell und robust.

von Peter Pander (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Hanns-Jürgen M. (yogy)


Bewertung
2 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> +1 für SPI, simpel, schnell und robust.

sehe ich genauso

von Klaus B. (butzo)


Bewertung
1 lesenswert
nicht lesenswert
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

von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ich bevorzuge SPI. Jetzt aber weg mit dem Troll.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Christian J. (Firma: privat) (christianj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Michael M. (avr-moby)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Günni (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sebastian S. (amateur)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> 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

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Alex (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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ß,

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tipps (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 
:)

von Günni (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.)

von volle (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Murmeltier (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> 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

von Olaf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
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
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Jemand (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
-3 lesenswert
nicht lesenswert
I2C oder SPI?
Raider oder Twix?

First World Problems!

von TR.OLL (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Falk B. schrieb:
> I2C oder SPI?
> Raider oder Twix?

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

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mark (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> 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

von Maxim B. (max182)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Dennis H. (c-logic)


Bewertung
0 lesenswert
nicht lesenswert
Gibt es eigentlich DDR-SPI ?

Gruß Dennis

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Dennis H. schrieb:
> Gibt es eigentlich DDR-SPI ?

Edit, es gibt NOR Flash Bausteine mit DDR, zum Beispiel den IS25LP256D.

: Bearbeitet durch User
von Dennis H. (c-logic)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.