Hallo. Ich möchte den RS485 zur Kommunikation unter mehreren Atmel-Controllern benutzen. Als Treiberbausteine würde ich den LTC485 benutzen. Nun zu den Unklarheiten: hat jemand informationen oder ein tutorial, wie man das ganze programmtechnisch angehen muss? freundliche Grüße,
torsten schrieb: > hat jemand informationen oder ein tutorial, wie > man das ganze programmtechnisch angehen muss? Ja, ich.
Als erstes benoetigst Du ein Protokoll. Dann ist die Programmierung auch gegeben. Das Protokoll ergibt sich aus den Anforderungen. Was sind denn die Anforderungen ?
Also um gleich mal alle Punktu zu erwähnen: Master-Slaves vollduplex Modellbahn Über ein Protokoll habe ich mir auch schon Gedanken gemacht: |Anfangsbyte|Adresse|Unteradresse|Befehl|Abschlussbyte| Die Adresse wäre dann die eines Controllers und die Unteradresse z.B. die eines Signals o.ä.. Wenn es allerdings ein Standart-Protokoll gibt, welches nicht so kompliziert, wie das des CANs ist, wäre das natürlich auch gut!?
HI >-Master-Slaves Dann sieh dir mal den Multi Processor Mode der UART an. >-vollduplex Mit dem LTC485? MfG Spess
torsten schrieb: > Wenn es allerdings ein Standart-Protokoll gibt, welches nicht so > kompliziert, wie das des CANs ist, wäre das natürlich auch gut!? Wenn du schon CAN erwähnst, solltest du ihn vielleicht auch benutzen. torsten schrieb: > Master-Slaves > vollduplex > Modellbahn Um noch einen Begriff in den Raum zu werfen: Kreuzschiene SDI RS485 vollduplex geht nur mit 4Adern+Masse. Die Treiber sind etwas schwach, um auch noch deine Eisenbahn anzutreiben.
Das erinnert mich an Sprüche aus dem PM: "UART ist tot, heute verwendet man RS485!" Die Kommunikation läuft über UART und dann kommt ein entsprechender Tranceiver zum Einsatz. z.B: RS232 RS485 0-24V (bei IO-Link) / ... Das beschreibt nur die pysikalische Übertragung. Profibus verwendet ebenfalls eine UART mit RS485. Unterschied ist das Protokoll eine Ebene höher. Schau dir mal das OSI Schichtenmodell an!
chick schrieb: > Du weißt schon, daß sich RS485 und vollduplex widersprechen? Bei eindeutigen Master-Slave-Beziehungen eben nicht: http://www.rn-wissen.de/index.php/RS485 Es grüßt RainerK
Jap, hab Protokoll+Implementierung (atmega, Xmega, PC, gut portierbar auf andere Architekturen) das für deine Zwecke ganz gut geeignet sein müsste. Bei Interesse melden ;) Standardprotokolle gibts bei RS485 nicht, RS485 is im wesentlichen nur die Busspezifikation und multiprotokollfähig, dh. man kann da drüberjagen was man will. Oft wird einfach die USART von Mikroprozessoren genommen und auf RS485 umgesetzt. Und dann byteorientierte Protokolle (wie du auch den Ansatz hättest)
torsten schrieb: > Wenn es allerdings ein Standart-Protokoll gibt, welches nicht so > kompliziert, wie das des CANs ist CAN ist nicht kompliziert. Im Gegenteil, es ist um Größenordnungen einfacher als UART/RS-485. Ich verstehe nicht, warum man sich für neue Projekte noch das uralte RS-485 antut. Vermutlich aus Langeweile, damit man länger programmieren darf. Das CAN macht alles komplett in Hardware. Du stellst nur eine Nachricht in den Sendepuffer und wenn sie mindestens ein Teilnehmer empfangen konnte, kriegst Du einen Interrupt: "Ich habe fertig". Der Empfänger kriegt auch nen Interrupt: "Da ist was im Puffer". Ob Master, Slave, Fehlererkennung, Arbitrierung, Retry und anderen Protokollkrams mußt Du Dich nicht kümmern. Einfacher gehts nun wirklich nicht Peter
Also steht jetzt praktisch CAN gegen RS485. Ich wollte den RS485 verwenden, da er ziemlich zuverlässig ist und multiprotokollfähig. Ich wollte ja eigentlich auch ein eigenes Protokoll entwerfen, es muss ja nicht sooo groß sein ;). Um mal zusehen wie viel aufwand das ist, wäre es nett, wenn Thomas mir mal seine Bemühungen nahelegt? vielen Dank für die Bemühungen, torsten
Nee, CAN ist fuer Autos und dergleichen. die maximale Meldungslaenge ist um die 6 Byte. Da ist nichts mit Filetransfers, resp das wird muehsam.
Pico Oschi schrieb: > Da ist nichts mit Filetransfers, resp das wird muehsam. Das ist Quatsch. Wir benutzen den CAN auch für Firmwareupdate (Bootloader), das geht ganz leicht. Der Bootloader nimmt 8 MOBs als Empfangspuffer, damit kann er 64 Byte am Stück empfangen. Danach gibts ne Quittung und die nächsten 64 Byte können kommen usw. Damit sich die 8 MOBs nicht in der Reihenfolge tauschen, sind 3 Bits im Identifier die Paketnummer. Peter
torsten schrieb: > Ich wollte den RS485 verwenden, da er ziemlich zuverlässig ist und > multiprotokollfähig. Ob er das ist, bestimmst Du allein mit Deiner Protokollsoftware. Der CAN ist es dagegen schon von Haus aus. Die UART ist ohne Protokoll nur ne unzuverlässige Krücke. Peter
Was ich brauche ist ein Programmierbespiel für einen Datenbus, also wie man überhaupt erstmal etwas sendet. Vielleicht gibt es ja auch ein tut, was ich dooferweise nicht gefunden habe!?
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.