Histoire du convertisseur Ethernet-CAN

Une journée claire et ensoleillée pour le travail a nécessité un convertisseur d'interface CAN vers Ethernet peu coûteux. Naturellement, la recherche a commencé avec des solutions toutes faites, mais, comme cela arrive souvent, il a finalement été décidé de développer leur propre échantillon. Naturellement, l’enthousiasme de l’auteur n’a pas pu résister et s’est limité à une telle fonctionnalité «tronquée». Qu'en est-il venu, comment et pourquoi - sous la coupe.

image

Résumé général. La photo ci-dessus montre un modèle 3D de la carte que j'ai développée en utilisant CAD Altium Designer. Caractéristiques et fonctionnalités clés:

  • Ethernet 10 \ 100 Mb
  • Rtc
  • MicroSD (FAT12, FAT16, FAT32) 4 Go
  • RS232 \ RS485
  • CAN
  • Buzzer
  • 3 LED utilisateur
  • GPIO
  • EEPROM 32 KB
  • FLASH 2 Mo
  • I2C
  • SPI
  • UART
  • SW \ JTAG
  • SĂ©rie USB (port COM)
  • Puissance: miniUSB 5V \ External 9..24V

Le coût de la carte collectée est d'environ 5000 R. Le projet est de nature open source, les sources peuvent être trouvées sur github . Ce qui s'est avéré en conséquence, en plus de la fonctionnalité principale, peut être considéré comme une bonne carte de débogage pour travailler avec le microcontrôleur STM32.

Et maintenant aux détails de la création.

Matériel informatique


L'étude de ce problème a commencé par la recherche et l'évaluation de solutions toutes faites. Les principales exigences étaient les suivantes:

  1. conversion des trames CAN2.0B entrantes en paquets TCP \ IP et vice versa;
  2. à faible coût, par conséquent, la mise en œuvre d'un dispositif basé sur un microcontrôleur.

Des collègues chinois ont plusieurs solutions industrielles, mais pas bon marché, donc un représentant du convertisseur d'interface CAN-Ethernet PIRS de production nationale a été livré à notre bureau pour un test. Selon les capacités et caractéristiques décrites, l'appareil satisfaisait le modeste T.Z., il ne restait plus qu'à vérifier les performances en pratique, ce que j'ai fait, armé de Wireshark et de l'oscilloscope. Pour une raison inconnue, lors de l'envoi de paquets vers le périphérique TCP à la sortie du périphérique, où des trames CAN étaient censées apparaître, des séquences avec des niveaux CAN physiques (paire différentielle) mais un protocole d'interface UART logique (avec des bits de démarrage et d'arrêt) crachent. En ouvrant le boîtier, en ouvrant la documentation des microcircuits et en faisant sonner les pistes de la carte, j'ai trouvé qu'en effet, les broches RX et TX (UART) du microcontrôleur sont connectées à l'émetteur-récepteur CAN et sont connectées à un connecteur externe de celui-ci. Ainsi, aucun support matériel pour la norme CAN2.0B n'était à prévoir.

Voici ce que j'ai vu sur la sortie CANL de "PIRS CAN-Ethernet" lors de l'envoi de deux octets de données [ 0xF0 ] et [ 0x0A ] sur TCP \ IP:

image

L'ordre des bits est inversé, mais vous pouvez le gérer par programme, mais il est déjà plus difficile de faire quelque chose au niveau de l'application avec des bits de démarrage et d'arrêt dans chaque octet, car ils sont insérés dans le matériel.

Et voici à quoi devrait ressembler la "vraie" trame CAN2.0B avec les deux mêmes octets de données:

image

Comme vous pouvez le voir sur l'oscillogramme, en plus des octets de données, la trame contient de nombreux bits de service du protocole ainsi que des bits de bourrage, et surtout, ils vont en continu sans aucun bit de démarrage et d'arrêt! (Pour ceux qui sont intéressés, sous le spoiler une description détaillée de ce package).

