SPI Verdrahtung zw. 2 ATMega8

Hero_123

Mitglied
17. Sep. 2010
183
3
18
Sprachen
  1. ANSI C
Hallo

Ich möchte 2 ATMega8 (3,686 MHz Quarz) miteinander per SPI kommunizieren lassen (ich habe mir die ATMEL AVR151 SPI Spec incl Beispieldateien runtergeladen) .
Die beiden Prozessoren sind nicht auf der gleichen Platine, sondern auf zwei ca 50cm voneinander getrennten Bastelplatinen untergebracht (ich kann sie nicht auf einer Platine unterbringen).
Meine Frage - was habe ich bei der HW-Verdrahtung zu beachten (außer die entsprechenden Leitungen MISO, MOSI etc korrekt zu verbinden) - reicht es, die Leitungen einfach zu verbinden (an beiden Platinen anlöten und "gut ist es") oder sollten es geschirmte Leitungen (auf 2 Bastelplatinen?) sein oder verdrillte oder ... was sollte ich da beachten?
Im Netz habe ich gelesen, dass die Kommunikation auch über 1,5 m funktionieren würde wenn die Frequenz entsprechend niedrig ist.
Ich will "nur" die Kommunikation per SPI verstehen bzw "zum Laufen bringen" - z.B. sollen Analogwerte von einem ATMega8 eingelesen und per SPI an den anderen gesendet werden, dieser wertet sie aus und zeigt sie auf dem PC an etc ...

mfg
Hero_123
 
Hallo Hero_123,
reicht es, die Leitungen einfach zu verbinden (an beiden Platinen anlöten und "gut ist es") oder sollten es geschirmte Leitungen (auf 2 Bastelplatinen?) sein oder verdrillte oder ... was sollte ich da beachten?
Genau richtig. Es kommt unter anderem auf die Kapazitäten der Leitungen an. Wenn diese zu hoch sind und die Frequenz auch, läuft alles aus den Rudern.

Habe bei Mir auch gerade einen Versuchsaufbau, mit einer SPI Frequenz von circa "921600" Hz via. Flachbandleitung (ca 30cm) funktioniert einwandfrei.

Ich will "nur" die Kommunikation per SPI verstehen bzw "zum Laufen bringen" - z.B. sollen Analogwerte von einem ATMega8 eingelesen und per SPI an den anderen gesendet werden, dieser wertet sie aus und zeigt sie auf dem PC an etc ...

Am besten wäre es wenn du Dir ein Protokoll ausdenkst. Das beide Seiten kennen und verstehen.
Die physikalischen Parameter bzw. das Verhalten der Schnittstelle kennst Du ja bereits?!.

Was halt noch zu beachten ist.. Wer darf was?!
Soll das eine Multimaster oder eine "Master <-> Slave" Kommunikation werden.

Wer darf Wann senden.
Wer darf Was senden.
 
Zuletzt bearbeitet:
Also ich habe mal ein Display per SPI mit ~ 2MHz Busfrequenz befeuert. Lochraster einerseits, Breadboard andererseits, sonst nur lose Strippen. Bei rund 30cm ging das noch problemlos, obwohl es sogar über den Spec's vom Display lag. Ist also nicht ganz so kritisch, grade wenn niedrigere Bandbreiten ausreichen.
Das war aber auch nur ein Testaufbau. Für wirkliche Projekte mache ich es auch immer so dass ich ein Flachbandkabel nehme. Bei 2,55 Rastermaß bleibt ja jede 2. Leitung quasi ungenutzt (außer man zuppelt die auseinander). Die lege ich denn auf Masse, ob nötig oder nicht. Zur Not, meistens muss man ja nicht so fix unterwegs sein.
 
Hallo Janiiix3, hallo TommyB

Vielen Dank für Eure Antworten => Flachbandkabel, die ungenutzten Adern auf Masse (auch wenn nicht unbedingt nötig) und die Frequenz klein halten ;).

