Plusieurs routines et techniques pratiques de développement embarqué-Problème commun-php.cn

Il existe de nombreuses techniques pour développer des systèmes embarqués de haute fiabilité, depuis des cycles de développement bien réglementés jusqu'à une exécution stricte et des vérifications du système.

Je vous présente 7 conseils faciles à utiliser et pouvant être utilisés pendant longtemps. Ils sont très utiles pour garantir un fonctionnement plus fiable du système et détecter les comportements anormaux

Astuce 1. - Utilisez une ROM Value Filled connue

Les développeurs de logiciels ont tendance à être un groupe très optimiste et veulent simplement que leur code s'exécute fidèlement pendant longtemps et c'est tout. Il semble assez rare qu'un microcontrôleur sorte de l'espace applicatif et s'exécute dans un espace de code involontaire. Cependant, le risque que cela se produise n'est pas moins probable qu'un débordement de tampon ou qu'un mauvais pointeur perd sa référence. Cela arrive ! Le comportement du système après cela ne sera pas défini, car l'espace mémoire est entièrement 0xFF par défaut, ou parce que la zone mémoire n'est généralement pas écrite, la valeur qu'elle contient ne peut être connue que de Dieu.

Cependant, il existe des techniques d'éditeur de liens ou d'IDE assez complètes qui peuvent être utilisées pour aider à identifier de tels événements et à récupérer le système. L'astuce consiste à utiliser la commande FILL pour remplir la ROM inutilisée avec un modèle de bits connu. Pour remplir la mémoire inutilisée, il existe de nombreuses combinaisons possibles, mais si vous souhaitez construire un système plus fiable, le choix le plus évident consiste à placer des gestionnaires de pannes ISR à ces emplacements. Si quelque chose ne va pas dans le système et que le processeur commence à exécuter du code en dehors de l'espace programme, l'ISR est déclenché et offre la possibilité de stocker le processeur, le registre et l'état du système avant de décider d'une action corrective.

Astuce 2 – Vérifiez le CRC de votre application

Un grand avantage pour les ingénieurs embarqués est que notre IDE et notre chaîne d'outils peuvent générer automatiquement la somme de contrôle du programme ou de l'espace mémoire des applications (Somme de contrôle ) pour vérifier si l'application est intacte sur la base de cette somme de contrôle. Il est intéressant de noter que dans bon nombre de ces cas, la somme de contrôle n'est utilisée que lors du chargement du code du programme sur l'appareil.

Cependant, si le CRC ou la somme de contrôle est conservé en mémoire, il est extrêmement important de vérifier que l'application est toujours intacte au démarrage (ou même périodiquement pour les systèmes qui fonctionnent depuis longtemps) pour garantir qu'aucun imprévu ne se produise. chemin.

De nos jours, la probabilité qu'une application programmée change est très faible, mais compte tenu des milliards de microcontrôleurs expédiés chaque année et de l'environnement de travail potentiellement difficile, le risque de crash de l'application n'est pas nul. Plus probablement, une faille dans le système pourrait provoquer une écriture flash ou un effacement flash sur un secteur, compromettant ainsi l'intégrité de l'application.

Astuce 3 – Effectuez une vérification de la RAM au démarrage

Afin de construire un système plus fiable et plus solide, il est important de s'assurer que le matériel du système fonctionne correctement . Après tout, le matériel peut tomber en panne. (Heureusement, le logiciel n'échoue jamais, il fait simplement ce que le code lui dit de faire, que ce soit bien ou mal). Vérifier qu'il n'y a aucun problème interne ou externe à la RAM au démarrage est un bon moyen de garantir que le matériel fonctionne comme prévu.

Il existe de nombreuses façons différentes d'effectuer une vérification de la RAM, mais une méthode courante consiste à écrire sur un modèle connu, puis à attendre un court laps de temps avant de le relire. Le résultat devrait être que ce qui est lu est ce qui est écrit. La vérité est que dans la plupart des cas, la vérification de la RAM réussit, ce que nous souhaitons. Cependant, il existe une très faible possibilité que la vérification échoue, ce qui constitue une excellente opportunité pour le système de signaler un problème matériel.

Astuce 4 - Utilisez un Stack Monitor

Pour de nombreux développeurs embarqués, la pile semble être une force plutôt mystérieuse. Lorsque des choses étranges ont commencé à se produire, les ingénieurs ont finalement été perplexes et ont commencé à penser qu'il se passait peut-être quelque chose dans la pile. Le résultat est un ajustement aveugle de la taille et de la position de la pile, etc. Mais l’erreur est souvent indépendante de la pile, mais comment peut-on en être si sûr ? Après tout, combien d’ingénieurs ont réellement effectué une analyse de la taille de la pile dans le pire des cas ?

La taille de la pile est alloué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 nécessaires à l'application sont stockées en permanence sur la pile. Ce mécanisme entraîne une croissance continue de la pile dans la mémoire allouée. Cependant, cette croissance dépasse parfois la limite de capacité déterminée au moment de la compilation, ce qui entraîne une corruption des données dans les zones mémoire adjacentes.

