Communication CAN Arduino / MS2 Kdfi and Co.

Modérateur : Team Modo

Répondre
tr450
Messages : 5
Enregistré le : mar. 12 janv. 2016 21:56
A été remercié : 6 fois

Communication CAN Arduino / MS2 Kdfi and Co.

Message par tr450 » dim. 7 avr. 2019 16:12

Salut à tout le monde !!
Bon par où commencer :langue3: J’ai décidé de créer ce post afin de partager sur tout ce qui attrait à la communication CAN sur les gestions prog. type Megasquirt (j’inclus K-Data and co.) tournant avec un firmware MS2extra. Voulant de mon côté palier au manque d’entrés sur ma Kdfi 1.4 j’ai décidé de me faire un petit projet CAN pour pouvoir avoir la température et la pression d’huile sur mon dash. Et comme j’ai pas mal galéré car très peu d’infos pour faire tourner ça sur une MS2 ou similaire, je me suis dit que ça serait sympa de partager tout ça, pour aider ceux qui auraient les mêmes idées que moi ::d .
Du coup je voulais vous montrer comment proprement rédiger l’identificateur et envoyer une trame avec une arduino, mais je pense que je vais vous le faire en plusieurs fois car rien que pour l’identificateur j’en suis déjà à 7 pages au moment où je vous rédige cette intro :gene: .
PS : Je ne suis pas le meilleur du monde en orthographe mais j’essai de faire attention. Ne soyez pas trop méchant si il en reste encore qui traines ^^. Et comme je n’ai pas la science infuse si par malheur j’ai balancé une connerie hésitez pas à en faire part on est là pour partager :gene: .



Bon après cette belle petites intro on saute direct dans le vif du sujet.


Pour commencer le message CAN, car je pense que c’est le point le plus difficile à cerner pour réussir à communiquer avec une megasquirt (ça a été lui le plus bloquant pour moi en tout cas X| ). Je ne vais pas vous faire un grand descriptif du message CAN en général, de bonne définitions existe déjà sur google. Ce qu’il faut juste retenir c’est que le message CAN est en gros divisée en 2 parties la partie identification et le package de donnés. Ici on va s’intéresser à l’identification. C’est elle que la gestion va lire pour savoir de qui vient le message, qui en est le destinataire et où il doit aller. Les systèmes avec un firmware Megasquirt vont tous utiliser « l’identification étendu » en 29Bit. C'est-à-dire un enchainement de 29 0 et 1 stockés dans plusieurs Bytes (je vais dire octet pour la suite pour éviter de mélanger avec les « Bits » :cote: ). C’est le format le plus répandu dans le secteur automobile à l’heure actuelle. Donc notre identificateur 29Bits c’est bien beau mais on met quoi dedans et comment . C’est très simple, pour chaque système utilisant de la communication CAN si les gens derrière sont professionnels ils vont fournir une spec. décrivant comment construire sont identificateur. C’est le cas pour les gestions MS et je vais le détaillé car je ne l’ai pas trouvé très clair au première abord, surtout quand on découvre la communication par CAN.
Donc le beau document s’appel « Megasquirt 29Bit Can protocol » (facilement trouvable en tapant le titre sur google) Pour ceux qui ne parle pas du tout anglais pas de problème, on va repasser en détail ce qui nous intéresse dans ce post.

Donc la forme de notre identificateur va se trouver dans la section 3.1 du document.

Image

Bon j’ai fais exprès de mettre les deux formats de message qu’ils présentent histoire de vous détailler mes boulettes, que personne ne les reproduise :gene: . Donc bien retenir le premier format CE N’EST PAS LE BON ! :nonon: Ne sachant pas je me suis servi d’un petit projet arduino sur Github permettant d’analyser une trame CAN au format du protocole MS et bien sûr il ma orienté dans un mic-mac de ces deux formats me faisant galérer pendant un bon moment =b. Donc nous ce qu’on doit utiliser c’est ce qu’ils appellent le « standard 29Bit identifier ».
Deuxième point à faire attention c’est le sens d’écriture. Comme on peut le voir les bits sont numérotés de droite à gauche et les octets de bas en haut. Du coup gros mélange mental pour le pauvre néophyte que j’étais. Quand on rédige le message on doit le faire de bas en haut, de Haut en bas ? On écrit tout l’octet de haut en bas et on inverse le tout à la fin (un miroir du message en gros) ou on inverse par bloc (chaque morceau se lit bien de gauche à droite mais le message final commence par les blocs d’en bas). Enfin bref plein de question sans explications. ^^
Du coup je me suis pris la tête pour vous et voilà la fameuse réponse.