Zuerst möchte ich eine "Master <-> Slave" Kommunikation "zum Laufen bringen", später eine Multimaster (wenn die Master <-> Slave Kommunikation fkt).

mfg

Hero_123
 
Als Master ist maximal der halbe Systemtakt drin, als Slave nur ein viertel (kennen wir alle vom ISP over SPI, gelt?!).

Leitungskapazitäten/-längen sind hier weniger kritisch als zB beim I²C, da hier beide Pegelzustände durch den Pin-Ausgangstreiber des Senders bedient werden - also 'ne Rechteckfunktion (ok, mit Überschwingern und so, aber wir befinden uns hier im einstelligen Megahertz-Bereich). Beim I²C hingegen werden die High-Pegel über einen Pull-Widerstand realisiert - je nach Leitungskapazität/-widerstand hat man da dann recht ausgeprägte Haifischflossen...

Beim SPI kehrt sich die Datenrichtung der Signalleitungen um, wenn ein Master zum Slave wird:

MOSI = Master Out, Slave In
MISO = Master In, Slave Out.

Du verdrahtest also Master und Slave 1zu1. (ggf abgesehen von der /CS (*)).

ABER... Das USI kehrt seine Datenrichtung nicht(!) um - es gibt ein Data In, und ein Data Out. Hier müssen die Leitungen also gekreuzt werden.

Multimaster mit zwei HW-SPI geht.
Multimaster mit zwei USI geht.
Multimaster SPI-USI geht nicht.

Multimaster mit mehr als zwei USI geht nicht wirklich (im Sinne von "jeder gegen jeden").

Multimaster mit mehr als zwei HW-SPI erfordert ein recht spezielles CS-Netz...

(*) und ...
Wer darf Wann senden.
Im "normalen" Master-Slave Betrieb bedient der Master die Clock und MOSI. Jeder Slave muß alle Leitungen tristate halten, solange er nicht selektiert ist. Wird er selektiert, legt er sein Schieberegister-Ausgang (je nach DORD das LSB oder das MSB) aktiv auf MISO.
Sinngemäß gilt das auch beim USI, hier muß das Chip-Select allerdings in Software realisiert werden -> Zeitkritisch.
Soll ein Master durch einen anderen Master selektiert werden können, muß er sich dann wie ein Slave verhalten.
Bei einem Slave wirkt der /CS-Pin automatisch, bei einem Master nur, wenn der Pin Eingang ist.
 
Hi Hero,

Meine Frage - was habe ich bei der HW-Verdrahtung zu beachten (außer die entsprechenden Leitungen MISO, MOSI etc korrekt zu verbinden) - reicht es, die Leitungen einfach zu verbinden (an beiden Platinen anlöten und "gut ist es") oder sollten es geschirmte Leitungen (auf 2 Bastelplatinen?) sein oder verdrillte oder ... was sollte ich da beachten?

Also du benötigst MISO, MOSI, den Datentakt und ganz wichtig GND. Die müssen entsprechend verbunden werden.

Master zum Slave
MISO ------- MOSI
MOSI ------- MISO
Takt ---------- Takt
GND --------- GND

Zwischen den Anschlüssen MISO und MOSI befindet sich in dem Atmel ein 8Bit Schieberegister was mit dem Datentakt getaktet wird.
Du hast also in deinem Fall einen Ring mit 2 enthaltenen 8Bit Schieberegistern.

Du kannst mit Takt und Phase vier verschiedene Übertragungsmodi einstellen. Die müssen zwischen Master und Slave passend sein.

Geschirmte Leitungen würde ich wegen der Kapazität Ader gegen Schirm nicht nehmen. Denk an R/C-Glieder (Tiefpaß).
Nimm notfalls 3 parallele GND-Leitungen und verdrill jede der Signalführungen mit einer GND. Das würde ich notfalls so machen.
Aber bei der kurzen Strecke sollte das auch ohne Verdrallung mit fliegenden Leitungen passen. Nur die Leitungen MISO, MOSI und Datentakt würde ich nicht miteinander verdrillen, da du sonst Übersprechen/Einkopplungen hast und es dir die Daten zersemmeln kann.

