Résoudre les problèmes cachés : réels

Jacob du Bénin | 30 août 2023

Aujourd’hui, l’une des capacités les plus sous-estimées du développement de logiciels embarqués consiste à tracer une application de système d’exploitation en temps réel (RTOS). Les RTOS ont trouvé leur place dans presque tous les appareils IoT et dans de nombreux appareils déconnectés. Lorsque les développeurs testent leurs systèmes, ils examinent souvent les comportements externes du système pour évaluer s'il fonctionne correctement. Le problème de cette approche est que de nombreux systèmes ont des comportements qui doivent se produire de manière déterministe sur des échelles de temps inférieures à 50 millisecondes. Sans traçage, vous pourriez croire que le système fonctionne, pour ensuite découvrir lorsqu'il est entre les mains de vos clients qu'il est défectueux et ne fonctionne pas correctement en toutes circonstances. Dans cet article, je vais vous présenter certaines fonctionnalités de trace et partager des exemples de la façon dont j'ai repéré des problèmes qui n'auraient peut-être pas été découverts avant que les appareils ne soient sur le terrain.

Avant d'examiner quelques exemples spécifiques, il est utile de comprendre comment tracer une application RTOS. Généralement, il y a deux parties : une bibliothèque d'enregistreur qui suit les événements dans l'application RTOS sur la cible et une interface graphique de visualisation qui reçoit et affiche les données d'événement. Plusieurs outils permettent aux développeurs de capturer ces données, tels que Percepio Tracealyzer, SEGGER SystemView et Microsoft Azure RTOS TraceX. Il en existe bien d'autres, mais l'outil que vous utiliserez dépendra du RTOS que vous utilisez et de vos besoins en visualisation.

Vous installez généralement la bibliothèque d’outils Trace Recorder, qui crée souvent une tâche de trace. Cette tâche de faible priorité prend les données d'événement enregistrées et les transmet à l'application hôte (au moins en mode streaming). Je mentionne cela car lorsque vous instrumentez votre code de cette manière, il est important de noter que des cycles CPU supplémentaires seront dédiés à l'enregistrement des données de trace. D'après mes expériences d'utilisation de ces outils, la surcharge est si minime que vous ne la remarquez pas (du moins dans toutes les applications sur lesquelles j'ai travaillé). Il est important de savoir si vous souhaitez laisser l'enregistreur de traces dans votre firmware. Si ce n'est pas le cas, testez et validez votre application avec votre firmware release !

J'ai récemment coaché ​​une équipe d'ingénieurs qui avaient commencé les tests de validation de leur produit. Ils ont effectué leurs tests et ont estimé que leur système fonctionnait parfaitement. Ils m'ont dit que leur système était prêt à être expédié ; ils ont constaté un problème mineur avec le timing de télémétrie de leur système – ce n’est pas grave. D’après mon expérience, il n’existe pas de problème mineur. Les problèmes mineurs ne sont généralement que la pointe de l’iceberg qui se transforme en problèmes titanesques lorsqu’ils arrivent entre les mains du client. Nous avons donc configuré Percepio Tracealyzer pour tracer l'application et voir comment leur système fonctionnait parfaitement.

Si vous regardez la figure 1 ci-dessous, vous pouvez voir une représentation de l'utilisation du processeur du système. Chaque couleur du diagramme correspond à une tâche différente. L'axe des x représente le temps et l'axe des y représente l'utilisation du processeur. Cela ressemble-t-il à un système validé, prêt à être mis entre les mains des clients ?

Figure 1. Un exemple de graphique d'utilisation du processeur dans lequel la charge du processeur atteint 100 % tout le temps.

Malheureusement, le système en question utilisait 100 % du processeur. Après un examen plus approfondi, il ne respectait pas les délais critiques et ne fonctionnait pas de manière déterministe. L’observation humaine s’est avérée inutile pour découvrir ces problèmes en traçant l’application. Si le produit avait été expédié de cette manière, les clients auraient eu des problèmes. En prenant quelques traces simples, nous pourrions déceler un problème et remédier à la situation. En approfondissant un peu, nous avons identifié quelques petites causes qui ont pris moins d'une demi-journée à résoudre, et l'utilisation du processeur qui en a résulté est passée de la figure 1 à quelque chose comme la figure 2.

Figure 2. Un exemple de graphique d'utilisation du processeur plus adapté à un système de production.

L'utilisation améliorée du processeur est beaucoup plus faible et laisse une marge pour ajouter de futures fonctionnalités et garantir au client un système capable de répondre et de respecter ses délais.

Le traçage RTOS ne détecte pas seulement les problèmes de performances du processeur. Il agit comme un oscilloscope pour logiciel ! Lorsque les threads sont visualisés, vous pouvez repérer différents modèles dans votre système et identifier les incohérences. Le résultat est que vous pouvez rencontrer des problèmes tels que des inversions de priorités, des blocages et une privation de tâches. Regardons un exemple.