Technologie PCB - Plusieurs astuces pour les cartes mères PCB intégrées

Devenir un ingénieur officiel de conception et de développement de cartes mères PCB intégrées est un processus difficile qui nécessite que les développeurs maintiennent et gèrent chaque bit et octet du système. Du cycle de développement des spécifications à la mise en œuvre rigoureuse et à l'inspection des systèmes, il existe de nombreuses technologies permettant de développer des systèmes embarqués de haute fiabilité. Aujourd'hui, je vais vous présenter 7 Technologies de PCB qui sont faciles à utiliser et qui peuvent être utilisées à long terme. Ils sont très utiles pour s'assurer que les systèmes fonctionnent de manière plus fiable et capturent les comportements anormaux.

Les développeurs de logiciels sont généralement un groupe de personnes très optimistes, à condition que leur code fonctionne fidèlement pendant une longue période, c'est tout. Il semble très rare qu'un microcontrôleur saute hors de l'espace applicatif et s'exécute dans un espace de code inattendu. Cependant, les chances que cela se produise ne sont pas inférieures à un dépassement de tampon ou à une référence manquante de pointeur incorrect. Ça va arriver! Une fois que cela se produit, le comportement du système est incertain, car l'espace mémoire est 0xff par défaut, ou parce que la zone mémoire n'est généralement pas écrite, donc cette valeur peut être connue de Dieu seul.

Cependant, il existe des compétences assez complètes en Linker ou IDE qui peuvent être utilisées pour identifier de tels événements et restaurer le système à partir de ceux - ci. L'astuce consiste à utiliser la commande fill pour remplir une Rom inutilisée avec un mode bit connu. Il y a beaucoup de différentes combinaisons possibles qui peuvent être utilisées pour remplir la mémoire inutilisée, mais si vous voulez construire un système plus fiable, l'option la plus évidente est de placer le FAILOVER ISR à ces endroits. Si un problème survient dans le système et que le processeur commence à exécuter du Code en dehors de l'espace du programme, il déclenche l'ISR et offre la possibilité de stocker l'état du processeur, des registres et du système avant de décider d'une action corrective.

Un grand avantage pour les ingénieurs embarqués est que notre IDE et notre chaîne d'outils peuvent générer automatiquement une application ou une somme de contrôle de l'espace mémoire (checksum), vérifiant ainsi que l'application est intacte en fonction de cette somme de contrôle. Il est intéressant de noter que dans de nombreux cas, les sommes de contrôle ne sont utilisées que lorsque le Code du programme est chargé dans l'appareil.

Cependant, si le CRC ou la somme de contrôle est sauvegardé en mémoire, alors vérifier au démarrage que l'application est intacte (ou même régulièrement pour les systèmes qui durent longtemps) est un excellent moyen de s'assurer que rien d'inattendu ne se produit. De nos jours, il est peu probable que les applications de programmation changent, mais compte tenu des milliards de microcontrôleurs livrés chaque année et des environnements de travail potentiellement difficiles, les chances de plantage des applications d'instruments médicaux ne sont pas nulles. Il est plus probable qu'un défaut dans le système peut entraîner l'écriture flash ou l'effacement flash dans un secteur, ce qui peut compromettre l'intégrité de l'application.

Effectuer une vérification RAM au démarrage

Pour construire un système plus fiable et plus robuste, il est important de s'assurer que le matériel du système fonctionne correctement. Après tout, le matériel échouera. (heureusement, le logiciel n'échoue jamais, le logiciel ne fait que ce que le Code veut qu'il fasse, à tort ou à raison). Vérifier qu'il n'y a pas de problème avec la RAM interne ou externe au démarrage est un excellent moyen de s'assurer que le matériel fonctionne comme prévu.

Il existe de nombreuses façons d'effectuer une vérification de la RAM, mais la méthode la plus courante consiste à écrire un schéma connu et à attendre un court moment avant de le relire. Le résultat devrait être que ce que vous lisez est ce que vous écrivez. La vérité est que dans la plupart des cas, la vérification de la RAM passe, et c'est ce que nous voulons. Cependant, il y a peu de chances que la vérification ne passe pas, ce qui donne au système une excellente occasion d'indiquer un problème matériel.

Utilisation du Stack Monitor

Pour de nombreux développeurs embarqués, la pile semble être une force assez mystérieuse. Lorsque des choses étranges commencent à se produire, les ingénieurs sont finalement éblouis et commencent à penser à ce qui pourrait se passer dans la pile. Le résultat est un ajustement aveugle de la taille et de la position de la pile, etc. mais les erreurs n'ont souvent rien à voir avec la pile, mais comment peut - elle être aussi sûre? Après tout, combien d'ingénieurs effectuent réellement une analyse de la taille de la pile dans le pire des cas?

