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
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
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
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 -.-
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
> 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.
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.
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.^^
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.
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?
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.
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.
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.
Schau dir einfach mal an wie man I2C benutzt und nimm dann den UART.
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
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.
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.
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
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.
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.
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.
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".
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.
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.
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.