Gruß
Dino
 
Was ist mit /CS bzw /SS ? Laut Datenblatt wird die SPI-Hardware im Slave-Mode durch /SS korrekt aktiviert/inaktiviert.
When configured as a Slave, the SPI interface will remain sleeping with MISO tri-stated as long as the SS pin is driven high.
und
When the SPI is configured as a Slave, the Slave Select (SS) pin is always input. When SS is held low, the SPI is activated, and MISO becomes an output if configured so by the user. All other pins are inputs. When SS is driven high, all pins are inputs except MISO which can be user configured as an output, and the SPI is passive, which means that it will not receive Incoming data. Note that the SPI logic will be reset once the SS pin is driven high.
Äh.. wie ist der zweite Teil zu interpretieren?

Irgendein Pin des Masters muß den /SS des Slaves ansteuern.
Grundsätzlich könnte man auch beide /SS verbinden (mit 'nem Pullup), Master ist dann, wer zuerst von Tristate-Eingang auf Low Ausgang schaltet (und anschließend sein Master-Bit setzt). Wobei das immer noch beide gleichzeitig machen könnten...
 
Hallo LotadaC, hallo dino03

Vielen Dank für Eure Hilfe. Ich bin nun doch etwas verwirrt, denn dino03 schreibt:

"Master zum Slave
MISO ------- MOSI
MOSI ------- MISO
Takt ---------- Takt
GND --------- GND"

LotataC hingegen schreibt, die Verbindung ist 1:1.
"Du verdrahtest also Master und Slave 1zu1. (ggf abgesehen von der /CS (*))."


Ich will nur ATMega8 <->ATMega8 (im Moment nur Master - Slave Kommunikation) und auch gemäß Atmel AVR151:
- ist die Verbindung 1:1,
- !SS (PB2) beim Master auf Vcc zu legen ist (mit Widerstand von 1k??)
- Slave ist !SS auf GND zu legen ...

Beide ATMega8 hängen an der selben Spannungsversorgung (sind nur auf jeweils anderen Bastelplatinen).
Leider bekomme ich den 2ten ATMega8 erst in den nächsten Tagen ...

mfg

Hero_123
 
MISO und MOSI müssen gekreuzt werden (wie das bei Multi-Master aussieht kA).

MISO = Master Input Slave Output
MOSI = Master Output Slave Input
 
- !SS (PB2) beim Master auf Vcc zu legen ist (mit Widerstand von 1k??)
Entweder internen Pullup aktivieren oder PB2 auf Ausgang und 'high' auf PB2 ausgeben.

Ansonsten MOSI mit MOSI und MISO mit MISO.
Für Kaskadierung oder Sternschaltung siehe hier.
Für Multi-Master ist SPI eigentlich nicht gedacht (gibt Probleme mit CLK)...
 
Slave ist !SS auf GND zu legen
Damit ist der Slave dauerhaft selektiert. Kannst Du machen, wenn es der einzige Slave sein soll. Es gibt aber AFAIR auch SPI-Bausteine, bei denen die empfangenen Daten erst mit der steigenden /SS-Flanke wirksam werden (zB um die genannte Kaskadierung sinnig zu ermöglichen).

Im Slave-Mode wird die Hardware erst aktiviert, wenn der CS-Pin low ist.
Im Master-Mode ist der Pin erstmal egal - insbesondere für mehrere getrennt selektierbare Slaves brauchst Du eh mehrere Pins die je einen Slave-/SS ansteuern.
Der /SS des Masters kann den Master aber in den Slave-Mode zwingen (löscht das MSTR-Bit in SPCR), und zwar immer wenn /SS (B2) Eingang ist und 'n low-Pegel draufgelegt wird. Das mußt Du nicht nur beachten, wenn Du einen zum Slave selektierbaren Master haben willst, sondern auch, wenn Du den Pin ganz anders nutzt (als Taster oder was auch immer).
Für Multi-Master ist SPI eigentlich nicht gedacht (gibt Probleme mit CLK)...
Ich sehe eher Probleme bei der Master-Arbitrierung. Grundsätzlich sind alle Teilnehmer Slave, und damit Tristate auf ihren Sende-Leitungen (auch der Clock). Die Master-Absicht müßte erstmal bei allen anderen Teilnehmern angemeldet, und von diesen abgenickt werden.
 
Ich sehe eher Probleme bei der Master-Arbitrierung.
Bei zwei Teilnehmern kann man das per Software hinkriegen.
Bei mehr als zwei Teilnehmern müssen alle SlaveSelect-Leitungen verbunden werden. Das funktioniert nur, wenn nur einer Master sein kann und die anderen als Slaves kaskadiert werden.
Sonst würden ja alle Slaves gleichzeitig auf der gleichen Leitung senden...
 
müssen alle SlaveSelect-Leitungen verbunden werden
Nein. Jeder Teilnehmer, der durch irgendeinen anderen Teilnehmer selektiert werden können soll, muß sein /SS von diesem angesteuert bekommen, aber eben nicht durch dessen /SS, sondern über einen anderen Pin. Anders formuliert:
Für jeden Teilnehmer, der Slave sein könnte, brauchst Du ein /SS-Netz. Dieses ist high via Pullup, jeder potentielle Master kann das Netz runterziehen (aber eben nicht mit seinem /SS-Pin). Zusätzlich muß aber sichergestellt werden, daß im gesamten Bus nur ein Teilnehmer gleichzeitig auf Master schaltet. Selbst wenn jeder potentielle Master alle anderen /SS-Netze überwacht, kann er nicht ausschließen, daß er und ein anderer Teilnehmer gleichzeitig denselben dritten Teilnehmer als Slave selektieren.
Wie gesagt: wäre ...
ein recht spezielles CS-Netz
 
Oder per Stern. Eine MS (Master Select) wenn man so will. Die verbindet alle Master die im Idle TriState sind (Bus, SS's und MS). Will ein Master was senden MS prüfen (Bus frei), MS hoch ziehen (blockt andere Master), normal agieren. Och, machen könnte man viel. Aber das ist jetzt etwas vorgegriffen, wenn nicht sogar :offtopic: ;)
 
Nein. Jeder Teilnehmer,...
Das will ich sehen. ;)
Zeichne mal ein Netz mit fünf Teilnehmern, von denen jeder Master werden kann.
Externe Bauelemente sind natürlich nicht erlaubt.
(Ok. Drei Teilnehmer reichen auch erstmal ;))
 