00001101000010000100000111000

Donc déjà on lit de haut en bas et de gauche à droite, même si les bits sont numérotés dans l’autre sens.
Ensuite pourquoi je me suis pris la tête avec cette histoire « inverser par bloques » ou de faire un « miroir » (comme si j’écrivais un mot à l’envers mots => stom). C’est la partie Table qui m’a mis ça en tête. Comme on peut le voir ils ont remis le bit 4 de la Table de l’autre côté des bits 0 à 3. Donc forcément en fonction de si je considérais mon message 5bits écrit en numérotant les Bits 01234 ou 43210, le Bit que j’allais mettre en position 4 allait changer, ce qui me flinguerait le message. Donc la réponse en exemple. (En relisant ça et en se posant moins de questions je me rends compte que la photo donne déjà le sens :gene: , mais pour ceux qui réfléchissent trop comme moi je donne un exemple)
Je veux la table 7
En binaire ça donne 00111 (en réalité c’est juste 111 mais comme on a 5Bits d’espace pour écrire la table il faut compléter avec des 0).

Et on numérote dans l’ordre suivant :

7 en binaire 00111
n° des Bits 43210
Donc pour pousser l’exemple de la Table jusqu’au bout, dans notre trame CAN notre 7 en binaire sera écrit comme ça 01110 avec le Bit numéro 4 rebalancé tout à droite.
C’est bon j’ai perdu personne ? Bon on s’accroche c’est bientôt fini.
Maintenant qu’on sait dans quel sens on doit écrire notre message passons à ce qu’on doit réellement mettre dedans. (Je commence par les plus simple et fini avec les plus compliqués)

-Spare

Ces deux Bits là restent vide. On va donc toujours mettre « 00 ».

-From ID et To ID

Ces deux groupes de 4 Bits vont dire de qui le message vient et à qui il va aller. L’ID attribué a une certaine importance car il permet de prioriser les messages si plusieurs appareils communiquent en même temps. L’appareil Master sera notre gestion prog. Et donc sera toujours ID 0. Comme on ne fait pas de système trop compliqué et qu’on va avoir une seule extension (pour l’instant ^^) notre carte (arduino) prendra en général l’ID 1. Le protocol CAN détail plusieurs ID pour certaines cartes dont « 2 » pour une « GPIO board », dans la façon dont on enverra des messages ca nous importera peu que notre extension est un ID 2 ou autre. J’en détaillerai la raison un peu plus tard quand je parlerai de l’interface CAN dans tunerstudio. S’il faut retenir une seule chose ici c’est que l’ID 0 doit TOUJOURS être attribué à la gestion prog. Comme ici on cherche à envoyer un message vers la gestion le To ID sera 0000 (0) et le From ID sera 0001 (1).

-message type

Ces 3 Bits là vont décrire le type de message qu’on envoi. Le protocol CAN les décrit bien et ils sont les suivants.

Image
Comme on est des débutants et qu’on veut simplement envoyer des data en continu à la MS pour un mano par exemple, le message type utilisé sera le 0 ou le 2. Le 0 comme il est dit vient déposer des data dans la MS sans qu’elle ne demande rien. Le 2 lui indique que c’est un message en réponse à une demande de data émise par la MS. Dans notre cas l’un ou l’autre convient, même si la MS n’envoi pas de demande de data, envoyer une trame avec un msg type 2 sera traité comme une trame avec un msg type 0.
0=>000
2=>010
(Dans mon cas j’ai utilisé le 2 car j’en avais marre de mettre des 0 partout :langue2: )

-Table

La table, elle, est principalement compliquée dans la façon de la rédiger au sein de l’identificateur (Cf. mes explications sur l’écriture de l’identificateur).
La liste des tables utilisable est également disponible dans le protocol CAN. Ce coup si je ne fais pas de capture d’écran car elle va prendre beaucoup de place. Ce qu’il faut retenir c’est que pour envoyer et stocker des data dans la MS on va toujours utiliser la table 7.
7=>00111 (avec la petite subtilité du Bit n°4 qui revient tout à droite on obtient 01110)

