SPI treiber IC

Hilft dir die App-Note von TI: 
http://www.ti.com/lit/an/slyt441/slyt441.pdf ?

Danke für die antworten.
Vom Prinzip her habe ich auf jeder slave Platine 2 Buchsen zum 
durchscheinen der SPI Signale.  Es wäre also schön eine Art Verstärker 
ic zu haben durch den die Signale ebenfalls durchgeschliffen werden. 
Ansonsten wäre ich ja trotzdem auf eine gewisse Gesamtlänge der gesamten 
buskette beschränkt.

Theoretisch ja. Dann bräuchte ich allerdings 2 ics auf jedem slave. eins 
zum empfangen und eins zum weiterseden um die Kette quasi von slave zu 
slave neu anzutreiben.  Mir wäre es halt lieber nur ein ic zu haben 
durch das der Spi Bus durchgeht wegen dem platz und weil man dann 
Bauteile spart.

evtl solltest du dir nochmals überlegen, ob SPI die richtige Wahl ist 
mit deinen Anforderungen.

Stefan S. schrieb:
> Der Bus ist eine offene kette
Du hast also nur einen Sender (MOSI) und willst von den Slaves nichts 
empfangen (MISO)?
Hast du eine Daisy-chain, oder hängen die Slaves parallel am Bus?
Falls das zweitere: wie wird die Busarbitrierung (SlaveSelect) gemacht?

Michael .. schrieb:
> evtl solltest du dir nochmals überlegen, ob SPI die richtige Wahl ist
> mit deinen Anforderungen.
Insbesondere das Empfangen eines Bits stelle ich mir vom Timing her 
sehr spannend vor, wenn da zig Treiber das Taktsignal immer weiter 
verzögern und das MISO-Signal auf dem Rückweg nochmal verzögert wird...

Gut dass wir mal drüber gesprochen haben danke für die antworten das hat 
mich schon echt weitergebracht.  Tatsächlich müssten die slaves nur 
Daten empfangen je nachdem wie ich es nun auslegen.

Aber Ursprünglich wollte ich auch Daten einmalig am start der siftware 
von den slaves an den Master zurücksenden.
Also wenn man einen neuen slave anstöpselt fragt der Master nach dem 
einschalten über den Bus an ob ein neuer slave da ist und der neue slave 
antwortet dann. Daraufhin bekommt er eine Adresse vom master zugewiesen.
Das war der ursprüngliche Gedanke.

Der Controller kann aber auch i2c. Atmega32

Ne keine daisy chain. SS brauch ich nicht weil ich mit Adressen arbeiten 
möchte

Stefan S. schrieb:
> Ne keine daisy chain. SS brauch ich nicht weil ich mit Adressen arbeiten
> möchte

Erkundige dich bitte einmal wie SPI funktioniert.

und dann kommen wir zum Punkt zurück

Michael .. schrieb:
> evtl solltest du dir nochmals überlegen, ob SPI die richtige Wahl ist
> mit deinen Anforderungen.

Stefan S. schrieb:
> Tatsächlich müssten die slaves nur
> Daten empfangen je nachdem wie ich es nun auslegen.

Stefan S. schrieb:
> ob ein neuer slave da ist und der neue slave
> antwortet dann.

??? das verstehe ich nicht

Der Slave soll nur empfangen aber auch antworten?

https://de.wikipedia.org/wiki/Serial_Peripheral_Interface
Wird sie gegen Masse gezogen, ist der jeweilige Slave aktiv und 
„lauscht“ an MOSI, so legt er seine Daten im Takt von SCK an MISO.

Irgendwie braucht es dann auch MISO

Ja der ss wird selbstverständlich genutzt aber alle hängen parallel 
dran.

Es gibt mehrere mölglichkeiten wie ich jetzt weitermache. Entweder die 
adressen sind statisch und werden von mir beim programmieren festgelegt, 
dann müssen die slaves wirklich nur daten empfangen. Oder eben mein 
ursprünglicher plan war, die adressen werden vom master vergeben dann 
muss aber ein neu hinzugekommener slave auch dem master mitteilen dass 
er neu ist und noch eine adresse braucht.

Wie ihr erkannt habt könnte das dann timing probleme geben mit der 
rückantwort vom slave zum master

Ich empfehle auch ein Studium der Unterlagen zum SPI. Es funktioniert 
nicht so wie du dir das vorstellst.
Ein SPI Slave hat keine Adresse. Ein SPI Slave ist nur ein 
Schieberegister von 1, 2, 3,4 byte Laenge. Und vielleicht gehorchen sie 
einem gemeinsamen Timing, vielleicht auch nicht. Man muss die einzelnen 
Timings genau anschauen, undd darf nichts voraussetzen.

Mit etwas Glueck kann man sie, falls identisch sogar in Serie haengen. 
Wenn sie denn einen durchgeschleiften Ausgang haben.

Stefan S. schrieb:
> Es gibt mehrere mölglichkeiten wie ich jetzt weitermache. Entweder die
> adressen sind statisch und werden von mir beim programmieren festgelegt,
> dann müssen die slaves wirklich nur daten empfangen. Oder eben mein

 Das geht.

> ursprünglicher plan war, die adressen werden vom master vergeben dann
> muss aber ein neu hinzugekommener slave auch dem master mitteilen dass
> er neu ist und noch eine adresse braucht.

 Aber das geht mit Sicherheit nicht, zumindest nicht mit SPI und ohne
 das jeder Slave seine eigene CS-Leitung hat.

Dampf T. schrieb:
> Ich empfehle auch ein Studium der Unterlagen zum SPI. Es funktioniert
> nicht so wie du dir das vorstellst.

Doch das geht sicherlich, man muss nur wissen wie

> Ein SPI Slave hat keine Adresse. Ein SPI Slave ist nur ein

Da meine slaves genau wie der master ein atmega sind, kann ich ihnen 
sehr wohl sagen, dass sie nur daten verwerten sollen, wenn die 
adressbyte auch ihrer adresse entspricht.
Da ich das datenprotokoll selbst festlege passt das schon :-)

> Mit etwas Glueck kann man sie, falls identisch sogar in Serie haengen.

Ich bin Gustav Gans der elektrotechnik!

Ok, dann wuerd ich alle in Serie haengen. Das MDI auf das MDO und das 
MDO auf des MDI des jeweils benachbaren, und das Ende wieder zurueck. 
Macht bei differentiellen Treibern insgesammt pro Station ein Paar. zB 
einen RS422 Treiber, zB einen AD489

Uups, den Clock brauchts ja auch noch. also noch  ein einzelner Treiber, 
der geht dann durch.

Stefan S. schrieb:
> Der Bus ist eine offene kette mit Twisted pair netzwerkleitungslängen
> von mehreren Metern zwischen den Slaves.

Da ist SPI mit Abstand die schlechteste Wahl. Insbesondere das Slave-SPI 
der AVRs ist gelinde gesagt suboptimal. Da muß der Master schon Pausen 
einlegen, damit keine Daten verloren gehen.

Die ultimative Lösung wäre CAN (AT90CAN128, ATmega64M1). Einfach die 
Daten in den Sendepuffer stellen bzw. aus dem Empfangspuffer lesen. Um 
den ganzen Übertragungsschrunz kümmert sich die Hardware.

Die 2.beste Lösung wäre RS-485. Da kann man auch adressieren 
(9Bit-Mode).
Der SW-Aufwand ist natürlich höher, als bei CAN.

Stefan S. schrieb:
> Da meine slaves genau wie der master ein atmega sind, kann ich ihnen
> sehr wohl sagen, dass sie nur daten verwerten sollen, wenn die
> adressbyte auch ihrer adresse entspricht.
> Da ich das datenprotokoll selbst festlege passt das schon :-)

 Verwertung der Daten ist eine Sache, aber sobald deine Mega selektiert
 ist, werden am MISO-Pin synchron zum Clock Daten ausgegeben.
 Wenn die MEGA aber nicht selektiert ist, werden die Daten am MOSI-Pin
 einfach nicht empfangen und somit nicht ausgewertet.
 Also, entweder kann man jede MEGA einzeln selektieren oder die MEGAs
 werden alle selektiert, MISO bleibt offen und MEGAs können nur
 hören aber nicht antworten.


>> Mit etwas Glueck kann man sie, falls identisch sogar in Serie haengen.
>
> Ich bin Gustav Gans der elektrotechnik!

 Schwer.

Stefan S. schrieb:
> Da ich das datenprotokoll selbst festlege passt das schon :-)
Es wäre aber prinzipiell eine überaus schlechte Idee, ganz ohne einen 
Frame-Sync (z.B. über einen SS) fahren zu wollen. Ein einziger EMV-Spike 
auf der Taktleitung sorgt dafür, dass deine Kette ab diesem Zeitpunkt um 
1 Bit "versetzt" bist (evtl. auch nur "teilweise").

Nur, wenn du durch das Deaktivieren des SS zwischendurch mal wieder alle 
Slaves auf einen neuen definierten Start "ausrichtest" kannst du wieder 
aufsynchronisieren.

Die Holzhammermethode ist, den Takt zwschendurch mal für ein paar ms 
"auszusetzen" und im Slave daraus ein Timeout zur Frame-Synchronisation 
zu gewinnen. Das ist aber letztlich nur die lange Schreibweise für 
"Murks".

Stefan S. schrieb:
> Ich bin Gustav Gans der elektrotechnik!
Für jede Gans kommt mal Martini oder Weihnachten...

Ich wuerd auch einen seriellen asynchronen Differentialbus wie RS422, 
oder RS485 verwenden. Das Timing ist weniger streng, und das Protokoll 
einfacher.

Christian schrieb:
> Du könntest RS422 Treiber verwenden. Dass du dann SPI darüber machst ist
> denen ja ziemlich egal.

Die idee finde ich ganz gut.

Rs485 fände ich aber nochmal besser wenn das auch geht weil ich da bis 
zu 32 slaves anschließen könnte. Ich hab ja jetzt schon 5 und da kommen 
sicher noch welche hinzu. Rs422 gehen nur 10

> Stefan S. schrieb:
>> Ich bin Gustav Gans der elektrotechnik!
> Für jede Gans kommt mal Martini oder Weihnachten...

Yamyam lecker :)

Eine Frage der Treiber, Es gibt Lowpower treiber, von denen gehen mehr.

Nur keine 75176 verwenden, das sind Grossvaters Stromfresser.