Erfahrungen mit CAN Adapter von Cooking Hacks?

[captain_to_slow]

Hi,
ich selbst nutze einen Raspberry Pi 2 mit einer Arduino Shield Connection Bridge sowie einem
CAN Bus Shield von Cooking Hacks. ArduPi Library 1.5 für RasPi2 sowie die CAN-Library für RasPi.

Nur sind meine Erfahrungen damit freundlich ausgedrückt: Nicht positiv.

Vielleicht gibt es hier aber jemanden der damit positiver Erfahrungen gemacht hat?

Ich verwende aktuell das Beispiel (CANBUS_basicexample.cpp) aus dem Cooking Hacks Tutorial Link zum Tutorial
habe damit aber das Problem das mir die Api dauerhaft meldet das die Buffer belegt sind und somit keine Nachrichten gelesen werden können.
Das Beispiel Programm soll empfangene CAN Nachrichten ausgeben und selbst eine eigene Nachricht mit hochlaufendem Zähler abschicken.

Ich nutze als Gegenstelle einen TinyCan an einem Windowsrechner.
Beide Can-Transmitter sind auf die gleiche Geschwindigeit eingestellt.

Was mir aufgefallen ist:
Solange ich mit dem TinyCan keine eigene Nachricht schicke bleibt der CAN Status auf OK, ist auch nicht verwunderlich, denn das Programm auf dem RasPi sendet ja selber nix.
Sobald ich von dem TinyCan eine Nachricht sende geht der Can-Status auf Error Passiv, da die Nachricht von niemanden bestätigt wird, also das ACK fehlt. Stimmt auch, denn beim RasPi Programm kommt die Nachricht nie an.

Vielleicht habe ich das Glück, dass hier schon jemand mit deren Produkten Erfahrungen gesammelt hat, oder besser noch genau diese Kombi zum laufen gebracht hat.
Falls sonst jemand noch eine Idee hat, was ich ausprobieren könnte: Immer her damit.

[Hiswif]

Heho.

Hast du zufällig einen Logikanalysator? Wenn ja, dann hänge den mal an CAN High und CAN Low und schaue was vom Tiny CAN rauskommt. Wenn nein, dann hohl dir lieber schnell einen Die aus China kosten um die 10€ -20€ und haben mir schon jede menge sucherei erspart.

Zurück zum Thema. Kannst du uns mal deinen Code zeigen? Ich habe da eine Vermutung, will dazu aber noch nix sagen, da es Glaskugelsehen wäre.

MFG

His

[captain_to_slow]

Hi,
Logikanalysator habe ich nicht, aber wenn das Preislich so interessant ist, wird es das erste sein was ich noch dazu ordere.

Code ist, wie oben schon erwähnt genau der des Beispiels.
Falls deine Vermuting sich auf die Can-Ids bezieht, ich habe mit dem Tiny die 200 als Dez. und Hex. ausprobiert.
Gehört habe ich auf alles was über den Can kommt.

Code: Select all

#include "CAN.h"
#include "arduPi.h"

// ID numbers
#define IDWAITED 200
#define OWNID 100

// Create an instance of the object
CAN myCAN = CAN();

// Setting up our devices and I/Os
void setup() {
  // Let's open the bus. Remember the input parameter:
  myCAN.begin(1000);
}

void loop() {
  
  //****************************************
  // 1. Receive data
  //****************************************
  
  if (myCAN.messageAvailable() == 1) {
    // Read the last message received.
    myCAN.getMessage(&myCAN.messageRx);
    // Print in the serial monitor the received message
    myCAN.printMessage(&myCAN.messageRx);
  }
  

  //****************************************
  // 2. Send data
  //****************************************
  
  // Insert the ID in the data structure
  myCAN.messageTx.id = OWNID;
  // These fields include the data to send
  myCAN.messageTx.data[0] = 0;
  myCAN.messageTx.data[1] += 1;
  myCAN.messageTx.data[2] = 2;
  myCAN.messageTx.data[3] = 3;
  myCAN.messageTx.data[4] = 4;
  myCAN.messageTx.data[5] = 5;
  myCAN.messageTx.data[6] = 6;
  myCAN.messageTx.data[7] = 7;

  // The length of the data structure
  myCAN.messageTx.header.length = 8;
  // Send data
  myCAN.sendMessage(&myCAN.messageTx);  
  // A time delay
  delay(1000);
}

