vorweg wünsche ich allen ein entspanntes Pfingstwochenende.
Ich weiß nicht, ob ich gerade nur einen Denkfehler habe oder wo der Hase im Pfeffer begraben liegt.
Vorweg.
Ich betreibe einen ATMega328P/ATMega16 erfolgreich mit der UART (RS232 ähnlich)
Daten werden auch Sauber in PicoCom dagestellt.
Da ich bei meinem nächsten Projekt jedoch nicht abschätzen kann, wieviel MCUs benödigt werden, will ich via RS485 in ein Netzwerk gehen.
Soweit von der Praxis und Theorie ja alles klar.
Ergo
Testschaltung mit einem SN 75176 ausgerüstet und diesen
Selbiger Output auf der RS232 ebene liefert mir meine Testdaten, welche ich ausgeben lasse.
1
Befehlstätze:
2
WakeUp: $
3
Trans_Start: <
4
Adresse des µCU:
5
Alle: A
6
Einzeln: 5
Als Randinfo.
Terminal = Picocom v3.1
Settings:
1
picocom --b 19200 /dev/ttyUSB0
2
picocom v3.1
3
4
port is : /dev/ttyUSB0
5
flowcontrol : none
6
baudrate is : 19200
7
parity is : none
8
databits are : 8
9
stopbits are : 1
10
escape is : C-a
11
local echo is : no
12
noinit is : no
13
noreset is : no
14
hangup is : no
15
nolock is : no
16
send_cmd is : sz -vv
17
receive_cmd is : rz -vv -E
18
imap is :
19
omap is :
20
emap is : crcrlf,delbs,
21
logfile is : none
22
initstring : none
23
exit_after is : not set
24
exit is : no
Was ich mir ggf noch gut vorstellen könnte, hoffe aber nicht, das es genau dies ist.
Das von dem Umsetzer zum TestPort der GND fehlt.
Die Leitungslänge beträgt unter 10cm.
Für jene, welche es interessiert.
Hier auch der Code für meine UART inkl RS485_Control (Nur Ansteuerung)
1
{$ifdef RS485}
2
procedure RS_Control(Value: Boolean);
3
begin
4
DDRB := DDRB or (1 shl RS_485_IO);
5
if Value then
6
// True = Data Send
7
PORTB := PORTB or (1 shl RS_485_IO)
8
else
9
// False = Data Read
10
PORTB := PORTB or (0 shl RS_485_IO);
11
end;
12
13
{$endif}
14
15
procedure UARTInit(_U2X: boolean);
16
// _U2X -> True = einfache Baudrate
17
// False = Doppelte Baudrate
18
begin
19
{$ifdef M16p}
20
if _U2X then begin
21
UBRRL := (F_CPU div (16 * Baud)) - 1;
22
UBRRH := 0;
23
UCSRA := UCSRA or (1 shl U2X);
24
end else begin
25
UBRRL := (F_CPU div ( 8 * Baud)) - 1;
26
UBRRH := 0;
27
UCSRA := UCSRA or (0 shl U2X);
28
end;
29
UCSRB := (1 shl TXEN) or (1 shl RXEN);
30
UCSRC := (1 shl URSEL) or (%011 shl UCSZ);
31
{$else ifdef M328p}
32
if _U2X then begin
33
UBRR0L := (F_CPU div (16 * Baud)) - 1;
34
UBRR0H := 0;
35
UCSR0A := UCSR0A or (1 shl U2X0);
36
end else begin
37
UBRR0L := (F_CPU div ( 8 * Baud)) - 1;
38
UBRR0H := 0;
39
UCSR0A := UCSR0A or (0 shl U2X0);
40
end;
41
UCSR0B := UCSR0B or (1 shl TXEN0) or (1 shl RXEN0) or // Empfangen und Senden
42
(1 shl RXCIE0); // RX Interrupt aktivieren
43
UCSR0C := UCSR0C or (%011 shl UCSZ0) // 8 - Bit übertragung, 1 Stop-Bits
Im Ergebnis erhalte ich jedoch nur folgenden Datensalat
Was zeigt die Messung mit dem Oszilloskop an? Brauchbare Pegel? Stetige Flanken? Passendes Timing?
Oder versuchst du tatsächlich, einen seriellen (und zudem bidirektionalen) Bus ohne Oszi in Betrieb zu nehmen? Falls ja: das wird üblicherweise eine vogelwilde Ratestunde.
Das von dem Umsetzer zum TestPort der GND fehlt.
Die Leitungslänge beträgt unter 10cm.
Die Leitungslänge ist in erster Näherung irrelevant. Nur die Potentialverhältnisse interessieren. Und für definierte Potentiale muss auch beim RS485 die Masse aller Teilnehmer verbunden sein.
Ja, dies ist unter FreePascal der Grundsyntax, falls dies deine Frage im
Kontext sein sollte.
Dann verschiebe bitte mal eine logische 0 und verordere sie mit irgendwas (auf Papier)!
Und guck dir das Ergbenis an!
Das sind Grundlagen der Programmierung von Digitaltechnik...
Ich meine, dass ein verodern mit 0 unabhängig von der Programmiersprache genau gar nichts bewirken sollte.
werd ich wohl einen anderen USB-RS485-Umsetzers suchen müssen, da
meiner nur A und B als Output hat.
Ja, diese Mistdinger musst du aufmachen und den GND extra anlöten. Denn auch wenn manche den RS485 auch ohne GND irgendwie zum Laufen bekommen: prinzipiell braucht der den GND, denn die Einzelsignale A und B sind auf GND bezogen. Lediglich die zu übertragende Information steckt in der Differenz zwischen A und B.
Ja, dies ist unter FreePascal der Grundsyntax, falls dies deine Frage im
Kontext sein sollte.
Oje.
Ja, Masse muss verbunden sein, damit die Pegel auf den Leitungen im Toleranzbereich liegen.
Es muss nicht die perfekte Masse sein, Spannungsabfall auf Grund Leitungslänge ist also erlaubt, auch Sender und Empfänger jeweils mit Masse an PE Schutzleiter ist ausreichend um sich das dritte Kabel sparen zu können.
den PE als Signal-Gnd zu verwenden ist das dümmste was man machen kann
+1.
Hilft halt nix, wenn man so einen 1,50€ RS485-USB-Stöpsel von Aliexpress hat der nur A+B rausführt, und Signal-GND indirekt über USB->PC-Netzteil auf PE liegen hat...
Die andere Seite hat dann am Ende ein Steckernetzteil ohne PE, mit Signal-GND schön auf 120V Wechselspannung... Gut, die sind nicht Belastbar, die Bias-Widerstände ziehen das schon passend zurecht...
Funktionieren tut vieles was außerhalb der Spec ist, aber wenn's dann klemmt hat man viel Spaß mit der Fehlersuche...
Klassiker: Mit Oszi dran klappt es plötzlich. Ja. Das stellt nochmal eine GND-PE Verbindung her.
RS485 ist ein Differenzieller Bus ohne GND Bezug.
Du brauchst nur A/B
Reichelt hat den MAX485 im DIL-Gehäuse
Denke daran dass RS485 kein Bidirektionaler Bus ist, du musst immer Rx/Tx umschalten (!RE/DE verbinden und dann mit einem Portpin toggeln).
RS485 ist ein Differenzieller Bus ohne GND Bezug.
Du brauchst nur A/B
Das ist leider nur die Theorie. Die Praxis sieht so aus, dass jeder Empfänger und jeder Sender sein Datenblatt auf seinen GND bezieht. Und deshalb muss man natürlich den GND mit verbinden. Nur Hasardeure tun das nicht.
dass RS485 kein Bidirektionaler Bus ist
Doch, natürlich, und genau deshalb muss man die Richtung umschalten. Nur bei einem unidirektionalen (RS232, RS422, SPI) oder einem passiven Bus (I2C oder CAN) muss man die Richtung nicht umschalten.
Was du eigentlich meinst, nennt sich Full- bzw. Halfduplex.
Und da ist RS232 Fullduplex (beide Teilnehmer können gleichzeitig in beide Richtungen übertragen) und RS458 Halfduplex (nur 1 Teilnehmer darf senden).
Bitte keine halbgaren Halbwahrheiten verbreiten. Einfach mal lesen, was die Hersteller in ihren Appnotes zu dem Thema so schreiben. Und wie die Schaltpläne und Spezifikationen in den Datenblättern aussehen.
Dort haben wir das mal wieder (zum wiederholten Mal) ausgekaspert:
Doch, natürlich, und genau deshalb muss man die Richtung umschalten.
Nur bei einem unidirektionalen (RS232, RS422, SPI) oder einem passiven
Bus (I2C oder CAN) muss man die Richtung nicht umschalten.
Jein, RS485 gibt es als Halb- und Vollduplex-Bus.
Die Vollduplex-Version hat aber vier Datenleitung und nur einen Master; der Balbduplex-Bus ist mulitmasterfähig und braucht nur zwei Leitungen.
Den Vollduplexbus habe ich aber noch nie in Betrieb gesehen.
RS485 ist ein Differenzieller Bus ohne GND Bezug.
Du brauchst nur A/B
Das kommt wohl aus der (professionellen, analogen) Audio-Technik, wo asymetrische Signale in symmetrische mit Hilfe von Audioübertragern gewandelt werden.
Da braucht man man GND nicht unbedingt, weil es dadurch auch zu Brummschleifen kommen kann. Umgekehrt kann man die Signale auch so umwandeln.
Rx/Tx umschalten (!RE/DE verbinden und dann mit einem Portpin toggeln).
Wenn man es so macht, unbedingt an den Pullup für RXD denken. Bei abgeschaltetem Empfänger ist der Ausgang hochohmig, und man will keinen floatenden RXD-Pin.
RS485 ist ein Differenzieller Bus ohne GND Bezug.
Du brauchst nur A/B
Nein, du musst zusätzlich sicher stellen, dass A und B innerhalb des zulässigen Bereichs liegen.
Beim MAX485 ist unter Absolute Maximum Ratings z.B. nachzulesen:
"Receiver Input Voltage (A, B).......-8V to +12.5V"
Alleine schon, damit diese Spannung überhaupt definiert ist, ist ein Gnd-Bezug zwischen Sender und Empfänger erforderlich, den man besser nicht dem Zufall überlässt.
Jein, RS485 gibt es als Halb- und Vollduplex-Bus.
Die Vollduplex-Version hat aber vier Datenleitung und nur einen Master;
Die heißt dann aber nicht RS485, sondern RS422.
Nein, RS422 ist symmetrisches RS232: Für jede Richtung ein Leitungspaar.
Vollduplex RS485 hat einen Master, der von allen Slaves empfangen wird. De Antwort erfolgt auf einem weiteren Leiterpaar, das an den Ausgängen aller Slaves hängt:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019M21SAE&l=ja-JP
Nein, RS422 ist symmetrisches RS232: Für jede Richtung ein Leitungspaar.
Vollduplex RS485 hat einen Master, der von allen Slaves empfangen wird.
De Antwort erfolgt auf einem weiteren Leiterpaar, das an den Ausgängen
aller Slaves hängt
Unsinn.
Was du da beschreibst, IST RS422. Signalmäßig (pro Richtung) identisch mit RS485. Der Unterschied halt einzig, dass es für die Richtung Slave->Master ein zusätzliches Leitungspaar gibt und damit die Richtungsumschaltung für das eine Leitungspaar von RS485 für alle Peers am Bus entfallen kann.
Was da steht, beschreibt auch nur RS422. Wenn auch stark verkürzt. sieht irgendwie nicht nach einem Standard aus, sondern nach einer Art Gedächtnisstütze für unfähige Programmierer. Und zwar nach einer sehr schlecht geschriebenen. Dagegen sind ja sogar die Standards wirklich gut verständlich. Du solltest die Quellen für deine eigene Aufschlauung weiser wählen...
Vollduplex RS485 hat einen Master, der von allen Slaves empfangen wird.
De Antwort erfolgt auf einem weiteren Leiterpaar, das an den Ausgängen
aller Slaves hängt
Ist das eine Art "Zweidrittelduplex" oder "Einundfünzighundertstelduplex"? Denn bei 100 Teilnehmern kann ja auch nur jeweils 1 der Teilnehmer auf jeweils 1 der 2 RS485-Adrenpaare senden. Also ist es garantiert nicht Vollduplex im Sinne von "jeder kann jederzeit an den anderen was senden".
Ist das eine Art "Zweidrittelduplex" oder
"Einundfünzighundertstelduplex"? Denn bei 100 Teilnehmern kann ja auch
nur jeweils 1 der Teilnehmer auf jeweils 1 der 2 RS485-Adrenpaare
senden. Also ist es garantiert nicht Vollduplex im Sinne von "jeder kann
jederzeit an den anderen was senden".
Vollduplex im Sinne, dass Master und Slave gleichzeitig senden können.
Langsam bereue ich, dass ich das Thema angeschnitten habe.
Bei den vielen Besserwisser hier...
Das "Master-Slave-Konzept" ist erst dann nötig, wenn Software ins Spiel kommt und mehrere Teilnehmer auf den Bus zugreifen wollen. Und auch dann muss es beim RS485 keinen "Master" im Sinne von "das hier ist die Baugruppe, die den Zugriff auf den Bus regelt" geben. Es kann z.B. auch ein Token-basierter Bus sein. Dann ist immer das Gerät der "Master", das gerade den Token hat.
Langsam bereue ich, dass ich das Thema angeschnitten habe.
Richtig, diese "Nebendiskussion" ist für das Problem des TO eigentlich nicht relevant. Aber der scheint sowieso anderweitig beschäftigt zu sein.
