RS485 -Logger - ein paar Fragezeichen

[Volkhard (Gast)]

Ich stehe beruflich oft vor dem Problem, Gerätschaften mittels RS485 zu
verbinden bzw. anzusteuern (max. 115kb/s). Da es dabei doch manchmal zu
Problemen kommt bzw. es interessant wäre, mitzuschneiden was dort hin
und her geht, plane ich jetzt, mir eine Art RS485 Datenlogger (mit ein
paar weiteren Funktionen) auf Basis eines ATMEGA128 zu bauen.
Das Gerät soll mit zwei RS485 Schnittstellen und einer RS232 für die
PC-Anbindung ausgestattet werden. Die beiden RS485 sollen über die
USARTs des ATMEGA bedient werden, der RS232 per Software emuliert
werden.
Momentan habe ich noch zwei große Fragezeichen in meinem Konzept:
1. Ich möchte verschiedene Betriebsweisen realisieren. Einmal sollen
die beiden RS485-Treiber sozusagen Back-to-Back zusammengeschaltet
werden und der ATMEGA soll nur auf seinen Tx-Leitungen lauschen und
mitschneiden. In einem anderen Fall sollen die RS485 komplett über den
ATMEGA abgewickelt werden, um beispielsweise eigene Sequenzen
abzusetzen. Diese Umschalterei (Back-to-Back <=> komplette Anschaltung
an Rx/Tx) möchte ich ungern über mechanische Relais erledigen. Was
bietet sich hier alternativ an?
2. Die Menge an Daten, die mitzuschneiden sind, sind relativ gering, so
dass ich zunächst mit dem RAM des ATMEGA auskommen werde. Allerdings
habe ich noch so ein paar Ideen, die ich mit der Kiste umsetzen möchte,
so dass ich zusätzlichen Speicher mit einplanen möchte. Was ist aus
eurer Sicht/ Erfahrung praktikabler: Die Nutzung von externem RAM über
die entsprechenden Adress-/Datenleitungen des ATMEGA oder der Anschluss
von Speicherbausteinen über I2C? Es soll kein Riesenspeicher werden -
ich denke, 64kbit dürften reichen. Es dürfte auch nicht allzu
zeitkritisch sein, da die Telegramme recht klein sind, so dass ein
Puffern im internen RAM allemal möglich ist, um dann die Daten
wegzuschreiben.

Sorry für den vielen Text, aber außer in meinem Kopf existiert noch
kein Schaltplan.

[juergen klauck (Gast)]

hi
leg doch mal den schaltpan aus deinem kopf hier ab
dann koennte man vieleicht was dazu sagen
juergen

[Olaf (Gast)]

Schalte die Datenleitung nach der Umwandlung zwischen RS485 nacht TTL
um. Ich sach nur OR/AND Gatter. Oder auch Encoder. Es gibt vermutlich
dutzende von Logicbausteinen mit denen du das machen koenntest.

Die Ansteuerung von Speicher ueber I2C ist natuerlich schoen einfach
wegen der wenigen Leitungen. Ich weiss aber jetzt garnicht ob es grosse
Rams mit I2C Bus gibt. Solltest du ueber EEPROM nachdenken musst du die
Speicherzeit beruecksichtigen.

Olaf

[Volkhard (Gast)]

So, ich habe versucht, meine Vorstellungen für das Gerätekonzept zu
Papier zu bringen. Herausgekommen ist das angehängte Blockschaltbild
mit eingetragenen Fragezeichen.
Es ist richtig, dass zwischen den RS485-Ports TTL-Pegel herrscht,
allerdings bin ich mir nicht ganz sicher, ob ich die gewünschte
Funktionalität einfach mit Logik hinbekomme. Bei der eingetragenen
Tastatur/Display überlege ich mir das Leben leicht zu machen und ein
fertiges Modul (z.B. von Robotikhardware mit I2C) einzusetzen.

[juergen klauck (Gast)]

