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é.

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.

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é.

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 ?

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 ...