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
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...
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.
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?
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.?
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?
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 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.
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.
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.
