Hallo, hab bis zu 30 Platinen ca. 200mm lang mit je einem Controller drauf. Die sollten alle Slaves sein, und über ein Busssystem mit dem Master kommunizieren. Welches Bussystem würdet Ihr bevorzugen? Braucht der Bus eine Verstärkung auf jeder Platine? Es sind schon mehrere Meter, die das ganze Konstrukt dann hat. Gruß Tweaker
Kommt drauf an, wenn es schnell sein soll und du genügend Platz hast ist ein 8/16/32 Bit parallel-Bus immer gut :). Wenn es nicht so schnell sein soll kann es auch RS232 auf niedriger Baudrate bzw. SPI mit niedrigen Takt verwendet werden.
Bisher hatte ich I2C bzw. TWI im Kopf, würde aber etwas Aufwand mit Autoadressierung und Verstärkung bedeuten. Grundsätzlich bin ich mir bei der Auswahl nicht so sicher. Je weniger Verkabelung desto besser... Hab 24V und 5V PWM auf der Platine mit drauf...
Peter K. schrieb: > Kommt drauf an, wenn es schnell sein soll und du genügend Platz hast ist > ein 8/16/32 Bit parallel-Bus immer gut :). Wenn es nicht so schnell sein > soll kann es auch RS232 auf niedriger Baudrate bzw. SPI mit niedrigen > Takt verwendet werden. Was heißt niedriger Takt?
Wenn CAN vorhanden ist würde ich CANopen empfehlen. Ist zwar etwas aufwändiger aber ich werde immer mehr und mehr ein Freund davon. Ansonsten würde ich dir auch RS485 oder RS232 raten.
Hab mal kurz gerechnet, bräuchte für jede Platine so 48kbit/s.. Das gibt etwa 1,4Mbit/s bei 30 Platinen. Autoadressierung sollte auch möglich sein...
Naja, das die Daten halt nicht mit xxx kHz/MHz übertragen werden. Bei RS232 wäre villeicht 9600 Baud sinnvol
Alex E. schrieb: > Hab mal kurz gerechnet, bräuchte für jede Platine so 48kbit/s.. > Das gibt etwa 1,4Mbit/s bei 30 Platinen. > > Autoadressierung sollte auch möglich sein... also doch RS485
RS485 ist an sich zwar sehr gut geeignet, aber bei der Datenrate ist das auf Controller-Seite nicht mehr trivial. Bei niedrigeren Datenraten lässt sich per UART und RS485-Transceiver ganz simpel und sehr zuverlässig ein MODBUS RTU aufbauen. Was darf es denn kosten? Welcher Controller steht zur Verfügung? Darf/soll für die Bus-Anbindung ein zusätzlicher Controller verwendet werden?
Als Master soll ein Raspberry oder ähnliches dienen. Der dann die Slaves mit Daten versorgt. Der Bus ist von der Topologie auf jeden Fall Linear, also kein Stern... Die Platinen sollen vorne ein Stecker und hinten eine Buchse haben, womit das Busssignal sowie Versorgung an die nächste Platine weitergegeben wird. Die Kosten sollen, wie immer, möglichst niedrig ausfallen. Hab auf der Platine/slave an einen Atmega88 oder so gedacht. Der Muss auch sonst relativ wenig machen außer die Daten zu kommunizieren und diese umsetzten. -> Also nur ein Controller/Slaveplatine. Kann aber Ressourcennotwenigkeit für die Datenrate schlecht einschätzen. Sollte ja eigentlich von der HW-Uart im Controller abgedeckt sein. Es ist vermutlich eher ein Problem auf der Masterseite. und diese Datenrate ist auch nur bei Vollauslast notwendig. Aber wäre halt super wenn ich das schaffe. Hier bin ich halt von 30mal/s alle Slaves mit Daten versorgen, ausgegangen. 5mal/s würde im Grenzfall auch reichen(240kbit/s). @Markus: Denkst du an einen anderen Bus?
Naturgemäß sehen an einem (linearen) bus alle Teilnehmer die gleiche Datenrate. Also haben alle "ein Problem". Sobald Du in Geschwindigkeiten kommst, bei denen der UART noch mitmacht, kannst Du RS485 verwenden. Den kannst Du "einfach so" mit einem möglichst einfachen Protokoll oder mit etwas mehr Overhead mit einem Standard-Protokoll wie MODBUS RTU verwenden. Was davon sinnvoll ist, musst Du selbst beurteilen. Bei Datenraten, die die Leistungsfähigkeit eines UARTs übersteigen, würde ich immer auf ein Ethernet-basiertes Protokoll gehen. Bei einer linearen Verbindung lässt sich das aber leider nicht umsetzen.
Stimmt hast recht, lesen und Auswerten müssen das alle. Also werde ich bei RS485 bleiben und schauen, wie hoch ich mit der Datenrate gehen kann. Wie würdet Ihr das auf der Platine machen? Einfach ein MAX485 zum umsetzten auf Uart nehmen und den Bus ohne Verstärkung an die Nächste Platine weitergeben? Oder soll ich da Verstärken? Werden ja bis zu 8 meter im Grenzfall...
Den Bus einfach die ganzen 8m durchziehen und über ST485x (Maxim kommt mir nicht über die Türschwelle ;-) ) an den μC anschließen. Abschlusswiderstände an den Enden nicht vergessen.
Moin, nur mal so als Denkanstoß: Die Datenrate würde sich halbieren, wenn der Master zwei Schnittstellen hätte und z.B. in der Mitte einspeisen würde. Oder, vielleicht mit den Steckern einfacher zu realisieren, immer eine Platine überspringen würde. Also als Beispiel: Bei einem 10pol. Stecker auf jeder Seite geht es bei 1 und 2 rein und am anderen Stecker bei 3 und 4 raus - dieser Bus wird benutzt. Der zweite geht auf 3 und 4 rein und auf 1 und 2 raus - dieser wird nur durchgeleitet. Je nachdem natürlich auch mit 3 oder mehr Bussen realisierbar. Bei der Länge würde ich auch auf einen Bus ohne Zwischenverstärker setzen. Gruß Jens
Noch einmal moin, ich vermute ja mal fast, Du willst LEDs ansteuern. Über den Strom, der vorne rein geht, hast Du Dir vermutlich Gedanken gemacht. Und den Spannungsabfall, bis Du mal hinten bist. Schaltregler je Platine, die mit z.B. 24V arbeiten, könnten da Sinn machen. Für die Autoaddressierung ein DaisyChain-Signal vorsehen, oder? Denn die Reihenfolge sollte vermutlich passen... Und vielleicht noch ein gemeinsames Reset- und/oder Sync-Signal. Gruß Jens
hi jens, wie kommst du dem auf die Idee? wozu ein reset oder sync? welchen schaltregler haste denn im sinn? hab grade den tps545360 rausgesucht... soll moeglischst klein sein
Aeh, 3. moin, wie wäre es mit einer schlichten TTL-Seriell-Verbindung, die aber nur von einer Platine zur nächsten geht? Spart die vielen Treiber und erlaubt das Festlegen der Reihenfolge ohne zusätzliche Leitung. Bei Bedarf eine Rückleitung durch alle Platinen wieder hin zum Master. Ok, hier sind die 8m ein Wort für TTL. Ach, wäre doch schön, etwas mehr über die Applikation zu wissen... Jens
Die Idee beim dritten moin war, jeden Platine das Signal empfangen und erneut aktiv aussenden zu lassen. Es entstehen also nur kurze, wohldefinierte Datenstrecken von 20cm. Du tauscht den Hardware-Aufwand gegen die Software, die die Daten weiterleiten muss.
das wurde aber auf kosten der datenrate gehen oder? und ich kann keine broadcast nachrichten mehr verschicken...
Alex E. schrieb: > wieso kein maxim? Schlechte Erfahrungen mit Preisen, Lieferfähigkeit, Abkündigung, usw.
Habe viele solcher Systeme mit I2C Bus gesehen, die meisten mit 4066 , dies schließt aber 3.3V Systeme aus. Wenn die Verkabelung in den Preis reingeht, hat sich auch LIN durchgesetzt, mit den Lin Tranceivern welche 5V PSU drin haben. 1Wire CAN habe ich auch gesehen, sind aber Nischenlösungen.
Jens schrieb: > Die Idee beim dritten moin war, jeden Platine das Signal empfangen und > erneut aktiv aussenden zu lassen. Es entstehen also nur kurze, > wohldefinierte Datenstrecken von 20cm. So habe ich das auch verstanden und halte die Idee für gut. Allerdings muß man sich im Klaren darüber sein, daß so eine Kette eine nicht zu unterschätzende Verzögerung erzeugt und das Protokoll so gestalten, daß möglichst wenige Frage-Antwort-Wechselspiele vorkommen, denn dabei geht die Verzögerung gleich doppelt ein und belegt den Bus, ohne daß irgendwelche Daten dabei transportiert würden. Sprich: Man sollte möglichst große Datenblöcke verwenden. > Du tauscht den Hardware-Aufwand gegen die Software, die die Daten > weiterleiten muss. Nö, man kann auch einfach ein paar Logik-Gatter zur Weiterleitung und Auskopplung verwenden. Softwarehilfe braucht man dann bloß für die Autoadressierung. Da wird einfach die Weiterleitung zur nächsten Platine blockiert, bis man eine Adresse bekommen hat, danach wird sie freigeschaltet. Da Logik-ICs spottbillig sind, würde ich vorschlagen, die Sache gleich doppelt vorzusehen und dann mit differentiellen Signalen zu arbeiten.
c-hater schrieb: > Allerdings > muß man sich im Klaren darüber sein, daß so eine Kette eine nicht zu > unterschätzende Verzögerung erzeugt und das Protokoll so gestalten, daß > möglichst wenige Frage-Antwort-Wechselspiele vorkommen, denn dabei geht > die Verzögerung gleich doppelt ein und belegt den Bus, ohne daß > irgendwelche Daten dabei transportiert würden. Sprich: Man sollte > möglichst große Datenblöcke verwenden. > angenommen ich nehme RS232 TTL pegel und schiebe das immer durch den Atmega88 durch. Von welcher verzögerung kann ich bei dem einen Controller ausgehen? > > Nö, man kann auch einfach ein paar Logik-Gatter zur Weiterleitung und > Auskopplung verwenden. Softwarehilfe braucht man dann bloß für die > Autoadressierung. Da wird einfach die Weiterleitung zur nächsten Platine > blockiert, bis man eine Adresse bekommen hat, danach wird sie > freigeschaltet. > > Da Logik-ICs spottbillig sind, würde ich vorschlagen, die Sache gleich > doppelt vorzusehen und dann mit differentiellen Signalen zu arbeiten. Das habe ich auch so in etwa vorgestellt, dass ich dafür Logik-ICs einsetzten kann nicht. Danke!
Alex E. schrieb: > Hab mal kurz gerechnet, bräuchte für jede Platine so 48kbit/s.. > Das gibt etwa 1,4Mbit/s bei 30 Platinen. > > Autoadressierung sollte auch möglich sein... Soll das irgend was mit Audiodaten werden? Wäre es dann nicht besser der Arduion würde 30 Kanäle bereit stellen?
Hast du das mit dem CAN denn mal in betracht gezogen? Wie sind die äußeren Bedingungen? Ist viel EMV im Umfeld? Natürlich wirds mit CAN aufwändiger und auch vermutlich teurer aber du hast gerade Vorteile in Sachen Störfestigkeit.
Jens schrieb: > Die Idee beim dritten moin war, jeden Platine das Signal empfangen und > erneut aktiv aussenden zu lassen. Das hat aber auch Nachteile: fällt eine Platine aus, so auch alle dahinterliegenden. Bei einem echten Bus funktioniert nur die eine nicht mehr. Kommt auf die Anwendung an, ob das was ausmacht. Gruss Reinhard
> Natürlich wirds mit CAN aufwändiger und auch vermutlich teurer aber du > hast gerade Vorteile in Sachen Störfestigkeit. Wieso soll CAN störfester sein als eine RS485-Verbindung? Ich kenne Beispiele, die das Gegenteil belegen. Die geforderte Datenrate und Topologie dürfte mit RS485 ohne große Probleme (vorausgesetzt, die richtigen µCs werden verwendet) und recht störfest zu realisieren sein. > angenommen ich nehme RS232 TTL Pegel Warum? RS485-Treiber kosten ähnlich viel wie RS485-Treiber, sind deutlich störanfälliger und erlauben nur Punkt- zu Punkt-Verbindungen. > Von welcher verzögerung kann ich bei dem einen Controller ausgehen? Je nachdem, was Du alles vorhast, liegt die Verzögerung etwa zwischen 1,5 Bytelängen bis mehreren Sendungslängen. > würde das mit ttl un evtl. Impedanzwandler je platine gehen? bei der länge? Ja, ist aber störanfälliger als RS485.
CAN ist nach aussen hin störfester als RS485, weil Übertragungsfehler automatisch erkannt werden. Physikalisch ist RS485 besser (es gibt den schlappen rezessiven Pegel nicht). CAN hat in deinem Fall auch den Nachteil, dass ne Menge Bits übertragen werden, die nichts zur eigentlichen Sache tun. Üblicherweise arbeitet CAN mit max. 1Mbit, was einer Nettodatenrate von etwa 500kbit entspricht, fällt also auch von daher schon aus. RS485 ist die ideale Lösung für Single-Master wie in deinem Fall. Einfach, billig, zuverlässig, schnell. Alles andere wäre meiner Meinung nach die falsche Lösung.
momentan ergibt aus der diskussion für mich rs485 am meisten Sinn. Welche vorschläge gibt es zur Auto adressierung? Ich würde gerne zusätzliche Signale auf dem Stecker vermeiden... Logik IC würde hier ja nicht mehr gehen!?
Alex E. schrieb: > angenommen ich nehme RS232 TTL pegel und schiebe das immer durch den > Atmega88 durch. Von welcher verzögerung kann ich bei dem einen > Controller ausgehen? Na mindestens eine Wortlänge zzgl. der Interrupt-Responsezeit.
Alex E. schrieb: > Welche vorschläge gibt es zur Auto adressierung? Du ziehst eine weitere Leitung auf dem Bus als daisy chain: Der erste Slave hängt schon beim Einschalten am Bus und bekommt vom Master eine Adresse zugewiesen. Danach schaltet er den receiver enable des nächsten Slaves ein, dann bekommt dieser eine Adresse vom Master zugewiesen, usw.
Bei den RS485 werden DE & RE immer an einen Pin vom µC angehängt. Was genau mach das Signal? Wozu brauche ich das?
soviel hab ich kapiert, aber was ist LOW was ist HI. Wie schaue ich ob nicht gerade jemand anders sendet?
Low = Empfang / High = Senden Bei einem Single-Master-System ist es einfach. Du weißt ja ob du gerade sendest bzw. wann eine Antwort von einem Slave komplett ist. Ansonsten musst du immer auf Empfang sein (müsste eh immer so sein) und nur senden wenn du nichts empfängst. P.S.: Darf man noch ein Master-Slave System beschreiben oder ist das mittlerweile "politisch Inkorrekt"???
Alex E. schrieb: > Wie schaue ich ob nicht gerade jemand anders sendet? Genau das ist das grundlegende Problem bei RS485-Multimastersystemen. Prinzipiell: ja, es geht. Aber es ist mit einem erheblichen Softwareaufwand verbunden. Ich persönlich setze RS485 nur in single-master-Systemen ein.
H.Joachim Seifert schrieb: > Alex E. schrieb: >> Wie schaue ich ob nicht gerade jemand anders sendet? > > Genau das ist das grundlegende Problem bei RS485-Multimastersystemen. > Prinzipiell: ja, es geht. Aber es ist mit einem erheblichen > Softwareaufwand verbunden. > Ich persönlich setze RS485 nur in single-master-Systemen ein. Sorry, hab auch nur einen Master. Von dem her passt das. Danke...
Eben. Und deswegen musst du nicht wissen, ob gerade jemand sendet. D.h. alle slaves sind auf Empfang. Es sei denn, sie werden vom master aufgefordert, ihren Datensalat loszulassen. Da lauert übrigens noch ein kleines timing-Problem. Je nach UART gibt es verschiedene Statusbits. Z.B. eines, das anzeigt, dass das Byte ins Senderegister geschrieben wurde. Das darf man natürlich nicht benutzen, um auf Empfang umzuschalten. Sondern erst dann, wenn das Datenbyte incl. parity/stopbit(s) tatsächlich raus sind.
Alex E. schrieb: > Wie schaue ich ob nicht gerade jemand anders sendet? Das ist genau das Problem am RS-485. RS-485 ist daher zeitgesteuert: Der Master muß zuerst an den Slave eine Nachricht senden, in welchem Zeitfenster dieser auf Senden umschalten darf, sobald er zum Senden adressiert wurde. Die minimale Wartezeit gibt an, wann der Master zuverlässig auf Empfang umgeschaltet hat. Und die maximale Zeit gibt an, wie lange der Master auf Empfang bleibt, ehe er ein Timeout annimmt und z.B. die Nachricht wiederholt.
Im 9Bit-Modus (9tes signalisiert Slave-Adresse) über UART auf RS485 bei 250k und einem miesen protokoll mit 12 Nutzbytes und 15 "Byte" (sind ja eigentlich 9 Bit) Rahmen dauert mit zwei zusätzlichen Bytes wg. Frame-Error Vorbeugung etwa: Start+9+Stop (keine Parity, das kann man Bitweise machen) => 11*4µS=44µS jetzt noch 12Nutzbytes+Adresse+Cmd+Parity+2*Frame-Sync => 17*44µS=748µS Mal den worst-case Überschlag angenommen der Master will 12 Nutzbyte senden und der Slave mit 12Nutzbyte antworten, dann kommt man bei 2*0,75=1,5ms raus! Wenn das ganze über 30 slaves geht, bist du nach spätestens 45ms einmal rum, wenn du die 12Byte ausnutzt. DMX ist ja auch 250k-UART-basiert und da hängen auch mehr als 30 slaves dran und trotzdem geht es irgendwie. Bei den RS485-Bausteinen gibt es tolle 5V-supply und gleichzeitig 3,3V-kompatible ICs von Maxim die auch 1/8 unit load haben, sprich von denen kannst du auch 8*32 an den Bus hängen und die Kommunikation läuft noch sauber über "mehrere meter".
René B. schrieb: > Bei den RS485-Bausteinen gibt es tolle 5V-supply und gleichzeitig > 3,3V-kompatible ICs von Maxim die auch 1/8 unit load haben, sprich von > denen kannst du auch 8*32 an den Bus hängen und die Kommunikation läuft > noch sauber über "mehrere meter". Kannst du das nochmal genau erklären? Was meinst du mit 8*32? 8/32/256 Busteilnehmer?
Ein RS485 transciever mit unit-load==1 belastet die Leitungen so, dass genau 32 Teilnehmer zuverlässig daran angeschlossen werden können. Wenn ein transciever in der Spec aber so beschrieben wird, dass er die Leitung mit 1/8 unit-load belastet, so kann man 8mal mehr Teilnehmer diesen Typs an den Bus hängen. Daher 8*32 Teilnehmer, wenn alle transciever vom typ (1/8-unit-load) haben.
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.