Forum: Mikrocontroller und Digitale Elektronik SS bei 2 uC weglassen?


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 Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
Nabend zusammen,

Gibt es irgendwelche Nachteile, wenn ich bei 2uC`s über SPI den SS 
weglasse?

Master: Atmega8
Slave: Atmega16

ich habe eine Kommunikation von 2uC`s über SPI, wobei uC2 nur Slave ist.
Wenn ich nun SS weglasse und bei uc2 SS auf dauer Gnd lege, funktioniert 
es noch immer einwandfrei.

Nun habe ich mir die Funktion der SPI Schnittstelle im Datenblatt 
angesehen.

Da steht unter anderem, dass SS auch zur Synchronisation genutzt wird.
Kann es nun im Dauerbetrieb passieren, dass die Kommunikation irgendwann 
fehlschlägt da es keine sync mehr gibt?
Oder gibt es noch ausreichend Sync über MISO/MOSI (kenne leider das SPI 
Protokoll noch nicht)?

Auf den ersten Blick liest es sich so, dass SS (da dies die 
Schnittstelle aktiviert) eigentlich schon immer genutzt werden sollte.


Gruß,
Philipp

: Bearbeitet durch User
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Philipp L. schrieb:
> Da steht unter anderem, dass SS auch zur Synchronisation genutzt wird.
> Kann es nun im Dauerbetrieb passieren, dass die Kommunikation irgendwann
> fehlschlägt da es keine sync mehr gibt?
> Oder gibt es noch ausreichend Sync über MISO/MOSI (kenne leider das SPI
> Protokoll noch nicht)?

Ja, das ist für mich der Hauptgrund SS zu benutzen. Stell dir einfach 
mal vor der Empfänger verrutscht aus irgendwelchen Gründen ein Bit weil 
eine Störung auf der Clock dafür sorgt das er ein extra Bit zählt, 
danach empfängst du nur noch Müll. Wenn aber SS nach dem Byte hoch geht, 
ist der Slave wieder sauber und hat nur ein Byte Müll empfangen.

: Bearbeitet durch User
von Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
Ja, so habe ich das auch verstanden.
Da ich Platzmäßig für die Buchsenleiste etwas begrenzt bin, wäre I2C für 
meine Anwendung dann wohl geeigneter.

Hat jemand ein Beispiel in C, wie ich zwischen 2uC`s mittels 
Hardware-I2C kommunizieren kann?

Ich muss lediglich 1 Byte vom Master zum Slave senden.

: Bearbeitet durch User
von Dussel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Philipp L. schrieb:
> Hat jemand ein Beispiel in C, wie ich zwischen 2uC`s mittels
> Hardware-I2C kommunizieren kann?
Da dazu absolut nichts zu finde ist, habe ich mal schnell was 
zusammengeschrieben: https://www.mikrocontroller.net/articles/AVR_TWI
-.-

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es eigentlich aus, müssen die µC in beide Richtungen 
miteinander Reden? Ansonsten könntest du MISO oder MOSI weglassen...

Philipp L. schrieb:
> Ich muss lediglich 1 Byte vom Master zum Slave senden.
EDIT: Dann lass MISO weg.

: Bearbeitet durch User
von Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
> Wie sieht es eigentlich aus, müssen die µC in beide Richtungen
> miteinander Reden?

Momentan zwar nicht, würde mir die Option jedoch für später gern offen 
halten.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt haufenweise Möglichkeiten, die Synchronisation zu verlieren:
- beide werden nicht gleichzeitg eingeschaltet,
- der Master ist zuerst mit dem Reset fertig und sendet schon los,
- der Slave ist zuerst mit dem Reset fertig und empfängt fleißig Takte 
auf dem noch floatenden SCK des Masters,
- einer macht zwischendurch ein Reset
usw.

Wenn Du knapp an Leitungen bist, nimm die UART oder ein IR-Protokoll.

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wenn Du knapp an Leitungen bist, nimm die UART oder ein IR-Protokoll.

Stimmt, UART können die beiden ja in Hardware, manchmal sieht man den 
Wald vor lauter Bäumen nicht.^^

von Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
Was wäre denn der Vor/Nachteil von Uart oder I2C ?

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Philipp L. schrieb:
> Was wäre denn der Vor/Nachteil von Uart oder I2C ?

Vorteil UART: Nur 2 Leitungen, synct bei jedem Byte selbständig neu 
(übers Startbit), einfach in Hardware zu benutzen.

