Hallo Leute, ich habe vor, in den kommenden Wochen ein neues Projekt zu starten. Dieses beinhaltet mehrere AVR uC miteinander zu verbinden. Dementsprechend habe ich mich ueber die gaengigen Moeglichkeiten zur Kommunikation zwischen mehreren uC etwas schlau gemacht, habe aber leider nicht das gefunden, was ich genau suche. Darum hier dieser Beitrag: Bei dem Projekt soll es einen Master-uC geben, an dem ein Display und Keypad angeschlossen sind. Abhaengig von Eingaben, die man dort machen kann, sollten mehrere Slave-uC angesprochen werden. Diese Slave-uC steuern dann weitere Peripherie an. Die Verbindung zwischen den uCs ist auf dem angehaengten Bild dargestellt. Zuerst ein paar Gegebenheiten: - Nur der Master sendet Daten an die Slaves. Nicht umgekehrt. - Ein "Datenpaket" enthaelt 32 Bit (8 Bit Adresse, 24 Bit Nutzdaten). - Jeder Slave bekommt seine Adresse ueber einen Dip-Schalter zugewiesen. - Die Entfernung zwischen Master und Slaves kann einige Meter betragen. - Taktraten aller uC mindestens 8MHz Nun die erste Frage dazu: Ist eine Kommunikation ueber mehrere Meter ueberhaupt moeglich (>5m)? Nach meinem Wissensstand scheiden somit die Verfahren SPI und I2C schon einmal aus, da diese eher fuer kurze Entfernungen ausgelegt sind? Nun die Bedingung: Es kann vorkommen, dass alle Slaves die selben Nutzdaten bekommen sollen. Ist dies der Fall, sollen diese auch moeglichst gleichzeitig darauf reagieren. Somit muss es moeglich sein eine Nachricht gleichzeitig an alle Slave-uCs zu senden. Aus der Sicht eines Slaves sollen Datenpakete akzeptiert werden, bei denen die eigene Adresse mit der im Datenpaket uebereinstimmt oder die Adresse im Datenpaket gleich Null (0x00) ist (Definition eines Datenpakets an alle Slaves). Noch einmal mit anderen Worten: Der Master kann ein Datenpaket an einen einzelnen Slave oder alle Slaves senden. Sendet er an alle, sollen alle Slaves moeglichst gleichzeitig darauf reagieren. Waere dies mit TWI oder UART grundlegend realisierbar? Eine Idee von mir, dies zu realisieren: Ich hatte mir gedacht, vor jedem Slave ein separates 8 Bit Schieberegister (http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister#Funktionsweise) zu platzieren. Sollen nun Daten an einen Slave-uC gesendet werden, schiebt der Master zunaechset 8 Bit eines Datenpakets gleichzeitig in jedes Schieberegister jedes Slaves (Eins pro Slave). Sind die ersten 8 Bit in jedem Schieberegister, setzt der Master das RCK Signal (Low-High-Low). Bei der steigenden Flanke werden die Daten somit von jedem Schieberegister auf die parallelen Ausgaenge gelegt. In jedem Slave wird bei der fallenden Flanke ein Interrupt ausgeloest, dass die 8 Bit einliesst und erstmal im Speicher ablegt. Dieser Vorgang wird mit den restlichen 24 Bit eines Datenpakets wiederholt. Wurde ein Datenpaket komplett uebermittelt, entscheidet jeder Slave, ob die Daten fuer ihn gueltig sind oder nicht. Fertig! Ist dies ueberhaupt verstaendlich geschrieben? Falls ja, realisierbar?? Ich bedanke mich zuerst einmal fuers lesen und erneut fuer eine Antwort. :) Schoenen Gruss
Angehängte Dateien:
-
Concept.png
1,6 KB
Schau Dir mal CAN-Bus oder RS485 an. I2C geht auch auf x Meter. Schieberegister? Für was? Die AVR haben TWI und UART mit dabei, brauchste nicht.
Diese geschilderte Lösung scheint etwas kompliziert. Wenn so etwas machen müsste, dann würde ich AVRs mit CAN-Hardware verwenden und via CAN kommunizieren. Vorteil: problemlos bei diesen Entfernungen, und es werden weniger Leitungen benötigt (CAN_L, CAN_H, GND) Ausserdem könnte man problemlos eine bidirektionale Kommunikation realisieren, und es gibt auch CAN Libraries wodurch nicht das Rad komplett neu erfunden werden muss. viele Grüße Max
Nimm i2c, wenn du nicht zu schnelle Datenraten hast. Die eingebaute Twi-Hardware übernimmt dir das ganze Managment, du musst nur noch die Datenbytes verwenden und die Adressen einstellen. :-)
Am unkompliziertesten ist UART. Wenn man genug davon hat, sollte man das nehmen. Bei kurzen Wegen <1m kann man z.B. alle RX-Leitungen verbinden und jede TX-Leitungen mit einer Diode (mit Kathode an den TX-Pin) an diese gemeinsame Leitung anschließen. Die gesamte Leitung wird mit einem Pullup nach VCC gezogen. Dann kann man im Halbduplex auf dieser Leitung sowohl im Single-, als auch Multimasterbetrieb arbeiten. Der Multiprozessor-Kommunikationsmodus ist dabei hilfreich und arbeitet mit bis zu 256 Adressen.
Also ich würde das ganz über RS485 lösen. Wie Herr Ballhause schon sagt hat man den Vorteil das die AVRs einen MPCM (Multi-processor Communication Mode) haben. Hier für werden Daten und Addresse mit Hilfe des 9 Bit unterschieden. Die Addressen sind frei konfigurierbar und man kann natürlich auch welche doppelt belegen z.B.: (0x00) für Braodcast. Mit RS485 sind auch 5 Meter kein problem und man hat nur zwei Drähte und kann ein Bus-System aufbauen.
Tsmc schrieb: > Mit RS485 sind auch 5 Meter kein problem Mit RS485 sind nicht mal 500m ein Problem ;-)
Mit nur einem master ist RS485 ideal. Einfach, billig, störfest.
Von Peter Dannegger gibt's in der Code-Sammlung einen 124-Bus. Dieser hat den Vorteil gegenüber rs232, dass die Taktabweichung bis zu 25% betragen kann. Bei rs232 sind es bis zu 4%. Selber ausprobiert habe ich ihn noch nicht.
RS485 ist wohl nicht der Weissheit letzter Schluss, da: Keine Sterntopographie Keine Stichleitungen Habe demnächst das selbe Problem, aber noch keine echte Lösung. Würde gerne RS232 verwenden. Habe aber das Problem, dass die Slaves "wahllos" dazu gesteckt werden müsen. Es sind also mal mehr und mal weniger Slaves vorhanden. Damit muss der Bus auch Stichleitungen vertragen können. Meine Slaves werden maximal 5m vom Master entfernt sein. Wenn jetzt hier keiner laut schreit, dann werde ich es einfach probieren. MfG Ulli
Ulli schrieb: > Würde gerne RS232 verwenden. RS232 ist kein BUS, sondern eine Punkt-zu-Punkt-Verbindung. Die oben vorgeschlagene Lösung mit den Dioden könnte für Dich funktionieren. Wenn man den/die Pullups schaltbar macht, kann man jedes Ende eines Strangs terminieren. Um das Ganze noch vor elektrostatischer Entladung zu schützen, kann man serielle Widerstände vor jedem Controller vorsehen.
Hi >RS485 ist wohl nicht der Weissheit letzter Schluss, da: >Keine Sterntopographie >Keine Stichleitungen Dann lies mal hier: www.national.com/an/AN/AN-1057.pdf MfG Spess
Vielen Dank an alle erst einmal fuer die Antworten! Ich habe mir jetzt darauf hin TWI und RS485 nochmal etwas genauer angeschaut und weiter gelesen. Dazu nun noch kurz ein paar Verstaendnisfragen: TWI: Ich kann ja jedem Slave ein eigene Adresse zuweisen (TWA Register bei den AVRs). Wenn ich jedem Slave die gleiche TWI-Adresse zuweisen wuerde und der Master an diese Adresse sendet, dann sollten ja ansich alle Slave die Daten bekommen (Broadcast). Falls soweit richtig: - Wuerde das dann nicht Probleme mit dem internen TWI-Management geben? - Jeder Slave sollte doch entsprechend ein ACK zuruecksenden, wenn dieser zum Empfang von Daten bereit ist. - Der Master wuerde es vermutlich nicht mitbekommen, wenn ein Slave kein ACK gesendet hat -> ein Slave bekommt die Nachricht nicht? RS485: Um diese Art der Uebertragung zu realisieren, braucht man ja noch zusaetzlich die entsprechenden Treiber ICs. Freund Google konnte mir nach eine kurzen Suche die beiden folgenden IC aufzeigt: SN75176A und MAX485. So wie ich das auf den ersten Blick sehen konnte, unterscheiden die sich nicht grossartig. Sehe ich das richtig, dass ich bei RS485 Bit fuer Bit uebertragen muss? Zudem sollte doch jeder Teilnehemer am Bus jedes Datenpaket bekommen -> nur Broadcast senden? (Wuerde mich nicht weiter stoeren) Bitte korrigiert wenn ich falsch liege. :)
Ich habe genau das gemacht als Midi-Steuerung. Die ist total unanfällig, wenn Du Optokoppler nimmst. Also mit TxD und evtl. einem Treiber (Transistor) raus und vor jeden Slave einen Optokoppler und dann wieder in RxD rein. Die Eingänge der Optokoppler sind beim Master zusammengeführt und daher alle parallel geschaltet. Jeder Slave bekommt die gleichen Daten, mit einem ersten Byte wählt man den Slave an (dieser entscheidet per Software oder dip ob er der richtige ist), für den die Information gilt. Man kann auch "absprechen" das eine Nummer bedeutet: Befehl für alle. Ähnlich des Midikanals und der Controllerwerte. Der 485 funktioniert auch sehr gut, habe ich auch schon verwendet. Aber letztendlich alles über die USART. Die Störanfälligkeit ist gering: 485, da beide Leitungen Störungen "gegenphasig" kompensieren. Bei MIDI handelt es sich um eine Stromverbindung, wenn ein Impuls gesendet wird fließt ein gewisser Strom (2mA?), kurzzeitig.
Jens (Gast) schrieb: >Also mit TxD und evtl. einem Treiber (Transistor) raus und vor jeden >Slave einen Optokoppler und dann wieder in RxD rein. Die Eingänge der >Optokoppler sind beim Master zusammengeführt und daher alle parallel >geschaltet. Hoert sich sehr interessant an. Leider ist mir noch nicht ganz klar, welcher Ausgang vom Optokoppler nun mit was verbunden ist. Die Eingaenge der Optokoppler beim Master zusammenfuehren ist klar. Aber welche Ausgaenge vom OK genau an welchens TxD und RxD?? Welches Protokoll hast du dabei genutzt? RS232 wuerde ich jetzt vermuten.
Chris L. schrieb: > TWI: > Ich kann ja jedem Slave ein eigene Adresse zuweisen (TWA Register bei > den AVRs). Wenn ich jedem Slave die gleiche TWI-Adresse zuweisen wuerde > und der Master an diese Adresse sendet, dann sollten ja ansich alle > Slave die Daten bekommen (Broadcast). Falls soweit richtig: > - Wuerde das dann nicht Probleme mit dem internen TWI-Management geben? > - Jeder Slave sollte doch entsprechend ein ACK zuruecksenden, wenn > dieser zum Empfang von Daten bereit ist. > - Der Master wuerde es vermutlich nicht mitbekommen, wenn ein Slave > kein ACK gesendet hat -> ein Slave bekommt die Nachricht nicht? Bei TWI (aka I²C) gibt es eine Broadcast-Adresse, auf die alle Chips reagieren. Ob diese überhaupt mit ACK quittiert wird, weiß ich gerade nicht. Das Problem, nicht sicher alle zu erreichen, hast Du mit Broadcasts immer. Wenn Du von jedem Empfänger einzeln ein Quittung haben möchtest, mußt Du ihn einzeln ansprechen. Gruß Jobst
Chris L. schrieb: > Welches Protokoll hast du dabei genutzt? RS232 wuerde ich jetzt > vermuten. RS232 ist kein Protokoll, sondern der physikalische Übertragungsweg. Das Protokoll ist eine Schicht darüber. Das Protokoll juckt es nicht wie die Daten physikalisch übertragen werden, sondern nur dass (!) Daten übertragen werden und was damit gemacht werden soll.
Also alles was Du da so beschreibst passt perfekt auf ein TWI/I2C-System mit entweder niedrigen Taktraten oder Treibern (P82B96 ist da das Stichwort). Broadcastfähig experimentelle Kabellängen über 100m Multimasterfähig Hot-Pug/-Unplugfähig Acknowledgement uvm. http://www.nxp.com/documents/user_manual/UM10204.pdf sind die Specs vom I2C-Bus da kannste alles nochma genau nachschmökern...
Chris L. schrieb: > Sehe ich das richtig, dass ich bei RS485 Bit fuer Bit uebertragen muss? Das macht Deine Hardware-UART, insofern der Controller eine hat. Ansonsten halt Software.
Angehängte Dateien:
-
Midi_Bus.gif
10 KB
Wenn Du nur ca 5 Slaves hast, kannst Du das ohne Treiber machen. Das Protokoll kannst Du Dir selbst ausdenken. Ich würde ein Midi ähnliches verwenden. Schicke das erste Byte mit Bit7 = 1, also > 127 Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du nur Bit6..Bit0 nutzen kannst. Also z.B. 1xxxxxxx 0xxxxxxx 0xxxxxxx usw. Damit bekommst Du raus, wann eine Übertragung beginnt. Das 1. Byte benutzt Du als Adressbytes z.B. 10000001 für Slave1. Du kannst den Block von x Bytes alle hintereinander senden mit der entsprechenden Senderoutine.
Jens schrieb: > Schicke das erste Byte mit Bit7 = 1, also > 127 > Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du > nur Bit6..Bit0 nutzen kannst. Was ein Quark, der AVR kann 9-Bit Frames generieren, wobei das 9te Bit (Bit8) für die Adressierung genutzt wird. Damit sind volle 8 Bit für Adressen und Daten möglich, bei den Adressen ist das neunte Bit = 1, bei den Daten ist das neunte Bit = 0. Dafür jetzt MIDI und Optokoppler zu verbasteln, ist reine Verschwendung.
Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und Probieren und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken hast. Außerdem geht es auch ums Verständnis und ich hab es erfolgreich in der Praxis eingesetzt. Aber es muss ja solche klugen Menschen wie Knut geben, sonst würde es ja zu einfach werden.
Also das mit den Optokopplern ist aus meiner Sicht die bisher beste und preiswerteste Lösung. Kein Can-Bibliotheken, keine teuren ICs, galvanische Trennung inclusive. Ich habe hier sowas ähnlichens für einen Datenlogger gemacht, nur in der anderen Richtung. Da sind ein paar 100m Kabel in wilder Stern-Topologie verbaut. Läuft mit 1200 Baud anstandslos. Kommt natürlich auf die gewünsche Geschwindigkeit an. I2C ist für den zweck denke ich die schlechteste der diskutierten Varianten. Der Hinweis auf Midi und die Technik mit dem gesetzen Bit für Befehle ist auch sehr brauchbar und bewährt. Auf die 9bit Variante würde ich nicht gehen, da verbaut man sich sonst die Möglichkeit das direkt über eine rs232 vom PC zu steuern.
Jens schrieb: > Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und > Probieren Und das 9-Bit-UART-Protokoll ist schon in Hardware vorhanden. SW gibt es dafür auch. > und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken > hast. Quark. Die sind bei MIDI eingebaut, um keine Brummschleifen zu erzeugen. > Aber es muss ja solche klugen Menschen wie Knut geben, sonst würde es ja > zu einfach werden. Sagen wir mal so: Es gibt Menschen, die es sich nicht unnötig kompliziert machen :-) Gruß Jobst
Vielen Dank fuer den gesamten Input! Nach und nach kommt fuer mich mehr Licht in die Geschichte - meine ich zumindest. ;) Wenn ich die AVRs untereinander mit der geschilderten Loesung von Jens (http://www.mikrocontroller.net/attachment/97095/Midi_Bus.gif) verbinde, dann sollte es doch moeglich sein, die Daten ueber die eingebaute HW-UART zu verschicken? Dies koennte man dann ja mit den Routinen aus dem AVR Tutorial sehr einfach realisieren. Wie die uebertragenen Daten dann schlussendlich von den Slave-uC behandelt werden, bleibt ja mir ueberlassen. Jens schrieb: >Schicke das erste Byte mit Bit7 = 1, also > 127 >Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du >nur Bit6..Bit0 nutzen kannst. >Also z.B. >1xxxxxxx 0xxxxxxx 0xxxxxxx usw. >Damit bekommst Du raus, wann eine Übertragung beginnt. Das 1. Byte >benutzt Du als Adressbytes z.B. 10000001 für Slave1. Du kannst den Block >von x Bytes alle hintereinander senden mit der entsprechenden >Senderoutine. In meinem Fall soll ein Datensatz ja immer 4 Byte betragen. Somit koennte man doch in den Slaves mitzaehlen, wie viele Bytes uebertragen wurden und jeweils nach vier Bytes einen neuen Datensatz erwarten. Somit waere es dann auch nicht noetig ein Bit zu reservieren, wodurch man alle 8 Bit nutzen koennte. Dies jetzt allerdings nur fuer meinen Fall. Ansonsten wird das ja bei dem Midi-Protokoll so gehandhabt.
Chris L. schrieb: > In meinem Fall soll ein Datensatz ja immer 4 Byte betragen. Somit > koennte man doch in den Slaves mitzaehlen, wie viele Bytes uebertragen > wurden und jeweils nach vier Bytes einen neuen Datensatz erwarten. Somit > waere es dann auch nicht noetig ein Bit zu reservieren, wodurch man alle > 8 Bit nutzen koennte. Das ist nur blöd, wenn sich einer der Slaves, z.B. durch einen Störimpuls, verzählt. Der hat keine Chance wieder Anschluss zu finden. Was einen dann gleich zur 2. Sache bringt: Wie sicher müssen die Daten beim Empfänger ankommen? Ist es egal, wenn mal ein paar Bytes fehlen oder hängen von jedem Byte Menschenleben ab? :-) Muss der Slave eine Prüfsumme bilden und diese mit dem Master abgleichen? Gruß Jobst
Jobst M. (jobstens-de) schrieb: >Das ist nur blöd, wenn sich einer der Slaves, z.B. durch einen >Störimpuls, verzählt. Der hat keine Chance wieder Anschluss zu finden. In der tat, waere eher so mittel... >Wie sicher müssen die Daten beim Empfänger ankommen? Ist es egal, wenn >mal ein paar Bytes fehlen oder hängen von jedem Byte Menschenleben >ab? :-) Menschenleben haengen davon definitv nicht ab. :) Kommen Daten bei einem Slave "falsch" an, dann wird der nicht explodieren oder sonstiges, nur die Ausfuehrung waere in diesem Sinne fehlerhaft. Kurz: Bringt niemanden um, waere aber unschoen. >Muss der Slave eine Prüfsumme bilden und diese mit dem Master abgleichen? Ist bisher nicht geplant. Nur Kommunikation vom Master zu den Slaves. Kein Slave -> Master oder Slave -> Slave. Vllt. ist es noch wichtig zu sagen, dass das System innerhalb einer "Standart"-Wohnung betrieben werden soll. Stoereinfluesse waeren daher "nur" Stromkabel in den Waenden, Handy-, Radio- und W-Lan Signale und was da sonst noch alles so rumschwirrt. Aber keine 100kV Leitungen etc..
Jens schrieb: > Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und > Probieren und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken > hast. > Außerdem geht es auch ums Verständnis und ich hab es erfolgreich in der > Praxis eingesetzt. MIDI ist eine 2-Punkt-Verbindung für Musikinstrumente. Diese Schnittstelle als BUS zu vergewaltigen, ist nicht nur unsinnig, sondern auch unzuverlässig. Jeder Optokoppler braucht Strom. Bei 20 Slaves kommen wir in einen Bereich von 200mA Steuerstrom für eine Richtung. Da müssen dann aber schon ganz nette Treiber am Werk sein. Bei hohen Strömen im Kabel gibt es auch ordentliches Übersprechen auf den Rück-Kanal. Ich denke, das ist eine Spur am Ziel vorbei. MIDI ist per Spezifikation auch lediglich für 5m-Kabellänge entwickelt worden. Klar geht mehr, ist aber ausserhalb der Spezifikation.
Knut Ballhause schrieb: > MIDI ist eine 2-Punkt-Verbindung für Musikinstrumente. Diese > Schnittstelle als BUS zu vergewaltigen, ist nicht nur unsinnig, sondern > auch unzuverlässig. Dafür gibt es doch die 'THRU' Buchse :-) > Bei hohen Strömen im Kabel gibt es auch ordentliches Übersprechen > auf den Rück-Kanal. MIDI hat ja gar keinen Rückkanal :-D Das wird im Ring gelegt. Gruß Jobst
Chris L. schrieb: >>Muss der Slave eine Prüfsumme bilden und diese mit dem Master abgleichen? > > Ist bisher nicht geplant. Nur Kommunikation vom Master zu den Slaves. > Kein Slave -> Master oder Slave -> Slave. Aber der Master kann eine Prüfsumme mitschicken und der Slave sie vergleichen. Chris L. schrieb: > Vllt. ist es noch wichtig zu sagen, dass das System innerhalb einer > "Standart"-Wohnung betrieben werden soll. Stoereinfluesse waeren daher > "nur" Stromkabel in den Waenden, Handy-, Radio- und W-Lan Signale und > was da sonst noch alles so rumschwirrt. Aber keine 100kV Leitungen etc.. (... und Waschmaschine, Microwelle, Heizung, ...) Kann auch schon ausreichen. Das ist aber nicht das Problem. Das Problem ist, daß Du Dir Gedanken darüber machen musst, wie damit umgegangen werden soll, wenn es mal passiert. Sollen Fehler entdeckt werden? Nein: Mit fehlerhaften Daten arbeiten. Ja: Wie soll darauf reagiert werden? Daten verwerfen. Daten mittels Prüfcodes zurückrechnen (z.B. Hammingcode). Zwischenwerte errechnen. Sich komplett abschalten. Darauf warten, daß das Paket nochmal gesendet wird. Gruß Jobst
Angehängte Dateien:
-
485.gif
10 KB
Wieviel Slaves sind es denn? Bei 20 Stück würde ich auch den 485er Bus nehmen. Da gibt es fertige 8pin ICs, die man direkt an RxD und TxD anschließen kann - geht prima. 5m bei Midi sollte man ignorieren - ich habe sehr sichere Anlagen gebaut mit über 20m Kabel, auch im Freien. Optokoppler (die im übrigen auch beim 485er Bus anzutreffen sind) haben für mich schon noch einen Vorteil. Kleine Störspannungen bringen die Led nicht zum Leuchten, sondern nur klare Impulse. Die Schaltschwelle ist nicht so empfindlich. Bei mittleren Baudraten ist das o.k.. Zum Protokoll. Ich weiß ja nicht was zu übertragen ist. Reserviere einfach ein Byte oder eine Bytefolge, die sonst nicht vorkommt, als Codewort. Also z.B. FF AA BB CC --- erst wenn der Slave dieses Wort erkannt hat, wertet er nachfolgende Bytes aus. Bei jedem ankommenden FF prüft er, ob das Codewort AA BB CC ist usw..
Hi >Bei 20 Stück würde ich auch den 485er Bus nehmen. Da gibt es fertige >8pin ICs, die man direkt an RxD und TxD anschließen kann - geht prima. Alternativ kann man auch CAN-Bustreiber (PCA82C250 und Konsorten) nehmen. Geht noch besser, da man sich nicht um die Sende/Empfangs-Umschaltung kümmern muss. >Also z.B. FF AA BB CC --- erst wenn der Slave dieses Wort erkannt hat, >wertet er nachfolgende Bytes aus. Bei jedem ankommenden FF prüft er, ob >das Codewort AA BB CC ist usw.. Wozu? Die USARTs der AVR haben einen Multiprozessormode. Da kann jeder Slave mit einer Adresse angesprochen werden. MfG Spess
spess53 schrieb: > Hi > >>RS485 ist wohl nicht der Weissheit letzter Schluss, da: >>Keine Sterntopographie >>Keine Stichleitungen > > Dann lies mal hier: > > www.national.com/an/AN/AN-1057.pdf > > MfG Spess Na so was ... das habe ich von hier: http://www.mikrocontroller.net/articles/RS-485 Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist. Dieser Thread beweist das Gegenteil ..... MfG Ulli
Hi >Na so was ... das habe ich von hier: >http://www.mikrocontroller.net/articles/RS-485 Man sollte halt keine Second-Hand-Quellen verwenden. >Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches >problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist. >Dieser Thread beweist das Gegenteil ..... Die sinnd alle problemlos, wenn man weiß, was man macht. Und kompliziert aufzubauen sind alle hier erwähnten Busse auch nicht. MfG Spess
Hi, bin mir nicht sicher ob ich was übersehen habe, aber LIN kommt auch in Frage. Ich denke es gibt AVRs mit LIN und der Transceiver sind nur ein paar Transistoren und Widerstände. Lt. Standard allerdings nur bis 20kBit/s, Checksumme usw. ist standardisiert. 5m sicher kein Problem und ich vermute C-Beispiele gibt's auch mehrere. Letztendlich baut das ganze auf UART auf, nur dass dann nur eine Leitung für die Übertragung genutzt wird - ggf. durch Master/Slave Frames sogar bidirektional. Da meines Wissens keine exakte Busabstimmung erforderlich ist, können die Slaves auch in begrenztem Umfang flexibel gehalten werden, ich wüsste nicht was Plug&Play entgegenspricht. Allerdings : LIN Funktioniert wie CAN signalbezogen, d.h. der Master sendet und die Slaves schauen sich an ob sie die Information interessiert und verarbeiten diese - das entspricht nicht ganz Deiner Anforderung. Über "Diagnose" und TP ist aber auch eine 1:1 Kommunikation möglich. Schau für Details auch mal unter http://www.lin-subbus.org //hufnala
Jobst M. schrieb: > Dafür gibt es doch die 'THRU' Buchse :-) Jobst M. schrieb: > MIDI hat ja gar keinen Rückkanal :-D > Das wird im Ring gelegt. Das erzählst Du einem Musiker!? ;-) Nein, ich bezog mich auf das, was der OP damit machen sollte, nämlich einen BUS... Jens schrieb: > Optokoppler (die im übrigen auch beim 485er Bus anzutreffen sind) Habe noch nie Optokoppler bei RS485 gesehen. Wenn doch, war es kein RS485. Ulli schrieb: > Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches > problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist. > Dieser Thread beweist das Gegenteil ..... RS485 ist einfach. Es liegt am Thread.
Lars Hufnagel schrieb: > aber LIN kommt auch in > Frage. Nicht auch noch LIN... Lars Hufnagel schrieb: > Ich denke es gibt AVRs mit LIN Nope. Nur für Automotive-Buden oder noch nicht am Markt. Wozu auch.
Wer den "Mutiprozessormode" der AVR Uarts schon mal eingesetzt hat, weiss, dass da nicht viel zu sparen ist. Ein paar Interupts vielleicht aber mehr nicht. Solange nicht Highspeed im Mittelpunkt steht völlig irrelevant. Hier ging es wirklich von Abfang an nur um eine! Richtung. Und um den Hobbybereich und nicht im AKW. Was sollen dann da die ganzen anderen Busse wie i2c, Lin, Can u.s.w. Irgendwann kommt jemand noch mit Ethernet. Alles was man sich an fremden Libs mit ins Boot holt, muss man verstehen oder fällt irgendwann darauf rein. Also wenn es nicht nötig ist, dann lieber die paar Bytes mit den wirklich einfachen UART-Befehlen versenden und gut. Manchmal denke ich hier sind welchen aus dar Architekten-Branche mit dabei, für die gilt ja bekanntlich: je mehr es kostet desto mehr bleibt für einen selbst übrig. Ein paar Wald- und Wiesen- Transitoren oder Optokoppler hat jeder in der Kiste, und mehr braucht man für diesen Anwendungsfall nicht. Wenn die galvanische Trennung nützlich ist, dann Optokoppler, wenn nicht dann eben direkt. Je schneller es gehen soll, desto niederohmiger muss das werden. Mehr nicht.
Hallo Leute, da ich gerade das Gefuehl habe, dass dieses Thema etwas den Rahmen sprengt - fuer mich zumindest - hier nochmal eine kurze Zusammenfassung meines Vorhabens: Ich moechte eine Bus-Struktur mit AVR-uC aufbauen (http://www.mikrocontroller.net/attachment/96944/Concept.png). Dabei gibt es einen Master und x Slaves. Jeder Slave hat eine feste Adresse (gesetzt per Dip-Schalter). Es gibt nur Kommunikation vom Master zu dem Slaves. Kein 'Slave -> Master' oder 'Slave -> Slave'. Der Master sendet Datenpakete ueber den Bus an die Slaves. Ein Datenpaket soll dabei aus 4 Byte bestehen: - 1 Byte Adresse - 3 Bytes Nutzdaten. Aufgrund der Bus-Struktur, empfaengt jeder Slave jedes gesendete Datenpaket. Bei der Auswertung der Daten entscheidet der Slave, ob die Nutzdaten fuer ihn relevant sind oder nicht. Entfernungen von mehreren Metern zwischen Master und Slave sind moeglich. Nun suche ich ein Bus-System, dass diese Anforderung erfuellt: Einer sendet, alle anderen Empfangen. Wobei der Sender(Master) fest gelegt ist. ------------------------------------------------------------- Jens schrieb: >Wieviel Slaves sind es denn? Therotisch von einem bis x Slaves. Wobei x nicht einmal durch die Anzahl moeglicher Adressen (1 Byte) beschraenkt wird, da es durchaus mehrere Slaves mit der gleichen Adresse geben kann. Jobst M. (jobstens-de) schrieb: >Sollen Fehler entdeckt werden? Theoretisch ja, ist aber erstmal nicht soo wichtig. Treten Uebertragungsfehler auf, wuerde ich mich um eine entsprechende Codierung und Decodierung der Daten kuemmern, wenn die Bus-Struktur aufgebaut ist. Bisherige Vorschlaege waren: 1. TWI/I2C 2. CAN-Bus 3. RS485 (http://www.mikrocontroller.net/attachment/97159/485.gif) 4. UART + Optokoppler (http://www.mikrocontroller.net/attachment/97095/Midi_Bus.gif) 5. LIN-Bus Zu 1.) Habe ich bereits etwas drueber gelesen. Ich weiss, dass viele AVRs bereits eingebaute HW dafuer mitbringen. In dieser HW, kann man jedem AVR eine TWI-Adresse fest zuweisen. Wuerde ich nun jedem Slave die gleiche TWI-Adresse zuweisen, wuerde dann jeder Slave jedes Datenpaket bekommen? Allerdings gibt es bei dieser Uebertragungsart - soweit ich weiss - einiges an Management im Hintergrund (ACK etc.). Koennten diese Management-Sachen nicht irgendwelche Probleme hervorrufen? Zu 2.) Kenne ich mich noch nicht wirklich mit aus - habe ich eher nur mal gehoert. Wenn ich mir aber das Datenblatt vom PCA82C250 anschaue, erscheit es mit so, als ob ich dann "einfach" die Daten ueber den UART der AVRs sende und empfange? Der PCA82C250 wandelt die Daten entsprechend um, so, dass diese ueber den CAN-Bus gesendet werden koennen. Spontan wuerde ich sagen, ich verbinde alle CAN_H und CAN_L jedes PCA82C250 miteinander um den Bus aufzubauen? Vermutlich noch ein paar Widerstaende dazu. Zu 3.) Aehnlich wie 2., nur dass andere Treiber-ICs benutzt werden. In diesem Fall z.B. die ICs SN75176A oder MAX485. Zu 4.) Bisher die optimistischste Variante. Im Prinzip auch senden und empfangen ueber die UARTs der AVRs. Problem war hierbei, dass bei der Uebertragung ein gewisser Strom fliesst. Dieser Strom multipliziert sich dann mit der Anzahl der Slave und kann gut auf einige 100mA kommen. Entsprechende Treiber benoetigt? Zu 5.) Hab ich gerade das erste oder zweite Mal gehoert, muss ich zugeben. Kann daher noch nicht viel dazu sagen. Aber den bisherigen Beitraegen dazu entnehme ich, dass diese Variante nicht unbedingt die "beste" fuere den Fall hier ist. Bitte korrigiert mich. Ich selber wuerde im Augenblick zu den Varianten 2, 3 oder 4 tendieren. Der Vorteil fuer mich ist, dass ich die UARTs der AVRs nutzen kann, wozu es gute Tutorials und unmengen an bestehender Software gibt. Nur, kann ich mit diesen Systemen auch den entsprecheden Bus aufbauen?? Schoenen Gruss! :) EDIT: Trotz aller Muehen, die Rechtschreibung zu wahren, habe ich es natuerlich im Titel vermasselt. Ich wuerde daher einen Mod bitten, dass fehlende "g" bei Bedin(g)'ung im Titel zu ergaenzen. ;)
Hi >Bitte korrigiert mich. >Zu 3.) >Aehnlich wie 2., nur dass andere Treiber-ICs benutzt werden. In diesem >Fall z.B. die ICs SN75176A oder MAX485. Der, von dir erwähnte, PCA82C250 ist lediglich ein Bustreiber. Der stellt nur die Verbindung zwischen CAN-Bus und CAN-Controller her. Letzterer ist für das definierte CAN-Protokoll zuständig. Ohne CAN-Controller kann man mit den PCA82C250 (o.ä.) auch einen Bus mit eigenem Protokoll realisieren. Das ist dann aber kein CAN mehr RS485 beschreibt lediglich die elektrischen Eigenschaften des Busses. Für das Protokoll bist du zuständig. >Zu 4.) >Bisher die optimistischste Variante. Im Prinzip auch senden und >empfangen ueber die UARTs der AVRs. Problem war hierbei, dass bei der >Uebertragung ein gewisser Strom fliesst. Dieser Strom multipliziert sich >dann mit der Anzahl der Slave und kann gut auf einige 100mA kommen. >Entsprechende Treiber benoetigt? Eher eine exotische Variante. RS454- und CAN-Bustreiber lassen sich problemlos an der UART eines AVRs betreiben. MfG Spess MfG Spess
Also um mal ein wenig Klarheit zu schaffen. Ihr redet von zwei unterschiedlichen Sachen. Man muss beachten dass die Adressierung nichts mit dem Physikalischen Medium zu tun hat. So kann man zum Beispiel auch ein CAN-Bus mit RS 485 betreiben. Die Bausteine für RS485 und CAN benutzen beide Differenzielle Signale mit denen man ein Bus-System aufbauen kann. Beide müssen auch am Ende terminiert werden und weisen fast die gleichen Eigenschaften auf. Im Prinzip kann die physikalische Schnittstelle des CAN-Busses auf unterschiedliche Weise realisiert werden. CAN ist mehr im Bereich des Protokolls definiert, dass man mit dem AVR dann nachbauen muss. Aber nur weil ich ein CAN Treiber benutze heißt dass nicht, das ich nur noch senden muss und der Treiber macht den Rest. Der Frame muss immer noch selbst generiert werden oder mit einer lib. Nur weil ein CAN Treiber eingesetzt wird ist es noch kein CAN-Bus. Erst das Protokoll macht es dazu. Die Varianten über CAN, RS845 und Optokoppler sind eigentlich das gleiche. Man muss einen Frame über den Uart schicken der dann letztlich über eins der drei Varianten versenden wird. Die Sende- und Empfangs- Routine musst du immer noch selber programmieren. Und diese machen letztlich erst die Adress Verwaltung. Also Physikalisch sind RS485 und CAN eigentlich die bessere Wahl, da sie Störungs- unanfälliger sind. Welches Protokoll du wählst ist dir überlassen. Ob du nun mit 8Bit arbeitest oder mit 9Bit für die Adressierung. Eine Adresse musst du so oder so senden. Der MPCM hat nur den Vorteil das er die Controller die nicht angesprochen sind bei ihrer Arbeit nur dann unterbricht wenn eine Adresse gesendet wird aber nicht bei Daten. Wenn diese aber in der Zeit so wie so nichts zu tun haben ist es egal was du benutzt. Das CAN Protokoll finde ich jetzt in deinem Fall unnötig. Es würde reichen wenn du ein Frame aufbaust mit 7 Byte. 1 Byte | 4 Byte | 2 Byte Adresse | Daten | CRC Somit hast du alles was du brauchst wobei die CRC mehr oder weniger optional ist.
Tsmc (Gast) schrieb: >Also um mal ein wenig Klarheit zu schaffen. Ihr redet von zwei >unterschiedlichen Sachen. Man muss beachten dass die Adressierung nichts >mit dem Physikalischen Medium zu tun hat. Gut, das ist mir nun soweit klar. Mir geht es zur Zeit erstmal um das physikalische Medium, ueber das ich Bits vom Master zu den Slave uebertragen kann. Tsmc (Gast) schrieb: >Die Varianten über CAN, RS845 und Optokoppler sind eigentlich das >gleiche. Man muss einen Frame über den Uart schicken der dann letztlich >über eins der drei Varianten versenden wird. Die Sende- und Empfangs- >Routine musst du immer noch selber programmieren. Dazu kann man doch dann die HW-UART der AVRs nutzen? Ansteuern tut man diese natuerlich mit Software. Als Beispiel die Funktionen aus dem AVR-Tutorial: http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART#Senden_von_Zeichenketten und http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART#Empfangen_von_Zeichen_per_Interrupt Tsmc (Gast) schrieb: >Und diese machen letztlich erst die Adress Verwaltung. Was ist mit dieser "Adressverwaltung" genau gemeint? Kuemmert es die UART-HW welcher uC seine Daten empfaengt? Tsmc (Gast) schrieb: >Welches Protokoll du wählst ist dir überlassen. Da hatte ich mir mein 4 Byte Ding ausgedacht (1 Byte Adresse, 3 Byte Nutzdaten). Optional natuerlich noch irgendwelche Checks, ob die Daten OK sind. Tsmc (Gast) schrieb: >Eine Adresse musst du so oder so senden. Der MPCM hat nur >den Vorteil das er die Controller die nicht angesprochen sind bei ihrer >Arbeit nur dann unterbricht wenn eine Adresse gesendet wird aber nicht >bei Daten. Wenn diese aber in der Zeit so wie so nichts zu tun haben ist >es egal was du benutzt. Kann ich die Multi-Prozessor-Kommunikation nicht einfach aus lassen? Es soll mir ja recht sein, wenn jeder Slave jede Nachricht erst einmal bekommt und dann entscheidet was er mit den Daten macht. Tsmc (Gast) schrieb: >Es würde reichen wenn du ein Frame aufbaust mit 7 Byte. > 1 Byte | 4 Byte | 2 Byte >Adresse | Daten | CRC Wofuer ist bei diesem Beispiel genau die Adresse gedacht? Wann soll die womit verglichen werden? Vielen Dank und einen schoenen Gruss. :) P.S.: Bin das Wochenende ueber weg. Werde somit vermutlich erst wieder am Dienstag hier reinschauen.
Chris L. (hazdur) schrieb: >Dazu kann man doch dann die HW-UART der AVRs nutzen? Genau für diese Varianten kannst du den HW-UART nutzen. Chris L. (hazdur) schrieb: >Da hatte ich mir mein 4 Byte Ding ausgedacht (1 Byte Adresse, 3 Byte >Nutzdaten). Optional natuerlich noch irgendwelche Checks, ob die Daten >OK sind. Das Protokoll das du dir ausgedacht hast ist im Prinzip OK. Ist halt ohne Fehlerüberprüfung. Chris L. (hazdur) schrieb: >Kann ich die Multi-Prozessor-Kommunikation nicht einfach aus lassen? Es >soll mir ja recht sein, wenn jeder Slave jede Nachricht erst einmal >bekommt und dann entscheidet was er mit den Daten macht. Natürlich kannst du ihn auslassen. Jeder Teilnehmer Empfängt dann halt alles, ob es nun eine Adresse ist oder Daten die vielleicht auch gar nicht für ihn bestimmt sind. Natürlich kannst du dann die Daten immer noch verwerfen. Der Vorteil ist einfach nur wenn auf einem Bus viele Daten gesendet werden, wird jeder Teilnehmer damit belastet und muss seine Arbeit unterbrechen. Wenn du allerdings den Empfang per Polling machst spiel dies keine Rolle da dein Controller so wie so immer den Uart prüft. Es hat halt nur Auswirkung wenn du den Empfang mit Interrupt machst. Dann bekommt dein Controller für jedes Byte ein Interrupt. Aber wie schon gesagt wenn dein Controller nur etwas machen wenn er einen Befehl bekommt (z.B.: ein Lampe ein/aus schalten) dann ist es völlig egal. Chris L. (hazdur) schrieb: >Wo für ist bei diesem Beispiel genau die Adresse gedacht? Wann soll die >womit verglichen werden? Die Adressverwaltung die bei diesen Varianten sind alle Software basierend auch beim MPCM. Du musst also in deinem Programm die Zieladresse im Frame mit der Adresse deines Slaves vergleichen damit der Slave weis ob er gemeint ist oder nicht. Dies hast du ja auch ein deinem Protokoll so vorgesehen. Ich hatte halt 4 Daten Bytes vorgesehen statt 3 Byte wie du.
Hi Knut, warum so negativ hab ich Dir was getan? Knut Ballhause schrieb: > Nicht auch noch LIN... Warum denn nicht? Geht einfacher klar, aber bietet Standards wie Checksummen etc. und ein relativ einfaches 2 Leitungsinterface (Data & Gnd) und ein relativ störsicheres Übertragungsverhalten, oder nicht? Soweit ich das kenne ist nicht mal Schirmung oder Twistet pair wirklich erforderlich (umgebungsabhängig?). >> Ich denke es gibt AVRs mit LIN > > Nope. sry : http://www.atmel.com/dyn/products/devices.asp?family_id=607 behauptes was anderes: The ATtiny87 : provides the following features: 8KB of In-System Programmable Flash, 512 bytes EEPROM, 512 bytes SRAM, 6 general purpose I/O lines, 32 general purpose working registers, one 8-bit Timer/Counter with compare modes, one 8-bit high speed Timer/Counter, Universal Serial Interface, a LIN controller, Internal and External Interrupts, a 4-channel, 10-bit ADC, a programmable Watchdog Timer with internal Oscillator, and three software selectable power saving modes. >Nur für Automotive-Buden Es gibt lt. Atmel auch noch die Automotive Variante ATtiny87 AUTO Unterschiede habe ich mir nicht angesehen (TempBereiche, Lagerfähigkeiten, Stromverbrauch, kann vieles sein)... >oder noch nicht am Markt. Yep, keine Verfügbarkeit, also eher theoretisch, konnte ich ja nicht ahnen. >Wozu auch. Um mehere uC einfach miteinander über LIN zu verbinden ;-) ? Aktuell finde ich keine gewünschte Datenrate (überlesen?) und keine echte Länge("meherere Meter", überlesen?). Ob das mit RS485 funktioniert und welchen Aufwand Plug&Play von Slaves a.d. STelle physikalisch bedeutet weiss ich nicht und habe daher nichts dazu beizutragen. Mit LIN geht das alles soweit ich weiß in einem bestimmten Rahmen. Welchen Aufwand das bzgl. der Lib/dem Speicher bedeutet weiß ich nicht (LIN Beiträge gibts ja mehrere im Forum - jetz kennt Chris den Bus kann selber schauen) aber physikalisch ist das mit weniger Aufwand als CAN oder ETH wie ziemlich weit oben beschrieben zu realisieren... Auswählen muss Chris es eh selber, ob es für seine Anwendung passt kann nur er entscheiden. Also bitte als Hinweis verstehen, Danke... In diesem Sinne schönen Abend //hufnala
Tsmc (Gast) schrieb: >Das Protokoll das du dir ausgedacht hast ist im Prinzip OK. Ist halt >ohne Fehlerüberprüfung. Klar ist das nicht DAS Protokoll, gebe ich dir vollkommen recht. Ist bisher nur ein erster Entwurf, den ich mir mal ausgedacht habe. Gewohnheitsmaessig sieht es dann bei der Realisierung eh anders aus. ;) Tsmc (Gast) schrieb: >Die Adressverwaltung die bei diesen Varianten sind alle Software >basierend auch beim MPCM. Du musst also in deinem Programm die >Zieladresse im Frame mit der Adresse deines Slaves vergleichen damit der >Slave weis ob er gemeint ist oder nicht. Dies hast du ja auch ein deinem >Protokoll so vorgesehen. Ich hatte halt 4 Daten Bytes vorgesehen statt 3 >Byte wie du. Vielen Dank, habe ich soweit verstanden. Lars Hufnagel (hufnala) schrieb: >Aktuell finde ich keine gewünschte Datenrate (überlesen?) und keine >echte Länge("meherere Meter", überlesen?). Nein, du hast nichts ueberlesen. Es ist mein erstes Porjekt, bei dem ich uC miteinander "vernetzen" moechte. Mein Wissen bzgl. des "Vernetzens" ist daher noch sehr rar. Da das Projekt bisher (fast) nur in meinem Kopf existiert, kann ich auch noch keine genauen Werte nennen. Bzgl. der Laenge kann ich aber sagen, dass es sich im Bereich von 5 - max. 30 m halten wird. Lars Hufnagel (hufnala) schrieb: >...jetz kennt Chris den Bus kann selber schauen In der tat, vielen Dank, das werde ich tun. :) Lars Hufnagel (hufnala) schrieb: >Auswählen muss Chris es eh selber, ob es für seine Anwendung passt kann >nur er entscheiden. Vielen Dank an alle dafuer! Auf meine Frage habe ich nun die entsprechenden Antworten und kann alleine weiter machen. Welches physikalische Medium ich jetzt genau verwenden werde, weiss ich noch nicht. Wo ich mir aber sicher bin, ist, dass ich das Protokoll gerne selber "entwickeln" oder gestalten moechte, um es meinen Beduerfnissen anpassen zu koennen. Ich bin aber dennoch offen fuer weitere Ideen und Vorschlaege. :)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.