hi!
schau hier vorbei http://www.rs485.com/prs485hub.html
die haben pdf vieler ihrer "sachen" auf der seite
als anregung (von wegen relais und so ) .-}
gruss juergen

[Rahul (Gast)]

Zu 1:
Prinzipiell könnte man das mit dem Lauschen und und Mitschneiden
dadurch realisieren, dass die Kommunikation durch den ATMega128 läuft,
sprich die Daten von der einen Schnittstelle einfach an die andere
übergeben werden.
Sonst könnte man auch Multiplexer oder Datenselektoren aus den
TTL-/CMOS-Baureihen benutzen (4051) und die Datenwege (Sendeleitungen
TXD)
umschalten.

Prinzipiell bleiben die RX-Leitungen des ATMega128 ja mit den
RX-Leitungen des Tranceivers verbunden.

Dass RS485 ein bidirektionaler Bus (also nur insgesamt 2 Leitungen für
Senden und Empfangen) ist, ist dir klar, oder? Somit muß auch die
Datenrichtung der Transceiver gesteuert werden.

<Moment in dem ich mir dein Bild angeguckt habe>

Was Du beschrieben/gemalt hast, fällt unter RS422. Dem differentiellen
Pendant zur RS232.
Übrigens hast Du RXD und TXD vertauscht.
Als Umschalter müsste ein 4051,4052 oder 4052 infrage kommen.
Die werden auch als Analog-Multiplexer betrieben. Im Digitalbetrieb
wird dann die negative Versorgungsspannung auf Masse (GND) gelegt.


Zu 2: kann ich leider nichts sagen, da ich noch nie mit externem RAM
arbeiten musste.
I²C ist auf jeden Fall löttechnisch einfacher. Programmiertechnisch
etwas aufwändiger. Bei Verwendung der Adress- und Datenleitungen müsste
es vom Aufwand her andersherum sein.
Ob es RAM auf I²C-Basis gibt, bezweifle ich etwas... Ist aber nur eine
Vermutung.

[Volkhard (Gast)]

@Rahul
Vielen Dank für deinen Kommentar. Der Hinweis mit den Multiplexern ist
glaube ich genau richtig - bin ehrlich gesagt ein bisschen aus der
Übung mit den Hardwarekomponenten.
Mit dem Vertauschen von Rx und Tx hast du natürlich recht (Freudsche
Fehlleistung).
Bei RS422/485 bin ich allerdings anderer Ansicht.
Es gibt in der RS485-Welt nicht nur Halbduplex-Betrieb mit zwei
Drähten. Ein RS485-Bus mit mehreren Teilnehmern kann auch mittels
4-Draht im Vollduplexbetrieb laufen. RS422 wird meines Wissens nur für
den Punkt-zu-Punkt-Betrieb eingesetzt.
Siehe dazu auch
http://www.bb-europe.com/bb-euro/literature/tech/485appnote.pdf

Volkhard

[Rahul (Gast)]

RS485-Transceiver haben noch die Enable-Eingänge, mit denen der Sender
hochohmig geschaltet und der Empfänger ausgeschaltet werden kann.

4-Wire-RS485-Netzwerke sind nicht multimasterfähig (Fig. 1.7,
485appnote.pdf), aber vollduplexfähig.

2-wire-RS485-Netzwerke sind multimasterfähig, aber nur halbduplex.

Somit habe ich etwas daneben gelegen.
Hatte mich bisher nur mit der 2-wire-RS485 auseinander setzen müssen,
da auf "meinem" Bus alle gleichberechtigt sind, und auch nicht viel
los ist.
...und wieder was gelernt.

RS422 ist im Regelfall eine 1:1-Verbindung.
Standardverwendungszweck der RS422 ist übrigens die "Verlängerung"
von RS232-Leitungen um einen Faktor ~100 (15m RS232 zu 1200m RS422).
In der Meerestechnik/Schiffahrt wird das System auch gerne zur
Verteilung der Schiffs- und Navigationsdaten verwendet (NMEA und
dergl.).

Nur so als Anmerkung...