Hallo, Ich suche ein Treiber / Verstärker IC für die avr SPI Schnittstelle. Der Bus ist eine offene kette mit Twisted pair netzwerkleitungslängen von mehreren Metern zwischen den Slaves. 5V Stehen am Master Und slaves zur Versorgung. Gruß Stefan
Du könntest RS422 Treiber verwenden. Dass du dann SPI darüber machst ist denen ja ziemlich egal.
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.
Dann mach es doch genau wie in der AN von TI - da sind sogar schon die ICs genannt, die du brauchst. Und zusätzlich haben die schon an den Transientenschutz gedacht. Was brauchst du mehr?
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Ne keine daisy chain. SS brauch ich nicht weil ich mit Adressen arbeiten möchte
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch Moderator
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.
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.