Hallo, in diesem alten Beitrag wurde ja schon über Vor/Nachteile CAN oder SPI diskutiert: Beitrag "CAN Bus Low speed Nutzdatenrate" Möchte jetzt doch mal konkret überlegen, ob SPI bei diesm Projekt machbar ist. Folgende Konfiguration: 1 Master MCU und bis zu 16 Slaves ohne Terminierung am Ende. Busleitung Länge ist ca 50 cm. Verbindeung der einzelnen Geräte über Phoenix Contact ICS Busverbinder (s.Anlage) Jeder Teilnehmer soll einen Treiber 74HC125 für die 4 SPI Signale MOSI MISO SCLK _SS bekommen. Gemeinsame Signal SCLK _SS MOSI und MISO Signal für alle Slaves! Alle Parallet verbunden! Jeder Slave schaltet seinen MISO Ausgang nur aktiv, wenn er angesprochen wird (über Software) Folgende Probleme sehe ich: 1. Einiger Hersteller des 74HC125 sagen, ein Ausgang kann max. 10 LS-TTL Eingänge treiben, ander sagen 15 Stück. Entspicht ein Eingang des 74HC125 einem LS-TTS Eingang ? 2. Um Probleme mit Reflexionen zu vebeiden, sollte ja bei 50 cm Buslänge die Rise/Fall time insbesondere des SCLK signales nicht zu schnell sein. Laut Datenblatt hat der 74HC125 ca. 5 ns, was schon in den kritischen Bereich der maximelen Buslänge kommt. Was kann man machen ? Anderen langsameren Treiber Chip ? Gruß Dirk
Angehängte Dateien:
-
Busverbinder2202891.jpg
14 KB
:
Bearbeitet durch User
Dirk F. schrieb: > Hallo, > in diesem alten Beitrag wurde ja schon über Vor/Nachteile CAN oder SPI > diskutiert: > Beitrag "CAN Bus Low speed Nutzdatenrate" > > Möchte jetzt doch mal konkret überlegen, ob SPI bei diesm Projekt > machbar ist. > Folgende Konfiguration: > 1 Master MCU und bis zu 16 Slaves ohne Terminierung am Ende. > Busleitung Länge ist ca 50 cm. > Verbindeung der einzelnen Geräte über Phoenix Contact ICS Busverbinder > (s.Anlage) Sternförmiger VErbindung zum Master? > Jeder Teilnehmer soll einen Treiber 74HC125 für die 4 SPI Signale MOSI > MISO SCLK _SS bekommen. > Gemeinsame Signal SCLK _SS MOSI und MISO Signal für alle Slaves! Alle > Parallet verbunden! > Jeder Slave schaltet seinen MISO Ausgang nur aktiv, wenn er angesprochen > wird (über Software) Nö, Hardware, nämlich das SS Signal. > Folgende Probleme sehe ich: > 1. Einiger Hersteller des 74HC125 sagen, ein Ausgang kann max. 10 LS-TTL > Eingänge treiben, ander sagen 15 Stück. Wer hat heute noch LS-TTL? Auch du nicht. Bei HC spielt eher die Kapazität eine Rolle. Wenn man nicht mit 10 Mbit/s++ arbeiten will, ist das weniger ein Problem. Da darf ein Signal auch mal 50ns Anstiegszeit haben. > Entspicht ein Eingang des 74HC125 einem LS-TTS Eingang ? Nö. > 2. Um Probleme mit Reflexionen zu vebeiden, sollte ja bei 50 cm Buslänge > die Rise/Fall time insbesondere des SCLK signales nicht zu schnell sein. > Laut Datenblatt hat der 74HC125 ca. 5 ns, was schon in den kritischen > Bereich der maximelen Buslänge kommt. > Was kann man machen ? Anderen langsameren Treiber Chip ? Auch das. Ober aber hier Serienterminierung, du hast je zu jedem Slave eine einzelne Leitung, siehe Wellenwiderstand.
Falk B. schrieb: > Auch das. Ober aber hier Serienterminierung, du hast je zu jedem Slave > eine einzelne Leitung, siehe Wellenwiderstand. Nein, alle parallel. Deshalb Serienterminierung nicht möglich. Falk B. schrieb: >> Entspicht ein Eingang des 74HC125 einem LS-TTS Eingang ? > Nö. Anders gefragt: Wie viele 47HC125 Eingänge kann ein 74HC125 Ausgang treiben ? Falk B. schrieb: > Sternförmiger VErbindung zum Master? Nicht möglich. Falk B. schrieb: > Nö, Hardware, nämlich das SS Signal. Nein, alle bekommen das SS Signal gemeinsam. Alle Slaves empfangen zuerst ein Adress Byte. Wenn das Byte mit der eigenen Adress übereib stimmt, dann schaltet der Slave seinen Ausgang aktiv für die nächste Datenübertragung.
Dirk F. schrieb: > Falk B. schrieb: >> Auch das. Ober aber hier Serienterminierung, du hast je zu jedem Slave >> eine einzelne Leitung, siehe Wellenwiderstand. > > Nein, alle parallel. > Deshalb Serienterminierung nicht möglich. Das widerspricht aber deiner Aussage "Jeder Teilnehmer soll einen Treiber 74HC125 für die 4 SPI Signale MOSI MISO SCLK _SS bekommen." Mach mal eine gescheite Skizze. > Anders gefragt: Wie viele 47HC125 Eingänge kann ein 74HC125 Ausgang > treiben ? Wenn man Zeit hat, sehr viele. 10, 20, 30. Die kapazitive Last der Eingänge + Verkabelung muss durch den Ausgang umgeladen werden. Das dauert halt. Die meisten Angaben in den Datenblätter sind für 50pF Last. Ein Eingang hat um die 5pF. Ein halber Meter Kabel je nach Kabeltyp um die 20-50pF. >> Sternförmiger VErbindung zum Master? > Nicht möglich. Ich bin verwirrt. Wie soll dein Aufbau aussehen. Siehe oben. Mach ne Skizze. > Nein, alle bekommen das SS Signal gemeinsam. > Alle Slaves empfangen zuerst ein Adress Byte. > Wenn das Byte mit der eigenen Adress übereib stimmt, dann schaltet der > Slave seinen Ausgang aktiv für die nächste Datenübertragung. Dann ist es aber kein normales SPI. Ob das so sinnvoll ist? Dann doch lieber I2C oder CAN.
Ahhh, die Diskussion hatten wir doch schon mal. Warum soll CAN jetzt nicht ausreichen? Versuch nicht das Rad neu zu erfinden, da kommt nur ein krummes Irgendwas-Eck raus.
Falk B. schrieb: > Ahhh, die Diskussion hatten wir doch schon mal. Warum soll CAN jetzt > nicht ausreichen? Versuch nicht das Rad neu zu erfinden, da kommt nur > ein krummes Irgendwas-Eck raus. > Da überlege ich doch auf SPI umzusteigen. Tu das! Aber das hast Du doch delber in dem anderen Thread gesagt ? Skizze kommt.
Dirk F. schrieb: > Jeder Teilnehmer soll einen Treiber 74HC125 für die 4 SPI Signale MOSI > MISO SCLK _SS bekommen. Dirk F. schrieb: > Jeder Slave schaltet seinen MISO Ausgang nur aktiv, wenn er angesprochen > wird (über Software) Ob das funktioniert? SPI Slaves werden per Hardware am MOSI- Ausgang bereits aktiv wenn das SS-Signal low wird. In deiner Konfiguration ergäbe das einen Buskampf, das wird dich nicht glücklich machen da alle Slaves sich erst mal angesprochen fühlen und aktiv werden. Einziger Ausweg ist, die MOSI Pins aller Slaves explizit zu tri-staten und durch die von dir vorgesehene Adressierung einen der MISOs per Programmfluss zu aktivieren. Dabei geht zwar das erste gesendete Byte vom Slave warscheinlich kaputt aber das ist sowieso meist nicht relevant.
Dirk F. schrieb: >> Da überlege ich doch auf SPI umzusteigen. > Tu das! > > Aber das hast Du doch delber in dem anderen Thread gesagt ? Ja, aber da kannte ich nicht alle Randbedingungen! Da war weder von diesen Starkstromsteckern noch von nicht sternförmigem Anschluss oder gar verkorkstem SPI die Rede! Wenn man 16 normale SPI-Slaves auf einer Platine platziert, kann man das ganz normal machen und dabei auch sehr hohe Datenraten erzielen. Klar braucht es dafür eine Parallelterminierung des Busses und auch eine linienförmige Signalführung mit minimalen Stichleitungen.
uff basse schrieb: > Einziger Ausweg ist, die MOSI Pins aller > Slaves explizit zu tri-staten und durch die von dir vorgesehene > Adressierung einen der MISOs per Programmfluss zu aktivieren. > Dabei geht zwar das erste gesendete Byte vom Slave warscheinlich > kaputt aber das ist sowieso meist nicht relevant. Genau so war es gedacht.
Dirk F. schrieb: > Skizze als Anlage Naj, ist nix außergewöhnliches. Aber du hat an jedem Slave 2 Stecker, naja. Den Bus kann und muss man parallel terminieren. Die Eingangstreiber an jedem Slave sind sinnlos, denn die sind nicht besser als die normalen Digitaleingänge der ICs dahinter. Bestenfalls der Ausgangstreiber mit Tristate für MISO ist sinnvoll. Aber wie gesagt, da fehlen noch die 16 SS-Signale. Wozu eigentlich diese komischen Stecker, wenn das alles so kompakt zusammen steckt? UNd wozu zwei mutmaßliche Stecker pro Slave? Da könnte man einfach ein Flachbandkabel mit ausreichend Steckern drauf nutzen.
Hm - viele Driver. Warum nicht alle Driver an den Slaves weglassen und jeweils am Ende einer Kette terminieren?
Falk B. schrieb: > Die Eingangstreiber an jedem Slave sind sinnlos, denn die sind nicht besser > als die normalen Digitaleingänge der ICs dahinter. OK, einverstanden. Falk B. schrieb: > Aber wie gesagt, da > fehlen noch die 16 SS-Signale Du hast es noch nicht verstanden. Ein gemeinsames SS Signal für alle. Falk B. schrieb: > Wozu eigentlich diese komischen Stecker, > wenn das alles so kompakt zusammen steckt? Das System ist ähnlich einer SPS. Die Baugruppen (Slave 1...16) werden nur nach Bedarf angebaut. Jeder Slave hat ein Modulgehäuse mit einem Busverbinder auf NS35 Nirmschine. Deshalb ist eine Endterminierung nicht ohne weiteren Aufwand möglich. Gruss Dirk
(prx) A. K. schrieb: > Das wäre beispielsweise der CD4503. Zu schwacher Ausgangstreiber (Datenblatt): 1 TTL Output Driver capacity
Dirk F. schrieb: > Zu schwacher Ausgangstreiber (Datenblatt): 1 TTL Output Driver capacity Hier ist kein einziger TTL Eingang beteiligt, weshalb die Rechnung darüber sinnlos ist. Solche Angaben waren vor Urzeiten mal sinnvoll, sind es heute nicht mehr. Allerdings wird die Flanke durch die kapazitive Belastung durch Eingänge, Stecker und Leitung entsprechend langsamer. Die Obergrenze beim Fanout ergibt sich deshalb aus der Mindestflankensteilheit der angeschlossenen Eingänge.
:
Bearbeitet durch User
Dirk F. schrieb: > Um Probleme mit Reflexionen zu vebeiden, sollte ja bei 50 cm Buslänge > die Rise/Fall time insbesondere des SCLK signales nicht zu schnell sein. Wichtiger ist eigentlich, dass die Leitung entsprechend ihrem Wellenwiderstand terminiert wird. Die Rise und Fall Zeiten legst du durch Auswahl der Logikfamilie fest. Die 74HC sind schon relativ langsam. Dirk F. schrieb: > Wie viele 47HC125 Eingänge kann ein 74HC125 Ausgang treiben ? Beliebig viele, weil das eine kapazitive Last ist. Je mehr Last, umso geringer die erreichbare Schaltfrequenz.
Beitrag #7296385 wurde vom Autor gelöscht.
Hallo zusammen, vielen Dank für die kreativen Antworten. Die Vorteile von SPI gegenüber CAN sehe ich so: - Geringer bis kein Overhead Nutzdaten/Gesamtdaten - Höhere Taktraten möglich - Größere Auswahl an MCUs ohne CAN. SPI hat fast jeder. Werde mal den ersten Prototypen mit SPI aufbauen und Testen. Gruß Dirk
Dirk F. schrieb: >> Aber wie gesagt, da >> fehlen noch die 16 SS-Signale > Du hast es noch nicht verstanden. > Ein gemeinsames SS Signal für alle. Das habe ich schon verstanden, halte es aber für ein unbrauchbares Konzept. Du vermischst in Hardware mit Softwareaddressierung. > Das System ist ähnlich einer SPS. Die Baugruppen (Slave 1...16) > werden nur nach Bedarf angebaut. Jeder Slave hat ein Modulgehäuse mit > einem Busverbinder auf NS35 Nirmschine. > Deshalb ist eine Endterminierung nicht ohne weiteren Aufwand möglich. Doch, die muss man halt immer ans Ende schrauben. So wie man den Terminator ans Ende vom CAN-Bus stecken muss.
Angehängte Dateien:
Stefan F. schrieb: > Beliebig viele, weil das eine kapazitive Last ist. Je mehr Last, umso > geringer die erreichbare Schaltfrequenz. Nicht ganz. Wenn Eingänge mangels Schmitt-Trigger Charakteristik eine Mindestflankensteilheit erwarten, ergibt sich daraus eine Grenze.
Braucht nicht jeder SPI Slave einen eigenes SS-Signal ? Oder habe ich da nicht richtig aufgepasst………
Hä… schrieb: > Braucht nicht jeder SPI Slave einen eigenes SS-Signal ? > Oder habe ich da nicht richtig aufgepasst……… Ja, um seine interne SPI Logic nach jedem Flankenwechsel zu synchronisieren. Und es bekommt ja jeder Slave sein SS Signal, nur halt alle gleichzeitig. Aber senden auf MISO mach dann noch keiner, weil es in Software unterbunden wird (Ansteuerung des Treibers) , somit auch keine Datenkollision auf MISO. Erst wenn sich ein Slave angesprochen fühlt, schaltet er seinen MISO auf Ausgang und sendet beim zweiten Byte seine Daten zurück an den Master.
Welches Problem soll hier eigentlich gelöst werden, das mit einer UART und RS485 nicht auch gelöst werden könnte?
DerEinzigeBernd schrieb: > Welches Problem soll hier eigentlich gelöst werden, das mit einer UART > und RS485 nicht auch gelöst werden könnte? UART: Hat nicht die Geschwindigkeit von SPI RS485: Ja wäre eine Alternative.
Dirk F. schrieb: > UART: Hat nicht die Geschwindigkeit von SPI Um was für eine Rate geht es denn hier? Eine UART ist eine Hardware-Komponente, die ein Protokoll implementiert, das die Grundlage dessen darstellt ... > RS485: Ja wäre eine Alternative. ... was man in diesem Kontext als RS485 zu bezeichnen pflegt. Also UART mit RS485 als physikalischer Schnittstelle.
:
Bearbeitet durch User
(prx) A. K. schrieb: >> UART: Hat nicht die Geschwindigkeit von SPI > > Um was für eine Rate geht es denn hier? Der OP will 16 Sensoren a 4 Byte im 10ms Raster abfragen. Beitrag "CAN Bus Low speed Nutzdatenrate"
Falk B. schrieb: > Der OP will 16 Sensoren a 4 Byte im 10ms Raster abfragen. Das wäre eine Nettodatenrate von tatsächlich 6400 Byte/sec. Und dafür soll 'ne UART zu langsam sein? Was soll das denn für 'ne UART sein?
Dirk F. schrieb: > Falk B. schrieb: >> Aber wie gesagt, da >> fehlen noch die 16 SS-Signale > Du hast es noch nicht verstanden. > Ein gemeinsames SS Signal für alle. Was an deinem Aufbau ist dann SPI. SPI verwendet individuelle SS-Signale um jeden einzelnen Slave bei Bedarf zu aktivieren und damit auch den MISO-Ausgang von High-Z auf Push-Pull umzuschalten.
Wolfgang schrieb: > SPI verwendet individuelle SS-Signale > um jeden einzelnen Slave bei Bedarf zu aktivieren Gab es da nicht auch so ein broad casting, das alle reagieren und sich die slaves selber anhand des Protokolls aussuchen, wann sie reagieren?
DerEinzigeBernd schrieb: >> Der OP will 16 Sensoren a 4 Byte im 10ms Raster abfragen. > > Das wäre eine Nettodatenrate von tatsächlich 6400 Byte/sec. Und dafür > soll 'ne UART zu langsam sein? Was soll das denn für 'ne UART sein? Der OP ist, ähhhh, etwas akademisch eingestellt. Er will unbedingt das Rad neu erfinden. Viel Spaß dabei!
Hallo zusammen, so der Prototyp ist fertig aufgebaut. Master + 4 Slaves. System läuft über Stunden ohne CRC Fehler in beiden Richtungen. SPI Busfrequenz = 1 MHz (Max 4 MHz getestet) SPI Clock Anstiegszeit gemessen ca. 10 ns. Alles bestens.
Dirk F. schrieb: > Nein, alle bekommen das SS Signal gemeinsam. Dirk F. schrieb: > System läuft über Stunden ohne CRC Fehler in beiden Richtungen. > SPI Busfrequenz = 1 MHz (Max 4 MHz getestet) Solange nicht jeder Slave sein eigenes Slave Select Signal bekommt, sondern den Ausgang (MISO) über das Protokoll gesteuert aktiviert, ist es kein Standard-SPI.
Dirk F. schrieb: > Ja dann ist es halt Sonder SPI Dann ist es aber kein SPI mehr, wie von Motorola unter der Bezeichnung "Serial Peripheral Interface (SPI)" seinerzeit definiert, sondern eine Sonderlocke, für die du dir einen eigenen Namen ausdenken solltest, damit es nicht zu Verwechselungen mit dem bereits als SPI festgelegten Interface kommt.
Rainer W. schrieb: > Solange nicht jeder Slave sein eigenes Slave Select Signal bekommt, > sondern den Ausgang (MISO) über das Protokoll gesteuert aktiviert, ist > es kein Standard-SPI. So arbeiten z.B. MCP23S17 von Microchip. Die haben drei Adresselinien wie auch MCP23017 für I2C. Deshalb können auf einer ~SS - Linie bis acht MCP23S17 sitzen. MCP23S17 brauchen immer 3 Bytes: zuerst wird Adresse übertragen, dann Registeradresse innerhalb von MCP23S17, und danach wird Byte geschrieben oder gelesen. Microchip nennt das auch "SPI".
:
Bearbeitet durch User
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.