Hallo schlaue µC-"Gang", ich frage mich gerade, wie man die Kommunikation von einem Hauptmodul mit mehreren Sensormodulen (15 Stück) über eine Entfernung von ca. 40 cm am sinnvollsten realisieren kann. Der Fokus soll dabei auf Störsicherheit liegen. Primär kam mir da SPI oder RS-485 mit irgendeinem Protokoll (z. B. SPI) oder CAN in den Sinn. Was ich hier im Forum rausgelesen hab war: SPI war anscheinend nur für auf Platinen integrierter Kommunikation gedacht. Man kann aber durch Probieren und Basteln auch teilweise viel höhere Reichweiten erreichen. RS-485 braucht ein eigenes Protokoll (was weiß ich..Polling vom Master im schlimsmten Fall...) - man könnte aber auch einfach das SPI Protokoll über einen RS-485 Treiber laufen lassen (solang man nicht zu schnell fährt, aber ne 1 MHz Clock geht wohl noch ohne Stress) - was ich auch gerne machen würde, da ich nicht weiß, ob ich es hinkrieg mir ein eigenes Protokoll auszudenken (bzw. ich dafür wahrscheinlich einfach ewig brauche). CAN hätte gegenüber RS-485 den großen Vorteil, dass man keine "Chip-Select"-Leitungen braucht (bei 15 Sensoren sind das nochmal 15 Leitungen) bzw. man sich kein CSMA Verfahren überlegen muss, weil das alles über die Nachrichten-Priorität der einzelnen Systeme geht (hier dürfen halt keine gleich prioritären Nachrichten vorgesehen werden). CAN und RS-485 brauchen dafür noch Treiberstufen (mehr Platzbedarf) und CAN noch dazu einen Controller (ich wollte ursprünglich einen kleinen, leistungsarmen µC auf den Sensormodulen platzieren - die haben meist keinen CAN-Controller on board, sondern nur SPI und UART) CAN und RS-485 sind wegen der differentiellen Übertragung sehr robust gegenüber Störungen. Was ich mich jetzt konkret frage ist, ob es sich lohnt, vielleicht doch auf einen µC mit CAN-Controller zu setzen und alles über CAN zu realisieren oder ob bei den kurzen Entfernungen nicht doch SPI-only (ohne RS-485 Treiber) mit einer Amplitude von 5 V völlig ausreichend ist (gut, das hängt natürlich stark vom "elektromagnetischen Smog" in der Anwendungsumgebung ab). RS-485 mag ich irgendwie nicht. Außerdem frag ich mich, ob ich bei meinen Überlegungen was vergesse oder was falsch interpretiert habe :) Bin dankbar für jegliche Tipps und Korrekturen Danke schonmal! :] lg neg0r
Hab natürlich noch einen großen Nachteil von CAN vergessen: Man braucht die ganzen Stacks irgendwoher. Gibts es da noch irgendeine "OpenSource"-Lösung? MicroCanOpen kostet mittlerweile in der einfachsten Form auch 600 € http://www.canopenstore.eu/epages/61343215.sf/de_DE/?ObjectPath=/Shops/61343215/Categories/Firmware/CANopen
Du vermischst hier ein Busprotokoll und eine Buspyhsik, und bekommst deshalb einen Knoten in das Hirn... > mit mehreren Sensormodulen (15 Stück) über eine Entfernung von ca. 40 cm > am sinnvollsten realisieren kann. Was für "Sensormodule"? Was willst du machen? Welche Übertragungsbandbreite brauchst du? Welche Bustopologie wäre gut? Könnte das auch eine Kette sein (z.B. eine SPI-Chain, so machen das LED-Lichtbänder)? > Der Fokus soll dabei auf Störsicherheit liegen. Definiere "Störsicherheit". Wenn eine Störung erkannt wird, muss dann die Übertragung wiederholt werden? > CAN hätte gegenüber RS-485 den großen Vorteil CAN verwendet so eine "Art" RS485...
neg0r schrieb: > Man braucht die ganzen Stacks irgendwoher. Nein. Man kann CAN mit komplexem Stack nutzen, man muss es aber nicht. Wenn jeder Sensor alle paar Sekunden oder Minuten seinen Kram ist Netz bläst und der Controller ihn dort runterfischt, dann ist der "Stack" einfacher als bei RS485.
> Hab natürlich noch einen großen Nachteil von CAN vergessen: > Man braucht die ganzen Stacks irgendwoher. Um es nochmal zu wiederholen: >>> Du vermischst hier ein Busprotokoll und eine Buspyhsik, und bekommst >>> deshalb einen Knoten in das Hirn... ;-) Ich kann eine CAN-Message ganz ohne jeden Stack absenden: einfach 8 Byte in den Puffer und ab damit...
Zuerst sollte wir mal erfahren, was das für 15Sensoren sind, und wie diese ihr Sensorsignal bereitstellen.
Ok - Knoten im Gehirn anscheinend :D Also CAN und RS-485 allein ist ein Bus ...? :) Dachte immer, dass ich irgendwie Stacks brauche um die Daten zu verpacken und wieder auszupacken. Aber das ist anscheinend nur nötig, wenn ich....was machen will? Ich mein: toll, dass es auch ohne geht :] - nur warum verwendet man es dann (Beim Ethernet gibts ja meines Wissens Layer 3 und Layer 4 z.B. für Routing und Fehlermanagent - des wars aber auch mit meinem Wissen :P) Zur anderen Sache: > Was für "Sensormodule"? Was willst du machen? Welche > Übertragungsbandbreite brauchst du? Welche Bustopologie wäre gut? Könnte > das auch eine Kette sein (z.B. eine SPI-Chain, so machen das > LED-Lichtbänder)? Die Sensormodule sind keine kommerziellen Sensoren. Fürs Labor sollen DMS-Messbrücken mit Verstärkern aufgebaut werden. Die Ausgangsspannung der Messbrücke soll dann über einen µC ausgelesen werden. Naja und dann müssen die Daten von allen Modulen von einem Hauptmodul aufgenommen werden. Die genauen Datenraten sind noch nicht bekannt, sagen wir: Ich möchte gerne jedes Modul mit 100 Hz laufen lassen. Wenn jeder Datenwert 2 Byte hat, hätte man somit 100 Hz 15 2 Byte = 24 kBit/s als gesamte Übertragungsrate auf dem Bus. Wenn eine der Messbrücken einen Grenzwert überschreitet, sollen alle Module schnell ihre Abtastrate erhöhen (z. B. auf 1kHz - also ingesamt 240 kBit/s). Hierfür wäre natürlich CAN gut, weil dass alles sofort mitkriegen würden. > Definiere "Störsicherheit". > Wenn eine Störung erkannt wird, muss dann die Übertragung wiederholt > werden? nein, das sind ja nur aktuelle Sensordaten - dann bekommt man halt den nächsten Wert wieder mit. Ein CRC-Wert sollte natürlich schon dabei sein, um falsche Daten rausfiltern zu können.
Ist doch ganz egal, welche Sensoren es sind und wie sie die Daten
bereitstellen. Der TE wollte doch bei jedem Sensor einen uC plazieren,
so geht es nur um die reine Datenübertragung.
>RS-485 mag ich irgendwie nicht.
Der Satz ist ja seltsam.
Vorweg: ich weiss nicht wie aufwändig CAN zu implementieren ist da ich das bisher nie benutzt habe. bei RS485 brauchst du kein Select Signal. Jeder Sensor besitzt bei Dir ja einen uC. Sprich jeder Sensor bekommt eine Adresse und lauscht dann ob er gepollt wird. Zumindest wäre das einfach zu implementieren, das der Master uC nacheinander alle Sensoren abklappert ob Daten anliegen. Mit Kollisionserkennung könnte man es auch einrichten, das jeder Sensor drauflossendet wenn er was zu senden hat, aber dann wirds aufwändiger. Es bleibt aber zu berücksichtigen, dass wenn einer der Sensoren einen Fehler produziert durch den er die Sendeleitung dauerhaft blockiert, dann nix mehr geht
achso...und mit SPI könntest du wahrscheinlich theoretisch auch auf die SlaveSelect Leitung verzichten. Dann muss halt auch jeder Sensor lauschen welche Daten für Ihn bestimmt sind. Da müsste man aber schauen ob das so geht. Durch das SS Signal wird eigentlich auch die Übertragugn gestartet/gestoppt. Keine Ahnung ob das noch irgendwelche anderen Konsequenzen für die Hardware SPI hat, wenn das Signal dauerhaft anliegt. Müsstest du im Detail nochmal anschauen
>achso...und mit SPI könntest du wahrscheinlich theoretisch auch auf die >SlaveSelect Leitung verzichten. Nein. Nicht auf eine. >Durch das SS Signal wird eigentlich auch die Übertragugn gestartet/gestoppt. Eben. Mindestens eine wird benötigt, um dem/der Slave(s) mitzuteilen, wann das Schieben der (vielen) Nutzbytes beendet ist und die Daten übernommen werden sollen.
A. B. schrieb: > Sprich jeder Sensor bekommt eine Adresse und lauscht dann > ob er gepollt wird. Jo, das hatte ich vorhin damit gemeint: > RS-485 braucht ein eigenes Protokoll (was weiß ich..Polling vom Master > im schlimsmten Fall...) - man könnte aber auch einfach das SPI Protokoll.. :) A. B. schrieb: > Es bleibt aber zu berücksichtigen, dass wenn einer der Sensoren einen > Fehler produziert durch den er die Sendeleitung dauerhaft blockiert, > dann nix mehr geht Wie meinst du das? Für den Fall mit Polling vom Master? Oder für die eigene "CSMA/CD"-Variante (jeder sendet wann er denkt, dass es gut ist)? Im Notfall könnte man ja mit einem Watchdog auf dem Sensor-µC einen Rest auslösen. Naja.. :) A. B. schrieb: > Keine Ahnung ob das > noch irgendwelche anderen Konsequenzen für die Hardware SPI hat, wenn > das Signal dauerhaft anliegt. Wenn die Hardware ein µC ist, wäre das primär egal - bei diversen komerziell erhätlichen Sensoren braucht man aber CS/SS um irgendwelche Befehle abzuschließen. Spielt hier keine Rolle.
Matthias Lipinsky schrieb: > Eben. Mindestens eine wird benötigt, um dem/der Slave(s) mitzuteilen, > wann das Schieben der (vielen) Nutzbytes beendet ist und die Daten > übernommen werden sollen. Wenn man einheitlich arbeitet wäre das wirklich ohne SS möglich. Master schreibt einen Befehl, dass Sensormodul 12 JETZT senden soll. Alle Module hören das und prüfen, ob sie gemeint sind. Naja und 12 sendet dann eben. Man muss halt immer mit einer Bitfolge beenden bzw. eine definierte Wortlänge einhalten. Das wäre sozusagen eine Softwarelösung, die nur geht, weil wirklich jedes Modul einen eigens programmierbaren µC hat. Aber ich würd trotzdem gern noch was zu CAN erfahren: Geht das wirklich so einfach mit Daten in Puffer und abgehts? Da muss ja dann die Nachrichten ID auch mit dabei sein. Kanns mir noch net so ganz vorstellen.
neg0r schrieb: > CAN und RS-485 brauchen dafür noch Treiberstufen (mehr Platzbedarf) und > > CAN noch dazu einen Controller (ich wollte ursprünglich einen kleinen, > > leistungsarmen µC auf den Sensormodulen platzieren - die haben meist > > keinen CAN-Controller on board, sondern nur SPI und UART) Es kann ja bei dem kleinen Controler bleiben. Für die Anbindung an eine CAN-Bussystem könnte man den MCP2515 verwenden. Das ist ein über SPI anzusteuernder externer CAN-Kontroler. Den kannst Du als kostenlose Muster bei Microchip bis zu 5 stück beziehen. Ansonsten kostet er zur Zeit bei csd-electronics ca 2,5 euro. Für das Ding gibt es diverse fertige Stacks. ...
Matthias Lipinsky schrieb: >>Durch das SS Signal wird eigentlich auch die Übertragugn gestartet/gestoppt. > > Eben. Mindestens eine wird benötigt, um dem/der Slave(s) mitzuteilen, > wann das Schieben der (vielen) Nutzbytes beendet ist und die Daten > übernommen werden sollen. ah, ok...hätte gedacht mann könnte die SS Eingänge an den Slaves evtl. auch dauerhaft auf High legen. Aber macht so natürlich Sinn. Jeder Slave übernimmt die Daten und schaut dann ob sie für Ihn bestimmt waren
neg0r schrieb: > Aber ich würd trotzdem gern noch was zu CAN erfahren: > Geht das wirklich so einfach mit Daten in Puffer und abgehts? Ja. Auf dieser untersten Ebene ist CAN so ähnlich wie eine SIO oder eine SPI-Schnitte. Und das ganze ISO-Zeugs: es ist gut, wenn du weißt, dass es das gibt, aber solltest du nicht eher deine Aufgabe lösen, als irgendwelche Normen implementieren? > Da muss ja dann die Nachrichten ID auch mit dabei sein. Die ID steckt beim CAN in der Adresse. Das solltest du dir noch mal genauer anschauen...
neg0r schrieb: > Aber ich würd trotzdem gern noch was zu CAN erfahren: > Geht das wirklich so einfach mit Daten in Puffer und abgehts? Exakt so. Welcher Sensor das ist steht in der ID, die Daten im Datenfeld. Der zentrale Controller fischt die Dinger aus dem Puffer von seinem CAN Controller und ist auch schon fertig. Jegliches Software-Framing wie in RS485 entfällt ersatzlos und für Sicherheit sorgt CAN dank der Hardware-CRC selbst. Wenn man es mal geschafft hat, den CAN Controller zu initialisieren, dann ist der Umgang kinderleicht. Sensoren muss man meistens auch nicht extra abfragen, man lässt die einfach regelmässig ins Netz blasen, obs jemanden interessiert oder nicht (es muss nur sichergestellt sein, dass eine sendende Node nie allein im Netz ist).
>Jeder Slave übernimmt die Daten und schaut dann ob sie für Ihn bestimmt >waren
Nein. SPI funtkioniert anders.
Der Master muss folgendes sicherstellen: Wenn der Master die SS-Leitung
deaktiviert, müssen in jedem Slave die jeweils für ihn gültigen Daten
bereits reingeschoben sein. Denn mit dem Deaktivieren der SS-Leitung
werden die Daten quasi zwangsübernommen. Adressen oder sowas gibt es
dort nicht.
ja, das ist mir jetzt klar. Ich meinte es so: Der Master besitzt einen SS Ausgang, welcher mit allen Slaves verbunden ist Er überträgt die selben Daten an alle Slaves, welche jeder Slave übernimmt mit dem setzten der SS Leitung Und jeder Slave schaut dann, ob das Telegramm für Ihn bestimmt war. Man propft dem ganzen quasi die Adressen per Software auf. Zumindest wäre das jetzt die einzige Lösung die mir auf die schnelle einfällt, um die extra SS Leitung zu jedem Slave einzusparen.
Das wäre, ums mal ganz vorsichtig zu formulieren, ein Vergewaltigen der SPI. Das SPI ist gemacht worden, um keine Adressen haben zu müssen. Dann würde ich eher mit RS485 anfangen und jedem Sensormodul eine Adresse spendieren.
Ich sage ja nicht das ich es so machen würde... Aber der Threadersteller wollte die SS Leitungen einsparen, was mit der Variante funktionieren würde und er braucht keine Treiber wie bei RS485 Quasi das hier: http://de.wikipedia.org/w/index.php?title=Datei:SPI_three_slaves.svg&filetimestamp=20070407163817 mit einer SS Leitung
Lothar Miller schrieb: > Die ID steckt beim CAN in der Adresse. > Das solltest du dir noch mal genauer anschauen... Ja, das hab ich glaube ich kapiert - ich habe eigentlich eher gemeint, dass beim Übertragen der Daten in den Sendepuffer irgendwo diese Adresse mit dabeistehen müsste. Das geht mir nicht so ganz in den Kopf. Du hast ja vorhin gemeint: 8 Bytes in den Puffer und ab damit. Ich denke du meinst mit den 8 Bytes das reine Datenfeld und hab mich gefragt, woher der Controller dann etwas über die Adresse weiß, die er dem Telegramm "beilegen" soll. Oder gibt es neben einem Sende- und Empfangspuffer noch ein Register in dem immer die aktuell gewünschte Zieladresse steht?
neg0r schrieb: > Oder gibt es neben einem Sende- und Empfangspuffer noch ein Register in > dem immer die aktuell gewünschte Zieladresse steht? das macht keinen Sinn, weil beim Empfangen müsste es sowas ja auch geben....also muss doch der Puffer mit Adresse und Datenfeld gefüllt werden..also 8byte+11bit ? Schaut das dann so aus?
1 | CAN_RX_PUFFER=010 01011010 11010110 11011011 11000110; |
2 | ADRESSE 3 Bytes DATEN |
A. K. schrieb: > Jegliches Software-Framing wie in RS485 entfällt ersatzlos und für > Sicherheit sorgt CAN dank der Hardware-CRC selbst. D.h. ein Frame wird dann über ein Statusregister mit "fehlerhaft" markiert? (Ich hab echt keine Ahnung von CAN-Controllern, sorry wegen der blöden Fragen)
neg0r schrieb: > D.h. ein Frame wird dann über ein Statusregister mit "fehlerhaft" > markiert? Ich habs grad nicht im Kopf, ich meine aber dass der defekte Frame effektiv ignoriert wird, es sei denn man legt Wert darauf, auch defekte Frames zu kriegen. Eine Zieladresse gibt es bei CAN nicht, die ID beschreibt in deinem Fall die Sendernode und deren Sensornummer (wenn mehrere pro Node). Der Zentralcontroller kriegt also beides zusammen frei Haus geliefert, Sensornummer und Sensorwert. Empfehlenswert für die Sensornodes wäre der erwähnte MCP2515 an einem kleinen AVR, weil schön einfach und recht arm an Bugs. Oder beispielsweise der PIC18F2585, wenn PICs genehm sind, denn das ist ein 28-Pinner mit einem CAN Controller an Bord, der mit dem MCP2515 eng verwandt ist. Die AT90CAN AVRs mit CAN drin sind demgegenüber deutlich komplexer gebaut.
Also bei einer Single Master Lösung, würde ich mir die Arbeit mit CAN nicht machen und auf RS485 setzen. Master frägt Sensor ab, Sensor antwortet, Master frägt nächsten Sensor ab, ... typische Polling eben. Erst wenn es Multi Master fähig werden soll, dann würde ich CAN verwenden, denn dann spart man sich viel Arbeit und Hirnschmalz. Ach ja, wegen dem Protokoll, ich persönlich finde S.M.A.R.T. ganz gut, man kann sich da schöne Ideen holen. Christian
A. K. schrieb: > Eine Zieladresse gibt es bei CAN nicht, die ID beschreibt in deinem Fall > die Sendernode und deren Sensornummer (wenn mehrere pro Node). Der > Zentralcontroller kriegt also beides zusammen frei Haus geliefert, > Sensornummer und Sensorwert. Hm, jop "ADRESSE" war oben falsch von mir formuliert. Nichtsdestotrotz: Ich hab nicht verstanden, wie man diese ID dem Frame mit auf den Weg gibt. Nimmt der Controller die ersten 11 Bits aus dem Sendepuffer als ID?
Christian Kreuzer schrieb: > Erst wenn es Multi Master fähig werden soll, dann würde ich CAN > verwenden, denn dann spart man sich viel Arbeit und Hirnschmalz. Ich sehe nicht so ganz, wo der Mehraufwand liegt. Ob ich jetzt für jedes Sensormodul eine "prüfe, ob beim Pollen ich gemeint bin"-Routine oder auf dem Hauptmodul eine "prüfe, von wem diese Daten kommen"-Routine schreibe, macht für mich wenig unterschied. Einen Transceiver braucht man in jedem Fall. Die zusätzliche Dreingabe des Errorhandlings (selbst wenn es nur falsche Frames verwerfen ist), spricht von meiner Perspektive gerade eher für CAN. Naja, aber ich lasse mich gerne aufklären, was ich übersehe... :]
neg0r schrieb: > Nimmt der Controller die ersten 11 Bits aus dem Sendepuffer als ID? Ein Frame besteht hauptsächlich aus einer 11 oder 29 Bit langen ID und 0-8 Datenbytes. Die im Netz verwendten ID müssen so definiert sein, dass keine 2 Nodes Frames mit der gleichen ID ins Netz stellen, sind also auch eine Art Absenderkennung. Die ID wird von der sendenden Node zusammen mit den Datenbytes in einem Registersatz des CAN-Controllers abgelegt und von der empfangenden Node ebenso abgeholt. Zu Details dieser Register siehe Doku des verwendeten Controllers. Im hier skizzierten Fall könnte die ID also schlicht die Nummer des Sensors sein, oder eine Kombination aus der Nummer der Node und der Nummer des Sensors. Die Sensornodes senden die ID zusammen mit dem Sensorwert als Frame ins Netz und der zentrale Controller fischt diese beiden Informationen zusammen dort raus. Im Unterschied zu RS485 ist ein zyklisches Abfrage-Antwort Spiel für reine Sensoren meist nicht erforderlich.
neg0r schrieb: > Nimmt der Controller die ersten 11 Bits aus dem Sendepuffer als ID? Die ersten Bits nach dem Framestart sind die ID. Die Arbitrierung folgt über den Mechanismus der dominanten und Rezessiven Bits. Beim Framestart fangen u.U. mehrere Nodes an, gleichzeitig zu senden. Wer mehr dominante Bits in der ID sendet, "gewinnt". Sobald auf dem Bus ein dominanter Pegel liegt, der Node aber rezessiven sendet, wird der Sender abgeschaltet und zum nächstmöglichen Zeitpunkt ein neuer Sendeversuch gestartet. Mit dem bereits genannten MCP2515 ersparst du dir wirklich viel Hirnschmalz. Du könntest aber auch sowas wie den LIN-Bus implementieren, wenn dir CAN ein bisschen zu kompliziert ist(Braucht IMHO nur eine UART, die auch 10 Bits senden kann). Spezifikation kann man auf http://www.lin-subbus.org/ anfragen(Emailadresse->Downloadlink per Mail). mfg mf
Mini Float schrieb: > Die ersten Bits nach dem Framestart sind die ID. Ah, super :) - genau das wollte ich wissen. Mini Float schrieb: > Die Arbitrierung folgt über den Mechanismus der dominanten und > Rezessiven Bits. Beim Framestart fangen u.U. mehrere Nodes an, > gleichzeitig zu senden. > Wer mehr dominante Bits in der ID sendet, "gewinnt". Ja, soweit ging meine Kenntniss sogar :] Mini Float schrieb: > Du könntest aber auch sowas wie den LIN-Bus implementieren, wenn dir CAN > ein bisschen zu kompliziert ist Moment mal, was ist denn jetzt los, ich dachte es ist einfach :) - in den Puffer und ab damit hieß es :) LIN ist glaub ich etwas zu langsam. Naja, zur Not müsste man irgendwie schon eine Datenvorauswertung auf den Modulen machen, dann wäre die Geschwindigkeit auch ok. Aber ich will eigentlich net noch mehr Lösungen aufbringen :]
A. K. schrieb: > Die ID wird von der sendenden Node zusammen mit den Datenbytes in einem > Registersatz des CAN-Controllers abgelegt und von der empfangenden Node > ebenso abgeholt. danke :]
neg0r schrieb: > Mini Float schrieb: >> Du könntest aber auch sowas wie den LIN-Bus implementieren, wenn dir CAN >> ein bisschen zu kompliziert ist > > Moment mal, was ist denn jetzt los, ich dachte es ist einfach :) - in > den Puffer und ab damit hieß es Wenn du den MCPdingsbums zum laufen bekommst, ist es tatsächlich einfach - Es kam mir nur so vor, als würdest du alles selber machen wollen :D mfg mf
Mini Float schrieb: > Wenn du den MCPdingsbums zum laufen bekommst, ist es tatsächlich einfach > - Es kam mir nur so vor, als würdest du alles selber machen wollen :D Ich raffs net ;) - alles selber machen? Du meinst ohne Controller?
Andi D. schrieb: > LIN over RS485 -> billig, kann jeder controller... Wie schon gesagt, das ist recht langsam. Oder kommt man da irgendwie über die 20 kbit/s.?
Sorry, nochmal ich: Brauch ich eigentlich für meinen CAN-Bus zwingend eine Drosselspule?
neg0r schrieb: > Andi D. schrieb: >> LIN over RS485 -> billig, kann jeder controller... > > Wie schon gesagt, das ist recht langsam. Oder kommt man da irgendwie > über die 20 kbit/s.? nicht wirkich, die 20kbit beziehen sich auf den KFZ eindrahtbetrieb ungeschirmt. sobald du rs485 als übertragungsmedium wählst kannste da auch mbits rüberjagen neg0r schrieb: > Sorry, nochmal ich: > Brauch ich eigentlich für meinen CAN-Bus zwingend eine Drosselspule? nicht wirklich. nur abschlusswiderstände sind wichtig!
Andi D. schrieb: > nicht wirkich, die 20kbit beziehen sich auf den KFZ eindrahtbetrieb > ungeschirmt. sobald du rs485 als übertragungsmedium wählst kannste da > auch mbits rüberjagen Was wäre dann daran noch LIN? Ich verwende ja dann auch keinen LIN-Bus Tranceiver. Hier ist LIN dann wohl wieder ausschließlich als Protokoll zu sehen? :) Argh, wie kann man sich anschaulich vorstellen, was Protokoll ist und was Busphysik.... bzw. in wie weit verschwimmen bei den einzelnen Bezeichnungen hier die Grenzen?
neg0r schrieb: > Argh, wie kann man sich anschaulich vorstellen, was Protokoll ist und > was Busphysik.... bzw. in wie weit verschwimmen bei den einzelnen > Bezeichnungen hier die Grenzen? => http://de.wikipedia.org/wiki/OSI-Modell Sowas wie CAN oder LIN besteht aus mehreren OSI-Layern. Wenn man in LIN den Layer 1 durch RS-485 ersetzt, dann kriegt man einen Hybrid.
Hm - da ich wirklich nur ein Singlemaster Konzept benötige, habe ich gerade nochmal meinen Fokus auf RS-485 gerichtet. Anscheinend hat dort oft in der "normalen" Anwendung das Adressbyte ein zusätzliches 9. bit, damit die Teilnehmer immer wissen, welches Byte eine Adresse war. Ist das korrekt? Dennoch hören alle Teilnehmer ja alles mit und müssen jedes Mal den Wert im Puffer prüfen. Nehmen wir an, ich bin ein Slave und dauernd geht die "Party auf dem Bus ab" - also es is einfach viel Traffic: Lohnt es sich bei einer Übertragung, die nicht für mich bestimmt ist, das Byte mit der Framelänge gezielt mit anzuschauen und dann abhängig von der Länge und von der Baudrate einen Timer zu starten, der dann über einen Interrupt signalisiert, bis wann das UART-Register nicht mehr geprüft werden muss? - Oder ist das Blödsinn?
Am Besten wäre es natürlich, wenn das Adressbit irgendwie einen Interrupt auslösen würde.
neg0r schrieb: > Anscheinend hat dort oft in der "normalen" Anwendung das Adressbyte ein > zusätzliches 9. bit, damit die Teilnehmer immer wissen, welches Byte > eine Adresse war. Ist das korrekt? Ja. Man kann das freilich auch anders realisieren, aber das 9. Bit ist - wenn die Hardware das hergibt - der einfachste Weg, Frames so zu gestalten, dass der Dateninhalt keine verbotenen Codes kennt und der Slave ihn nicht interessierende Frames ignorieren kann, weil ... > Oder ist das Blödsinn? ... er eine UART-Hardware besitzt, die bei entsprechender Einstellung alle Bytes ohne gesetztes 9. Bit von sich aus ignoriert.
A. K. schrieb: > ... er eine UART-Hardware besitzt, die bei entsprechender Einstellung > alle Bytes ohne gesetztes 9. Bit von sich aus ignoriert. wenn der µC die aber nicht hat? (TI Stellaris... :/)
Dann ist hoffentlich der Controller schnell genug, um die Bytes aktiv ignorieren zu können.
...dann muss man es anders machen - schon klar :) Noch eine zusätzliche GPIO-Adress-Signalleitung legen? Oder ein ganz charakteristisches Bitmuster verwenden, dass hoffentlich in der normalen Übertragung nie dabei ist?
A. K. schrieb: > Dann ist hoffentlich der Controller schnell genug, um die Bytes aktiv > ignorieren zu können. Hm, aber woher weiß er denn, dass zum Beispiel... JETZT...wieder eine Adresse geschickt wurde? Dadurch dass er wirklich alles mitzählt? Adresse, Framelänge, Datenbytes, CRC und damit das Ende von jedem Frame mitbekommt? Meinst du das mit "aktiv ignorieren"?
Hi >Am Besten wäre es natürlich, wenn das Adressbit irgendwie einen >Interrupt auslösen würde. So ist es doch auch. Bei den AVRs wird im Multiprozessormode ein RX-Interrupt nur bei gesetztem 9.Bit ausgelöst. Der Datenaustausch erfolgt mit gelöschtem 9.Bit und die nicht adressierten Slaves bekommen davon nichts mit. MfG Spess
spess53 schrieb: > So ist es doch auch. Bei den AVRs wird im Multiprozessormode ein > RX-Interrupt nur bei gesetztem 9.Bit ausgelöst. Der Datenaustausch > erfolgt mit gelöschtem 9.Bit und die nicht adressierten Slaves bekommen > davon nichts mit. Ah - das ist natürlich gut. Blöd, dass das der µC hier nicht kann :/ -hm. Das gibt wieder ein + für CAN. Hatte mir auch mal die LIN-Spezifkiationen geholt, als mögliche Alternative. Da steht aber überall nur 20kbit/s und ich kann mir vorstellen, dass wenn man das erhöht, irgendwelche definierte Timingsachen nicht mehr klappen. Sonst würde da dass ja nicht so explizit drin stehen.
neg0r schrieb: > Hm, aber woher weiß er denn, dass zum Beispiel... JETZT...wieder eine > Adresse geschickt wurde? Dadurch dass er wirklich alles mitzählt? > Adresse, Framelänge, Datenbytes, CRC und damit das Ende von jedem Frame > mitbekommt? Meinst du das mit "aktiv ignorieren"? Wenn ein 9. Bit zur Verfügung steht, dann ist der Anfang eines neuen Frames dadurch signalisiert und wenn die Adresse nicht passt, dann wird jedes Byte bis zur nächsten Adresse weggeworfen. Sei es per Hardware, wenn die UART das kann, sei es im UART-Interrupt wenn nicht. Muss man 8-Bit Übertragung verwenden, weil man Komponenten hat, die kein 9. Bit können, dann hilft es sehr, wenn man das Protokoll dem anpasst und sicherstellt, dass beispielsweise das Byte 0xAA in den Daten nirgends vorkommt. Dann steht 0xAA,0xNN für den Anfang eines neuen Frames mit der Adresse 0xNN. Wenn man dann noch die Frames durch 2 Bytes Pause trennt und den Frame per CRC absichert, dann ist sichergestellt, dass der Anfang eines Frames sicher erkannt werden kann, egal zu welchem Zeitpunkt eine Node startet. Will man Binärdaten übertragen, dann kann man das beispielsweise durch Escapes realisieren, also indem man die beispielsweise Datenbytes 0xAA und 0xAB als 0xAB,0x2A und 0xAB,0x2B übertragt (so ungefähr arbeitet asynchrones PPP). Solche Spässe wie narrensicheres Framing sind übrigens auch ein Grund, weshalb CAN bei Übertragung kleiner Messages letztlich softwareseitig einfacher ist als RS485. Man muss sich weder um Ruhepausen noch um CRCs noch um solche Escape-Codes kümmern und eine Node kriegt per Hardware-Filter nur die Frames mit, die sie interessieren.
A. K. schrieb: > Wenn man dann noch die Frames durch 2 Bytes > Pause trennt Warum die Pause? A. K. schrieb: > Will man Binärdaten übertragen, dann kann man das beispielsweise durch > Escapes realisieren, also indem man die beispielsweise Datenbytes 0xAA > und 0xAB als 0xAB,0x2A und 0xAB,0x2B übertragt (so ungefähr arbeitet > asynchrones PPP). Generell ne tolle Sache. Nur mit UART-Interrupts kann man da dann wohl wirklich nichts mehr machen. Wie gesagt, man könnte die einzelnen Module mit an die Framelänge angepassten Timer-Interrupts entlasten. Aber das ist natürlich irgendwo Gepfusche. Danke jedenfalls für die vielen hilfreichen Tipps (besonders an A. K.) Ich versuchs jetzt also doch erstmal mit CAN :] - aber interessant ist es alle Mal. Hier gibt übrigens eine nette und anschauliche Beschreibung von einer Singlemaster RS-485-Lösung (falls jemand das hier liest und mit RS-485 arbeiten will) http://www.wiki.elektronik-projekt.de/mikrocontroller/rs485_bus
neg0r schrieb: > Ich möchte gerne jedes Modul mit 100 Hz laufen lassen. > Wenn jeder Datenwert 2 Byte hat, hätte man somit 100 Hz 15 2 Byte = > 24 kBit/s als gesamte Übertragungsrate auf dem Bus. > > Wenn eine der Messbrücken einen Grenzwert überschreitet, sollen alle > Module schnell ihre Abtastrate erhöhen (z. B. auf 1kHz - also ingesamt > 240 kBit/s). Bei der erhöhten Abtastrate wird das bei CAN aber eng werden. Falls nur ein Messwert je Telegramm enthalten ist, dann klappt das mit 1kHz sicher nicht mehr.
Konrad S. schrieb: > Bei der erhöhten Abtastrate wird das bei CAN aber eng werden. Falls nur > ein Messwert je Telegramm enthalten ist, dann klappt das mit 1kHz sicher > nicht mehr. Jop, stimmt, wenn man immer nur 2 Byte hat man natürlich 6 Bytes Overhead und damit nur noch ein Viertel der Nutzdaten. Man sollte also eine Art Preprocessing auf den Sensormodulen durchführen lassen.
neg0r schrieb: > Warum die Pause? Wenn eine UART mittendrin in einer Übertragung einschaltet, dann wird sie die nächste 0 als Startbit interpretieren, egal obs eines ist oder nicht. Bei einer ununterbrochenen Bytefolge ohne Pause zwischen den Frames kann der Fall eintreten, dass sie so lange den Anfang eines Bytes nicht findet, bis mal zwischendrin mindestens 1 Byte Pause ist. Nach der Pause sind zumindest die Bytes wieder synchron. Krasses Beispiel: Schau dir mal eine asynchrone 8N1-Übertragung an, in der pausenlos 0x55 gesendet wird. Und sag mir dann wo ein Byte aufhört und das nächste anfängt. Das ist nämlich ein perfektes Rechteck mit F=Baud/2.
A. K. schrieb: > Krasses Beispiel: Schau dir mal eine asynchrone 8N1-Übertragung an, in > der pausenlos 0x55 gesendet wird. Und sag mir dann wo ein Byte aufhört > und das nächste anfängt. Das ist nämlich ein perfektes Rechteck mit > F=Baud/2. Wäre dass nicht auch bei 0xFF schwierig? - Oder beinhaltet das Rechteck noch irgendwas besonders trickreiches? :]
neg0r schrieb: > Wäre dass nicht auch bei 0xFF schwierig? Nein, bein 0xff kommt eine 0 (Startbit) und danach 9mal die 1 (8 Datenbits, ein Stoppbit). Da kann nichts schiefgehen. Ganz anders bei 0x55, da kommen immer nur abwechselnd 0en und 1en. Wenn da die Synchronisation einmal verlorengegangen ist, dann kommt sie auch nicht wieder (wir sprechen von Senden ohne jede Pause).
Hm,aso. D.h. im Normalbetrieb wartet die UART von der Hardware her selbst so lange ab, bis sie sicher ist, dass sie ein Byte eindeutig gefunden hat? Wie kann die UART eigentlich ein 9.bit zur Adress-Identifizierung ausmachen? Ist zwischen jedem Byte ne kurze Pause?
Neg0r schrieb: > D.h. im Normalbetrieb wartet die UART von der Hardware her selbst so > lange ab, bis sie sicher ist, dass sie ein Byte eindeutig gefunden hat? Keineswegs. Im Gegenteil, Schrott rein Schrott raus. Sie nimmt die nächstbeste 0 als Startbit, die darauf folgenden 8 Bits als Datenbits, egal obs welche sind oder nicht. Einzig das Stopbit danach muss 1 sein, sonst signalisiert sie einen Framing Error. Lässt man jedoch zwischen den Frames mindestens 1 Byte Pause, dann wird unabhängig von den übertragenen Daten jede UART auf das nächste Byte korrekt synchronisieren. > Wie kann die UART eigentlich ein 9.bit zur Adress-Identifizierung > ausmachen? Ist zwischen jedem Byte ne kurze Pause? Konvention. Entweder überträgt man immer 8 Bits oder immer 9 Bits. Bei 9 Bits ist der Zustand dieses 9. Bits die Unterscheidung zwischen der Adresse am Anfang des Frames und dem Inhalt davon. Mischbetrieb mit mal 8 mal 9 Bits geht nicht.
Analoge Frage meinerseit's jedoch mit einer kleineren Tieferen Ecke. Welchen µC (PIC/AVR) könnte ich verwenden um CAN und RS-485 zu verwalten? Bin aufgrund einer Steuerunger auf beide angewiesen. Die RS soll dabei erst mal nur als Übergang für die nächten 6 Monate Entwicklung dienen, bis wir raus haben, wie wir CAN auf Sabo und Nanotec 100 Pro anwenden können.
Übersicht über verfügbare Schnittstellen, ROM/RAM-Kapzitäten etc. haben beide Hersteller, also warum schaust du nicht einfach mal dort rein?
Werd wohl daher auf einen Pic18F6680 und einem MCP2515 steigen. somit hab ich D/A I/O, RS485 und Can angedeckt... es sei denne, der AT90CanXX kann das alles ohne Streß ab... Modul soll die Nanotec programmieren und zusätzlich einen max 16 Bit A/D I/O können. Can brauch ich nur als Knoten...
Maik Geßner schrieb: > es sei denne, der AT90CanXX kann das alles ohne Streß ab... Modul soll > die Nanotec programmieren und zusätzlich einen max 16 Bit A/D I/O > können. Can brauch ich nur als Knoten... vergleich am besten die datenblätter und entscheide dich für die controllerfamilie mit der du schon umgehen kannst. ich verwende seit jahren den at90can128 und bin voll zufrieden
Maik Geßner schrieb: > Werd wohl daher auf einen Pic18F6680 und einem MCP2515 steigen. somit > hab ich D/A I/O, RS485 und Can angedeckt... Der PIC hat CAN doch schon intern. Weshalb dann noch den MCP?
A. K. schrieb: > Maik Geßner schrieb: > >> Werd wohl daher auf einen Pic18F6680 und einem MCP2515 steigen. somit >> hab ich D/A I/O, RS485 und Can angedeckt... > > Der PIC hat CAN doch schon intern. Weshalb dann noch den MCP? RS485? ist ein weiteres Muß bei den Projekten... CAN, RS485 MÜßEN ohne großen Aufwand laufen. RS232 und USB kann ja fast jeder Wald und wiesen µC
Maik Geßner schrieb: >> Der PIC hat CAN doch schon intern. Weshalb dann noch den MCP? > > RS485? Sorry, aber kann es sein, dass du hier einen Haufen Begriffe in die Runde wirfst, deren Bedeutung du noch nicht sortiert hast? Der MCP2515 macht CAN, und nur CAN. Der erwähnte PIC hat einen CAN Controller an Bord, sowie eine UART. Damit sind CAN und die verbreitetste Variante von RS485 bereits durch den PIC abgedeckt (ebenso AT90CAN). Nur die Tranceiver für CAN und RS485 fehlen noch.
Hallo, den Avr ATMega16 gibt es auch mit CAN Bus, ansonsten wäre eine alternative der AT90CAN32.
A. K. schrieb: > Maik Geßner schrieb: > >>> Der PIC hat CAN doch schon intern. Weshalb dann noch den MCP? >> >> RS485? > > Sorry, aber kann es sein, dass du hier einen Haufen Begriffe in die > Runde wirfst, deren Bedeutung du noch nicht sortiert hast? > > die Tranceiver für CAN und RS485 fehlen noch. das ist doch mal 'ne klare Info, mit der ich was anfangen kann.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.