Also weiterhin OT...

Du hast ja selbst auf den Wikipedia-Artikel hingewiesen - den also als Ausgangspunkt:
MultiSPI_1.png
Teilnehmer 1 ist Master, 3..5 sind Slaves.
Edit: Das /CS1-Netz oben ist natürlich /CS2...

Jetzt muß das nur konsequent erweitert werden...
MultiSPI_2.png
Grundsätzlich sind alle Teilnehmer Slaves. Ob die /CS-Leitungen über den Pullup des jeweiligen /SS-Pins hochgezogen werden können, weiß ich nicht. Also eventuell doch je einen externen Pullup je /CS-Netz.
Die /CS-Pins sind im Idle tristate (also Low-Eingang), soll einer aktiviert werden, schaltet er auf Gnd (Low-Ausgang).
Das Problem ist nun, auszuschließen daß mehrere Teilnehmer je irgendein /CS aktivieren, insbesondere gleichzeitig...

P.S.:
Das will ich sehen. ;)
Zeichne mal
So, ich hab gezeichnet - Du lötest :aetsch:
 
Zuletzt bearbeitet:
  • Like
Reaktionen: TommyB
Hab mir das mit MISO/MOSI mal im Datenblatt (Blockschaltbild vom SPI) angesehen.

Also je nach Modus (Master/Slave) ist das 8Bit-Schieberegister anders mit MISO und MOSI verbunden.
Aha ... ( lang ists her ;) ) also keine feste Zuordnung des Registers zu den Pins.