-Offset

Ah l’offset le truc qui n’est pas dans le protocol CAN et qu’on te dit pas où ça se trouve :nono:
Du coup l’offset c’est quoi ? Si on considère les Tables comme des tiroirs, les Offset eux seront toutes les petites boites qu’on retrouvera à l’intérieur d’un tiroir. La faut pas se gourer ! Si on met la data de la température d’huile dans la boite qui sert à modifier l’avance à l’allumage KABOOOMM !!!
Après la mise en garde, le bon offset où le trouver ? Dans le fichier de config. de calculateur tout simplement.
Comme on a une gestion sur base Megasquirt on va retrouver ce fichier dans Document/TunerstudioProjects/nom du projet/ ProjectCfg/mainController

Image

On va ouvrir ce fichier avec bloc-Notes ou wordPad.
Une fois ouvert on va faire un Ctrl+F et rechercher « OutputChannels ».
Si les fichiers de config ne bougent pas, ce qui nous intéresse se trouve juste en dessous du 11ième « output channel ».

Image

Ce qu’on voit c’est qu’il y a une liste avec tout plein de nom de donné, leur type de valeur, leur format/taille, et surtout leur offset (entouré en rouge). C’est cette valeur qu’il faut récupérer.

Image

Voici les 8 offset qui vont nous intéresser le plus dans le cas d’un transfert de data simple.
Exemple, si je veux envoyer quelque chose sur le gpioadc0 je vais utiliser l’offset 104.
104 => (0000)1101000 pour les 0 entre parenthèse c’est comme j’ai dis plus haut. Pour l’offset on a 11Bits d’espace pour l’écrire donc on doit combler l’espace non utilisé avec des 0 pour rédiger notre identificateur final.
Point intéressant à noter. Le package de data pourra faire plusieurs octets. Chaque octet correspondra à un offset+1. Dans l’exemple du gpio0 le premier octet de data correspondra au 104 le deuxième au 105 et ainsi de suite. Ca nous permet d’envoyer plusieurs donnés différentes dans un même message. A noter aussi, je dis offset 105 mais quand on regarde il n’y a pas de 105. On passe directement au 106. C’est normal ! Si vous regardez le gpio0 ça dit « U16 » ce qui nous indique que cette data s’écrit sous 16Bits ou 2 octets et la data à l’offset 104 englobe donc avec elle l’octet à l’offset 105. Je pense que ça fait un peu chinois là mais on verra ça en détail plus tard quand on programmera notre arduino.

Bon pour résumer avec tous les exemples précédents, on obtient tout les morceaux suivants

offsetmsg TypeFrom IDTo IDtable 3-0table 4spare
00001101000010000100000111000
Ce qui nous fais au final notre identificateur 29Bits qui va nous permettre d’envoyer une data de l’ID 1 à l’ID 0 dans la table 7 et l’offset 104 correspondant à la zone de stockage de data pour le GPIO 0. Arrivé là le plus dur est fais. J’espère que mon petit cours vous aura plus ::d . Je détaillerai une prochaine fois comment utiliser cette identificateur avec une arduino et un module de communication CAN pour envoyer de la data à la MS (un peu de pratique c’est important :langue2: ).
Modifié en dernier par tr450 le lun. 8 avr. 2019 18:03, modifié 2 fois.

Avatar du membre
dydy77
Webmaster
Messages : 1889
Enregistré le : sam. 19 mai 2012 20:58
Localisation : 77 IDF
A remercié : 34 fois
A été remercié : 10 fois
Contact :

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par dydy77 » dim. 7 avr. 2019 23:27

Alors j'ai pas pris le temps de tout bien lire et examiné, mais j'ai survolé.

Merci vraiment pour ce partage, de la pure info que l'on trouve quasi que sur JSO ! Bravo.
Continu la suite, c'est genial franchement !!!
306 XSI PH1 2.0 TCT
Ma présentation => ICI
Image

tr450
Messages : 5
Enregistré le : mar. 12 janv. 2016 21:56
A été remercié : 6 fois

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par tr450 » lun. 8 avr. 2019 18:01