int main (){
	setup();
	while(1){
		loop();
	}
	return (0);
}

Habe mir erlaubt etwas Kommentare aus dem Beispiel zu entfernen, damit es nicht so lang wird

[crumble]

Moin,

ist die Bibliothek ueberhaupt an den Pi 2 angepasst?
Es gab da ein paar winzige Aenderungen bei der Ansteuerung der GPIO Pins. Versuch es mal mit einem Update fuer das Board oder mit einem alten Pi. Ansonsten wirst Du nach den Sourcen suchen und die Stellen selber anpassen muessen.

[captain_to_slow]

Hi crumble,
welche der beiden Bibliotheken meinst du?
Die ArduPi Shield Bibliothek ist schon die für den Raspberry Pi 2, wie ich auch im Eingangsposting geschrieben habe.
Die CAN Bibliothek gibt es bisher meines wissens in keiner neueren Variante, sollte aber dort auch kein Problem darstellen,
da die Kommunikation ja über das ArduPi Shield stattfindet, mit der Bibliothek für den Raspi 2.

[Hiswif]

Heho,

Falls deine Vermuting sich auf die Can-Ids bezieht, ich habe mit dem Tiny die 200 als Dez. und Hex. ausprobiert.

Ja das war meine Vermutung, denn die ID's sind beim CAN das Hauptproblem, vorallem wenn man in andere Systeme hören will. Nicht umsonst ist die Kommunikationsmatrix mit den ID's meist Verschlussache. Aber das ist Offtoppic.

... ich habe mit dem Tiny die 200 als Dez. und Hex. ausprobiert

Du hast zwar im Code

Code: Select all

#define IDWAITED 200

definiert. Aber du verwendest die ID doch nirgens? Ich kenne mich jetzt leider mit dem Controller und dem Board nicht aus, aber bist du sicher das der Controller automatisch auf alles hört wenn du ihm keine ID angibst?

MFG

His

[captain_to_slow]

Deine Frage ist berechtigt und ehrlich gesagt:
Als ich mir das Beispiel, welches ich ja gepostet habe, angeschaut habe, ist mir
die gleiche Frage gekommen die Du gestellt hast:

Wozu definieren die eine Wait-Id wenn diese nirgends Verwendung findet?
Wobei ich vielleicht von den Vector Can-Adaptern verwöhnt bin: Die hören auf alles was auf dem Can los ist.
Ich werde mir die Can-Library mal im Detail zu genüge fügen.

VorEdit:
Dann poste ich noch mal ob ich aus deren Beispiel Code schlau geworden bin.
Mein Gedanke war eigentlich banal: Ich probiere erst einmal deren Beispiel aus und danach
schreibe ich den eigene Code. Da aber das Beispiel nicht einmal rennt, hänge ich da ziemlich in der Luft.

Mfg Marc

Edit:
Also der Code den die Cooking Hacks für OBD Werte benutzten vergleicht nach dem Empfang einer Nachricht, ob die Id der Nachricht, welche Empfangen wurde der EmpfangsId entspricht.
Meine Schlußfolgerung: Es werden alle Nachrichten unabhängig von den Ids empfangen.

Hilft mir bei meinem Problem der Buffer natürlich keinen Meter weiter.
Montag soll der Logikanalyser kommen, dann schaue ich mal weiter was auf dem Kabel den so los ist, oder auch nicht.

[Hiswif]

Sehr schön. Du wirst den Logik analyser nicht mehr missen wollen. Da fällt mir noch ein. Was für abschlusswiderstände benutzt du und wo sind diese verbaut? Schau mal hier. Das war am Anfang für mich recht hilfreich.
http://www.microcontrol-blog.net/2012/1 ... etzwerken/

[captain_to_slow]

Ich werde es ausmessen,
laut Cooking Hacks hat deren Can-Shield einen 120 Ohm Wiederstand integriert.
Was der Tiny Can hat, kann ich nicht sagen, werde das mal versuchen auszumessen ohne das Kabel zu zerstören zu müssen.
Naja Unterseite der Adapter wird dann wohl herhalten müssen.

Warte schon sehnsüchtig auf den Postboten, damit ich den Logikanalyser dann mal testen kann.

[Hiswif]

Wo hast du den Analyzer bestellt, dass der so schnell da ist?

[captain_to_slow]

@Hiswif Ich hatte mich leider im Liefertermin vertan, wird wohl 27 April, also direkt frisch aus China

