Projet bus CAN

[invite7d2538d5]

Bonjour a tous,
Nous sommes actuellement en train de réaliser un projet d’électronique portant sur le bus CAN. Nous avons pour objectif de réaliser un bus entre 2 cartes MBED. Après s'être taper un sacré paquet de documentations(nous n'y connaissons absolument rien en électronique appliquée ) nous avons réalisé un premier montage.
Plus précisément c'est un "demi montage" afin de tester si notre configuration marche à l'aide d'un générateur de trames CAN.
Notre idée (simple me direz vous! ) est de placer un interrupteur et une LED sur le bus et faire réagir la LED selon la position de l'interrupteur.
Par contre, nous ne parvenons pas a faire communiquer le générateur de trames et la carte MBED.
On arrive tant bien que mal a configurer le générateur de trames mais nous ne voyons pas comment réaliser le programme de la carte MBED pour réaliser ce qu'il faut.

Merci d'avance pour vos réponses!
-----

[invite03481543]

Bonsoir et bienvenue sur le forum d'électronique,

le bus CAN est l'un des bus de communication les plus complexe du moment, car extrêmement fiable, je suis toujours étonné par la manière très "légère" avec laquelle ceux qui vous mettent sur ce genre de projet ne vous briffent pas davantage... et vous laisse dans la forêt sans boussole si je puis dire.

Dernièrement nous avons mené à bien un projet à base de bus CAN orienté sur un système de mise en réseau de BMS pour batteries Lithium, et il nous a fallut un bon mois à 2 pour aboutir.
Avec plus de 25 ans d'expérience derrière nous, autant dire que la tâche n'est pas aisée même si notre projet fut fait en assembleur, ce qui était imposé par notre client.

Bref, c'était juste pour vous dire par cela qu'entrer dans le CAN nécessite une bonne connaissance générale et de la pugnacité, surtout si vous n'avez aucune connaissance préalable d'autres bus de communication.

Déjà je vous suggère vivement de vous munir d'un analyseur de trame CAN, ça ne coûte pas cher et ça rend d'immense service.
Ensuite pour pouvoir vous aider il va falloir en dire plus sur tout ça, comment voulez-vous être aidé avec si peu de description sur ce que vous avez fait?
C'est quoi vos cartes embedded, quel µC, quel CAN (standard, étendu)?

@+

[invite03481543]

Il n'est pas plus compliqué d'allumer une led que de piloter un écran LCD à travers le bus CAN, c'est de mettre en place le CAN qui est le plus fastidieux.
Bien comprendre la notion de filtres et d'identificateurs, bien comprendre également qu'avec le CAN il n'y a ni maitre ni esclave, ni système d'adressage.

[invite7d2538d5]

Tout d'abord merci de votre réponse.
Il est vrai que notre la personne qui est sensée nous guidée nous a imposé ce sujet et ne nous a pratiquement pas aidé. (Lisez la doc sur internet étant sa réplique préférée).
Nous avions bien compris que le problème n'était pas le fait d'allumer ou d'éteindre une lampe ou quoi que ce soit d'autre mais bien de mettre en place les échanges sur le bus.
Notre carte est une MBED LCP 1768. Nous avons des transceivers 2551. Voici le montage que nous avons réalisé (c'est ce que j'appelle le demi montage dans mon post précédent).