Merci ^^
Bon ça va mettre un peu de temps comme j'écris des pavés, mais d'ici une petite semaine la suite devrait tomber.

Avatar du membre
BaTmadZ
Moderateur
Messages : 12078
Enregistré le : sam. 26 févr. 2011 18:23
A remercié : 7 fois
A été remercié : 7 fois

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par BaTmadZ » mer. 3 juil. 2019 07:36

@tr450

Vivement la suite
Car ça peut bien être utile
Par contre effectivement c'est pas évident a bien comprendre

tr450
Messages : 5
Enregistré le : mar. 12 janv. 2016 21:56
A été remercié : 6 fois

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par tr450 » sam. 27 juil. 2019 20:22

Salut BaTmadz!

Ça va venir =b. J'avais déjà commencé à taper la suite mais j'ai dû mettre le sujet un peu en stand-by.
Je vais retrouver un peu de temps avec les congés en août.

tr450
Messages : 5
Enregistré le : mar. 12 janv. 2016 21:56
A été remercié : 6 fois

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par tr450 » ven. 2 août 2019 23:35

En avant pour la deuxième suite ^^.

Du coup je vais vous présenter un petit exemple pratique où je vais vous détailler le matos que j’ai utilisé, les différents codes, et les liens vers les originaux.
Du coup en terme de matos j’ai fais mes essais sur une base d’Arduino UNO et d’un module CAN v1.2 (Cf.photo).

Image

La marque importe peu comme les schémas sont en libre accès tout le monde copie tout le monde et du coup c’est grosso modo le même module quelque soit le vendeur^^.
Ensuite en terme de matos si vous voulez pousser le truc et expérimenter un peu plus, ce qui peu être intéressant c’est de se créer une box pour alimenter sont calculateur et avoir les différentes sorties accessible.

Image

Je vais pas entrer dans les détails de sa fabrication ce n’est pas le sujet ici mais globalement c’est juste un faisceau branché sur une broche avec une prise pour brancher sur le secteur et un fusible pour pas cramer le calculo (on sait jamais ^^).

Pour le schéma de branchement avec le calculo je vous en dispense comme c’est ultra simple => CANH du calculo sur CANH du module et CANL du calculo sur CANL du module. Et c’est tout !

Bon maintenant la partie la plus intéressante surtout pour les feignants qui ont la flemme de chercher sur internet (on a tous ses moments de faiblesse ^^).

Donc pour la communication CAN comme il existe plusieurs types d’adressage (11 et 29Bits pour les plus connus) il nous faut un programme arduino qui nous permette d’envoyer des trames avec un identificateur 29 Bits. Je me suis servie de l’exemple de ce monsieur en lien qui est très clair et simple d’utilisation.

https://matthewcmcmillan.blogspot.com/search/label/CAN

Petite parenthèse ci-dessous le lien vers la librairie à ajouter au logiciel arduino pour pouvoir faire tourner notre module CAN.

https://github.com/Seeed-Studio/CAN_BUS_Shield

Bon revenons au programme de notre amis Matthew. Après un peu d’élagage on obtient le truc suivant qui est le strict minimum nécessaire.
------------------------------------------------------------------
#include "mcp_can.h"
#include <SPI.h>

MCP_CAN CAN(10); //CAN CS pin


int cantxValue = 0;

void setup()
{
Serial.begin(115200);
// init can bus, baudrate: 500k
if(CAN.begin(CAN_500KBPS) ==CAN_OK) Serial.print("CAN init ok\r\n");
else Serial.print("CAN init failed\r\n");
}

void loop()
{
//Create data packet for CAN message
unsigned char canMsg[8] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
// format: (id, id_type, dlc, data buf)
CAN.sendMsgBuf(0x1A10838, 1, 8, canMsg);
delay(100);
}
-------------------------------------------------------------

Pour l’instant on va principalement s’intéresser à cette partie.

CAN.sendMsgBuf(0x1A10838, 1, 8, canMsg);

Le premier morceau c’est l’identificateur. Oui, le beau tas de 0 et de 1 qu’on s’est embêté à créer dans mon premier post. La seule différence c’est qu’il est écris en Hexadécimal. Rien de bien compliqué pour nous ici un petit convertisseur Binaire vers Hexadécimal on balance notre chaine de 29Bits dans la moulinette et ça nous recrache le tout en Hexa.