Une façon d'être absolument sûr que votre pile fonctionne correctement est d'implémenter un moniteur de pile dans le cadre du code « santé » de votre système (combien d'ingénieurs feraient cela ?). Le moniteur de pile crée une zone tampon entre la pile et l'"autre" zone mémoire, remplie de modèles de bits connus. Le moniteur surveille ensuite en permanence le modèle pour déceler tout changement. Si cette configuration binaire change, cela signifie que la pile est devenue trop grande et est sur le point de pousser le système dans un enfer sombre ! À ce stade, le moniteur peut enregistrer l'apparition d'événements, l'état du système et toute autre donnée utile pour une utilisation ultérieure dans le diagnostic des problèmes.

Un moniteur de pile est disponible dans la plupart des systèmes d'exploitation en temps réel (RTOS) ou des systèmes à microcontrôleur qui implémentent une unité de protection de mémoire (MPU). Ce qui est effrayant, c'est que ces fonctionnalités sont désactivées par défaut ou sont souvent désactivées intentionnellement par les développeurs. Une recherche rapide sur le Web montre que de nombreuses personnes 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.Attendez, cela n'en vaut pas la peine !

Astuce 5 – Utiliser un MPU

Dans le passé, il était difficile de trouver une unité de protection de la mémoire (MPU) dans un microcontrôleur petit et bon marché, mais cette situation a commencé à changer. Les microcontrôleurs du haut de gamme au bas de gamme disposent désormais de MPU, et ces MPU offrent aux développeurs de logiciels embarqués la possibilité d'améliorer considérablement la robustesse de leur micrologiciel.

Les MPU ont été progressivement couplés au système d'exploitation pour créer des espaces mémoire où le traitement est séparé ou où les tâches peuvent exécuter leur code sans craindre d'être piétinées. Si quelque chose se produit, le traitement incontrôlé sera annulé et d'autres mesures de protection seront mises en œuvre. Gardez un œil sur les microcontrôleurs dotés de ce composant et si c'est le cas, profitez de cette fonctionnalité.

Astuce 6 - Créez un système de surveillance puissant

L'une des implémentations de surveillance les plus populaires que vous trouverez souvent Oui, où le chien de garde est activé (ce qui est un bon début ), mais aussi où le chien de garde peut être effacé avec une minuterie périodique ; l'activation de la minuterie est complètement indépendante de tout ce qui se produit dans le programme.

Le but de l'utilisation du chien de garde est de garantir que si une erreur se produit, le chien de garde ne sera pas effacé, c'est-à-dire que lorsque le travail est suspendu, le système sera obligé d'effectuer une réinitialisation matérielle (réinitialisation matérielle) afin pour récupérer. L'utilisation d'une minuterie indépendante de l'activité du système permet au chien de garde de rester effacé même en cas de panne du système.

Les développeurs embarqués doivent examiner et concevoir soigneusement la manière dont les tâches d'application sont intégrées dans le système de surveillance. Par exemple, une technique pourrait permettre à chaque tâche exécutée pendant une certaine période d’indiquer qu’elle a réussi sa tâche. Dans ce cas, le chien de garde n'est pas effacé et est forcé de se réinitialiser. Il existe également des techniques plus avancées, telles que l'utilisation d'un processeur de surveillance externe, qui peut être utilisé pour surveiller les performances du processeur principal et vice versa.

Pour un système fiable, il est important d'établir un système de surveillance puissant. Parce qu'il existe trop de technologies, il est difficile de les couvrir entièrement dans ces paragraphes, mais je publierai des articles sur ce sujet à l'avenir.

Astuce 7 - Évitez les allocations de mémoire volatiles

Les ingénieurs qui ne sont pas habitués à travailler dans un environnement aux ressources limitées peuvent être tentés d'exploiter les fonctionnalités de leur langage de programmation , un langage qui leur permet d'utiliser l'allocation de mémoire volatile. Après tout, il s’agit d’une technique souvent utilisée dans les systèmes de calcul, où la mémoire n’est allouée que lorsque cela est nécessaire. Par exemple, lors du développement en C, les ingénieurs peuvent avoir tendance à utiliser malloc pour allouer de l'espace sur le tas. Une opération sera effectuée, et une fois terminée, free pourra être utilisé pour restituer la mémoire allouée afin que le tas puisse être utilisé.

Dans un système aux ressources limitées, cela pourrait être un désastre ! L'un des problèmes liés à l'utilisation de l'allocation de mémoire volatile est que des erreurs ou des techniques inappropriées peuvent entraîner des fuites de mémoire ou une fragmentation de la mémoire. Si ces problèmes surviennent, la plupart des systèmes embarqués ne disposent pas des ressources ou des connaissances nécessaires pour surveiller le tas ou le gérer correctement. Et lorsqu’ils le font, que se passe-t-il si une application fait une demande d’espace, mais que l’espace demandé n’est pas disponible ?

Les problèmes causés par l'utilisation de l'allocation de mémoire volatile sont très compliqués, et on peut dire que c'est un cauchemar de gérer correctement ces problèmes ! Une alternative consiste simplement à allouer de la mémoire directement de manière statique. Par exemple, au lieu de demander un tampon mémoire de cette taille via malloc, créez simplement un tampon dans votre programme d'une longueur de 256 octets.Cette mémoire allouée est conservée tout au long de la durée de vie de l'application sans se soucier des problèmes de tas ou de fragmentation de la mémoire.

Conclusion

Ce ne sont là que quelques façons dont les développeurs peuvent commencer à créer des systèmes embarqués plus fiables. Il existe de nombreuses autres techniques, telles que l'utilisation de bonnes normes de codage, la détection des retournements de bits, la vérification des limites des tableaux et des pointeurs et l'utilisation d'assertions. Toutes ces technologies sont le secret qui permet aux concepteurs de développer des systèmes embarqués plus fiables

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!