Ensuite nous avions prévu de brancher le générateur de trame sur les can high et can low (désolé si mon vocabulaire n'est pas exact).
Au niveau de la théorie sur le CAN j'ai l'impression d'avoir comprit dans les grandes lignes mais la pratique me parait plus difficile ^^.

[A voir en vidéo sur Futura]

[invite7d2538d5]

Et il me semble que nous utilisons un CAN standard.
Juste une question vous y avez passé un mois a temps complet?
Au niveau des filtres nous ne connaissons pour ainsi dire que la théorie. La notion d'identificateur m'est inconnue. Serait-ce la méthode d'adressage qu'utilise le CAN? (comme les adresses IP ou MAC pour les ordinateurs?)

[invitefaaca50b]

http://fr.wikipedia.org/wiki/Controller_area_network
http://edelaunay.chez-alice.fr/buscan.htm
http://www.oberle.org/can-can.html
http://uuu.enseirb.fr/~kadionik/form...us_enseirb.pdf
http://fr.wikipedia.org/wiki/SAE_J1939
http://zone.ni.com/devzone/cda/tut/p/id/9046

Voila de quoi lire et affuter l'appetit pour aller plus loin avec le bus CAN...

[invite03481543]

Et il me semble que nous utilisons un CAN standard.
Juste une question vous y avez passé un mois a temps complet?
Au niveau des filtres nous ne connaissons pour ainsi dire que la théorie. La notion d'identificateur m'est inconnue. Serait-ce la méthode d'adressage qu'utilise le CAN? (comme les adresses IP ou MAC pour les ordinateurs?)

Il ne faut pas qu'il te semble tu dois en être certain, les trames qui vont circuler auront des champs étendus et pour retrouver tes petits c'est plus que nécessaire.

Un noeud CAN ne se gère pas par adresse du tout.
Je te conseille vivement de lire le protocole sans quoi tu ne verras jamais une trame passer...
Et de te renseigner sur la vitesse du bus avec lequel tu es sensé communiquer.

Sinon oui, un mois à temps complet en partant comme toi de 0 ou presque

[invite7d2538d5]

Nous avons trois mois a 2 sans aucune expérience et a coup de 3h par 2 semaines .
J'ai vérifier nous utilisons un CAN standard. La vitesse du bus est de 125 Kbits/s.
Je me suis surement mal exprimé mais j'ai lu sur les différentes documentations ceci :

L'indentifieur CAN dans l'ordre

Bit 1 à 3 : Priorité
Bit 4 : Réserve
Bit 5 : Page de données
Bit 6 à 13 : Format PDU
Bit 14 à 21 : Spécifique PDU
Bit 22 à 29 : Adresse Source

Si le champ format PDU est inférieur à 240, la communication est alors de type « Point à Point ». Dans ce cas le champ spécifique PDU contient alors l'adresse destination.

L'adresse 255 est globale, cela veut dire vers tous les nœuds.
L'adresse 254 est nulle, elle ne s'utilise que dans des cas spécifiques.

Si le champ format PDU est supérieur ou égal à 240, la communication est alors de type « diffusion ». Dans ce cas le champ spécifique PDU ajouté au champ format PDU crée le Nombre du Groupe de Paramètre.

Je confond peut-être des choses totalement différentes ...

[invite03481543]

Là tu me parles d'un ID à 29 bits donc du bus CAN étendu.

Les trames de données transmises par un nœud sur le bus ne contiennent ni une quelconque adresse du nœud expéditeur ou du nœud destinataire.
C’est plutôt le contenu du message, ce qu'il signifie, qui est précisé par un identificateur (ID).
Chaque nœud recevant un message regarde si celui-ci est intéressant pour lui grâce à l’ID.
Si c’est le cas, il le traite, sinon, il l’ignore tout simplement.
Cet unique ID indique aussi la priorité des messages, plus la valeur est faible, plus le message est prioritaire.
Si deux nœuds ou plus cherchent à avoir accès au bus au même moment, c’est celui de plus haute priorité qui gagne l'arbitrage selon le principe "récessif/dominant", le bit dominant l'emportant toujours .
Les messages de priorité inférieure seront automatiquement retransmis lorsque le bus sera libre.

Voici en résumé de quoi se compose la structure d'une trame:

1/Start of frame
Le bit Start of frame (SOF) marque le début d’une Data Frame ou d’une Remote frame.
C’est un unique bit dominant.
Un nœud ne peut débuter une transmission que si le bus est libre.
Ensuite, tous les autres nœuds se synchronisent sur SOF du nœud ayant commencé une transmission.

2/Arbitration field

L’Arbitration field est constitué de l’identifieur et du bit RTR.
L’identificateur (ID) permet d’identifier le message. Il est transmis dans l’ordre ID10 à
ID0, où ID0 est le bit le moins significatif.
Le bit RTR (Remote Transmission Request) caractérise les Remote Frames.
Il est dominant dans les Data Frames et récessif dans les Remote Frames.
Un bon moyen mémotechnique est Dominant-> Data Frames et Recessif-> Remote Frames

3/Control field
Le Control field est composé de 6 bits. Les 2 premiers sont des bits réservés et les 4 suivants constituent le Data length code (DLC).
Le DLC indique le nombre d’octets du Data field. La valeur du DLC est forcément comprise entre 0 et 8, soit 9 valeurs. 4 bits dominants (0000)
correspondent à la valeur 0 pour le DLC, tandis que 1 bit récessif et 3 bits dominant (1000) correspondent à la valeur 8.

4/Data field
Ce sont les données transmises par la Data frame. Il peut contenir de 0 à 8 octets, où chaque octet est transmis avec le bit de poids fort en premier.

5/CRC field

Le CRC field est composé de la séquence de CRC sur 15 bits suivi du CRC delimiter (1bit récessif).
La séquence de CRC (Cyclic redundancy code) permet de vérifier l’intégrité des données transmises.
Les bits utilisés dans le calcul du CRC sont ceux du SOF, de l’Arbitration field, du Control field et du Data field.

6/ACK field
Le ACK field est composé de 2 bits, l’ACK Slot et le ACK Delimiter (1 bit récessif).
Le nœud en train de transmettre envoie un bit récessif pour le ACK Slot.
Un nœud ayant reçu correctement le message en informe le transmetteur en envoyant un bit dominant pendant le ACK Slot: il acquitte le message.

7/End of frame
Chaque Data frame et Remote frame se termine par une séquence de 7 bits récessifs.

Ce qui est important pour le moment, pour pouvoir commencer à causer un peu, c'est d'éplucher la doc du PIC pour configurer le baud rate, la config temporelle est une des parties les plus chiante...
As-tu au moins un scope?
Dans quel langage vas-tu créer ton programme?

@+

[invite7d2538d5]

Nous avons configuré le baudrate a 125k.
La programmation est en C.
Nous avons réalisé le montage du post précédent (vérifié). Par contre pour les test nous avons généré des trames CAN depuis le générateur CAN sur le bus afin de faire réagir la carte mais nous n'y sommes pas parvenu.
Nous avons ensuite essayer de généré des trames CAN a partir de la carte MBED afin de pouvoir les visualiser sur le générateur (branché en USB sur l'ordinateur qui nous affiche ce qu'envoie et reçoit le générateur de trames CAN). Ceci n'a pas fonctionné non plus...
Je ne voit qu'une erreur au niveau logiciel possible mais je ne voit vraiment pas ou nous aurions put faire une erreur dans un programme aussi court.

[Qristoff]

Salut à tous,
je ne sais pas si pour ton projet l'émulation de protocole doit être obligatoirement réalisé avec le pic mais sinon il y a une solution avec controller can de microchip qui va parfaitement bien avec ton transceiver. Le MCP2515 n'est pas cher du tout (~3 euros chez Farnell)

[invite7d2538d5]

Je doit absolument utiliser tout le matériel cité précédemment donc je ne peux rien changer ^^
Mais merci de la solution ça marchera peut-être sur un autre projet!

[Qristoff]

Tu peux peut être dans ce cas lire la datasheet du controller pour t'inspirer de la formation des trames pour le transceiver. La doc Microchip est bien faite. Bon courage

[invite03481543]

Fais voir ton prog, je peux te filer un coup de main.
@+

[invite7d2538d5]

Je travaille avec le compilateur fourni avec la carte MBED (site internet).

[invite03481543]

Cette carte est sur une base ARM 32 bits, c'est quoi le rapport avec ton schéma du début avec le PIC18F258?

Si tu pouvais décrire en détail ton appli j'y verrais personnellement plus clair.

[invite7d2538d5]

En fait nous avons juste remplacer le PICF18F258 par notre carte MBED. Nous l'avons connecté par les pin 29 et 30 (pin utilisé pour le CAN sur cette MBED)

[invite7d2538d5]

Voici le "programme" commenté

#include "mbed.h"
#include "CAN.h"

DigitalOut led1(LED1);
DigitalOut led2(LED2);
CAN can2(p30, p29);
Ticker ticker;
char counter=0;
CANMessage msg;


void send() //fonction permettant d'envoyer un signal CAN
if(can2.write(CANMessage(555, &counter, 1))) //Si l'écriture du message est un succès la carte change l'état de la led1 (allumé ou éteint)
{
counter++;
led1 = !led1;
}

}

