Hi NG, nachdem ich nun schon einiges zum Thema gelesen habe bleiben trotzdem einige Fragen offen....
lt. Literatur sind die Identifier als Sender-Identifikation vorgesehen. Wie aber ADRESSIERE ich dann ein Paket an einen bestimmten Node ?
2.In der Literatur ist immer wieder die Rede von den Remoteframes mit denen eine Antwort angefordert werden kann. Wie funktioniert dann die Adressierung ? Sendet der angesprochene Node automatisch nur eine Bestätigung oder muß der übergeordnete µC ein Antwortpaket individuell generieren `?
Gar nicht. Wer's hört (und dass muss jeder sein) und sich dafür interessiert, wertet das Paket aus. Sieh es eher als Inhalts-Identifikation, so nach dem Motto "und nun die Lottozahlen von heute" (gestern/morgen), oder "Hier die Temperatur von Sensor 7", oder noch CAN-näher, "Hier die Nachricht, für die der Programmierer Priorität xyz vorgesehen hat". Alles weitere ist eine Frage höherer Protokollschichten, die vorschreiben, wer was zu senden und wer was wie zu verstehen hat.
Anders als bei z.B. TCP/IP ist ein nacktes Paket an keinen bestimmten Empfänger gerichtet. Die meisten Empfängerbausteine können zwar Filter setzen und den µC nur mit Paketen belästigen, die er sehen will, sie müssen aber trotzdem alle Pakete lesen und bei Übertragungsfehlern laut (auf dem Bus) aufschreien. Auch wenn der µC das evtl. nur über Fehlerzähler mitkriegt.
Remoteframes sind nach meiner Erfahrung praxisfremd. Wo kommen sie in freier Wildbahn vor?
Andreas
--
You can only fit so many mistakes into 128kB. :)
(Greg Alexander)
Im Prinzip garnicht, der Node soll einfach auf diese ID hören.
CAN ist so gedacht:
- Motorsteuergerät sendet mit ID=280 Drehzahl und Verbrauch,
- ESP Steuergerät sendet mit ID=180 Raddrehzahlen,
- Instrumententräger ("Tachobrett") hört auf 280 und 180 und zeigt Fahrgeschwindigkeit, Drehzahl und Verbrauch an,
- Mobiltelefon hört auf 280 und überträgt bei zu großer Verbrauchssumme elektronisch Kreditantrag zur Bank zwecks Großeinkauf von 10 Litern 95er Wüstengold ;-/
Manche CAN Controller unterstützen Mailboxen, wo für jede Box eine ID programmiert werden kann. Will man dann die übertragenen Parameter erfahren, liest man einfach die entsprechende Mailbox aus, die immer den neuesten Stand beinhaltet, teilweise auch mit Zeitstempel.
Es wird ein Paket mit RTR rezessiv und Datenlänge 0 unter einer ID auf den Bus gelegt, und die Device, die sich für diese ID als Datenquelle zuständig fühlt, sendet dann eine vollständige Message (wie üblich RTR dominant) unter dieser ID auf den Bus. Auch das geht teilweise automatisch über eine sendende Mailbox, wenn der Controller die Anforderung sieht, kippt er einfach den Mailboxinhalt unter der gleichen ID auf den Bus. Lesen darf die Daten dann jeder, den es interessiert.
Deshalb wird üblicherweise auch dringend empfohlen, wirklich jedem Parameter eine feste Position in einer Nachricht zuzuordnen (z.B. Tankstand = Byte 3 Bit 0 bis 5 von ID 380). Natürlich kann man auch mit Sequenznummern arbeiten, aber das widerspricht IMHO dem CAN-Konzept.
Also angenommen, ich stelle dem Bus unter einer ID xyz Daten zur Verfügung (so interpretiere ich Deine Ausführungen zum Thema Identifier), dann interessiert sich eben nur ein knoten für IDs xyz. O.k. ? Nun angenommen, ich möchte von genau diesem Knoten die Software-Version zurücklesen, dann würde ich jetzt die ID xyz als Remote-Frame senden, oder ? Wie aber antwortet dieser Node dann ? Mit xyz wäre doch eigentlich verkehrt, oder ? Es soll ja etwas anderes zurückgesendet werden.
Nicolas Nickisch
"Oliver Bartels" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...
Gleich noch eine Frage: Momentan verwende ich den MCP2510 als CAN-Controller zusammen mit Atmel AVRs. Gibt es noch andere CAN-Controller, die leichter zu kriegen, rsp. billiger sind ?
Nicolas Nickisch
"Oliver Bartels" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...
Ohne Wertung gibt es von Philips (SJA1000), Intel (82527), Infineon (SAE81C90) Standalone-Controller, neben den unzähligen auf Microcontrollern und DSP's integrierten solchen.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.