I2C ist da umständlicher weil nicht nur für zwei Teilnehmer und ich 
würde es nicht grundlos nehmen wenn eine UART auch geht.

von Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
I2C ist umständlicher in der Programmierung?
Ist das ein nennenswerter Unterschied, wenn nur 1 Byte übertragen werden 
muss?
Hätte natürlich den Charm, eine Option für mehr Teilnehmer zu haben.

Hardwaretechnisch sind doch bei beiden nur 2 Leitungen notwendig, 
richtig?

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Philipp L. schrieb:
> I2C ist umständlicher in der Programmierung?
Ja, woher weiß der entsprechende Teilnehmer das er angesprochen wird? 
Also brauchst du Adressen die du jeweils vor den Nutzdaten übermitteln 
musst.

> Ist das ein nennenswerter Unterschied, wenn nur 1 Byte übertragen werden
> muss?
Ja.

> Hätte natürlich den Charm, eine Option für mehr Teilnehmer zu haben.
>
> Hardwaretechnisch sind doch bei beiden nur 2 Leitungen notwendig,
> richtig?
Ja.

von Name: (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Tim T. schrieb:
> Ja, das ist für mich der Hauptgrund SS zu benutzen. Stell dir einfach
> mal vor der Empfänger verrutscht aus irgendwelchen Gründen ein Bit weil
> eine Störung auf der Clock dafür sorgt das er ein extra Bit zählt,
> danach empfängst du nur noch Müll. Wenn aber SS nach dem Byte hoch geht,
> ist der Slave wieder sauber und hat nur ein Byte Müll empfangen.

SPI ist per Default nicht für eine gestörte Übertragungsstrecke 
ausgelegt.

Entweder deine SPI ist elektrisch störungsfrei, dann ist SS bei nur 
einem Slave nutzlos.
Oder sie ist es nicht. Dann hift dir SS auch nicht wirklich weiter. Denn 
wenn deine Daten im nennenswerten Umfang Bitfehler enthalten können die 
du nicht erkennst, was nützen sie dir?

In dem Fall würde man ohnehin ein fehlertolerantes Protokoll 
implementieren müssen. Zum Beispiel mit CRC. Dann sehe ich den Vorteil 
von SS auch nicht.

Philipp L. schrieb:
> Ich muss lediglich 1 Byte vom Master zum Slave senden.

Dafür nehme ich persönlich gerne UART.

Im Normalfall ist das sehr einfach, vorausgesetzt beide µC haben ein 
UART-Modul. Nur zwei Leitungen, und bei den µC die ich kenne, nur sehr 
wenige Codezeilen und minimalste Prozessorlaufzeit - rein in den FIFO, 
den Rest erledigt das Peripheral. Wenn ein Byte da ist, gibts einen 
Interrupt.
Einfacher als SPI zu handhaben, weil asynchron und bidirektional.

von Philipp L. (viech)


Bewertung
0 lesenswert
nicht lesenswert
Da ich noch keine Ahnung von der I2C, sowie Uart Schnittstelle habe, 
rede ich evtl. Quatsch:

Solange nur 1 Teilnehmer an der I2C hängt, kann doch sofort im ersten 
Byte die Information liegen.
Denn er ist ja immer gemeint?
Wenn ich doch mehrere dranhängen möchte, muss man halt die 
Programmierung dementsprechend ändern?

Es geht hauptsächlich um das Platinendesign.
Ich habe eine Hauptplatine und die Kommunikation mit der 
Zusatz(Aufsteckplatine).
Momentan gibt es zwar nicht viel zu übermitteln, aber  die Möglichkeit 
mehrere Teilnehmer auf der Zusatzplatine einsetzen zu können ist schon 
super.
Bei gleichem Hardwareaufwand ist es vermutlich sinnvoll, I2C auf die 
Verbindungspins zwischen Haupt/Zusatzplatine zu legen.

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Schau dir einfach mal an wie man I2C benutzt und nimm dann den UART.

von Klaus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Tim T. schrieb:
> Vorteil UART: Nur 2 Leitungen, synct bei jedem Byte selbständig neu
> (übers Startbit), einfach in Hardware zu benutzen.

Nachteil UART: beide Teilnehmer müssen einigermaßen stabile und bekannte 
Clocks haben, da die Übertragung asynchron ist. Da punkten die 
synchronen Verfahren wie SPI oder I2C.

MfG Klaus

von Name: (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Nachteil UART: beide Teilnehmer müssen einigermaßen stabile und bekannte
> Clocks haben, da die Übertragung asynchron ist. Da punkten die
> synchronen Verfahren wie SPI oder I2C.

Korrekt, guter Einwand.

Aber trotzdem:
Erstens sind die modernen µC oft genau genau für 9,6kBd oder sogar viel 
mehr, zweitens reden wir hier von einzelnen Bytes.
Da spielt die Baudrate bei 1Byte vermutlich eine untergeordnete Rolle.

Der große Vorteil der UART ist aber die Asynchronität. Bei I2C und SPI 
muss man definieren, wer Master ist, und wer Slave. Der Master muss die 
Daten beim Slave aktiv anfordern.
Oder der Slave signalisiert das - was eine Leitung nötig macht.

Das entfällt bei der UART völlig, und damit jeglicher logistische 
Aufwand in der Hinsicht.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Liebe Leute,

I2C sowie auch SPI erfordern bestenfalls etwas mehr Fleißarbeit aber 
wirklich mehr Aufwand als UART ist das eigentlich nicht wirklich. Man 
muss sich halt etwas reinfuchsen, also mal so ca. 1 Tag damit 
beschäftigen, aber dann hat mans ziemlich schnell raus.
Da die Frage im Raum steht ob man SS nicht dauerhaft auf GND liegen 
lassen kann lässt mich vermuten, dass hier ein µC der Master sein soll, 
der nur Daten versendet und ein µC der Slave sein soll, der nur Daten 
empfängt (aber nicht sendet). Damit ist die MISO-Leitung überflüssig. SS 
würde ich aus Synchronisationsgründen immer schaltbar lassen und nicht 
hart verdrahten.

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> I2C sowie auch SPI erfordern bestenfalls etwas mehr Fleißarbeit aber
> wirklich mehr Aufwand als UART ist das eigentlich nicht wirklich. Man
> muss sich halt etwas reinfuchsen, also mal so ca. 1 Tag damit
> beschäftigen, aber dann hat mans ziemlich schnell raus.

So ist es. Ich führe einen I2C Bus eigentlich bei jeder µC Platine an 
den Rand. Dazu noch Vcc und GND. Und schon hat man einen Portexpander 
und/oder einen Temperatursensor oder auch ein kleines OLED Display 
rangehäkelt (auch mal zum Debuggen). Der Rest ist Software. Und wenn man 
I2C mal richtig verstanden hat, kann man aus kleinen µCs (8 bis 20 
polig) eigene "Peripheriebausteine" basteln: ADCs, die selbsttätig MAX, 
MIN und Mittelwert berechnen; PWM-Generatoren mit Überstrom und 
Übertemperaturüberwachung; Soundchips etc

MfG Klaus

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
I2C hat immer das Problem, dass ein einzelner Teilnehmer den ganzen Bus 
abschießen kann wenn er irgendwo mitten in einem byte hängen bleibt. 
Genauso sind einige I2C Implementierung in Hardware sehr "interessant" 
(Beispiel STM32F103: die Filter hängen sich auf und müssen beim Starten 
mit manuellem Pingewackel "entsperrt" werden).
Ich würde mir kein I2C antun wenn ich es nicht muss.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
UART benötigt nur 1 Leitung, synchrone 2.

Aber der Hauptvorteil: synchrone brauchen saubere Signale. Jeder 
Doppelimpuls an clock erzeugt Fehler.

Beim UART sind alle Unsauberkeiten beim Umschalten egal.

Und wenn es bidirektional wird, ist das Timing im Slave viel einfacher.

von Name: (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max D. schrieb:
> I2C hat immer das Problem, dass ein einzelner Teilnehmer den
> ganzen Bus
> abschießen kann wenn er irgendwo mitten in einem byte hängen bleibt.
> Genauso sind einige I2C Implementierung in Hardware sehr "interessant"
> (Beispiel STM32F103: die Filter hängen sich auf und müssen beim Starten
> mit manuellem Pingewackel "entsperrt" werden).
> Ich würde mir kein I2C antun wenn ich es nicht muss.

Weder braucht man bei der SPI über eine gut gemachte Platine SS-Voodoo 
um böse Bitteufel auszutreiben, noch bleibt bei einem sauber 
programmierten I2C ständig ohne Grund der Bus hängen.

In der Arbeit haben wir Millionen Platinen mit I2C im Feld, und solche 
Probleme sieht man im Höchstfall während der Firmwareentwicklung. I2C 
mag zickig und kompliziert sein, aber es bleibt niemals "einfach so ohne 
Grund" "der Bus hängen". An Bitfehler bei SPI kann ich mich überaupt 
nicht erinnern. Und ja, sowas wird bei uns bei der Inbetriebnahme und 
EMV durchaus überprüft.

Wenn man Argumente aufzählt, dann bitte echte.

Wenn wir schon beim Thema sind:
Warum habe ich oben die UART aufgeführt?
Weil mit der UART das Handling von Master / Slave wegfällt, und es immer 
eine Leitung weniger ist als bei I2C oder SPI, und weil die UART ein 
häufiges Peripheral bei µC ist. Darum.

Nicht weil die UART "unempfindlicher gegen Störungen ist", die UART 
"Standart(sic)" ist oder ich sie "so toll, und alles andere dumm" finde.

Wenn man jetzt die UART nicht benutzen kann (möglicherweise wegen dem 
Takt, oder Pins nicht frei), wäre das nächstgünstigere sicher die SPI. 
Weil sie simpel ist.
Erst wenn das nicht möglich ist, würde ich auf I2C zurückgreifen. Der 
Grund ist der höhere Aufwand in Software bei I2C, insbesondere dem 
Slave.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Entweder deine SPI ist elektrisch störungsfrei, dann ist SS bei nur
> einem Slave nutzlos.

Selten so gelacht.
Lies Dir mal durch, was ich oben geschrieben habe. Die Synchronisation 
kann ganz ohne Bus-Störungen verloren gehen bzw. schon beim Einschalten 
durch unterschiedliche Programmlaufzeiten verloren sein.

Ein kurzer Spannungseinbruch, der den Master resetten läßt, während der 
Slave mitten im Byte hängt, reicht aus. D.h. auch die Versorgung über 
das selbe Netzteil muß nicht zuverlässig sein.

Man kann natürlich einen Würg-Around basteln, indem der Slave sein SPI 
zurück setzt, wenn einige Zeit Ruhe war. Und der Master macht dazu 
zyklisch "Sync-Pausen".

von my2ct (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Weder braucht man bei der SPI über eine gut gemachte Platine SS-Voodoo
> um böse Bitteufel auszutreiben

Dann erklär bitte mal, wie du ohne SS Synchronität zwischen Master und 
Slave sicher stellst.

von Name: (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ein kurzer Spannungseinbruch, der den Master resetten läßt, während der
> Slave mitten im Byte hängt, reicht aus. D.h. auch die Versorgung über
> das selbe Netzteil muß nicht zuverlässig sein.

Kann schon sein. Muss aber nicht. Man kann Timeouts nehmen.

Mal ehrlich, es wird immer Fälle geben, wo SS nötig ist. Ich habe 
nirgends behauptet, es wäre "IMMER UND ÜBERALL BLÖDSINN" der ähnlichen 
Quatsch.

Es ging um den konkreten Fall - Kommunikation zwischen zwei µC, und da 
ist es unnötig.

my2ct schrieb:
> Name: schrieb:
>> Weder braucht man bei der SPI über eine gut gemachte Platine SS-Voodoo
>> um böse Bitteufel auszutreiben
>
> Dann erklär bitte mal, wie du ohne SS Synchronität zwischen Master und
> Slave sicher stellst.

Man kommuniziert nach einem bestimmten Protokoll. Der Slave bekommt 
Daten, wenn er Takt bekommt. Eine zusätzliche Synchronisation ist nicht 
nötig. Das habe ich so schon verwendet. Erfolgreich und mehrfach.

Wenn der Master während der Kommunikation "wegstirbt", und dann wieder 
hochkommt, ist es übrigens übelster Pfusch, den Slave nicht 
zurückzusetzen. Das ist kein Argument für SS, weil ein Slave im 
unbekannten Zustand wenig nützlich ist. Das gilt so auch ganz besonders 
für I2C ;-)

Im Übrigen kann man da lange diskutieren, weil es viele Fälle gibt: SPI 
ist nicht so super standardisiert. Es gibt viele Arten von Slaves und 
viele Arten, wie die SPI implementiert sein kann. Manche Slaves werden 
ein SS zwingend benötigen. Für die Kommunikation zwischen zwei µC (wie 
hier diskutiert) ist SS nicht zwingend.

Im Übrigen sieht man an dieser Diskussion wunderbar einen weiteren 
Vorteil einer UART. Stirbt ein Teilnehmer während der Kommunikation, 
bleibt da nichts hängen, lediglich die Daten sind ungültig. Eine CRC 
deckt das problemlos auf. Komplexes Gehampel mit obskuren Leitungen oder 
Timeouts ist  unnötig.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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