RS485 Protokoll auf einen ATmega32

Pascal Gast #919660
Lesenswert?
• ▲
▼ 
Hallo,

ich möchte zwei ATmega32 miteinander vernetzen. Der eine sitzt ca. 60m 
(in HF-verseuchter Umgebung) von dem anderen uC entfernt. Ziel ist es 
mit dem einen uC eine Steuerung zu realisieren und mit dem anderen eine 
Art zusätzliche "Fernbedienung" zu realisieren.

Ich dachte mir, dass ich das ganze per RS485 übertragen, denn für RS232 
ist der weg zu lang und andere Busse sind ggf. zu anfällig auf die 
starken elektromagnetischen Felder!?

Ich habe schonmal einen ATmega (vom STK500 mit AVRStudio und WinAVR) mit 
dem PC via RS232 sprechen lassen, mehr Erfahrung habe ich auf dme Gebiet 
nicht.

Soweit ich nun herausfinden konnte benötige ich nun für jeden uC einen 
RS485 Bustreiber (z.B. MAX485), die Ein-/Ausgänge zum uC trenne ich noch 
mit schnellen Optokopplern. Benötige da wohl 3 Pins vom uC (TXD, RXD, 
Richtung) und somit für den Bus eine 3-Draht-Leitung für halfduplex.

Nur: Wie implementiere ich das nun im Programm, was muss ich 
programmieren, ich hab keinen Plan wo ich anfangen soll. Gibt es denn 
ggf. fertige Libs für ein RS485 Protokoll??

Für jegliche Hilfestellung wäre ich sehr dankbar.

Grüße Pascal
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Andreas K. #919666
Lesenswert?
• ▲
▼ 
RS485 (und RS422) sind keine Protokolle, sondern nur Definitionen von 
Übertragungsleitungen. Wenn du mit 4 statt 2 Leitungen (evtl. plus GND) 
leben kannst, nimm RS485 oder RS422 full duplex statt RS485 half duplex, 
dann ändert sich softwareseitig gegenüber RS232 rein garnichts, weil 
beide Richtungen unabhängig arbeiten können und somit keine 
Richtungsumschaltung nötig ist.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Pascal Gast #919703
Lesenswert?
• ▲
▼ 
Hi,

vier Adern (plus GND) sollten kein Thema liegen, auf der Strecke liegt 
noch eine CAT5-Leitung (also 8 Adern plus Schrim). Die kann ich alle 
verwenden...

Jetzt ne blöde Frage: Du sagst, es ändert sich dann nichts auf der 
Softwareseite?
Was heißt das nun genau? Wie schließe ich denn nun die 
Schnittstellen-ICs an den uC an, wie steuere ich denn nun den Transfer?
Kann mir jemand ma ein Codeschnipsel zukommen lassen wie dass für mein 
Problem aussehen könnte? (z.B. ich drücke am uC 1 einen Taster, der uC 2 
soll das per RS485 "erfahren" und einen Ausgang schalten).


Grüße Pascal
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas K. #919718
Lesenswert?
• ▲
▼ 
Pascal wrote:

> Was heißt das nun genau?

Das heisst, dass die Kommunikation exakt genauso verlaufen kann, als 
wäre die Verbindung mit RS232 realisiert. Einzig die Leitungen selbst 
und deren Treiber unterscheiden sich.

> Wie schließe ich denn nun die
> Schnittstellen-ICs an den uC an,

Beispielsweise MAX488, oder auch gleich potentialgetrennt mit MAX1490. 
Wie das aussieht steht in den Datasheets.

> wie steuere ich denn nun den Transfer?

Du schreibst, dass du RS232 schon mal verwendet hast. Genau so.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Pascal Gast #919873
Lesenswert?
• ▲
▼ 
Alles klar, dann ist mir schonmal ein wenig geholfen.

RS232 hab ich schonmal verwendet um vom uC zum PC (Terminalprogamm) 
Infos zu senden und um vom PC Terminal Befehle an den uC zu senden.
Wie mache ich das denn nun wenn statt dem PC der zweite uC ins Spiel 
kommt? Wie regle ich wann wer sendet und wann hört? Wie verpacke ich die 
Steuerinformationen für den jeweils anderen uC?

Grüße
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jochen S. #919915
Lesenswert?
• ▲
▼ 
Hallo,
der Witz liegt darin, dass du jeweils 2 Bustreiber pro Teilnehmer hast 
und von denen je einer an TX und einer an RX hängt. Derjenige der an TX 
(senden) hängt ist dauherhaft so beschaltet das er sendet der an RX 
(empfangen) ist so beschaltet, dass er dauerhaft empfängt. Dadurch hast 
du den Sende/Empfangswechsel weg.

Jochen
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter.B Gast #934594
Lesenswert?
• ▲
▼ 
Hallo,

es fehlt wohl noch das Protokoll.

Da muss man nicht alles neu erfinden. Sowas gibt es schon.

Für eine Punkt zu Punkt Kopplung hat Siemens schon vor langer Zeit das 
Protokoll 3964R / RK512 definiert. Die Dokumentation dazu steht auf der 
Siemens Internetseite (Bereich Automation) zum Download bereit.

Von dem ganzen Protokoll braucht man in der Regel nur eine kleine 
Teilmenge. Das sollte innerhalb von 2 bis 3 Tagen programmiert und 
getestet sein.

Das Siemens Protokoll zeichnet sich auch durch eine sehr hohe 
Datensicherheit aus, da es verschiedene Fehlerüberprüfungen beinhaltet.

Leider sind mir keine Bibliotheken bekannt, die man für einen 
Microcontroler bekommen kann.

Ein anderes sehr schönes und sehr leistungsfähiges Protokoll ist der 
Modbus. Auch für dieses Protokoll steht die komplette Dokumentation im 
Internet kostenlos zum Download bereit.

Mit dem Modbusprotokoll kann man problemlos ein System mit einem Master 
und mehreren Slaves aufbauen. Auch hier braucht man in der Regel nur 
eine kleine Teilmenge der gesamten Funktionalität.

Der Modbus ist einer der weltweit verbreitesten Bussysteme auf RS485- 
Basis. Für diesen habe ich auch schon mal fertige Bibliotheken für AVR 
etc. gesehen. Leider waren diese Angebote immer kommertiell.

Die Notwendige Teilmenge des Modbus für einen einfachen Datenaustausch 
zwischen 2 Partnern sollte innerhalb von 1 bis 3 Tagen programmiert und 
getetstet werden können.

Bei allem gilt: Google hilft wunderbar.

Viel Spass
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren