Hallo, ich habe da ein kleines Projekt und mache mir grade ein paar Gedanken über die technische Umsetzung. Die Idee: Der Grundgedanke ist, dass es 8 Slave-Controller gibt und einen Master. Die Slaves messen jeweils ein Gewicht, führen eine simple Berechnung pro Wert durch und geben diesen auf einer kleinen Anzeige wieder. Zusätzlich sollen sie die Werte an den Master senden. Die Slaves und der Master sind auf einer Strecke von ca. 10m verteilt. Der Master soll die Daten nun abspeichern. Zum Beispiel auf einer SD-Karte. Diese sollen später z.B. am PC ausgewertet werden können. Abspeicherung in einer Art CSV-Format? Die Umsetzung: Als Slaves dachte ich an sowas: https://www.reichelt.com/Atmel-ATMega-AVRs/ATMEGA-32A-AU/3/index.html?&ACTION=3&LA=2&ARTICLE=119676&GROUPID=2959&artnr=ATMEGA+32A-AU Die sind günstig, in SMD Bauweise und verfügen über JTAG. Als Master dachte ich an den: https://www.reichelt.com/ATMEGA-644PA-PU/3/index.html?&ACTION=3&LA=446&ARTICLE=121842&artnr=ATMEGA+644PA-PU&SEARCH=at+mega+644pa Verfügt über 2 Uarts. Also kein Multiplexing nötig, falls man Daten direkt an den PC senden möchte. Er verfügt ebenfalls über JTAG und ist möglicherweise schon vorhanden. Die Fragen: 1. Die Slaves sammeln 10 oder 80 Werte pro Sekunde (fest einstellbar wegen Peripherie). Die Peripherie liefert die Messwerte mit 24 bit Genauigkeit. Für den Fall, dass diese auch gesendet werden sollen und einem Byte Overhead(Adressierung etc.) pro Datenpaket, entspricht das einem Gesamttraffic für den Master von mindestens 20480bps. Darin sind die Reaktionszeiten etc. noch nicht mit inbegriffen. Ist also eine Übertragungsrate von 32kBaud realistisch? 2. Ich habe mir vorgestellt, dass der Master ein byte auf den Bus schreibt und somit den passenden Slave adressiert. Dieser antwortet dann und überträgt alle gespeicherten Werte aus seinem Puffer. Das Wiederholt der Master stetig und fragt so alle Sensoren der reihe nach immer wieder ab. 3. Ist es korrekt, das die TX Leitung des Masters an alle RX der Slaves angeschlossen wird, die RX Leitung des Masters allerdings über einen Pullup auf 5V gelegt werden muss? Die Slaves ziehen zur Übertragung z.B. über einen NPN-Transistor die Leitung dann immer nur auf Ground. Um ein Push-Pull der Slaves zu verhindern. 4. I2C scheidet aufgrund der Abstände ja schonmal aus korrekt? Ich hoffe ich habe mich mit meinen Überlegungen nicht zu dumm angestellt und würde mich über jedes konstruktives Feedback freuen.
Ich würde als Schnittstelle RS485 nehmen, da hast Du saubere und stabile elektrische Verhältnisse. Da kannst Du auch noch höhere Baudraten benutzen, falls die Geschwindigkeit nicht reichen sollte. Gruß Dietrich
Marvin H. schrieb: > 4. I2C scheidet aufgrund der Abstände ja schonmal aus korrekt? So langsam ist I2C nun auch nicht. CAN könntest du auch nehmen.
Marvin H. schrieb: > über einen NPN-Transistor Extrem ungeschickt! Das ergibt eine Pegelumkehr, aus Hi wird Lo. Damit kommt das UART im Master nicht klar. Der Rx des Master bekommt einen Pullup und jeder Slave kann über eine Diode den Rx nach Minus ziehen.
Warum gibt das eine Pegelumkehr? Liegt die Leitung nicht dauerhaft auf HI (5v) und wird für z.B. das Startbit auf LOW gezogen? Oder verwechsle ich da jetzt etwas ?
Wenn UART ohne RS232-Phy gehen soll, dann muss auch I2C gehen. Schließlich müssten die Slaves ja auch über OC und Pullup verodert senden. Wo ist dann noch der große Unterschied? Die Übertragungsrate kann man, da beides Controller sind, sicher auch unter 100kBit/s betreiben.
Marvin H. schrieb: > Warum gibt das eine Pegelumkehr? Zeichne ein Schaltbild mit zB der ersten Flanke des Startbits an den Knoten. Dein Problem ist nicht neu, das haben vor dir schon viele andere gelöst. HildeK schrieb: > UART ohne RS232-Phy Das habe ich so nicht gelesen. den Port des ATMega direkt über 10m zu verdrahten halte ich für sportlich. Spätestens beim ersten Sommergewitter hat sich das dann erledigt.
Georg G. schrieb: > den Port des ATMega direkt über 10m zu > verdrahten halte ich für sportlich. Kommt drauf an, aber recht hast du. Ich habe das mal aus einer Notlage heraus probiert und es ging so leidlich. Ein Problem ist, dass es nicht so einfach hinzubekommen ist, dass sich alle auf den gleichen Ground beziehen. Bei RS485 ist dies wegen der differentiellen Übertragung nur noch ein Problem der common mode rejection und das kriegt so ein RS485 transceiver, in den üblichen Grenzen, ganz allein in den Griff :)
Ich würde direkt CAN Transceiver verwenden, nur die sind für Mehrfachzugriff ausgelegt und sind auch günstiger als die RS485 Transceiver. Bei RS485 Transceivern hat man immer ein Problem, wenn mehrere gleichzeitig senden. Eine Kollision kann nicht erkannt werden, da mehrere Treiber den Bus treiben und der Pegel undefiniert ist und sich sogar zwischen den Knoten unterscheidet. Es funktioniert also nicht zu senden und gleichzeitig den Bus zu belauschen, ob das richtige auf dem Bus lag, da die Pegel an einem Anderen Knoten ganz anders ausgesehen haben können. Mit CAN hast du das Problem nicht, da es nur einen dominanten Pegel hat, und du daher sicher den Bus belauschen kannst und so eine Kollisionserkennung in SW machen kannst.
sprintf("%s, name) schrieb: > Bei RS485 Transceivern hat man immer ein Problem, wenn > mehrere gleichzeitig senden. Eine Kollision kann nicht erkannt werden, > da mehrere Treiber den Bus treiben und der Pegel undefiniert ist und > sich sogar zwischen den Knoten unterscheidet. Das ist doch kein Problem, denn Marvin hat einen Master und 8 Slaves. Und ein passendes Protokoll, wo der Master nacheinander die Slaves aufruft, hat ja auch schon geplant. Das ist meiner Meinung nach einfacher und übersichtlicher als ein Multimaster-System mit CAN, da hier ganz nebenbei auch ein Ausfall eines Slaves erkannt werden kann (Time-Out). Bei CAN müsste man dafür für jeden Slave einen eigenen Timer im Master laufen lassen. Gruß Dietrich
Dietrich L. schrieb: > Das ist doch kein Problem, denn Marvin hat einen Master und 8 Slaves. > Und ein passendes Protokoll, wo der Master nacheinander die Slaves > aufruft, hat ja auch schon geplant. Ja, noch nicht aber vllt. möchte er später die Slaves ja von sich aus senden lassen. Wenn man direkt CAN Transceiver nimmt, ist das später möglich, mit RS485 wird es komplizierter. > Das ist meiner Meinung nach einfacher und übersichtlicher als ein > Multimaster-System mit CAN, da hier ganz nebenbei auch ein Ausfall eines > Slaves erkannt werden kann (Time-Out). > Bei CAN müsste man dafür für jeden Slave einen eigenen Timer im Master > laufen lassen. Ich meine nur den CAN Transceiver verwenden, und direkt an die UART hängen, ohne CAN Controller. Dann verhält er sich im Prinzip wie ein RS485 Transceiver (mit anderen Pegeln), kann aber zusätzlich bei Bedarf kollisionen erkennen. Zusätzlich sind die CAN Transceiver billiger und elektrisch normalerweise robuster.
Rufus Τ. F. schrieb: > W.A. schrieb: >> So langsam ist I2C nun auch nicht. > > Abstand != Geschwindigkeit. Hier geht es um 10m. Wenn es um den räumlichen Abstand der Sensoren und nicht um den zeitlichen Abstand der Datenblöcke geht, sollten 10m mit I2C kein Hindernis sein, jedenfalls wenn man dem Erfinder des I2C Glauben schenkt. AN10658 Sending I2C-bus signals via long communications cable http://www.nxp.com/documents/application_note/AN10658.pdf
sprintf("%s, name) schrieb: > Ich meine nur den CAN Transceiver verwenden, und direkt an die UART > hängen, ohne CAN Controller. Das hatte ich anders verstanden. > Dann verhält er sich im Prinzip wie ein > RS485 Transceiver (mit anderen Pegeln), kann aber zusätzlich bei Bedarf > kollisionen erkennen. Wenn man das aber "richtig" machen will, braucht man eigentlich auch den CAN-Controller. Denn die Kollision muss ja während des laufenden Bits erkannt werden, damit der Verlierer sich vom Bus abkoppelt und die weiteren Datenbits des Gewinners nicht zerstört. Das per SW nachzubilden ist bestimmt nicht einfach. Das Erkennen einer Kollision mit Datenverlust ist zwar einfach(er), aber ein Multimaster-Protokoll, das die Daten irgendwann kollisionsfrei überträgt, ist nicht trivial - zumindest, wenn man garantierte Reaktionszeiten haben will. Gruß Dietrich
:
Bearbeitet durch User
Hm…warum CAN benutzen? Ich würde hier auch RS485 benutzen, ist doch eine Parade-Anwendung dafür. Vielleicht sogar was Richtung Profibus. sprintf("%s, name) schrieb: > Bei RS485 Transceivern hat man immer ein Problem, wenn > mehrere gleichzeitig senden. Richtig, dann hat man ein Problem: Nämlich dass man das Protokoll falsch implementiert hat. Das darf doch erst gar nicht passieren, dass der Master zwei Slaves gleichzeitig die Sendefreigabe gibt.
Dietrich L. schrieb: > Wenn man das aber "richtig" machen will, braucht man eigentlich auch den > CAN-Controller. Nein, man nimmt einfach nur CAN-Transceiver. Was ist denn daran so schwer zu verstehen? Marvin H. schrieb: > Ist also eine > Übertragungsrate von 32kBaud realistisch? Nein. Takte die µCs mit >= 16 MHz und nimm als minimale Baudrate 115,2 kBd. Interruptgetriebene Sende- und Empfangsbuffer sind selbstverständlich und ein Multiprozessorprotokoll (9. Adressbit) sorgt dafür, daß nur der angesprochene µC seine Daten erhält, ohne die anderen Busteilnehmer mit Interrupts zu nerven.
m.n. schrieb: > Dietrich L. schrieb: >> Wenn man das aber "richtig" machen will, braucht man eigentlich auch den >> CAN-Controller. > > Nein, man nimmt einfach nur CAN-Transceiver. Was ist denn daran so > schwer zu verstehen? 1. Egal was man macht, man sollte nicht noch ein neues Protokoll erfinden. Das lohnt sich nicht. 2. Außerdem ist es schön, wenn man kompatibel zu irgendeinem halbwegs verbreitetem Standard ist. 3. Deshalb würde ich auch sagen, wenn CAN dann richtig. ...ODER auf meinen Rat defäkieren und CAN-Transceiver benutzen, weil sie billig sind. Das könnte ich auch noch nachvollziehen, das monetäre Argument ist stets kräftig. Ich hab mich bei meiner letzten Bus Bastelei übrigens für Modbus auf RS485 entschieden. Hauptgrund war die extrem weite Verbreitung und gleichzeitig sehr einfache Implementierbarkeit. Klar es kommt aus der Steinzeit und es hat sicher seine Gründe warum man CAN, Profibus, $anderesZeug erfunden hat, aber für meine Anwendung hats locker gelangt und ich kann jederzeit irgendein Modbus-Gerät kaufen und mit auf den Bus hängen :)
Max B. schrieb: > m.n. schrieb: >> Dietrich L. schrieb: >>> Wenn man das aber "richtig" machen will, braucht man eigentlich auch den >>> CAN-Controller. >> >> Nein, man nimmt einfach nur CAN-Transceiver. Was ist denn daran so >> schwer zu verstehen? Es geht hier ja nur um den Hardware Layer, und nicht um das Protokoll und da ist es egal ob man RS485 oder CAN Transceiver nimmt, wobei letztere die schon beschriebenen Vorteile haben, gleichzeitig aber keine Nachteile. > 1. Egal was man macht, man sollte nicht noch ein neues Protokoll > erfinden. Das lohnt sich nicht. Doch, man lernt was dabei. > 2. Außerdem ist es schön, wenn man kompatibel zu irgendeinem halbwegs > verbreitetem Standard ist. Stimmt. > 3. Deshalb würde ich auch sagen, wenn CAN dann richtig. Wenn der Controler es nicht kann, lohnt es sich nicht einen extra CAN Controler zu nehmen. > ...ODER auf meinen Rat defäkieren und CAN-Transceiver benutzen, weil sie > billig sind. Das könnte ich auch noch nachvollziehen, das monetäre > Argument ist stets kräftig. Es ist nicht nur günstiger sondern hat auch andere Vorteile, s.o. > aber für meine Anwendung hats locker gelangt Siehst du, da hast du dir selbst noch ein Argument geliefert, mit dem du deinen zweiten und dritten Punkt entkräften kannst.
Hallo, nach der ganzen Diskussion, habe ich mal nach einem Can Controller gesucht. Habt ihr an soetwas gedacht ? http://www.reichelt.de/MCP-2515-I-SO/3/index.html?&ACTION=3&LA=446&ARTICLE=54515&artnr=MCP+2515-I%2FSO&SEARCH=MCP2515 Weiterhin habe ich noch keine Erfahrung und müsste mich erst noch einarbeiten. Also verzeiht bitte folgende Fragen im Vorfeld. Ich hatte ja vor,an jeden Teilnehmer noch ein kleines Display anzuschließen. Dafür hätte ich ebenfalls ein einfaches SPI Display verwendet (so ein 16x2 Zeilen Display). Beide laufen dann ja über SPI und normalerweise würde man ja über einen Chip_Select den passenden Teilnehemer auswählen. Also Can-Adapter oder Display. Nur in diesem Fall würde der Can-Adapter ja einen Interrupt auslösen müssen, um die Verbindung "umzuschalten" und die Datenübertragung zu beginnen. Kann dies zu Interferenzen führen ?
Marvin H. schrieb: > nach der ganzen Diskussion, habe ich mal nach einem Can Controller > gesucht. ... > Weiterhin habe ich noch keine Erfahrung und müsste mich erst noch > einarbeiten. Also verzeiht bitte folgende Fragen im Vorfeld. Was soll denn der Schwachsinn mit einem CAN-Controller? Willst Du spielen oder auch mal fertig werden?
Marvin H. schrieb: > Hallo, > > nach der ganzen Diskussion, habe ich mal nach einem Can Controller > gesucht. > Habt ihr an soetwas gedacht ? > http://www.reichelt.de/MCP-2515-I-SO/3/index.html?&ACTION=3&LA=446&ARTICLE=54515&artnr=MCP+2515-I%2FSO&SEARCH=MCP2515 Ich denke an das hier: http://www.reichelt.de/PIC-18-Controller/PIC-18F24K50-ISO/3/index.html?ACTION=3&GROUPID=2968&ARTICLE=144988&SEARCH=pic18f24k80&OFFSET=500&; Da ist eine deutlich verbesserte Version des MCP2515 bereits eingebaut, plus der Prozessor mit Speicher und so. Spart auch einen Quarz, und der SPI-Flaschenhals zwischen Prozessor und Controller ist auch weg. fchk
m.n. schrieb: > Was soll denn der Schwachsinn mit einem CAN-Controller? > Willst Du spielen oder auch mal fertig werden? Hallo, es tut mir leid, sollte ich das falsch verstanden haben... Ich würde gern einen AtMega verwenden, da ich mich schon an die Entwicklungsumgebung gewöhnt habe und die Debugfunktionen kenne.
Marvin H. schrieb: > Hallo, es tut mir leid, sollte ich das falsch verstanden haben... > > Ich würde gern einen AtMega verwenden, da ich mich schon an die > Entwicklungsumgebung gewöhnt habe und die Debugfunktionen kenne. Du kannst die USART der ATmega nutzen, nimmst aber für die Ankoppelung an den Bus keine RS232-Treiber sondern CAN-Transceiver. Beispielsweise: http://www.reichelt.de/USB-CAN-BUS-Controller/PCA-82C250-T/3/index.html?&ACTION=3&LA=2&ARTICLE=39908&GROUPID=2946&artnr=PCA+82C250+T Die Kommunikation erfolgt halbduplex, aber im Gegensatz zu RS485 braucht man keine Richtungsumschaltung. Mehr ist da nicht zu tun.
Hallo, das sieht ja schonmal viel einfacher aus, als der CAN-Controlelr, den ich herausgesucht habe. Habe ich das richtig verstanden, dass sich dieser Transreceiver nicht um irgendwelceh CAN-Protokolle etc. scheert, sondern einfach mein UART-Signal auf den CAN Pegel umsetzt? Sodass quasi meine ganze Logik gleich bleibt, als wenn ich direkt über UART verbunden wäre ?
Marvin H. schrieb: > Habe ich das richtig verstanden, dass sich dieser Transreceiver nicht um > irgendwelceh CAN-Protokolle etc. scheert, sondern einfach mein > UART-Signal auf den CAN Pegel umsetzt? jep
Na dann sollte das ja eigentlich kein Problem darstellen, solange meine Logik sonst funktioniert. Vielen Dank für all die sinnvollen Vorschläge!
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.