La taille de la pile est assignée statiquement au moment de la compilation, mais la pile est utilisée de manière dynamique. Au fur et à mesure de l'exécution du Code, les variables, les adresses de retour et d'autres informations requises par l'application sont stockées en permanence dans la pile. Ce mécanisme entraîne une croissance constante de la pile dans la mémoire qui lui est allouée. Cependant, cette croissance peut parfois dépasser la limite de capacité déterminée lors de la compilation, ce qui entraîne la destruction des données dans les zones de mémoire adjacentes par la pile.

Une façon de s'assurer absolument que la pile fonctionne correctement est d'implémenter Stack Monitor dans le cadre du Code de « santé» du système (Combien d'ingénieurs le font?). Le moniteur de pile crée un tampon entre la pile et les « autres » zones de mémoire et le remplit avec un schéma de bit connu. Le moniteur surveillera ensuite en permanence si le mode a changé. Si le mode bit change, cela signifie que la pile croît trop et que le système est sur le point d'être poussé dans un enfer sombre! À ce stade, le Moniteur peut enregistrer l'occurrence de l'événement, l'état du système et toute autre donnée utile pour diagnostiquer le problème à l'avenir.

Un moniteur de pile est fourni dans la plupart des systèmes d'exploitation temps réel (RTOS) ou des systèmes à microcontrôleur qui implémentent des unités de protection mémoire (MPU). Ce qui est effrayant, c'est que ces fonctionnalités sont désactivées par défaut ou souvent délibérément désactivées par les développeurs. Une recherche rapide sur le Web a révélé que beaucoup de gens recommandent de désactiver le moniteur de pile dans le système d'exploitation en temps réel pour économiser 56 octets d'espace Flash, etc. c'est quelque chose à gagner et à perdre!

Avec MPU

Dans le passé, il était difficile de trouver une unité de protection de la mémoire (MPU) dans un petit microcontrôleur bon marché, mais cela a commencé à changer. Maintenant, les microcontrôleurs, du Haut de gamme au bas de gamme, ont déjà des MPU qui offrent aux développeurs de logiciels PCB embarqués l'occasion d'améliorer considérablement la robustesse du firmware.

Le MPU a été progressivement couplé au système d'exploitation pour créer un espace mémoire où les traitements sont séparés ou les tâches peuvent exécuter leur code sans crainte d'être piétinées. Si quelque chose se produit, le traitement incontrôlé sera éliminé et d'autres protections seront mises en œuvre. Faites attention aux microcontrôleurs avec ce type de composant, et si vous en avez, utilisez davantage ses caractéristiques.

Construire un système de chien de garde puissant

Une des implémentations préférées de chien de garde que vous trouverez souvent est la position activée du chien de garde (ce qui est un bon point de départ), mais vous pouvez également utiliser une minuterie régulière pour effacer la position du chien de garde; L'activation de la minuterie est complètement isolée de tout ce qui se passe dans le programme. Le but de l'utilisation d'un chien de garde est d'aider à s'assurer que si une erreur se produit, le chien de garde ne sera pas effacé, c'est - à - dire lorsque le travail est suspendu, le système sera obligé d'effectuer une Réinitialisation matérielle pour la récupération. Même si le système tombe en panne, l'utilisation d'une minuterie indépendante de l'activité du système peut permettre au chien de garde de rester dégagé.

Comment intégrer des tâches d'application dans un système Watch Dog, les développeurs de cartes mères PCB intégrées doivent réfléchir et concevoir soigneusement. Par exemple, il existe une technique qui peut permettre à chaque tâche exécutée sur une période de temps précise d'indiquer qu'elle peut mener à bien sa tâche. Dans ce cas, le chien de garde n'est pas effacé, mais forcé à réinitialiser. Il existe également des technologies plus avancées, telles que l'utilisation d'un processeur externe Watch Dog, qui peuvent être utilisées pour surveiller le comportement du processeur PCB principal et vice versa. Pour un système fiable, il est important de mettre en place un système de surveillance solide.

Évitez d'allouer de la mémoire volatile

Les ingénieurs qui ne sont pas habitués à travailler dans un environnement avec des ressources limitées peuvent essayer d'utiliser les fonctionnalités de leur langage de programmation, ce qui leur permet d'utiliser l'allocation de mémoire volatile PCB. Après tout, c'est une technologie de PCB couramment utilisée dans les systèmes de calculatrice. Dans un système de calculatrice, la mémoire n'est allouée que si nécessaire. Par exemple, lors du développement en langage C, les ingénieurs peuvent être enclins à utiliser malloc pour allouer de l'espace sur le tas. Il y a une opération qui sera exécutée. Une fois cela fait, vous pouvez utiliser Free pour retourner la mémoire allouée pour la pile.