Retour à l'accueil

CAN dans STM32 : guide technique d'intégration | Embarqué

Guide technique pour intégrer l'interface CAN dans un projet de contrôle d'entraînement électrique sur STM32. Analyse détaillée de la configuration des timings, de la gestion des erreurs et des tests de charge. Recommandations pour les développeurs de systèmes embarqués.

Guide complet de l'interface CAN dans les projets STM32 Motor Control
Advertisement 728x90

Implémentation de l'interface CAN sur STM32 pour le contrôle d'entraînement électrique : Guide technique

Le bus CAN reste la norme de facto pour la communication dans les systèmes embarqués à exigences élevées de tolérance aux pannes. Contrairement aux interfaces populaires UART/I2C, CAN fournit une transmission de données différentielle avec gestion matérielle des collisions par arbitrage non destructif. Pour les projets basés sur STM32G431RB (comme dans le kit IHM03), il est crucial de prendre en compte les spécificités des couches physique et liaison de données lors de la conception des pilotes.

Paramètres techniques clés influençant l'implémentation :

  • Vitesse de transmission : De 125 kbit/s (basse vitesse) à 1 Mbit/s (haute vitesse)
  • Topologie réseau : Linéaire avec terminateurs de 120 Ω aux extrémités
  • Format de trame : Standard (ID 11 bits) ou Étendu (29 bits)
  • Remplissage de bits : Insertion automatique de bits après une séquence de 5 bits identiques

Les contrôleurs CAN intégrés de STM32 (bxCAN) supportent tous les modes de fonctionnement mais nécessitent un réglage précis des paramètres de temporisation (SJW, BS1, BS2). Une erreur dans le calcul du prédiviseur de taux de baudot entraînera une perte de synchronisation sous forte charge du bus.

Google AdInline article slot

Conception de l'interface CAN pour le contrôle moteur sur STM32

Modification du projet de contrôle PMSM

Pour intégrer CAN dans un projet de contrôle d'entraînement existant, les étapes suivantes ont été nécessaires :

  • Ajouter la bibliothèque CAN de STM32CubeMX au projet
  • Configurer l'horloge du périphérique CAN via RCC
  • Implémenter un tampon circulaire pour la réception/émission de messages
  • Synchroniser le traitement des trames CAN avec la boucle principale de contrôle moteur

Un aspect critique est le partage du temps entre le traitement PWM et CAN. En utilisant FreeRTOS, une tâche séparée a été créée avec une priorité supérieure à celle de la tâche de contrôle moteur mais inférieure à celle des interruptions de sécurité.

Structure de la base de données CAN

Une structure de type DBC a été développée pour la gestion des messages :

Google AdInline article slot
typedef struct {
    uint32_t id;
    uint8_t dlc;
    void (*handler)(uint8_t*);
} can_msg_t;

const can_msg_t can_db[] = {
    {0x123, 8, handle_motor_status},
    {0x246, 4, handle_control_cmd},
    // ... other messages
};

Chaque message est lié à une fonction de gestion spécifique via une table de dispatch. Cela a évité un switch-case monolithique et simplifié l'ajout de nouveaux types de trames.

Mise en œuvre pratique et tests

Débogage de la couche physique

Lors des tests initiaux, des erreurs CRC ont été observées dues à :

  • Placement incorrect des terminateurs (installés seulement à une extrémité)
  • Longueur du bus dépassant les limites (plus de 40 m à 1 Mbit/s)
  • Utilisation de paire torsadée non blindée

Solution :

Google AdInline article slot
  • Installer des terminateurs de 120 Ω aux deux extrémités de la ligne
  • Réduire la vitesse à 500 kbit/s pour une longueur de 60 m
  • Utiliser un câble blindé avec impédance de 120 Ω

L'analyse à l'oscilloscope a confirmé la correction des signaux différentiels (CAN_H=3,5 V, CAN_L=1,5 V à l'état dominant).

Tests de charge

Des tests de stress ont été menés à 80 % de charge du bus :

  • Débit maximum : 700 kbit/s (limite théorique pour trames de 8 octets — 750 kbit/s)
  • Latence de traitement des trames : < 100 µs
  • Taux d'erreur : 0 pour longueurs de bus jusqu'à 30 m

Une erreur critique s'est produite lors de la transmission simultanée de 3 messages de haute priorité (ID bas). Elle a été résolue en configurant les filtres CAN_RX, en séparant les messages par banques de filtres.

Points clés à retenir

  • Temporisation du bus : Les calculs précis de BS1/BS2 sont critiques pour un fonctionnement stable à haute vitesse
  • Arbitrage de priorité : Les ID bas ont la priorité — planifiez votre hiérarchie de messages à l'avance
  • Gestion des erreurs : Implémentez un mécanisme de réinitialisation du contrôleur CAN lors de l'atteinte de l'état passif d'erreur
  • CEM : Le blindage des câbles et la mise à la terre du blindage aux deux extrémités sont obligatoires pour les environnements industriels
  • Tests : Utilisez des analyseurs CAN (p. ex., PCAN-USB) pour la vérification du protocole

L'intégration d'une interface CAN dans un projet de contrôle d'entraînement électrique sur STM32 nécessite une compréhension approfondie des fonctionnalités matérielles du périphérique et des spécificités du protocole. Une implémentation réussie ouvre la porte aux systèmes de contrôle distribués avec une intégration potentielle dans des plateformes IoT et des analyses IA.

— Editorial Team

Advertisement 728x90

Lire ensuite