Implémentation d'une couche de protocole CAN dans le logiciel

12

Contexte

Je développe un projet qui nécessitera les modestes spécifications du microcontrôleur de:

  • 8 CAN 12 bits, 10 kHz
  • 1 Ko de RAM
  • 48-QFN ou encombrement inférieur
  • Protocole de communication résistant au bruit et correcteur d'erreurs à connexion en chaîne de 20 kbps

Les exigences de traitement du signal sont assez faibles et la plupart peuvent être exportées vers le processeur maître du système. Les trois premières spécifications sont faciles à respecter et peuvent être effectuées pour moins de 2 $ en quantité. Cependant, la communication se fera dans un environnement très bruyant électriquement, donc les réseaux vulnérables au bruit comme LIN et I2C sont hors service. Un argument supplémentaire contre LIN est que je voudrais faire fonctionner le tout à 5V ou 3,3V, et les émetteurs-récepteurs LIN nécessitent 12V, et donc nécessiteraient un régulateur ou un fil supplémentaire par carte de capteur. J'ai d'abord choisi CAN pour cette tâche. Cependant, les contrôleurs CAN ajoutent un coût considérable, et je suis curieux de savoir si cela peut être fait par logiciel.

CAN couche physique

La spécification CAN définit la liaison de données et les couches physiques du modèle de référence du réseau OSI. De nombreux circuits intégrés à 8 broches bon marché, tels que les NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 et TI SN65HVD1050 existent pour implémenter la couche physique. La mise en œuvre de la couche physique avec des convertisseurs N / A ou des amplificateurs opérationnels serait difficile, voire impossible, de sorte que ces circuits valent bien le dollar ou environ qu'ils coûtent.

Liaison de données CAN / couche de protocole

Pour la couche liaison de données, certains microcontrôleurs ajoutent des modules de protocole CAN aux couches de communication de base UART, I2C et SPI. Cependant, ceux-ci sont nettement plus chers que les puces de base.

Étude du coût des modules du protocole CAN

Pour étayer cette affirmation, voici quelques micros populaires dans les versions CAN et non CAN, des:

  • ATmega16 - ATMEGA16M1 (avec CAN): 3,87 $, ATMEGA168A (sans CAN): 3,23 $
  • dsPIC - DSPIC33FJ64MC802 (avec CAN): 6,14 $, DSPIC33FJ64GP202 (sans CAN): 5,48 $
  • PIC18 - PIC18F2480 (avec CAN): 6,80 $, PIC18F24J10 (sans CAN): 2,10 $
  • Cortex-M3 - STM32F103C4T6A (avec CAN): 6,50 $, STM32F100C4T6B (sans CAN): 2,73 $

Pour être honnête, je n'ai comparé que les microcontrôleurs avec des tailles de mémoire équivalentes, cependant, la plupart des versions non CAN sont disponibles avec des tailles de mémoire plus petites pour moins. Les contrôleurs CAN externes, comme le Microchip MCP2515 , coûtent près de 2 $, il est donc évidemment plus rentable d'intégrer le CAN dans le microcontrôleur si vous en avez la possibilité.

Fait intéressant, la pièce ATmega est de loin la pièce la moins chère équipée de CAN dans l'inventaire de Digikey.

Fonction de la couche de protocole CAN

Le module CAN présent dans les microcontrôleurs dsPIC effectue les opérations suivantes:

Le module de bus CAN se compose d'un moteur de protocole et d'une mise en mémoire tampon / contrôle des messages. Le moteur de protocole CAN gère toutes les fonctions de réception et de transmission de messages sur le bus CAN. Les messages sont transmis en chargeant d'abord les registres de données appropriés. L'état et les erreurs peuvent être vérifiés en lisant les registres appropriés. Tout message détecté sur le bus CAN est vérifié pour les erreurs, puis comparé aux filtres pour voir s'il doit être reçu et stocké dans l'un des registres de réception.

