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
Angehängte Dateien:
-
RS485_ohne_Treiber.JPG
35 KB
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
:
Bearbeitet durch User
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.
Warum steht im Betreff mit Atmel, wenn doch speziell um AVR geht? AVR ist immer Atmel, aber Atmel ist nicht immer AVR!
Ja, mea culpa. Mittlerweile müsste der Betreff sowieso eher "RS485 vs. CAN in Sterntopologie heissen: Pest oder Cholera" heissen ;)
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]
Nochwas: Das mit dem "Vergewaltigen" hätte ich auch noch gern erklärt bei der Gelegenheit. War das alles so schlimm, ja? Danke für die Aufklärung.
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.