hallo leute, hat jemand schon ein einfaches protokoll für RS485 bus geschrieben? ich muß 3-4 avr's auf einen bus hängen. falls jemand schon dies programmiert hat, brauche ich nicht das rad neu zu erfinden ... :-) ansonsten muß ich mich wohl dahinterklemmen und dann natürlich hier posten :-) schöne grüße, thomas
Die Firma Kramer-Electronics hat sich mal das "Protocol 2000" für die Steuerung ihrer AV-Kreuzschienen ausgedacht. Es besteht aus 4 Byte... Du willst aber wohl eher eine Muli-Proz-Kommunikation aufbauen, wo man vielleicht 9Bit benutzt...
hallo rahul, gibt's das protokoll "lizenzfrei"? meine controller plaudern nicht wirklich permanent miteinandner ... gruß, thomas
ICh weiß ja nicht, ob das wirklich ein Protokoll für dich ist. www.kramerelectronics.com Welche Art von und wie viele Daten musst du denn übertragen? Ein einfaches selbst geschriebenes Protokoll ist vielleicht sinnvoller als ein "gekauftes".
Warum nimmst Du nicht ganz einfach den UART mit RS232 oder noch simpler I2C mit dem TWI? SPI geht auch, braucht aber ein paar Leitungen mehr.
Hi, ich hab für meinem Laufroboter ein Protokoll geschrieben. ( http://www.kreatives-chaos.com/index.php?seite=laufroboter ) Es gibt demnächst auch noch mehr Informationen dazu auf der Seite. Ich muss ihr allerdings erstmal für den Landeswettbewerb fit machen ;) Schreib mir einfach mal ne Email... MfG Kjion
hi kjion, das mit dem snap ist ein heißer tip ... das werde ich mir genauer anschauen ... thanx, thomas
@nick: ich muß längere strecken in einem wohnmobil überbrücken, da geht sich rs232 nicht aus. außerdem verwende ich den uart, nur mit einem rs485 converter vorn drauf ... dieses modell hat auch den vorteil, daß ich (mit einem pegelwandler) mit dem notebook über die rs232 schnittstelle mitsniffen kann, wie sich die controller unterhalten. gruß, thomas
@frankl: soveit ich informiert bin, ist rs232 eine punkt-zu-punkt verbindung zwischen zwei teilnehmern, bei rs485 können wesentlich mehr teilnehmer am selben bus hängen.
um genau zu sein passen an den RS485-Bus 32 Teilnehmer... Was willst du denn überhaupt übertragen? So wie ich das sehe, hast Du Messwerte (Talker) von irgendwelchen Messfühlern (Wasserstand, Batterieleistung, Chemie-Klofüllstand...) und dann wirst du auch noch ein paar Listener haben, die irgendwelche Befehle empfangen (Licht?) Da würde es sich empfehlen, die 9Bit-Übertragung zu realisieren, wobei das erste Byte eine Adresse überträgt, das zweite vielleicht einen Befehl, dann die Länge der Daten und dann entsprechend der angegeben Länge die Daten. Und vielleicht noch eine Prüfsumme. Als Rückmeldung kann man dann NAK für nicht kompletten Empfang oder ACK für gültigen Empfang geben. Bei NAK wird die Übertragung wiederholt; bei ACK ist alles i.O. Beide Befehle sind 1Byte lang und sind im ASCII zu finden. Es gibt eine ganze Menge Protokolle, die aber meistens für irgendwelche speziellen Aufgaben vorgesehen sind. Baue dir doch dein eigenes, oder willst du noch mit der Aussenwelt in Verbindung treten? Dann würde ich CAN oder Ethernet vorschlagen. Gruß Rahul
@rahul: danke für die info. es werden nur die avr's untereinander kommunizieren. ich werde mit das protokoll selber anpassen, nur ist es einfacher von einem bestehenden gerüst wegzuarbeiten. so, wie du das beschrieben hast, so stelle ich mir die kommunikation auch vor ... hast du vielleicht links zu der 9bit-übertragung bei der hand? wäre super. danke, thomas
Hi bei Multimaster-RS485 bleibt eigentlich nur CSMA/CD wie es bei Ethernet verwendet wird. Zusätzlich noch etwas "erfinden" was der Packetstruktur von Ethernet sehr ähnlich ist und man macht eigentlich nix verkehrt. Matthias
@Matthias: das mit dem Ethernet-Protokoll ist dann interessant, wenn man auch einen Controller hat, der sich um den ganzen Spaß kümmern kann. Bei Thomas' Anwendung ist die Kommunikation nur ein Mittel zum Zweck. Es wird sich dabei vermutlich um gelegentlichen Datenaustausch handeln, indem ein Master (im Cockpit / Bordcomputer) irgendwelche Slaves gelegentlich nach ihrem Status abfragt bzw. Slaves dem Master gelegentlich ihren Status zukommen lassen. @Thomas: Ich habe mal im Mikrocontroller-Kochbuch von Andreas Roth etwas darüber gelesen. Links dazu habe ich noch nicht gefunden, aber im Datenblatt zum ATmega162 steht eine kurze Beschreibung. Man kann die USART so konfigurieren, dass das 9. Bit kenntlich macht, ob es sich um Daten oder eine Adresse handelt. Bei der Modelleisenbahn gibt es auch ein interessantes Protokoll, das auf die Versorgungsspannung moduliert wird. DMX bietet sich meiner Meinung nach nicht an, weil es sich dabei nur um einen Master und viele Slaves (Listener) handelt. Am besten drei AVR nehmen, jeweils einen DS75176 (Reichelt ~50 Cent?)und die drei auf einen Bus legen. Die beiden äusseren sollten einen Terminierungswiderstand von 120Ohm zwischen Leitung A und B bekommen. Allen dreien die gleiche Applikation verpassen (LEDs ein,je nach Taster) und allen eine andere Adresse... Ich habe leider keine AVR rumliegen und mein lokaler Händler verlang 5 Euro für einen RS485-Transceiver, sonst würde ich das ausprobieren.
@rahul: danke für die hilfe. so ähnlich habe ich mir den vesuchsaufbau auch vorgestellt. ich werde versuchen, das s.n.a.p protokoll zu implementieren. da gibts auch einen art sniffer mit dem auch daten gesendet/empfangen werden können, und der über die serielle schnittstelle eines pc auf den bus gehängt werden kann. wenn es mir gelingt (und von dem gehe ich aus :-)), das protokoll standardgemäß zu implementieren, werde ich den source natürlich hier posten. für alle, die das protokoll auch interresiert: http://www.hth.com/snap/ schöne grüße und besten dank an alle, thomas
Hi es muß ja nicht das Ethernet-Protokoll sein. Aber zumindest ist CSMA/CD (Carrier Sense Multiple Access with Collision Detection) sehr einfach mit den üblichen RS485-Chips zu implementieren. Man empfängt einfach jedes gesendete Byte wieder selber und vergleicht es mit dem gesendeten. Sind sie gleich -> weitersenden, ungleich -> zufällige Zeit warten und nochmal. Wenn man dann noch Datenpäckchen schnürt mit [Absender, Empfänger, Länge, Daten, CRC] hat man im Prinzip das Ethernet-Protokoll schon drin. Ethernet hört sich immer so toll an es ist aber von der Protokollsicht sehr primitiv. BTW: 10MBit Ethernet auf TP ist elektrisch nichts anderes als RS485. Matthias
Auf Koax Kabel wird doch bei Ethernet Manchester-Codierung benutzt. Dachte auf TP wird das genauso gemacht, nicht RS232/485 like ?? Mfg Suschman
Hi ich bezog mich auf das elektrische nicht auf die Kodierung -> differentielle Übertragung. Matthias
Wer benutzt heute denn noch Koax-Verdrahtung? Naja, zumindest nicht mehr für neue Anlagen... Die Idee mit dem CSMA/CD ist doch ziemlich gut. Ich hab nur IEEE802 gesehen und dachte gleich an Manchester etc. Thomas wird den ganzen Schnickschnack um das Protokoll brauchen. Die Kollisionsdetektion ist ziemlich einfach und interessant. Rahul
"Die Kollisionsdetektion ist ziemlich einfach" Na, na. Das ist aber wirklich nur ein Gerücht ! Die RS-485-Treiber sind sehr leistungsstark. Bei langen Leitungen (hoher Widerstand) kann es daher passieren, daß sie gegeneinander kämpfen und jeder gewinnt auf seiner Seite. Keiner kriegt also die Kollision mit. Man könnte höchstens CAN-Treiber nehmen (PCA80C251), die haben einen dominanten Level, d.h. eine 0 setzt sich immer durch. Und sobald einer eine 1 sendet, aber eine 0 liest, weiß er daß er kollidiert ist. Aber dann ist es noch lange nicht einfach, diese Kollision aufzulösen. Wenn mehrere gleiche Baugruppen kollidieren, ist nämlich die Gefahr groß, daß sie auch versuchen zur gleichen Zeit nochmal zu senden, wieder kollidieren usw. usw. bis zum Sankt-Nimmerleins-Tag. Das einfachste Protokoll ist daher immer noch der Single-Master, der zyklisch alle Slaves fragt, ob sie was zu sagen haben. Und dann ist für den adressierten Slave ein Zeitfenster (z.B. 10ms) offen, in dem nur er alleine senden darf. Peter
hi, ich habe noch eine idee zur kollision: da jeder avr eine eigene adresse hat (destination im paket) - könnte er ja diese adresse zur erzeugung der pause bei einer kollision hernehmen. somit dürften eigentlich die bereits kollidierten nach dem ablauf der zeit nicht wieder kollidieren ... außerdem sollte der absender auf ein ack des empfänger innerhalb einer zeit warten - kommt es nicht, sendet er sein paket nochmals ... das ganze ist eine interessante diskussion - ich bin schon gespannt, wie meine kommunktiaon laufen wird :-) thomas
Die Idee mit der (durch Adressierung) unterschiedlichen Wartezeit ist zwar ein guter Weg um die "wiederholte" Kollision zu unterbinden, löst aber nicht das Problem der unerkannten Kollision. So wie peter schon schrieb sind die RS-Treiber so stromstark (vertragen in der Regel ja auch Kurzschlüsse) daß sie auf jedem Kabelende "richtige" Daten sehen. Eine (wenn auch nicht sehr "schöne") Möglichkeit wäre eventuell nicht per TX sondern über TX-Enable zu senden. Damit wird nur ein Pegel "stromstark" auf die Leitung gelegt (den anderen müßte man halt pull-upen bzw. -downen) und die Kollision müßte auf beiden Seiten der Leitung dedektierbar sein. Für Multimaster-Systeme halte ich CAN (als Transportlayer, das Protokoll kann man ja vereinfachen) für sinnvoller. Wenn man den CAN-Vorteil der Kollisionerkennung auf Bit-Ebene auf Byte-Fehler ausdehnt hält sich auch der Programmieraufwand in Grenzen (dafür können dann aber auch destruktive Kollisionen auftreten). grüße leo
wenn der absender auf eine ack meldung wartet, müsste es eigentlich auch klappen. nehmen wir an, wir senden und es tritt eine kollision auf, die wir nicht erkennen. dann wird der empfänger das paket auch nicht lesen können, bzw. die prüfziffer wird falsch sein ... kann der empfänger nun da paket nicht lesen, wird er auch keine ack-meldung retournieren können ... somit wird der absender nach einer gewissen zeit das paket nochmals senden (die zeit wird aus der "station id" berechnet). wäre das nicht eine idee? gruß, thomas
@matthias Hallo Matthias du hast oben geschrieben "....es muß ja nicht das Ethernet-Protokoll sein. Aber zumindest ist CSMA/CD (Carrier Sense Multiple Access with Collision Detection) sehr einfach mit den üblichen RS485-Chips zu implementieren. Man empfängt einfach jedes gesendete Byte wieder selber und vergleicht es mit dem gesendeten. Sind sie gleich -> weitersenden, ungleich -> zufällige Zeit warten und nochmal." Wie soll ich das gesendete Byte wieder empfangen. Hab nur eine Schnittstelle?? Benötige das für ein Projekt dringend. Kannst du mir das etwas genauer erklären. THX Mario
Hi die üblichen RS485 Treiber (MAX485) haben zwei Pins um den Empfänger und den Sender einzuschalten. Du schaltest jetzt einfach den Empänger immer ein und den Sender wenn du senden willst. RS485 kann ja nur Halbduplex. Matthias
@Matthias Ist das so richtig ??? Schritte im Programm: 1.der max485 wird auf empfangen eingestellt 2.Habe 1 byte zum versenden 3.der max485 wird auf empfangen und auf senden eingestellt 4.sende das byte nach Rx 5.empange das byte über Tx 6.der max485 wird wieder nur auf empfangen eingestellt Das was über Rx gegangen ist über Tx wieder zurückgekommen. Tx würde also ein verändertes bit empfangen falls ein anderer Teilnehmer zur selben Zeit sendet ??? mario
hey, - hat jemand von euch die sache mit S.N.A.P weiterverfolgt - möchte vielleicht dieses ScalableNodeAddressProtocol in meinen atmega einbinden -> um das rad nicht neu erfinden zu müssen : hat jemand vielleicht einen source dazu (in c wäre fein :) ?!?!) neubi
Ich hab mal ein Master Slave Protokoll geschrieben : http://www.ibrtses.com/embedded/shortmsgprotocol.html Master Slave bedeutet die kommunikation wird immer vom selben initiiert, sonst laeuft nichts.
Gibt es hier einen Preis zu gewinnen, wenn man die älteste Leiche ausbuddelt?
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.