Cela semble assez faisable dans les logiciels.

La question

Une couche de protocole logiciel peut-elle être utilisée pour mettre en œuvre la spécification CAN avec uniquement un microcontrôleur UART peu coûteux et un émetteur-récepteur CAN? Si oui, existe-t-il des implémentations open source?

Les émetteurs-récepteurs CAN peuvent-ils également être utilisés avec les UART pour implémenter un protocole personnalisé? Je suis d'accord avec une topologie à maître unique; Je comprends que l'arbitrage peut être difficile à obtenir correctement dans un protocole personnalisé.

Kevin Vermeer
la source
CAN est également 12v, car il a été développé pour une utilisation automobile.
kenny
@Kenny - Les niveaux de tension utilisés sur les émetteurs-récepteurs ci-dessus sont de 5V.
Kevin Vermeer
Si vous envisagez la série STM32F, puis-je également suggérer cette partie NXP? Il s'agit d'un noyau Cortex-M0. search.digikey.com/scripts/DkSearch/…
Jon L
@Jon - Ceux-ci n'étaient pas nécessairement pris en considération, et un M0 serait idéal pour ce cas d'utilisation - Cependant, considérez les pièces que le Nuvoton M052LAN est également Cortex-M0, et environ la moitié du prix en quantité (1,21 $ contre 2,35 $), mais n'a pas le module CAN. Ce genre de différence de prix est ma motivation.
Kevin Vermeer
vous voudrez peut-être également prendre en compte la notation opérationnelle. La plupart des pièces avec support CAN seront industrielles ou automobiles vs commerciales pour les variantes non CAN.
Mark

Réponses:

11

Je pense que la mise en œuvre du protocole CAN uniquement dans le micrologiciel sera difficile et prendra un certain temps pour bien fonctionner. Ce n'est pas une bonne idée.

Cependant, vos prix sont élevés. Je viens de vérifier, et un dsPIC 33FJ64GP802 en paquet QFN se vend 3,68 USD sur microchipdirect pour 1000 pièces. Le prix sera plus bas pour les volumes de production réels.

Le périphérique matériel CAN fait des choses réelles pour vous, et l'augmentation de prix pour cela est loin de ce que vous prétendez.

Ajoutée:

Puisque vous semblez déterminé à essayer la route du firmware, voici quelques-uns des problèmes évidents qui nous viennent à l'esprit. Il y aura très probablement d'autres problèmes qui ne m'ont pas encore été rencontrés.

Vous voulez faire du CAN à 20 kbit / s. C'est un taux très lent pour CAN, qui monte à 1 Mbit / s pour au moins 10s de mètres. Pour vous donner un point de données, la norme de signalisation de bord NMEA 2000 est superposée sur CAN à 200 kbits / s, et cela est censé aller d'une extrémité à l'autre d'un grand navire.

Vous pouvez penser que tout ce dont vous avez besoin est d'une interruption par bit et vous pouvez faire tout ce dont vous avez besoin pendant cette interruption. Cela ne fonctionnera pas car il se passe plusieurs choses dans chaque temps de bit CAN. Deux choses en particulier doivent être faites au niveau sous-bit. Le premier détecte une collision et le second ajuste le débit binaire à la volée.

Il existe deux états de signalisation sur un bus CAN, récessif et dominant. Récessif est ce qui se passe lorsque rien ne conduit le bus. Les deux lignes sont réunies par un total de 60 Ω. Un bus CAN normal tel qu'implémenté par des puces courantes comme le MCP2551, devrait avoir des terminaisons de 120 Ω aux deux extrémités, donc un total de 60 Ω rassemblant passivement les deux lignes différentielles. L'état dominant est lorsque les deux lignes sont activement séparées, quelque part autour de 900 mV de l'état récessif si je me souviens bien. Fondamentalement, cela ressemble à un bus à collecteur ouvert, sauf qu'il est implémenté avec une paire différentielle. Le bus est en état récessif si CANH-CANL <900mV et dominant quand CANH-CANL> 900mV. L'état dominant signale 0 et le récessif 1.