Aber ich habe zu 99% die Lösung meines Problems gefunden, wenn ihr das lest werdet ihr wahrscheinlich
einen Lachanfall bekommen.
Die Lösung scheint sehr simpel zu sein:
TinyCan und CanShield nutzen den DB9 Stecker, nun bin ich dummerweise davon ausgegangen, dass die Belegung bei beiden gleich ist. Gibt ja schließlich eine Norm dafür.

Hiswif hatte einen guten Riecher mit dem Logianalysator, denn damit würde ich das Problem auch sofort sehen,
Die Signale werden zerhackt.
Warum? Ganz einfach, TinyCan DB9 Belegung ist nach CiA-DS102-1 während die CanShield DB9 Belegung nach OBD-2 ist.

Also wie folgt:

Code: Select all

TinyCan Pin #; Belegung
01; nicht Belegt
02; CAN-L
03; CAN-GND
04; reserviert
05; CAN-Shield
06; GND
07; CAN-H
08; reserviert
09; CAN-V+ aber nicht verdrahtet

CAN-Shield von Cooking Hacks

Code: Select all

CAN-Shield #; Belegung
01; Signal Ground
02: Chassis Ground
03: CAN High (J-2284)
04: ISO 9141-2 K Line
05: CAN Low (J-2284)
06: J1850 Bus -
07: J1850 Bus +
08: ISO 9141-2 L Line
09: Battery Power

Wie man jetzt leicht sehen kann, sieht man nix, also das wird so nicht klappen.
Ich muss mir das über mein Prototyping Board patchen, dann klappt das wahrscheinlich auch mit dem Nachbarn.

Ich werde noch mal ein Feedback geben ob es das war, ich gehe aber davon aus das dies das letzte Problem ist

[Hiswif]

Oh. Da haben wir beide was gelernt. Da wir viel mit Fahrzeugen machen, kannte ich bisher auch nur die obd2 stecker. Gut zu wissen das es auch andere gibt. Den fehler macht man zum glück nur das erste mal
Ansonsten ist der logik analyzer trotzdem immer die investition wert und wird dir bestimmt noch so einige schlaflose nächte ersparen.

Schöne Ostern wünche ich. Immer schön dran denken: Wer Ostern mit den Eiern spielt, hat Weihnachten Bescherung.

Mfg

His

[captain_to_slow]

Naja jetzt warte ich erst mal darauf, dass mein frei belegbares Kabel mit der Post kommt.
Nach dem fünften Elektronikladen hatte ich die Nase voll.
Da wurde man schon super angeschaut wenn man nach einem 9 Poligen D-Sub Stecker suchte.
Meiste Antwort: " Ein was?", worauf ich dann sagte: RS232 Schnittstelle z.b.;
Kennt heute kein Mensch mehr, selbst der Hinweis das Ding sieht aus wie ein VGA Kabel, nur mit 9 Polen statt der vielen.

Aber der Herr Amazon hat das zuhauf.

Tante Edit:
Danke, euch auch ein frohes Ostern!

[captain_to_slow]

Also heute kam ich doch noch zum Basteln:

Neben den offensichlichten Problemen durch unterschiedliche Steckerbelegung,
war auch noch das DB9 M/F Kabel, welches Cooking Hacks mitgeliefert hat,
defekt.
Einige Pins waren nicht durchkontaktiert, was meinen Patchversuchen nicht zuträglich war,
aus Verzweifelung und Zufall direkt ohne das DB9 Kabel ausprobiert und es lief.
Manchmal ist die Lösung so einfach.

Also an alle die diese Kombi auch ausprobieren wollen: Denkt an die unterschiedliche Pin Belegung der DB9 Stecker und patcht diese, dann sollte es auch mit dem Nachbarn funktionieren.

Für alle neugierigen: Lasst euch von der schlecht dokumentierten API von Cooking Hacks nicht abschrecken, es funktioniert alles sehr easy, wenn es läuft. Fehlersuchen in den StatusBits des Kontrollers ist Aufgrund der Kontroller-Spezifikation nicht so schwer, nur muss man sich einmal die Mühe machen und die festen Werte und Abfragen in vorhandene Define-Namen umzuwechseln und schon ist das Debuggen ein Traum!
Warum das von den Entwicklern von Cooking Hacks unterlassen wurde? Keine Ahnung.