La conception et le développement de carte mère embarquée doivent connaître 7 compétences

Devenir un ingénieur formel de conception et de développement de carte mère embarquée est un processus laborieux qui exige des développeurs de maintenir et de gérer chaque bit et octet du système. Des cycles de développement bien régulés à l’exécution rigoureuse et aux inspections de système, il existe de nombreuses techniques pour développer des systèmes embarqués hautement fiables. Voici sept conseils faciles à utiliser et durables qui peuvent contribuer à rendre votre système plus fiable et à détecter les comportements inhabituels.

Astuce 1 - remplissez la ROM avec des valeurs connues

Les développeurs de logiciels ont tendance à être un groupe très optimiste et juste garder leur code fonctionnant fidèlement pendant une longue période, c’est tout. Il semble assez rare pour un microcontrôleur de sortir de l’espace d’application et de s’exécuter dans un espace de code non intentionnel. Cependant, ce n’est pas moins probable qu’un débordement de cache ou un pointeur d’erreur perdant une référence. Cela arrive! Le comportement du système après que cela se produise sera incertain, parce que l’espace mémoire est 0xFF par défaut, ou parce que la zone mémoire n’est généralement pas écrite, la valeur qu’elle contient peut seulement être connue de dieu.

Cependant, il existe des techniques de liaison ou IDE assez complètes qui peuvent être utilisées pour aider à identifier de tels événements et à récupérer le système à partir de ceux-ci. Il existe de nombreuses combinaisons possibles que vous pouvez utiliser pour remplir la mémoire inutilisée, mais si vous voulez construire un système plus fiable, le choix le plus évident est de placer un gestionnaire de défaut ISR à ces endroits. Si quelque chose se passe mal dans le système, le processeur commence à exécuter le code en dehors de l’espace du programme, ce qui déclenche l’isr et permet de stocker l’état du processeur, du registre et du système avant de décider de la mesure corrective à prendre.

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 automatiquement générer une application ou une somme de contrôle de l’espace mémoire par rapport à laquelle vérifier que l’application est solide. Il est intéressant de noter que dans la plupart de ces cas, la somme de contrôle n’est utilisée que lorsque le code du programme est chargé dans le périphérique.

Cependant, si le CRC ou la somme de contrôle est conservé en mémoire, vérifier que l’application est toujours intacte au démarrage (ou même périodiquement pour un système de longue durée) est un excellent moyen de s’assurer que l’inattendu ne se produise pas. La probabilité de changement d’une application programmée est maintenant faible, mais compte tenu des milliards de microcontrôleurs livrés chaque année et de l’environnement de travail potentiellement difficile, le risque de crash d’une application de dispositif médical n’est pas nul. Plus probablement, une faille dans le système pourrait entraîner une écriture flash ou un effacement flash dans un secteur, compromettant ainsi l’intégrité de l’application.

Astuce 3 - effectuer 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 échouer. (heureusement, le logiciel ne tombe jamais en panne; Il fait ce que le code lui dit de faire, que ce soit bien ou mal.) Vérifier qu’il n’y a pas de problèmes à l’intérieur ou à l’extérieur de la RAM au démarrage est un bon 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 une approche commune est d’écrire un motif connu et d’attendre un court laps de temps avant de le lire à nouveau. Le résultat devrait être que ce qui est lu est ce qui est écrit. La vérité est que les contrôles de RAM passent dans la plupart des cas, et c’est ce que nous voulons. Cependant, il y a aussi une très faible chance que la vérification ne passe pas, ce qui fournit une excellente occasion pour le système de signaler un problème matériel.

Astuce 4 - utiliser le moniteur de pile

Pour de nombreux développeurs embarqués, la pile semble être une force assez mystérieuse. Quand des choses étranges commencent à se produire, les ingénieurs sont finalement trompés, et ils commencent à penser que peut-être quelque chose se passe dans la pile. Le résultat est d’ajuster sans réfléchir la taille et la position de la pile, et ainsi de suite. Mais l’erreur est souvent indépendante de la pile, mais comment pouvez-vous être si sûr? Après tout, combien d’ingénieurs ont réellement effectué une analyse de la taille de la cheminée dans le pire des cas?

La taille de la pile est attribuée statiquement au moment de la compilation, mais la pile est utilisée dynamiquement. Lorsque le code s’exécute, les variables, les adresses de retour et les autres informations requises par l’application sont stockées en continu sur la pile. Ce mécanisme fait croître la pile dans la mémoire qu’elle alloue. Cependant, cette croissance peut parfois dépasser les limites de capacité déterminées lors de la compilation, provoquant la corruption des données dans les régions mémoire adjacentes.

Une façon de s’assurer que la pile fonctionne correctement est d’implémenter un moniteur de pile dans le code "d’intégrité" de votre système (combien d’ingénieurs font cela?). Le moniteur de pile crée une zone tampon entre la pile et l’ "autre" zone mémoire et la remplit de motifs de bits connus. Le moniteur surveille alors constamment le modèle pour tout changement. Si le motif des bits change, cela signifie que la pile a trop évolué