Master: MISO -->-- Schieberegister -->-- MOSI
Slave: MOSI -->-- Schieberegister -->-- MISO

Dann muß also bei 2 Chips doch 1:1 verkabelt werden.

Gruß
Dino
 
Wie bereits gesagt: Die AVR-SPI-Hardware bestimmt die Datenrichtung der drei Pins, und zwar abhängig vom Master-Bit.
Wie, außerdem, gesagt: Geht (ist ?) bei einem (AVR-) Master ein als Eingang gesetzter /SS-Pin low, wird automatisch das Master-Bit gelöscht, der Master zum Slave. Geht der Pin wieder high, bleibt der AVR weiterhin Slave - das Bit muß also (bei Bedarf) manuell wieder gesetzt werden, um den Master wiederherzustellen.

Und auch nochmal: Bei USI im SPI-Mode kehrt sich die Datenrichtung nicht um (strenggenommen gibts da gar keinen Master - Clock und /SS sind (weitgehend) in Software zu umzusetzen) - es gibt einen Ausgangs- und einen Eingangspin, die fest mit dem Schieberegister verbunden sind (daraus folgt auch, daß dort immer MSB-first übertragen wird).

Jaja, wir werden (auch) langsam alt...
 
Jetzt muß das nur konsequent erweitert werden...
Ich erhöhe die Teilnehmerzahl auf zwölf… ;)

Wenn ich davon ausgehe, daß kein Teilnehmer außer einem Master mehr als drei bzw. vier Pins für SPI frei hat, führst Du das SPI-Prinzip mit Deiner Schaltung ad absurdum.

Wenn ich schon Tmax + 3 Pins an jedem Controller brauche, dann spendiere ich noch zwei für I2C, mache darüber die Arbitrierung und benutze die anderen als Parallelbus, über den ich dann die Daten um ein vielfaches schneller als die maximale SPI-Datenrate übertragen kann.

Die von @TommyB vorgeschlagene Lösung braucht übrigens nur eine Leitung mehr (unabhängig von der Anzahl der Teilnehmer (ist damit aber auch kein reines SPI mehr)).
 
Du hattest ja selbst bereits darauf hingewiesen, daß SPI nicht wirklich auf Multimaster ausgelegt ist. Bei zwei Teilnehmern ist es noch halbwegs sinnig umsetzbar (bzw auch bei einem Netz mit einem Master, mehreren Slaves und einem übergeordnetem Master (der seinerseits nur den Master erreicht) - genau dafür ist ja die Auswirkung von /SS auf das MSTR-Bit in SPCR vorgesehen.
Tmax + 3 Pins an jedem Controller
Nur an jedem, der jeden anderen Teilnehmer als Slave adressieren können soll. Zusätzlich bleibt das Problem zu erkennen, wann der Bus frei ist. Das kann über die /CS-Netze geschehen, reicht aber nicht unbedingt.
Die von @TommyB vorgeschlagene Lösung braucht übrigens nur eine Leitung mehr (unabhängig von der Anzahl der Teilnehmer (ist damit aber auch kein reines SPI mehr)).
Versteh ich nicht. Im Stern muß für jeden Slave ein eigenes /CS-Netz existieren - damit er unabhängig von anderen Slaves selektiert werden kann. Damit bist Du bei T(slave-)max+3...
Das ist auch die Ausgangssituation aus Deinem Link (der feste Master ist nie Slave).

Natürlich kannst Du immer ein eigenes System Stricken (und/oder vorhandene Hardware-Busse einbeziehen/kombinieren.)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)