Le deuxième point qui est un 1 ici sert à indiquer au module CAN s’il doit envoyer un identificateur 11 ou 29 Bits. Nous on veut envoyer un 29 Bits donc il faut que la valeur soit à 1 (0 si on veut le 11 Bits).

Le 8 qui vient ensuite indique au module le nombre d’octet de data qu’il va envoyer derrière l’identificateur.

Et le canMsg on s’en fou xD (Je sais que ça reste côté Arduino et que ça ne fait pas parti du message envoyé à notre calculateur. Et comme on dit, On ne change pas un truc qui marche =b).

Ensuite les datas. Celles-ci seront marquées directement dans cette partie en Hexadécimal.
unsigned char canMsg[8] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

Comme j’ai pu l’expliquer dans mon premier post certaines data comme les gpioADC 0-1-2-3 etc. sont stockées sur 16Bits et donc vont utiliser deux octets à chaque fois. Si le message que vous voulez envoyer tiens sur 1 octet mettez le toujours dans le deuxième octet du code ci-dessus. Ca vous évitera un peu la prise de tête pour reconvertir la data dans tunerstudio.

Parlons un peu plus pratique maintenant. Le code ci-dessus il est beau, mais au mieux il nous permet d’envoyer qu’un message fixe qu’on défini au moment ou on programme l’arduino. Pas très intéressant tout ça. Nous on veut une data qui varie en permanence (un capteur en gros). On aura principalement 2 types de capteurs les 0-5v et les thermistances. (Les sondes TC entrent dans la case des 0-5V avec un module qui converti leur signal).

-0-5v

C’est de loin le plus simple à mettre en application.

-------------------------------------------------------
#include "mcp_can.h"
#include <SPI.h>

MCP_CAN CAN(10); //CAN CS pin

int cantxValue = 0;
int analogPin0 = A0;
int analogPin1 = A1;

int ADC0 = 0;
int ADC1 = 0;


void setup()
{
Serial.begin(115200);
// init can bus, baudrate: 500k
if(CAN.begin(CAN_500KBPS) ==CAN_OK) Serial.print("CAN init ok\r\n");
else Serial.print("CAN init failed\r\n");
}

void loop()
{
ADC0 = analogRead(analogPin0)/4;
ADC1 = analogRead(analogPin1)/4;

//Create data packet for CAN message
unsigned char canMsg[8] = {0x00, ADC0, 0x00, ADC1, 0x00, 0x00, 0x00, 0x00};
// format: (id, id_type, dlc, data buf)
CAN.sendMsgBuf(0x1A10838, 1, 8, canMsg);
delay(100);
}
-------------------------------------------------------

Voila le code modifié pour avoir 2 entrés analogiques 0-5V. L’Arduino fait tout le boulot à notre place et transforme directement le signal 0-5V en une valeur de 0-1023. Vous aurez remarqué que j’ai surligné en deux couleurs différentes. Comme au moment où j’ai créé mon programme je n’avais pas percuté que le message prenait 2 octets et non un seul je me suis dit mince 0-1023 ça rentre pas dans 1 octet (on peut faire que 0-256) du coup ni une ni deux je créé une nouvelle variable qui serait la première divisée par 4 tout simplement. Il est tout a fait possible de ne pas diviser le message comme je l’ai fait et directement l’envoyer en le coupant en 2 parties allant dans chacun des deux octets, mais comme je n’ai pas encore creusé cette idée je n’ai malheureusement pas de programme à vous proposer (une prochaine fois surement ^^).

Bon arrivé là félicitation ! Vous êtes capable d’envoyer la data d’un capteur de pression d’huile (0-5V) ou d’une sonde TC (équipé d’un module de transformation du signal).

C’est déjà cool, mais il manque encore un truc qu’on utilise souvent dans nos voitures et ce sont les thermistances. En gros tous les capteurs de température « classiques ».

-Thermistance

Pour ces capteurs là on va avoir besoin de faire un peu plus de maths.
Je vais aussi vous montrer le schéma de branchement car c’est un poil plus compliqué que les capteurs 0-5v qui eux se limitent à un seul branchement.

Image

