Will RS485 mit AVR machen (Sensor), und auf zusätzlichen
Transceiverbaustein verzichten. Woher das differentielle Signal
bekommen? Nix Profi, nur Bastelbau, 5V reichen auch. Eigentlich würde
mir ein Transceiver mit paar GPIOs zusätzlich schon ausreichen, aber so
etwas finde ich nicht.
Gedanke dann: USB macht ja differentiell. Kann man beispielsweise einen
Atmega8/16U2 für Soft RS485 missbrauchen? Jemand schonmal so etwas
probiert? Preise solcher Bausteine scheinen solche Gedanken zu
unterstützen (TME: satte 3EU). Mir gehts um Platz, den
(Transceiver-)baustein einsparen. Im Forum/Datenblatt (8/16U2) erstmal
keine offensichtlichen Hinweise gefunden, das sowas Praxis sein könnte -
aber auch nichts, dass sagen würde, dass es nicht geht. Hoffnung sinkt
trotzdem ;(
Riskier mal Forumsprügel: jemand was beizutragen? Muss nicht zwingend
Atmel sein - für anderes wäre ich auch offen. 5x5mm^2 QFN 32 mit
inklusivem Transceiver wäre .. - cool :)
umdeutung schrieb:> Kann man beispielsweise einen> Atmega8/16U2 für Soft RS485 missbrauchen?
unwahrscheinlich dass man die USB Hardware dazu bringen kann, eigene
Bitmuster zu senden...
Wenns nicht unbedingt RS485 sein muss, guck mal den LPC11C0, der hat CAN
komplett integriert (inkl. Transceiver). Ist onehin einfacher zu
benutzen als RS485 auch bei Multi-Master.
Es gibt auch Transceiver in VSSOP8 (3mm*3mm, 0.65mm Pin Pitch). Zusammen
zB mit einem PIC16F1574 im TSSOP oder UQFN (4mm*4mm, 0.65mm Pitch)
sollte das eine recht kompakte Lösung werden.
fchk
Hallo,
> umdeutung schrieb:> Will RS485 mit AVR machen (Sensor), und auf zusätzlichen> Transceiverbaustein verzichten. Woher das differentielle Signal> bekommen? Nix Profi, nur Bastelbau, 5V reichen auch.
grundsätzlich kann man die notwendigen RS485-Pegel auch mit sehr
einfachen Mittel erzeugen.
RS485 werte ja die Differenz zwischen den beiden Leitungen A und B aus.
Wenn du die B-Leitung vom Sensor mit einem Spannungteiler auf 1/2 Ub
setzt kannst du im Prinzip direkt mit Logikpegel auf die A-Leitung
gehen.
Um keinen Pegelkonflikt beim Senden vom Sensor zum uC zu verursachen,
muß die Txd-Leitung entkoppelt werden.
Im Anhang findest du 2 einfache Varianten, si so funktioniere sollten.
Das geht natürlich nur mit kurzen Kabellängen geringen Baudraten
problemlos.
Gruß Öletronika
Hallo,
> Stefan U. schrieb:> Das ist nicht wirklich RS-485.
ja logisch, denn wenn der Fragesteller "richtiges RS485" wollte, dann
sollte er auch einen "richtigen RS485-Treiber" nutzen. Aber eben genau
das wollte er offenbar nicht
Zitat: "Nix Profi, nur Bastelbau, 5V reichen auch."
Allerdings, wenn er doch einen RS485-Treiber wollte, der nur sehr klein
ist, dann wäre so was doch eine alternative Lösung im QFN-Gehäuse 3x3mm:
http://www.ti.com/lit/ds/symlink/sn65hvd75.pdf
Gruß Öletronika
Ja, "richtiges" RS485 war schon gemeint. Primär ging es um die
zusätzlichen GPIOs im Transceiver (oder einen Tranceiver mit kleinem
MUC), also Integration von RS485 und MUC. So ein FTDI für USB-UART hat
auch ein paar GPIOs. (In welchen Packages der kommt sei dahin gestellt).
Dass das nicht die Regel ist hat sicher Gründe (Transceiverwahl
schmälert Universalität, Aufwand der Integration selbst, usw.). USB ist
aufgrund der Verbreitung vielleicht Ausnahme, so dass man integrierte
USB PHYs dort häufiger findet. Nicht aber RS485, offensichtlich, dafür
geht man wohl direkt auf CAN. Der erwähnte LPC11C22 im zweiten Post ist
im Prinzip die Faust aufs Auge - nur eben mit CAN, allerdings
interessant. Einen (reinen RS485) Transceiver im 3x3 Package kann ich
dann extern zum MUC genausowenig vertragen wie einen SO8, auch wegen des
erforderlichen zusätzlichen Routings. Zusammen im Chip wäre halt cool,
da kompakt. (Trotzdem werd ich mir den merken ob des kleinen Packages).
Alles in allem bin ich auf den LPC ja jetzt schon ein wenig angefixt.
Müsste mich mit CAN anfreunden. Hab hier eine reinrassigen Stern, also
eigentlich nix CAN. Die RS485 Lösung würde ich mit Hardware erschlagen:
Dicker MUC im Zentrum (bzw. mehrere), der massig (spezialisierte)
softUARTs macht (6 Ports pro MUC -> 3 für TX, 3 RX). Das geht dann nicht
besonders fix, aber 2400-9600Baud sind schon ausreichend - nicht zuletzt
wegen der Parallelität dieser UARTs. Kollisionen gibts ja nicht, nur
eben die Serialisierung im MUC selbst. Um ein wenig Strecke machen zu
können in den (~50) Sternenlinien (jede zwischen 5-10m lang) im
"harschen Environment" dann brav differentiell statt UART pur. Da der
softUART sowieso recht customized ist, wäre differentiell dann nur ein
Switch auf ein sichereres Medium für die Distanzüberbrückung (statt
gleich RS232). Auf der Sensorenseite muss allerdings klein gebaut werden
(bis zu ~2x1cm PCB). Deswegen der Wunsch nach hoher Integrationsdichte.
Isolation mit ADUMs gibt auch noch. Aber kaum zu treibende Lasten
(deswegen: 5V OK)
Wenn der Stern doch nur nicht wäre. Vielleicht sollte ich was testen mit
CAN und den LPC mal probieren und AVR verlassen?
Erste Tests heute eines P2P UARTs über 80m Einkabel ohne Terminierung
zeigten nur bei 230kBaud einen Vorteil der verwendeteten ADM483 RS485
Transceiver gegenüber RS232. Vermutlich wegen der "limited slew rate".
umdeutung schrieb:> Die RS485 Lösung würde ich mit Hardware erschlagen:> Dicker MUC im Zentrum (bzw. mehrere), der massig (spezialisierte)> softUARTs macht (6 Ports pro MUC -> 3 für TX, 3 RX)
Voll kompliziert...
umdeutung schrieb:> Wenn der Stern doch nur nicht wäre.
Bei niedriger Geschwindigkeit geht auch CAN im Stern. Im Zweifelsfall
machst du halt einen Doppelstern: Starte den Bus an der Zentrale, dann
zum einen "Slave" hin und wieder zurück, dann zum nächsten "Slave" und
wieder zurück usw. Braucht zwar mehr Kabel, dafür aber weniger Stecker,
und der zentrale uC ist schön einfach. Großer Vorteil von CAN:
Wunderschön einfach zu programmieren; einfach die gewünschte Nachricht
an die Controllerperipherie übergeben und die sorgt dafür dass sie
ankommt sobald der Bus frei wird.
Programmierer schrieb:> Voll kompliziert...
Ja!
> Bei niedriger Geschwindigkeit geht auch CAN im Stern. Im Zweifelsfall> machst du halt einen Doppelstern
Letzteres ist keine Option. Stattdessen vielleicht kaskadierte
Sub-Sterne?
http://www.oschmid.ch/mt/can-hub5/can-hub5.php
Ist natürlich auch Gewürge, aber immerhin wäre man protokolltechnisch
CAN-konform (wie Appealing das wirklich ist weiss ich noch nicht -
einfache Programmierbarkeit ist natürlich nicht von der Hand zu weisen).
Vielen hier dreht sich vermutlich eh gerade der Magen rum.
Anwendung: Meistens ist der Bus ruhig. Ein Sensor meldet i.d.R. 0-10
Zustandsänderungen pro Tag. Selten (und nicht periodisch) werden
einzelne Knoten mal von einem ausgezeichneten Knoten abgefragt - dem
"Master" im Sternzentrum. Sensoren untereinander sprechen in der
Anwendung nicht miteinander - wäre mit CAN dann theoretisch möglich,
bleibt aber die Ausnahme. Zwei Situationen, bei denen etwas mehr Traffic
ist: Es gibt ein Worst-Case Szenario, in dem 20 Sensoren ziemlich
gleichzeitig an den "Master" melden. Da könnte es etwas Pingpong geben.
Außerdem: Flashen der Sensoren über den Bus. Das findet nicht häufig
statt, soll aber Option sein in der Not. Für diesen Fall könnte man auch
eine Sternenstrippe isolieren und P2P machen für besseren Durchsatz,
falls notwendig.
Bleibt die Frage welches Gewürge das Konsequentere ist bei gegebener
Topologie, RS485 oder CAN.
umdeutung schrieb:> Letzteres ist keine Option. Stattdessen vielleicht kaskadierte> Sub-Sterne?
Auch voll die Fummelei... Worin genau besteht denn das Problem ein Kabel
vom Master zum Slave1 zu legen, von dem weiter zu Slave2, da weiter zu
Slave3 usw... ?
Und warum geht der "Doppelstern" nicht, zu geizig für die Kabel (die
"Hubs" werden bestimmt teurer) oder ist kein Platz für zwei weitere
Adern?
> Und warum geht der "Doppelstern" nicht, zu geizig für die Kabel (die> "Hubs" werden bestimmt teurer) oder ist kein Platz für zwei weitere> Adern?
Eben - an Geiz liegts deshalb eben nicht:) Es ist kein Platz für die
Leitungen, das ist alles. Den Doppelstern würde ich sonst sofort machen.
Sehe den Stern als gegeben (mir schmeckts nicht, aber darüber ärgern
bringt auch nichts). Ich habe fast die Vermutung, dass CAN auch im
Einzelstern schon funktionieren könnte, wenn es langsam zugeht. Für
RS485 hab ich aber ein paar Transceiver jetzt zum Spielen da. Damit leg
ich jetzt erstmal los auf dem Hackbrett mit 2 Sensoren. Der oben
erwähnte parallel Soft UART ist eigentlich auch schon fertig. Vorteil
ist ja schon, dass es recht simpel bleibt, natürlich mit gewissen
Einschränkungen (keine Arbitrierung durch Bus-Hardware etc.; zentraler
Master). Außerdem: braucht keine extra CAN Controller; nach den ersten
Versuchen kann ich mir Terminierung vermutlich komplett sparen bei den
gutmütig langsamen Flankenwechseln des ADM483E. Kollisionen sind
physikalisch auch kein Problem mit dem Transceiver, eher deren
Erkennung, aber dafür kann man sicherlich was Tüfteln. Soll ja auch
Spass machen. Der Weg bleibt das Ziel ;)
Ich habe noch eine andere Idee:
Viele PIC16 haben konfigurierbare Logikzellen (CLC), die bestimmte
Logikfunktionen in Hardware ausführen können, FF, AND, OR XOR, NOT,...
Du kannst den Ausgang des UARTS in das CLC-Array routen und dort zwei
Signale erzeugen: TX und not(TX). Für die Empfangsrichtung hat der Chip
zwei konfigurierbare analoge Komparatoren. Damit könntest Du die
Spannungsdifferenz auswerten, über das CLC-Array auf einen IO-Pin
leiten und über einen anderen IO-Pin in den UART routen.
Ist jetzt zwar kein standardkonformes RS485/422, aber immerhin echt
differentiell.
Wenn Du es im Datenblatt nachlesen willst: PIC16(L)F18325/18345 kämen
dafür in Frage.
fchk
Frank K. schrieb:> Für die Empfangsrichtung hat der Chip> zwei konfigurierbare analoge Komparatoren. Damit könntest Du die> Spannungsdifferenz auswerten, über das CLC-Array auf einen IO-Pin> leiten und über einen anderen IO-Pin in den UART routen.
Die Idee finde ich erstmal nicht schlecht. Man verlöre zwar die Hälfte
des Signalhubs zwischen A und B, aber das ist vermutlich kein Problem.
Mit dem Komparator, da bin ich weisses Blatt Papier: ist das der ADC?
Ich glaub der verträgt dann -5V beim Empfangen vom (u.U.) R485-compliant
Master nicht, oder? Dann müsste man den Master (i.e. P2P Partner) also
auch so betreiben?
umdeutung schrieb:> Frank K. schrieb:>> Für die Empfangsrichtung hat der Chip>> zwei konfigurierbare analoge Komparatoren. Damit könntest Du die>> Spannungsdifferenz auswerten, über das CLC-Array auf einen IO-Pin>> leiten und über einen anderen IO-Pin in den UART routen.>> Die Idee finde ich erstmal nicht schlecht. Man verlöre zwar die Hälfte> des Signalhubs zwischen A und B, aber das ist vermutlich kein Problem.
Der Signalhub ist ±5V. Echtes RS422 hat ±6V.
> Mit dem Komparator, da bin ich weisses Blatt Papier: ist das der ADC?
Nein, das ist wieder was anderes. Die Komparatoren sind quasi eingebaute
Operationsverstärker, wie ein eingebauter LM393.
http://ww1.microchip.com/downloads/en/DeviceDoc/40001795B.pdf
Und da Kapitel 17 ab Seite 182.
Die Logikblöcke sind in Kapitel 20 ab Seite 219 beschrieben. Die
Peripherie ist das geniale an diesen PICs.
> Ich glaub der verträgt dann -5V beim Empfangen vom (u.U.) R485-compliant> Master nicht, oder? Dann müsste man den Master (i.e. P2P Partner) also> auch so betreiben?
Ich weiß nicht, was die RS422-Treiber da rauswerfen. Der PIC kann nur
0-Vcc. Im Standard ist nur die Spannungsdifferenz beschrieben, aber
nicht die Spannung gegen GND. Wäre also zu prüfen.
fchk
Hallo,
> umdeutung schrieb:> Ja, mea culpa. Mittlerweile müsste der Betreff sowieso eher "RS485 vs.> CAN in Sterntopologie heissen: Pest oder Cholera" heissen ;)
mein Gott, ist es denn so schwer in der Ausgangsfrage mal halbwegs die
Randbedingungen zu nennen und sich nicht über 50 Postingsverteilt jedes
relevante Detail aus der Nase ziehen zu lassen.
Das hört sich erst so an, als wolltest du mal eben provisorisch einen
einzigen Sensor an eine uC anschließen und dafür die Verdrahtung des
Treibers sparen.
Dannn werden aus 1 Sensor 50 Sensoren und aus RS485 wird eine extreme
Sternstruktur??? Das nenne ich maximale Verarschung der Forenteilnehmer.
Die Mühe dafür noch einen Schaltplan zu mache, den zu fotografieren und
zu bearbeiten hätte ich mir wirklich sparen können.
RS485 ist ein Feld-BUS, der in aller Regel als Linien-BUS für max.
Störsicherheit auf langen Leitungen bis ca. 1000m zu nutzen ist.
Dazu kommen meist auch Baudraten, die es erforderlich machen, die lange
Leitung impedanzmäßig abzuschließen. Die Terminierung ist dann
grundsätzlich nur an den Leitungsenden zu setzen.
Bei einer Sternstruktur mit dutzenden Slaves kannst du diese Konzept
aber komplett vergessen. Eine Terminierung an 50 Slaves wäre ziemlicher
Humbug.
Es ist auch nicht wirklich notwendig, wenn man poplige 10...20m hat und
dazu niedrigste Baudraten. Hier ist viel eher auf eine ausreichende
Bandbreitenbegrenzung an den Treibern zu achten, dann kann man die paar
Meter Leitunglänge zu den Sensoren auch locker als kurze Leitungen
definieren. HF-Effekte an Wellenleitern muss an dann nämlich nicht
berücksichtigen.
Das gilt dann im Prinzip auch für CAN.
Da steht jetzt also erstmal die Frage, was du überhaupt willst?
Alleine das Schlagwort "differenzielle Leitung" bringt dir wenig, wenn
du die Konzepte eh vergewaltigst und sonst nicht weißt, auf was es bei
der Anwendung überhaupt ankommt. Es nenne das Konfusion und
Konzeptlosigkeit.
Statt aleo
So würde ich doch überlegen, ob nicht einfach eine ganz normale
Spannungübertragung völlig ausreichend ist. Dann kann ganz normal
bidirektional übertragen werden.
Um da eine ausreichende Störsicherheit zu erreichen, sind trotdem einige
Massnahmen sinnvoll anzuwenden. So braucht man ausreichend
leistungsfähige Treiber (RS232 ist dafür auch nicht unbedingt notwendig
und original schon gar nicht dafür ausgelegt).
Ich würde an den Enden auch einen Abschluss mit einer Last beschalten,
die auch 50-fach parallel nicht zu Problemen führt (z.B. ca. 1kOhm).
Aber über die konkreten und Störeinflüsse Randbedingungen wissen wir ja
auch nix.
Gruß Öletronika
U. M. schrieb:> Das nenne ich maximale Verarschung der Forenteilnehmer.> (...)> poplige 10...20m (...) dazu niedrigste Baudraten> (...)> Die Mühe dafür noch einen Schaltplan zu mache, den zu fotografieren und> zu bearbeiten hätte ich mir wirklich sparen können.
Erbärmlicher Ton, aber im Netz durchaus möglich...
Also:
Die Ausgangsfrage war ein Detail für den Parallelbetrieb. Hatte nicht
vor das hier alles auszubreiten - der Thread hat sich aber danach
entwickelt aus den Alternativvorschlägen. Mit CAN lockt plötzlich die
Möglichkeit alles auf einem Bus machen zu können, dazu kam dann der
Kontext vom mir. Würde ich nicht als Verarsche empfinden, aber wenn es
dir damit so geht: war nicht beabsichtigt.
Hatte eher nicht den Eindruck Infos aus der Nase gezogen zu bekommen -
eher freiwillig gegeben, um der Entwicklung gerecht zu werden. Bis auf
jetzt gerade, aber ist schon OK.
Die angesetzte konservative (mickrige) Baudrate verstehe ich eher schon
als Ergebnis der Bemühung Wellencharakter möglichst zu vermeiden, auch
um auf Terminierung verzichten zu können. Schön aber, von jemandem ein
eindeutig unterstützendes Statement dazu zu erhalten - ist ja auch
selten. Du würdest also die parallelen Leitungen mit Lasttreiber und
Last von beispielsweise KOhm "durchspannen" wollen - ich denk damit kann
ich was anfangen, nicht unsinnig.
Der Preis für die niedrige Baud wird an anderer Stelle bezahlt,
offensichtlich (im Master MUC). In der seriellen (Bus-)Variante mit
potentiellen Kollisionen (eigentlich nur im oben beschriebenen worst
case) in Verbindung mit (irgendeiner Art von) Arbitrierung packt man
mehr auf den Bus und wollte wahrscheinlich im Gegenzug höhere Baudraten.
Nasenwurm: Mit 9600 Baud geht ein Byte in 1ms über die Leitung. Mit
parallel Soft-UART ist diese Baud realistisch (wenn nicht sogar
unterschätzt), aber wenn man dabei bleibt hat man in einer handvoll ms
die Stati von 20 (50, ...) gleichzeitig sendenden Sensoren im Master MUC
durch paralleles Lesen (ich komme mit 0xFF Stati des Sensors aus;
Adressierung kann man sich bei parallel sparen - nix Overhead bei
parallel; von mir aus kann man noch ein zweites Byte für CRC
dazurechnen). Für CAN ist es jetzt auch nicht die Hölle (bitte
verbessern, falls unpräzise), aber schon anders: aus 2 werden etwa 4
Bytes pro Frame und die 19 verprellten Sensoren müssen es nochmal
probieren - der niederpriorisierteste dann eben 19 Retries lang, wenn
nichts passiert in der Zwischenzeit. Faktor 40 für dieselben Daten im
MUC. Sind immerhin 340kBaud auf der Leitung, wenn die Zeit der
Datenübertragung gleich sein soll. Habe mich noch nicht sonderlich damit
beschäftigt, aber das könnte im Sternbus evtl. dann doch eine andere
Situation bedeuten bezüglich Wellenwiderstand? Am Ende sind 9600 Baud
parallel ordentlich genug. Und erlauben neben fehlender Terminierung
vielleicht sogar die von dir vorgeschlagene Logiklevelübertragung. Dass
man Logiklevel (überhaupt) übertragen kann in diesem Fall ist aber nicht
dein Verdienst. Du nimmst nur die niedrige Baudrate und versuchst
einen Strick daraus zu drehen (ist ja alles Larifari bei der Baudrate).
Find ich Bad Taste. Falls solche Übertragungen auf 10m mit 5V
zuverlässig funktionieren, dann will ich das natürlich so machen - schon
immer (yeah, jeder will das dann, klar).
Bemerkung:
Wenn man solche "perversen" Sachen wie Logiklevel (Beispiel: I2C) mit 5V
über 10m Leitung haben will, so wird man in anderen Threads hier im
Forum regelmässig geradezu gejagt und anschliessend gesteinigt).
[Deine Art hier zu schreiben wie heute finde ich abstoßend]