Chaque fois qu'un nœud "écrit" un 1 sur le bus (le laisse aller), il vérifie si un autre nœud écrit un 0. Lorsque vous trouvez le bus en état dominant (0) lorsque vous pensez envoyer et le le bit actuel que vous envoyez est un 1, cela signifie que quelqu'un d'autre envoie également. Les collisions n'ont d'importance que lorsque les deux expéditeurs ne sont pas d'accord, et la règle est que celui qui envoie l'état récessif recule et abandonne son message. Le nœud qui envoie l'état dominant ne sait même pas que cela s'est produit. C'est ainsi que l'arbitrage fonctionne sur un bus CAN.

Les règles d'arbitrage du bus CAN signifient que vous devez regarder le bus à mi-chemin à travers chaque bit que vous envoyez en tant que 1 pour vous assurer que quelqu'un d'autre n'envoie pas de 0. Cette vérification est généralement effectuée aux 2/3 du chemin dans le bit et constitue la limitation fondamentale de la longueur du bus CAN. Plus le débit binaire est lent, plus il y a de temps pour la propagation dans le pire des cas d'une extrémité du bus à l'autre, et donc plus le bus peut être long. Cette vérification doit être effectuée chaque fois que vous pensez que vous êtes propriétaire du bus et que vous envoyez un bit.

Un autre problème est l'ajustement du débit binaire. Tous les nœuds d'un bus doivent s'accorder sur le débit binaire, plus étroitement qu'avec RS-232. Pour éviter que de petites différences d'horloge ne s'accumulent en erreurs significatives, chaque nœud doit être capable de faire un bit un peu plus long ou plus court que son nominal. Dans le matériel, cela est implémenté en exécutant une horloge quelque part entre 9x et 20x plus vite que le débit binaire. Les cycles de cette horloge rapide sont appelés quanta temporels. Il existe des moyens de détecter que le début de nouveaux bits se déplace par rapport à l'endroit où vous pensez qu'ils devraient être. Les implémentations matérielles ajoutent ou sautent ensuite un quanta dans un bit pour se resynchroniser. Il existe d'autres façons d'implémenter cela tant que vous pouvez vous adapter à de petites différences de phase entre vos temps de bits attendus et les temps de bits mesurés réels.

Quoi qu'il en soit, ces mécanismes nécessitent que diverses choses soient faites à différents moments dans un même temps. Ce type de synchronisation deviendra très délicat dans le micrologiciel ou nécessitera que le bus soit exécuté très lentement. Disons que vous implémentez un système quanta temporel dans le firmware à 20 kbits / s. Au minimum de 9 quanta de temps par bit, cela nécessiterait une interruption de 180 kHz. C'est certainement possible avec quelque chose comme un dsPIC 33F, mais cela consommera une fraction importante du processeur. Au taux d'instruction maximum de 40 MHz, vous obtenez 222 cycles d'instruction par interruption. Cela ne devrait pas prendre autant de temps pour effectuer toutes les vérifications, mais probablement 50 à 100 cycles, ce qui signifie que 25 à 50% du processeur seront utilisés pour CAN et qu'il devra préempter tout ce qui est en cours d'exécution. Cela empêche de nombreuses applications que ces processeurs exécutent souvent, comme le contrôle d'impulsion par impulsion d'une alimentation à découpage ou d'un pilote de moteur. La latence du cycle 50-100 sur chaque autre interruption serait un arrêt complet pour beaucoup de choses que j'ai faites avec des puces comme celle-ci.

Vous allez donc dépenser l'argent pour faire CAN d'une manière ou d'une autre. Si ce n'est pas dans le périphérique matériel dédié prévu à cet effet, puis en obtenant un processeur plus grand pour gérer la surcharge significative du micrologiciel et ensuite faire face à la latence d'interruption importante et imprévisible pour tout le reste.