Spoiler
image

Les 4 premiers octets sont l'identifiant de trame. Vous pouvez en savoir plus sur le format CAN Ă  partir de [1]

Ainsi, il n'a pas été possible pour moi de résoudre le problème d'incompatibilité des trames CAN et UART avec une méthode logicielle, et, en regardant les résultats de la recherche intermédiaire avec un regard déçu, il a été décidé de développer notre propre prototype du dispositif requis.

Étant donné qu'il était désormais possible de prendre le contrôle d'une plus large gamme de caractéristiques techniques de l'appareil, les exigences suivantes ont été ajoutées:

3. La capacité d'alimenter de 12-24 V dans les systèmes de transport;
4. La présence de mémoire externe pour stocker les journaux;
5. Les dimensions de la carte ne dépassent pas 86x80 mm.
6. Plage de températures de fonctionnement -40..85 °

La célèbre plate- forme STM32F407VET6 [2] a été choisie comme cerveau du nouvel appareil, qui prend en charge le matériel pour toutes les interfaces nécessaires et une bonne alimentation en mémoire RAM et FLASH. Après avoir peaufiné Internet, l'émetteur-récepteur DP83848IVV [3] a été choisi comme PHY Ethernet, qui a, à mon avis, une bonne documentation et suffisamment d'exemples de schémas de connexion et de routage. En tant que mémoire non volatile externe pour le stockage des journaux, j'ai choisi SPI FLASH 2 Mo et SPI EEPROM pour stocker divers paramètres. De plus, la protection de l'alimentation contre les surtensions, l'inversion de polarité a été ajoutée. Après N soirs et M week-ends, un schéma de circuit et une trace de la carte de circuit imprimé de l'appareil de la première version ont été compilés. Parce que il y avait assez d'espace sur la carte, mais je ne voulais pas laisser les jambes MK inactives, en plus de la fonctionnalité principale, la carte a été ajoutée:

  • outils de dĂ©bogage SW, JTAG;
  • Commutateur 8 DIP;
  • micro-USB (USB sĂ©rie);
  • RS-232;
  • UART
  • I2C;
  • GPIO

L'idée était que, si nécessaire, la carte était prête à étendre les fonctionnalités en installant des composants supplémentaires. De plus, les sièges de rechange n'affectent pas le coût de production. D'un côté, malheureusement, à cause de cela, il n'était pas possible de tout adapter, donc la carte s'est avérée être 86x80mm bilatérale, min. largeur de voie 0,25 mm, diamètre de trou min 0,6 mm.

image
La première version de la conception PCB

Plus tard, deux échantillons de test ont été commandés et assemblés avec un ensemble complet de périphériques pour la recherche. Afin d'économiser de l'argent, la planche a été fabriquée sans masque et a donc une couleur si inhabituelle.

image

Avec l'aide de STM32CubeMX, j'ai esquissé un firmware de test avec un test de l'opérabilité des principaux modules périphériques de l'appareil et, en première approximation, tout a fonctionné sauf le lancement du MK à partir d'un quartz externe de 8 MHz. Il s'est avéré qu'en raison de mon erreur lors de l'élaboration de la spécification, les mauvais condensateurs de charge ont été soudés. Mais cela n'a pas empêché le STM32F407 de fonctionner avec un générateur RC interne. Quand j'ai pu cingler mon appareil, il n'y avait aucune joie de retenue. J'ai pris le plus de temps avec la trace Ethernet PHY. Ensuite, dans le navigateur, j'ai vu ma page http de test et me suis calmé avec les tests.

La production des premiers échantillons des planches a été commandée à Zelenograd. Et, malgré le fait que le coût de «avec» le masque et «sans» était presque deux fois différent, je ne recommande pas de le faire même au stade du prototype, car, en règle générale, c'est à ce stade que les erreurs de trace apparaissent et que quelque chose se passe souder. Mais se saouler sur les pistes «nues» est extrêmement désagréable, économiser de l'argent, mais pratiquement pas de nerfs. Oui, et deviner alors s'il y a eu une courte pause quelque part ou si la trace est incorrecte - un tel plaisir. En raison de mon inexpérience, de la soudure d'un résonateur à quartz et de condensateurs de charge, j'ai tué un échantillon.