void receive() //fonction permettant de recevoir un message CAN
{

if(can2.read(msg)) //Si la carte lit un message elle change l'état de la led2
{
led2=!led2;
}
}

int main()
{
can2.frequency(125000);//on configure la carte a un débit de 125kbits/s
ticker.attach(&send,1);//toutes les 1 secondes on execute la fonction send
}

[invite03481543]

En fait nous avons juste remplacer le PICF18F258 par notre carte MBED. Nous l'avons connecté par les pin 29 et 30 (pin utilisé pour le CAN sur cette MBED)

Oui mais ça change tout, j'ai pas envie de me palucher toute la doc du bidule MBED...
Les registres seront tous différents et en plus c'est du 32 bits ton truc, vous avez pas pris le plus simple.

J'imagine vu la pub commerciale de ce truc que tu dois avoir la possibilité de charger des sources qui prémâchent le travail à faire.
Ce n'est pas à mon avis une bonne approche de l'apprentissage du CAN, d'où ce choix de la part de tes profs que je trouve vraiment limite...

Quoiqu'il en soit je vais regarder comme promis.
@+

[DavidDB]

Salut,

Dans ce bout de code, aucune configuration des segments du "nominal bit time", ni même du RJW et encore moins du type de trame...
Et, pas la moindre trace d'une configuration des filtres et masques indispensables pour espérer le transfert d'une trame dans le buffer de réception de l'interface CAN...