Ensuite, il y a l'ingénierie initiale. Le périphérique CAN fonctionne juste. D'après votre commentaire, il semble que le coût différentiel de ce périphérique soit de 0,56 $. Cela me semble être une bonne affaire. À moins que vous n'ayez un produit à très haut volume, il est impossible de récupérer le temps et les dépenses considérables qu'il faudra pour implémenter CAN dans le micrologiciel uniquement. Si vos volumes sont si élevés, les prix que nous avons mentionnés ne sont de toute façon pas réalistes et le différentiel pour ajouter le matériel CAN sera plus bas.

Je ne vois vraiment pas cela logique.

Olin Lathrop
la source
J'apprécie votre opinion, mais je suis curieux de savoir pourquoi personne n'a essayé de contourner les difficultés - Chaque projet aura ces problèmes! Je vous ferai savoir comment ça se passe si je finis par l'essayer.
Kevin Vermeer
À des quantités de 1000, je trouve un prix de 3,12 $ pour le dsPIC33FJ64GP202 de microchipdirect - Une différence de valeur totale de 560 $! Cela vaut au moins la peine d'essayer. Je proposais des prix par pièce simplement parce qu'il était plus facile d'obtenir des numéros pour des pièces individuelles sans avoir à se soucier du dévidage, de la quantité de colis standard, etc.
Kevin Vermeer
2
@Kevin, les prix des quantités faibles ne sont pas toujours proportionnels aux prix des quantités élevées. Je ne sais pas combien de ces choses vous prévoyez de faire, mais 560 $ ne commenceront pas à payer pour l'ingénierie pour faire CAN dans le firmware. J'ajouterai à mai répondre expliquant certaines des difficultés que vous rencontrerez.
Olin Lathrop du
WTF !? Je viens d'ajouter quelques éléments à ma réponse, et la majeure partie de la pause de paragraphe a disparu. Il y avait définitivement des lignes vides dans la fenêtre d'édition que je tapais.
Olin Lathrop
1
La réponse est oui, vous pouvez mais je suis totalement d'accord avec Olin ici. Je travaille actuellement à plein temps dans ce domaine. J'utilise la puce dsPIC33FJ256. Le temps passé à écrire les choses en adoptant l'approche du bit-bang vient de supprimer l'avantage du coût d'avoir du matériel pour le faire pour vous et de réinventer la roue. Sans compter que tout ce que vous faites d'autre dans le matériel devrait être soigneusement planifié. Aussi, je me demande si vous cherchez d'autres protocoles de plus haut niveau tels que ISO14229 ou OSEK / Autosar NetworkManagement.
Eric M
2

Nous utilisons le PIC18F25K80 . Bien qu'il n'ait pas de DSP, il est d'environ 2 $ en quantité. C'est presque un substitut direct au PIC18F2480 que vous mentionnez. Nous utilisons le compilateur CCS et leur pile logicielle pour CAN qui est probablement porté depuis Microchip. Cela fonctionne bien pour tout ce dont j'avais besoin et essayé.

kenny
la source
N'a pas recherché ECAN. Nom idiot de Microchip, mais je devrai lire de plus près la prochaine fois! Comme je l'ai dit, mes besoins en traitement du signal sont faibles, donc je ne pense pas avoir besoin d'un véritable DSP.
Kevin Vermeer
2

Si je lis bien, il semble que vous souhaitiez réduire la fonctionnalité CAN en utilisant uniquement un UART et un micrologiciel intelligent. Croyez-moi, cela ne fonctionnera jamais - je suggère de lire un bon texte sur les subtilités de CAN ou CANopen. Vous aurez éradiqué toutes les économies de coûts que vous recherchez en empruntant cette voie.