Donc pour comprendre la raison d’un tel schéma il faut savoir qu’une arduino n’est pas capable de mesurer directement une résistance (ils ont oublié l’option multimètre…). Ce qu’elle sait faire c’est mesurer une tension. Ce petit montage permet donc d’avoir une tension qui varie en même temps que la résistance du capteur.

Maintenant la partie programmation de l’arduino.

---------------------------------------------------------

#include "mcp_can.h"
#include <SPI.h>

MCP_CAN CAN(10); //CAN CS pin


int cantxValue = 0;
int analogPin0 = A0;
int ADC0 = 0;
int R0 = 0;
int T0 = 0;
int REF = 10000;


void setup()
{
Serial.begin(115200);
// init can bus, baudrate: 500k
if(CAN.begin(CAN_500KBPS) ==CAN_OK) Serial.print("CAN init ok\r\n");
else Serial.print("CAN init failed\r\n");
}

void loop()
{

ADC0 = analogRead(A0);
R0=1023*(REF/ADC0)-REF;
// coef. de Steinhart A=0.00141466 B=0.00024153 C=0.00000026758
T0=1/(0.00141466+0.00024153*log(R0)+0.00000026758*log(R0)*log(R0)*log(R0))-273;


//Create data packet for CAN message
unsigned char canMsg[8] = {0x0, T0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
// format: (id, id_type, dlc, data buf)
CAN.sendMsgBuf(0x1, 0, 8, canMsg);
delay(100);
}
------------------------------------------
Donc pour expliquer tout ce Chinois dans l’ordre. Notre circuit nous donne une valeur adc (0-1023) qui correspond à une tension. La formule suivante nous permet d’avoir la valeur réelle de cette tension :

Vout=5* ADC/1023

Après cette tension est liée à une résistance qu’on obtient avec la formule suivante :

Rth=5* Rref/Vout-Rref

Ici Rref étant la résistance de référence qu’on a ajoutée (Cf. schéma). Info supplémentaire pour bien choisir la valeur de Rref il faut prendre la classe de la thermistance utilisé. Si une thermistance de 10Kohm, alors on prend une résistance de 10Kohm. Si on ne connait pas la classe de notre capteur, la règle que j’ai pu voir c’est prendre une résistance du même ordre de grandeur que la plage de Resistance du capteur. Sinon option 2, comme la classe correspond à la valeur de résistance du capteur à 25° suffi de trouver cette valeur R à 25° et roule.

Comme dans l’idée avoir Vout on s’en fou un peu, on peut simplifier l’équation en regroupant les deux et obtenir le truc qui suit :

Rth=1023* Rref/ADC-Rref

Bon c’est bien beau on a Rth mais nous on veut une température. Pour ça c’est cette partie plus ou moins dégueulasse de notre programme qui correspond à l’équation de Steinhart.

---------------------------------------------------------------------
// coef. de Steinhart A=0.00141466 B=0.00024153 C=0.00000026758
T0=1/(0.00141466+0.00024153*log(R0)+0.00000026758*log(R0)*log(R0)*log(R0))-273;

---------------------------------------------------------------------
Alors l’équation de Steinhart c’est une belle équation qui permet avec l’aide de trois variables A, B, et C (variables qui dépendent de notre capteur) de calculer « précisément » la température.

T= 1/(A+B*ln(Rth)+C*ln(Rth)^3 )-273

Pour info les valeurs que je prends en exemple sont des valeurs que j’ai recalculées à partir d’un graph de température de capteur PSA, Et donc valable pour nos TCT et autres XU. Au cas où pour les autres les fabricants donnent ces valeurs en temps normal, sinon on peut les calculer en connaissant 3 points de fonctionnement du capteur.

Bon voila on a notre température en Celsius. Maintenant suffi de jeter ça dans le package de donné et l’envoyer vers le Megasquirt.
Alors je n’ai pas trop détaillé mais ceux qui jouent déjà un peu avec des Arduino vont me dire, Attention tu balances directement une valeur de température sans la reconvertir en valeur ADC (0-1023) !! Effectivement, mais comme je suis feignant et que j’ai pas prévu de faire tourner mon moteur au dessus de 256°C que ça soit en température d’huile ou d’eau, mettre la valeur directement n’est pas gênant et nous évite d’ailleurs de se taper les reconversions des valeurs ADC comme ça va être le cas pour les capteurs 0-5v (c’est pas non plus super compliqué).

Côté TunerStudio

Bon je suis sympa je vous ai montré les bases du programme pour communiquer, j’ai même un peu dévié sur comment traiter les infos des deux principaux capteurs qu’on utilise sur nos voitures. Maintenant on va jeter vite fait un coup d’œil à comment on gère la com. CAN côté tunerstudio et pour finir comment on traite les signaux envoyés pour lire proprement des températures, pression, ou quoique ce soit d’autre.

Alors concernant la com. CAN on peut faire plein de choses avec Tuner notamment programmer des messages qu’on pourrait envoyer à l’arduino ou autre appareil pour que celui-ci réponde en conséquence. Mais je vous avouerai que perso je trouve que leur interface est un peu un foutoire avec des trucs qui se répètent et trop peu d’info pour prendre en main correctement le truc (surtout pour un débutant comme moi ^^). Au grand bonheur je ne vais rien vous expliquer de tout ça car au final on n’en a absolument pas besoin. Vous pouvez même garder la com. CAN en desabeled dans tunerstudio, avec ce que je vous ai montré ça marchera quand même. Au final ce qu’il faut comprendre c’est que dans sa façon de fonctionner ce menu sert juste à envoyer des demandes le fait de le désactiver ne coupe pas la « boite au lettre » qui elle continue de recevoir et traiter les messages. Enfin tous ça pour donner un warning final sur un point que j’avais remonté déjà dans mon premier message, faites bien attention à l’adressage car envoyer une trame n’importe où peu avoir des conséquences plus ou moins néfastes.

Bon sautons directement à la parti « hors sujet » mais intéressante côté tunerstudio. Comme j’ai dis pour les capteurs 0-5v on envoi un signal ADC allant de 0 à 1023. Ce truc là il faut bien sûr le reconvertir pour avoir une température ou autre.

Dans Tunerstudio vous devrez aller dans le menu suivant : Add custom Channel Wizard

Image

Custom Channel Editor lui permet de gérer tout les cadrans déjà crées.
Bon quand on clique sur Add custom Channel Wizard on obtient ça.

Image

Dans la version simple il n’y a pas grand-chose à expliquer. Input c’est le nom de l’entré donc tout les gpioadc que vous allez utiliser.
Ensuite le nom de la nouvelle variable que vous créé son unité. Nous on a un signal 0-5v qui est linéaire donc on prend ça. Le inc File c’est bien pour les capteur non linéaire mais je sais pas comment en créer donc je risque pas de vous expliquer comment faire xD.
Ensuite la conversion on en a pas besoin vue qu’on reçoit directement un signal adc.
Et ensuite comme c’est linéaire deux points de fonctionnement (en général maxi et mini donné par le constructeur) et roule c’est converti. Vous noterez un vestige de mon erreur avec le placement des data dans les octets du message qui m’a obligé à prendre des valeurs un peu extravagantes ^^.

Vous noterez l’option Advanced. Celle-ci permet de tapez directement des équations comme celles vue dans la section thermistance. J’ai personnellement choisi de les faire dans l’arduino car mon pc de bord est assez faible et donc moins il mouline moins j’ai de chance de me taper des freeze du dash.
Bon la deuxième raison c’est qu’en version light ou normal cette option n’est pas dispo xD.
Une technique à l’ancienne c’est de créer manuellement une variable géré par une fonction dans le fichier de config. (pas eu besoin donc jamais testé).

Bon voilà j’ai fais à peu près le tour du sujet maintenant libre a vous de poser des questions si jamais je n’ai pas été des plus clair.

Next step pour moi, passer d’un empilement plutôt épais de arduino et modules CAN à un truc custom et miniature.

Image

Avatar du membre
dydy77
Webmaster
Messages : 1889
Enregistré le : sam. 19 mai 2012 20:58
Localisation : 77 IDF
A remercié : 34 fois
A été remercié : 10 fois
Contact :

Re: Communication CAN Arduino / MS2 Kdfi and Co.

Message par dydy77 » sam. 3 août 2019 14:47

Chapeau !!!
306 XSI PH1 2.0 TCT
Ma présentation => ICI
Image

Répondre