Le MCP2551 est-il un convertisseur UART-CAN?

Je veux faire un renifleur de bus CAN à 250 kbit / s en utilisant mon ordinateur. Après quelques recherches, j'ai découvert que le MCP2551 est une sorte de régulateur de niveau de tension pour la couche physique du CAN. Gardant cela à l'esprit, je me demande si cette configuration pourrait fonctionner. Je veux juste enregistrer les messages échangés à des fins de test automatisé, ne pas faire partie de la communication:

PC <-> USB-UART (peut-être CP2102, car j'en ai déjà un) <-> MCP2551 <-> Bus CAN

Sinon, quel type de signaux doivent entrer dans le MCP2551 pour que je fasse partie du bus?

Vous pouvez le faire, mais ce que vous obtiendrez sur votre bus CAN sera UART en utilisant les niveaux de tension CAN. Vous devez fournir au MCP2551 des messages de protocole CAN si vous souhaitez communiquer avec des appareils CAN sur votre bus. Idem pour l'écoute: les messages CAN sont tellement différents du format UART que l'UART ne saura pas quoi en faire. Vous aurez au moins des erreurs de trame tout le temps et vous n'obtiendrez pas le contenu du message.
Cette image montre la structure d'un message CAN:

Il y a beaucoup de microcontrôleurs autour qui ont une interface CAN, sans l'émetteur-récepteur. C'est pour cela que le MCP2551 a été conçu. Dans le passé, nous avons utilisé le NXP LPC2294, qui dispose de 4 interfaces CAN. Chacun d'eux a besoin d'un MCP2551 pour se connecter à un bus CAN. Les contrôleurs plus récents de NXP incluent la famille LPC1800 , dont tous les membres prennent en charge CAN.

J'ai créé une interface USB / CAN en utilisant FT2232H en mode MPSSE (oubliez UART), MCP2515 et MCP2551. MCP2515 est la pièce clé qui vous manque ici. Etudiez bien ce qu'il fait. C'est le contrôleur CAN réel qui effectue le cadrage, les ACK, la génération et la vérification de la somme de contrôle, le filtrage des messages et d'autres choses moins évidentes qu'un nœud CAN est tenu de faire par la norme. Si vous voulez un renifleur, le MCP2515 a un mode d'écoute uniquement qui garantit aucune transmission sur le bus. Le MCP2551 est simplement un adaptateur de couche physique stupide, similaire à un MAX232 pour RS-232 ou ADM485 pour RS-485.

Maintenant, cette architecture est loin d'être parfaite car la technologie FTDI MPSSE ne prend essentiellement pas en charge les interruptions (je crois qu'elle n'utilise que des transferts USB en masse dans les coulisses), donc je dois fréquemment interroger le contrôleur pour de nouveaux messages. Cela place beaucoup de charge sur le contrôleur hôte USB mais ne garantit toujours pas qu'aucun message ne soit perdu (le MCP2515 peut stocker jusqu'à 2 messages reçus en interne si vous activez le "mode de débordement", un seul si vous ne le faites pas). Une bien meilleure solution serait un microcontrôleur approprié avec des périphériques CAN et USB intégrés tels que STM32F105 (103 ne peuvent pas utiliser USB et CAN en même temps). Voir ce projet pour une implémentation fonctionnelle de cette idée. LPC18xx comme suggéré par stevenh fonctionnera aussi, mais LPC17xx est probablement moins cher et plus facile à trouver.

Puisque vous voulez écouter sur un bus CAN existant si je comprends bien la question, vous ne pouvez vraiment pas utiliser du tout d'UART. CAN et UART siganlling sont totalement différents.

Vous pourriez en théorie regarder la ligne de réception CAN sortant du MCP2551 et décoder le trafic CAN. Ce ne sera pas facile, mais c'est théoriquement possible. Sans matériel CAN spécialisé, vous devrez échantillonner quelques fois plus rapidement que le débit binaire CAN et décoder ce flux binaire dans le logiciel plus tard. Vous devrez probablement enregistrer à environ 1 Mbit / s pour décoder 250 kbit / s CAN.

L'utilisation d'un microcontrôleur sera beaucoup plus facile. Le PIC 18F2580 et d'autres processeurs similaires ont un périphérique CAN intégré. Le matériel effectue tout le décodage au niveau des bits et reçoit des trames CAN entières. Le processeur peut ensuite envoyer les trames CAN reçues via son UART à votre PC.