Je voudrais soit utiliser un microcontrôleur avec un module CAN et passer les 2 $ supplémentaires, ou avez-vous pensé à un protocole différent qui est compatible avec un UART, tel que Modbus sur RS-485 ?

BullBoyShoes
la source
Vous le lisez bien. J'ai lu attentivement le livret de formation Vector sur CAN. Il semble que chaque message aura besoin d'un prétraitement pour CRC, mais le reste du paquet devrait être le même et je devrai juste continuer à vérifier la ligne de réception pour un conflit. Cela ne semble vraiment pas aussi difficile que les gens le prétendent, mais je prendrai certainement vos conseils en considération.
Kevin Vermeer
J'aime bien l'idée Modbus sur RS485. Il semble que la plupart de ces émetteurs-récepteurs sont également alimentés en 5 V; J'avais l'impression qu'il fallait une tension d'entrée +/- comme RS232. Faudra examiner cela.
Kevin Vermeer
frapper un peu fonctionnera très certainement! Ce n'est pas anodin comme Olin, ci-dessus, le mentionne, mais cela peut être fait. Je l'ai personnellement retiré à la fois sur une série PIC18F et une série micro dsPIC33. Je peux télécharger la source PIC18F si vous voulez vraiment la voir. Je ne peux pas, cependant, donner la source dsPIC car elle fait partie d'un projet commercial sur lequel je travaille. Dans les deux cas, nous utilisons MCP2551 et j'ai aussi du code LIN. LIN est un peu plus simple au niveau de la couche de protocole, mais la mise en œuvre des horaires LIN est un peu plus difficile ...
Eric M
1
@EricM - Quel était le débit binaire et avez-vous pu implémenter la spécification CAN complète dans le logiciel? J'aime voir le code PIC18F pour cela.
Rocketmagnet
Oui, implémentation de la spécification CAN complète pour ne pas dupliquer le module ECAN sur le dsPIC qui prend en charge de nombreux aspects. Sur l'implémentation PIC18, j'ai bangé le bus à la spécification complète et plus tard et ce code fonctionnera sur un dsPIC utilisant des lignes GPIO. Je mettrai à jour dans quelques jours avec un lien vers le code.
Eric M
0

Je pense également au protocole CAN-banging sur un µC PIC, alors s'il vous plaît EricM, si vous l'avez vraiment fait, veuillez répondre et dire au moins quel débit à quelle fréquence de base PIC18F ou DSPic vous avez obtenu. THX!

En général: RS 485 serait la solution au problème principal posé, mais il serait également possible d'utiliser des émetteurs-récepteurs CAN (ou même FlexRay) avec des communications UART non duplex intégral (point 2 point) comme tous ces protocoles. utilisez le codage NRZ.

Mais dans UART / V24 / RS232, le duplex intégral est principalement utilisé sans réfléchir en détail, alors vous devrez peut-être mettre un peu de cerveau sur la superloop ou la statemachine de votre application ...

Mais revenons au bitbanging CAN: je travaille avec CAN depuis de nombreuses années et je n'ai jamais vu d'implémentation de bitbanging, mais pour autant que je puisse penser, cela devrait fonctionner pour des timings binaires jusqu'à 100kBit avec µC moderne comme DSPic ou ARM etc. (ayant des cœurs à 80 MHz ou plus ...)

Au moins si seule la relecture est prise en compte ... L'envoi entraînerait une surcharge dans la préparation des structures de bits afin que la charge de bus ne soit pas à 100% accessible, mais en CAN plus de 65% est rare du tout ...

roby111
la source
2
Bienvenue sur le Génie électrique StackExchange. La première partie de votre réponse n'est pas du tout une réponse, vous posez donc une nouvelle question si c'est ce que vous voulez. Le PO a posé des questions spécifiques sur la mise en œuvre logicielle du protocole CAN et votre réponse semble errer sans répondre à cette question; veuillez essayer de rester sur le sujet de la question.
Joe Hass