Problem mit Variablen in CAN Nachricht

Hallo zusammen,

ich komme gerade nicht weiter, brauche also jemanden, der mich in die richtige Richtung schubst.

Es geht darum einen Wechselrichter und ein Batteriemanagementsystem miteinander zu verbinden, die Kommunikation erfolgt über CAN. Dazu benutze ich einen Leonardo und das CANDIY Shield von Watterott in Verbindung mit der MCP2515 Library von coryfowler.

Die Kommunikation an sich ist nicht das Thema, kann von beiden Geräten Werte empfangen und welche an diese schicken. Sobald ich jedoch einen Wert empfange und diesen an das andere Gerät senden möchte, hakt es noch etwas. Ich vermute, dass meine Variablen nicht das richtige Format haben.

Das hier funktioniert einwandfrei, die Werte kommen an und werden in der Software meines BMS angezeigt:

unsigned char stmp3[8] = {highByte(550),lowByte(550),highByte(200),lowByte(200),0,0,0,0};
CAN0.sendMsgBuf(0x18FF50E5, 1, 8, stmp3);

Wenn ich jedoch die empfangenen Werte verwende, geht es in die Hose:
(Ich habe den Code auf die hoffentlich relevanten Teile gekürzt)

long unsigned int rxId;
unsigned char len = 0;
unsigned char rxBuf[8];
int unsigned si_bat_v;

//Werte als CAN Nachricht empfangen und verarbeiten
CAN0.readMsgBuf(&len, rxBuf);
si_bat_v = rxBuf[1]*256+rxBuf[0];
unsigned char stmp3[8] = {highByte(si_bat_v),lowByte(si_bat_v),highByte(200),lowByte(200),0,0,0,0};

Laut Datenblatt wird der ankommende Wert als U16 gesendet.

Ein Serial.print(si_bat_v) gibt mir die 550 aus, offenbar ist das jedoch nicht das Gleiche wie die 550 im Code oben. Habe es auch schon mit word(rxBuf[1], rxBuf[0]) statt rxBuf[1]*256+rxBuf[0] versucht, gleicher Effekt.

Bits und Bytes sind wohl noch nicht so ganz meine Welt.

Danke schon mal für eure Hilfe.

Guy

hi,

vielleicht weiß ich da ja was nicht, aber was ist ein:
long unsigned int
??

gruß stefan

Gute Frage, ist mir bislang nicht aufgefallen.

Das stammt aus dem Beispiel zu der Bibliothek, die ich verwendet habe. Keine Ahnung, was dann gilt, int oder long.
Sollte mit meinem Problem allerdings wenig zu tun haben.

GuyW:
Ein Serial.print(si_bat_v) gibt mir die 550 aus, offenbar ist das jedoch nicht das Gleiche wie die 550 im Code oben.

Warum bastelst Du überhaupt erst eine Variable zusammen, auf die dann wieder ein Makro angewendet wird?
Warum sendest Du nicht gleich die einzelnen Bytes wieder raus:

unsigned char stmp3[8] = {rxBuf[1],rxBuf[0],highByte(200),lowByte(200),0,0,0,0};

Laut Datenblatt wird der ankommende Wert als U16 gesendet.

Und das sendende System ist big endian oder little endian?

Verwende im Code nur die klar definierten Typen (uint16_t, uint8_t, int32_t, etc.), alles andere wirft nur Probleme auf.

jurs:
Warum bastelst Du überhaupt erst eine Variable zusammen, auf die dann wieder ein Makro angewendet wird?

Der Code oben ist stark gekürzt. Ich muss Werte aus unterschiedlichen CAN Nachrichten in eine neue packen, direkt geht das also nicht. Zudem möchte ich auf bestimmte Werte reagieren und eventuell Strom und Spannung begrenzen.

pylon:
Und das sendende System ist big endian oder little endian?

Der Wechselrichter sendet die Daten als little endian, unsigned 16 bit, signed 16 bit und unsigned 8 bit Werte. Der Wert, den ich oben erwähnt habe, sollte unsigned 16 bit laut Datenblatt sein.

Ich habe bislang immer int und long benutzt, werde meine Variablen nun genauer definieren. Da mir Serial.print() den richtigen Wert liefert, muss der Fehler ja da irgendwo zu finden sein. Dachte bislang, dass es passen müsste, wenn der Wert als unsigned 16 bit ankommt und die Variable als unsigned int definiert ist.

Danke schon mal für eure Hinweise.

Dachte bislang, dass es passen müsste, wenn der Wert als unsigned 16 bit ankommt und die Variable als unsigned int definiert ist.

Grundsätzlich sollte das auch genügen, aber mit den genauen Typen ist immer klar, was passiert, ohne bleibt häufig Interpretationsspielraum.

Poste den kompletten Sketch. Die hier geposteten Auszüge liefern das selbe Resultat, wenn wirklich 550 ausgegeben wird. Aber was im restlichen Code noch schiefgehen kann, das wissen wir noch nicht.
Falls der Code zu gross ist, kürze ihn so, dass ein minimaler Sketch herauskommt, der das Problem aber noch nachvollziehen lässt.