Configurer uniquement le débit du bus CAN est loin d'être suffisant!
Je ne suis même pas certain que l'interface CAN prenne en compte le débit du bus, car très souvent(voir toujours), il faut une séquence particulière pour entrer en mode configuration de l'interface CAN...

Bon courage quand même avec ton LPC, qui est un chouette jouet.

David.

[invite03481543]

Oui je sais c'est déconcertant ce type d'écriture parceque ça cache tout le coté config...

J'ai trouvé ce truc là:
http://mbed.org/handbook/CAN

On voit bien que toute la procédure bas niveau est totalement masquée, du fait il faut utiliser les fonctions prémâchée et leur faire confiance, ce qui est loin d'être une bonne chose selon moi, en tout cas je n'utiliserai jamais un truc comme ça dans une appli pro.

Bref, comme tu peux le voir dans ce tableau tu as les fonctions qui vont te servir à configurer ta trame, je suppose que tu as déjà ce document.
Tu as le détail de la syntaxe en cliquant sur les fonctions.

Comme le dit David, en l'état rien d'anormal que tu n'es rien qui cause dans le tuyau.
Il te manque plein de chose dans le code.

Je te laisse phosphorer un peu avec ce premier document.
Je te conseille de définir un flow chart de ce que tu veux faire, ce sera ton canevas de programme.
@+

[DavidDB]

Salut,

Oui je sais c'est déconcertant ce type d'écriture parceque ça cache tout le coté config...

Ben, en fait le problème est bien plus grave...

Si c'est pour créer des noeuds CAN entre MBED, cela passera probablement(en espérant que les librairies restent identiques entre les versions du compilo).
Par contre, créer des noeuds entre MBED et d'autres composants CAN, cela tiendra du miracle de réussir a faire passer une trame sur le bus, le simple fait de ne pas pouvoir agir sur le point d'échantillonnage d'un bit CAN rend quasiment impossible de connaître le niveau réel de ce bit...

De plus, dans cette "librairie" pas un mot sur les filtres et masques de l'interface CAN!

Vu que le MBED est un LPC1768, vaudrait peut-être mieux utiliser un autre compilo compatible (du style DENX) afin de savoir ce que l'on fait et où on se dirige.

David.

[invite03481543]

A priori c'est juste pour allumer 2 leds .... avec 2 boutons.