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