À ce moment-là, au travail, dans les bacs, il y avait un morceau de fer capable de résoudre la tâche de conversion dans le projet actuel, mais, en plus de la grande taille et du coût, ayant écrit un micrologiciel pour cela, j'ai rencontré des problèmes liés à la taille de la RAM et à la fonctionnalité tronquée de la pile TCP \ IP MK LPC2368. Le désir de rendre votre appareil ne fait donc que s'intensifier.
Ayant soigneusement étudié les lacunes de la première version, j'ai réfléchi sans réfléchir à la seconde. Et encore une fois, je voulais ajouter un «carnet de commandes pour l'avenir», incorporant les composants suivants dans le facteur de forme précédent:

  • Prise en charge RTC avec batterie;
  • RS-485;
  • micro-SD;
  • tweeter buzzer;
  • Option d'alimentation USB
  • SPI vers connecteur externe;
  • Alimentation 5V et 3,3V vers un connecteur externe.

Entre autres choses, la protection actuelle de l'alimentation et les diodes TVS sur les connecteurs utilisateur ont été ajoutées.

Le résultat est une sorte de carte de développement avec la possibilité de connecter des modules externes. Cette fois, j'ai commandé une planche en Chine. Le montage a été effectué avec nous.

image

image
La deuxième version du tableau

Pour la deuxième version, j'ai compris la modélisation 3D dans Altium Designer, ce qui a beaucoup aidé à éviter les erreurs dans le positionnement relatif des composants sur deux côtés (il s'est avéré que l'Internet avait déjà beaucoup de modèles prêts à l'emploi de composants SMD [4] ). Ainsi, toutes les erreurs de la première version ont été corrigées, les innovations ont montré leur efficacité, ce qui m'a fait très plaisir.

Firmware


La description du code dépasse le cadre de cette partie, cependant je voudrais dire quelques mots sur le composant logiciel. Dans mon appareil, j'ai décidé d'utiliser la pile FreeRTOS + LwIP. Il existe un nombre suffisant d'articles à leur sujet, par exemple [5] et [6] , il ne devrait donc pas être difficile de les lier à votre projet. En bref, LwIP est une pile TCP \ IP pour les systèmes embarqués, caractérisée par une faible consommation de RAM et une API pratique (il y a même un shell de socket BCD). J'ai utilisé l'API netconn. Au moyen de FreeRTOS, tout le travail de la pile TCP \ IP est placé dans un flux distinct de l'application. En plus du travail principal (connexion d'un serveur TCP externe au bus CAN), un serveur Web distinct tourne dans un flux indépendant pour accéder aux paramètres de l'appareil. Une telle interface Web est destinée à la surveillance et à la configuration des paramètres de l'appareil - définition de différents modes de fonctionnement, vitesses de transmission, adresses, etc. Je ne sais pas encore s'il sera possible de faire une mise à jour du firmware par ce biais.

Conclusion


Ce fut mon premier (et j'espère que ce n'est pas le dernier) projet matériel d'une telle complexité et, malgré les erreurs commises, la deuxième version de la carte, je pense, peut être considérée comme réussie. À chaque itération, il y avait beaucoup de doutes, mais, néanmoins, encore une fois, je suis convaincu que si vous n'essayez pas, rien ne se passera sûrement.

Sources utilisées


1. Wikipedia / Controller_Area_Network
2. Fiche technique STM32F407VET6
3. Fiche technique DP83848
4. Modèles 3D
5. Introduction Ă  FreeRTOS
6. Introduction au LwIP

Source: https://habr.com/ru/post/fr464043/


All Articles