Hallo, ich habe folgendes Problem mit einer CAN Kommunikation. Ich verwende einen Peak-CAN Dongle sowie einen Mikrocontroller mit CAN. Der Mikrocontroller bekommt von einem anderen Mikrocontroller alle 100ms zwei CAN Nachrichten mit unterscheidlichen CAN ID's (ID1=0x13 und CAN ID2=0x200). Diese CAN Nachrichten empfängt der andere Mikrocontroller. Jetzt möchte ich zusätzlich über CAN einige Daten/Informationen von dem einen Mikrocontroller auslesen. Dies soll mit dem Peak-CAN Dongle erfolgen. Dafür habe ich eine Art Transportprotokoll entworfen (ohne Timeout Funktionalität), mit der man mehr als 8 Bytes vom Mikrocontroller auslesen kann. Diese CAN Verbindung ist manchmal nicht zuverlässig. Ich verwende dafür die CAN ID's 0x7FF und 0x7FE. Damit keine Kommunikationsaussetzer entstehen bzw. CAN Nachrichten verloren gehen können, welche Maßnahmen müsste beim Transportprotokoll unbedingt berücksichtigen werden ? Ich vermute, dass die CAN Nachrichten mit den niedrigeren CAN ID's die CAN ID's 0x7FF und 0x7FE behindern. Die CAN ID's 0x7FF und 0x7FE werden laut CAN von der Priorität niedrig eingestuft.
Entwickler schrieb: > Damit > keine Kommunikationsaussetzer entstehen bzw. CAN Nachrichten verloren > gehen können, welche Maßnahmen müsste beim Transportprotokoll unbedingt > berücksichtigen werden ? Dazu muss eine Sicherungsschicht dafür sorgen, dass alles ankommt. Am Einfachsten werden dabei fortlaufende Sequenznummern sein. Wenn ein Paket einer bestimmten Sequenznummer fehlt, muss dieses gezielt angefordert werden. Oder man machts über eine Bestätigung der Sequenznummern. Wenn zu einem Paket eine Bestätigung fehlt, wird es eben nochmal gesendet. Und weil das gleich so aufwendig selbst zu schreiben sein wird, würd ich mich mal danach umsehen, wie du dein CAN-Bus aufbohren kannst, um einen TCP/IP drüber zu bekommen. Da kann man dann aber auch gleich auf Ethernet umsteigen... Das OSI-Modell ist dir ein Begriff? mfg mf
Hallo, vielen Dank für deine Hilfe. Das Problem liegt hauptsächlich daran, dass die CAN Nachrichten mit den höheren Prioritäten die anderen CAN Nachrichten stören. Ja das Wort stören ist vielleicht hier falsch. Das OSI Model ist mir ein Begriff. Das Problem haben doch bestimmt viele andere Entwickler auch.
Jemand eine Idee was ich in meinem Fall tun könnte ? Wenn die CAN Nachricht mit der ID 0x13 vom Mikrocontroller empfangen wird und zugleich eine weitere CAN Nachricht mit der ID 0x7FF empfangen werden sollte, dann wird die zuletzt genannte CAN ID möglicherweise gar nicht empfangen.
Wenn Nachrichten mit einer hohen Priorität zu oft "reinkommen", dann muss dafür gesorgt werden, dass diese weniger oft pro Zeiteinheit gesendet werden. Oder die Übertragungsgeschwindigkeit muss erhöht werden. Oder ... Beschreibe doch einmal dein System genauer, Geschwindigkeit, Buslast, etc.
Ja die Buslast ist bei mir nicht so hoch. Ich habe maximal nur 4 CAN Nachrichten die der Mikrocontroller empfangen und verarbeiten müsste. Ich habe da ein großes Problem ein eigene Transportprotokoll mit CAN zu implementieren. Ich habe mir dies zunächst so vorgestellt: Es sollen nur zwei CAN ID's für das Transportprotokoll verwendet werden. - PC sendet CAN ID=0x7FE und ist fungiert als Slave (Programmiersprache C#) - Mikrocontroller sendet CAN ID=0x7FF und fungiert als Master (Programmiersprache ANSI C) Nur wenn der Master eine anfrage an den Slave sendet, soll der Slave daraufhin antworten. Das Problem liegt bei mir auch noch darin, wie man einen Timeout implementiert. Soll ein Timeout nur auf dem Master oder auch auf dem Slave eingesetzt werden ?
Hi, hast du dein p-can auf active oder listen-mode geschalten? CAN Botschaften gehen eigentlich nicht so ohne weiteres verloren. Sie werden über den Bus "öfter" gesendet, falls kein Teilnehmer ein ACK setzt. Ich gehe mal davon aus das dein Empfangs-µC noch mit der 1. Nachricht beschäftigt ist, deswegen die 2. nicht verarbeiten kann und dann aber der p-can das "ACK" setzt. Dann ist die Nachricht weg, da der Sender bestätigt bekommen hat, das sie empfangen wurde. Gruß SD
ah, sorry...vergiss es hab grad erst gelesen, dass du ja mit dem p-can auch kommunizieren willst, also brauchst du den active-mode. Gruß SD
Entwickler schrieb: > Nur wenn der Master eine anfrage an den Slave sendet, soll der Slave > daraufhin antworten. Mach das doch als Remote-Message. SD schrieb: > CAN Botschaften gehen eigentlich nicht so ohne weiteres verloren. Genau, sie verzögern sich nur, wenn eine Message mit höherer Priorität unterwegs ist. Das musst du ev. ausfiltern.
Hallo Guido, Dies bedeutet der Master soll ein Remote Frame senden und der Slave entwortet darauf ? Was meinst du genau mit herausfiltern. Was soll ich rausfiltern und auf welchem Teilnehmer Master oder Slave ? >>Mach das doch als Remote-Message. >>Genau, sie verzögern sich nur, wenn eine Message mit höherer >>Priorität unterwegs ist. Das musst du ev. ausfiltern.
Ja ich vermute auch, dass der Mikrocontroller noch mit der 1. Nachricht beschäftigt ist, deswegen die 2. nicht verarbeiten kann. Wie könnte man vorgehen, das eine größer Menge von Daten durch den Mikrocontroller gesendet und auf dem PC empfangen werden kann ? Die Remote Funktionalität möchte ich nicht dazu benutzen. Ich bräuchte nur so ein paar Ratschläge praktische Vorschläge wie man sowas in ANSI C Implementieren könnte.
Welche Baudrate verwendest du denn? Dann kann man mal schauen was die Buslast sagt. Prinzipiell sollte das kein Problem sein. Schonmal ISO TP angeschaut? Das funktioniert mit statischer Adressierung, also eigentlich genau das was du eh vor hattest. RTR würde ich nicht verwenden, das macht in der Regel mehr Probleme als ein simples TP. Hast du mal geschaut was wirklich auf dem Bus passiert? Das die hohen IDs verloren gehen, kann eigentlich nicht sein. Könnte es sein, dass deine SW die Botschaften verliert?
verwendest du einen CAN Nachrichten Puffer oder arbeitest du jede Nachricht einzeln ab wenn sie eintrifft? Bei CAN empfiehlt sich schon einen Puffer von mehreren Nachrichten zu haben, der über die CANRXIrq gefüllt wird. Die Abarbeitung findet dann in einer "kommunikationsfreien" Zeit statt. Bsp: CANMsg CANRxMsgs[20]; wobei CANMsg ein struct ist mit: byte MsgLen; dword MsgID; byte Data[8]; Somit kannst du im RxIrq das Ding ringpuffermäßig füllen, und woanders abarbeiten. Musst dir halt noch einen counter machen der dir sagt wie weit gefüllt wurde. Gruß SD
Guten Morgen, ich verwende auf meinem Mikrocontroller einen FIFO Puffer, indem die CAn Nachrichten abgelegt werden. Gibt es eine nähere Beschreibung zu dem ISO CAN Transportprotokoll ?
Für die CAN Kommunikation verwende ich die Baudrate 500kBit/s. Nicht mehr als 10 CAN Nachrichten sind auf dem CAN Bus vorhanden.
Folgender Ablauf habe ich mir vorgestellt: 1) PC (PcanDongle) --> Start CAN TP --> Mikrocontroller 2) PC (PcanDongle) <-- Acknowledge <-- Mikrocontroller 3) PC (PcanDongle) <-- Daten senden (256 Bytes) über CAN <-- Mikrocontroller 4) PC (PcanDongle) <-- Alle Daten gesendet <-- Mikrocontroller 5) PC (PcanDongle) --> Acknowledge --> Mikrocontroller Das Versenden von der Daten, sollte dies in einem eigenen Timer, der alle 100ms ausgeführt wird, erfolgen ?
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.