par Lotta Frimanson et Anders Lundgren (IAR Systems)

Application  Développement
Visualiser la consommation
d’un microcontrôleur via
un environnement de débogage
Comment détecter les fuites d’énergie et comment optimiser le logiciel applicatif
pour minimiser la consommation d’énergie dans un système embarqué ? La technologie
du débogage énergétique (power debugging) est une solution pour y parvenir.
IAR Systems, présente ici des cas concrets où cette approche s’avère très utile.
L
Auteurs
Lotta Frimanson
et de Anders
Lundgren,
responsables
produit chez
IAR Systems
a notion de débogage énergétique fournit aux développeurs l’information
nécessaire pour déterminer
comment l’implémentation d’un
logiciel embarqué affecte la consommation énergétique d’un système à
base de microcontrôleur (MCU). En
corrélant code source et consommation, il est possible de tester ce logiciel embarqué et de l’ajuster pour
l’optimiser au plan énergétique.
Aujourd’hui, la durée de vie de la
batterie (ou d’une pile) est un facteur
extrêmement important pour les systèmes embarqués dans presque tous
les segments du marché : le médical,
le grand public, la domotique et bien
d’autres. Traditionnellement, la
consommation d’énergie relevait des
concepteurs de matériel et ils semblaient les seuls en mesure d’influer
sur sa valeur. Pourtant dans un système en fonctionnement, cette
consommation dépend autant du
matériel que de la manière de l’utiliser ; or cette manière découle direc-
1 Mesure de consommation
La chute de tension est ici mesurée par
un amplificateur différentiel puis échantillonnée
grâce à un convertisseur A/N autorisant
la mesure du courant en tout point.
Régulateur
de tension
Résistance 1 Ω
(pour 100 mA max.)
I+
I-
Carte sous test
Jtag
28 / L’EMBARQUÉ / N°1
VDD
MCU
tement du logiciel embarqué dans le
système.
La technologie de débogage énergétique, mise au point par IAR Systems,
permet de visualiser la consommation d’un système via les outils de
développement de logiciel embarqué. Cela revient à mettre entre les
mains des développeurs un outil les
aidant à minimiser la consommation
en agissant au cœur du logiciel
embarqué : c’est ce que nous appelons le débogage énergétique.
Le débogueur IAR C-SPY relève les
données de consommation énergétique, aussi bien statistiquement que
dynamiquement, et permet de les
afficher sous différentes formes. Il
fournit également les moyens d’effectuer un profilage et un débogage
énergétique de l’application.
Comment fonctionne
le débogage énergétique ?
Cette technologie repose sur l’acquisition d’échantillons de valeurs de la
puissance consommée puis sur la
corrélation de chaque échantillon
avec la séquence correspondante
d’instructions du programme, donc
avec le code source. L’une des difficultés consiste à obtenir un échantillonnage de haute précision. Dans
l’idéal, il faudrait mesurer la consommation à la fréquence d’horloge du
système ; cependant les capacités
intrinsèques au système réduisent la
fiabilité de telles mesures. Autrement
dit, la consommation mesurée peut
être « polluée » par rapport à la
consommation effective du CPU et
des périphériques.
En fait dans la pratique, ce problème
n’en est pas un. En effet, du point de
vue du concepteur, il est beaucoup
plus intéressant de corréler la puissance consommée avec le code
source et divers événements intervenant dans l’exécution du programme
qu’avec les instructions proprement
dites. La résolution nécessaire est
donc bien plus faible qu’un échantillon par instruction.
Au sein du circuit, la consommation
est mesurée grâce à une sonde, IAR
I-scope dans notre cas, qui évalue la
différence de tension aux bornes
d’une petite résistance mise en série
entre la source d’alimentation et le
dispositif. I-scope doit être utilisée en
association avec la sonde de débogage IAR I-jet (figure 1). La chute de
tension est mesurée par un amplificateur différentiel puis est échantillonnée grâce à un convertisseur analogique-numérique. Cette technique
autorise la mesure du courant en tout
point de la carte.
La clé d’un débogage énergétique
précis est la justesse de la corrélation
entre la trace d’instruction et les
mesures de puissance consommée.
La meilleure corrélation est obtenue
si une trace d’instruction complète
est disponible ; ce qui est le cas avec
le support ETM (Embedded Trace
Macrocell) des MCU ARM. Le problème est que deux conditions
doivent être remplies : l’usage d’une
sonde de débogage spéciale et la
prise en charge d’ETM au sein du
dispositif.
Une technique moins précise mais
donnant encore une bonne corrélation consiste à utiliser la fonction
d’échantillonnage du compteur de
programme (PC) qui est disponible
dans les cœurs ARM Cortex-M3/M4
(figure 2). Le module DWT implémente l’échantillonneur et relève le
Développement  Application
PC régulièrement, jusqu’à 50 000 fois
par seconde. Pour chaque échantillon
acquis, un paquet ITM (Instrumentation Embedded Macrocell) est stocké.
L’ITM a pour rôle de formater les événements issus du DWT. Il les range et
les horodate. La sonde de débogage
échantillonne la puissance consommée par le dispositif via un convertisseur analogique-numérique. Par le
marquage temporel des données
énergétiques et des valeurs du PC, il
est alors possible au débogueur de
présenter la consommation sur le
même axe des temps que les courbes
chronologiques d’arrivée des interruptions, ou d’évolution des variables,
et de corréler les données de consommation avec le code source.
Afficher les valeurs
du débogage énergétique
Comme indiqué précédemment, le
débogage énergétique implique
l’échantillonnage de la puissance
consommée et la corrélation de
chaque échantillon avec le code
source. Dans l’outil IAR Embedded
Workbench, les mesures de puissance peuvent être affichées sous
différents formats. Ainsi la fenêtre
« Power Log » donne le graphique
complet des mesures de consommation collectées. Elle permet de repérer les pics de consommation et,
puisque les mesures sont corrélées
avec le code exécuté, de retrouver le
code correspondant en double-cliquant sur une valeur d’énergie. La
précision dépendra de la fréquence
d’échantillonnage de la mesure de
puissance, mais elle suffit le plus souvent à retrouver la séquence de code
responsable du pic.
Une autre façon d’étudier les échantillons de consommation peut se
faire via la fenêtre « Timeline ». Dans
cette fenêtre chronologique, les
mesures de puissance sont affichées
sur l’axe des temps avec les interruptions éventuelles et un maximum de
quatre variables d’application à choisir (figure 3).
Dans les systèmes embarqués, les
périphériques sont responsables
d’une grande partie de la consommation de puissance et, qu’ils soient
ou non intégrés dans le microcontrôleur, leur utilisation est contrôlée par
logiciel. La fenêtre « Timeline » est
donc extrêmement utile pour corréler la consommation avec les appels
de fonctions et, en choisissant des
2 Module de débogage du Cortex-M3/M4
Par le marquage temporel des données énergétiques
et des valeurs du compteur de programme, il est
possible au débogueur de présenter la consommation
sur le même axe des temps que les courbes
chronologiques d’arrivée des interruptions.
FPB
DWT
4 points
d’observation
Echantillonneur
ETM trigger
Trace
d’interruption
Statistiques
CPU
6 points
d’arrêt
ITM
Trace logicielle
sur 32 canaux
Time stamping
DWT
Accès en direct
au cœur
Jtag
SWD/SWO
Trace du port
ETM
Trace
des instructions
variables dépendant de l’état de tel
ou tel périphérique, avec des activités pouvant faire grimper la consommation. L’objectif est évidemment de
voir si le code peut être optimisé sur
le plan énergétique.
De plus, la fenêtre « Timeline » étant
corrélée avec la fenêtre « Power Log »
et celle du code source, un simple
double-clic sépare ce dernier des
valeurs présentées sur l’axe des temps.
Vers un profilage énergétique
Dans la pratique, et notamment dans
un système structuré en tâches, il est
probablement plus intéressant de
suivre comment la consommation
évolue avec chaque fonction plutôt
qu’avec chaque instruction. Pour un
stimulus donné, le profileur fonctionnel aide à identifier les fonctions
dont l’exécution est la plus longue.
Il fait ainsi apparaître clairement les
zones de l’application qu’il faudrait
optimiser sur le plan énergétique.
Avec un processeur Cortex-M3 par
exemple, le débogueur peut utiliser
la possibilité d’échantillonnage du
compteur de programme dans le
module DWT. Grâce à cette fonctionnalité, le débogueur peut fournir
une analyse de performance statistique. Le profileur retrouve les fonctions corrélées avec la valeur du PC
et crée une base de données interne
répertoriant le nombre de fois où
chacune d’elles s’exécute, pour
générer une analyse de performance
de fonctions. Le débogueur affiche
cette information pour chaque fonction d’une application pendant l’exécution de celle-ci.
Pour le profilage énergétique, on
combine le profilage de fonction
avec les échantillons de mesure de
consommation pour obtenir la
consommation de chaque fonction,
et l’afficher dans la fenêtre « Function
Profiler » (figure 4 page suivante).
Cette fenêtre « Function Profiler »
présente pour chaque fonction le
nombre de fois où une mesure a été
relevée ainsi que les valeurs
moyennes, maximales et minimales.
Une fois de plus, on peut aisément
repérer les pics de consommation et
les comportements énergétiques
anormaux au sein du système embarqué analysé. En effet, un système
peut sembler fonctionner parfaitement et satisfaire entièrement les
tests effectués, et néanmoins la puissance consommée peut y être nettement plus élevée que nécessaire ; et
maintenant nous avons un moyen de
le détecter.
En général, ce travail d’optimisation
de la consommation est très proche
de l’optimisation de la vitesse de traitement. Plus une tâche s’exécute
rapidement, plus le système passe de
3 Fenêtre « Timeline »
Une autre façon d’étudier les échantillons de consommation peut se faire
via la fenêtre « Timeline » où les mesures de puissance sont affichées sur l’axe des temps
avec les interruptions et quatre variables d’application à choisir.
L’EMBARQUÉ / N°1 /
29
Application  Développement
temps dans les modes de basse
consommation. Ainsi en maximisant
le temps en mode inactif, on réduit
la consommation d’énergie.
Prenons quelques exemples montrant combien il est difficile d’identifier les mécanismes par lesquels un
système consomme de l’énergie sans
nécessité, et les zones de code se
prêtant à l’optimisation énergétique.
Typiquement, ce ne seront pas des
défauts explicites du code source qui
apparaîtront, mais plutôt des opportunités d’ajuster la manière d’utiliser
le matériel. Il peut arriver néanmoins
que des vraies fautes d’écriture du
code soient ainsi dénoncées.
Un exemple classique est l’attente du
changement d’état d’un dispositif. La
faute courante, pouvant générer une
consommation énergétique inutile,
consiste ici à utiliser une boucle de
lecture en attendant le changement
d’état d’un périphérique, par
exemple. Des segments de code
comme ceux présentés ci-dessous
s’exécutent sans interruption jusqu’à
ce que l’état bascule à la valeur
attendue :
4 Fenêtre « Fonction Profiler »
La fenêtre « Function Profiler » indique la consommation de chaque fonction.
while (USBD_GetState() < USBD_STATE_CONFIGURED);
while ((BASE_PMC->PMC_SR & MC_MCKRDY) != PMC_MCKRDY);
Un autre segment de code ayant le
même effet implante un retard logiciel comme une boucle « for » ou
« while » :
i = 10000;
do i--;
while (i != 0);
// SW Delay
Ces quelques lignes de code maintiennent le processeur en pleine activité pour exécuter des instructions
qui n’ont d’autre but que de faire
passer le temps.
Dans ces deux cas, il est possible de
modifier le programme pour minimiser la consommation énergétique.
Ainsi, l’utilisation des compteurs
(timers) matériels est un moyen bien
plus efficace d’implanter des délais.
L’interruption du compteur est activée et le processeur passe en mode
basse consommation jusqu’à ce que
cette interruption le réveille. La lecture des changements d’état de périphérique doit, elle aussi, être gérée
à l’aide d’interruptions si possible, ou
avec l’interruption d’un compteur,
afin que le processeur puisse passer
en mode veille entre deux acquisitions.
Selon les caractéristiques du système
30 / L’EMBARQUÉ / N°1
embarqué, il peut être plus ou moins
difficile d’identifier les cas de figure
précédemment présentés. Un moyen
d’y arriver consiste à utiliser les différentes fenêtres de débogage énergétique afin de bien connaître le profil
de consommation de l’application
pour pouvoir détecter plus facilement
les comportements anormaux.
Prenons l’exemple des DMA versus
les E/S contrôlées. Dans ce cas, le
mode DMA sert traditionnellement
à augmenter la vitesse de transfert.
Les fabricants de microcontrôleurs
ont inventé toute une panoplie de
techniques DMA afin d’offrir plus de
souplesse et de vitesse, tout en diminuant la consommation. Dans certaines architectures, le processeur
peut même être mis en sommeil
durant les transferts DMA. Avec le
débogage énergétique, le développeur peut effectuer des essais et
comparer directement l’effet de ces
techniques DMA avec celui des
approches traditionnelles d’entrées/
sorties contrôlées par le processeur.
Poser un diagnostic
sur les modes à basse
consommation
De nombreuses applications embarquées passent la plus grande partie
de leur temps à attendre l’occurrence
d’un événement : l’arrivée d’une
donnée sur un port série, un changement d’état sur une broche d’E/S, ou
l’expiration d’un délai. Si le processeur reste à pleine vitesse en étant
inactif, il consomme l’énergie de la
batterie sans accomplir grand-chose.
En le plaçant en mode basse consommation pendant ces temps d’inactivité, la durée de vie du système peut
être nettement allongée.
Une bonne approche consiste à
structurer l’application en tâches et
à utiliser un système d’exploitation
temps réel. La technique multitâche
permet alors d’attribuer la plus faible
priorité à une tâche qui, dès lors,
s’exécutera uniquement lorsqu’au-
cune autre n’aura besoin du CPU. La
tâche « idle » est idéale pour instaurer
une telle gestion de l’énergie. A
chaque fois qu’elle est activée, elle
place le processeur dans un mode
basse consommation. De nombreux
microprocesseurs et autres composants possèdent plusieurs modes de
basse consommation qui désactivent
différentes zones du processeur
lorsque celles-ci ne sont pas nécessaires au traitement en cours. Par
exemple, l’oscillateur sera désactivé
ou sa fréquence diminuée, les périphériques et les compteurs seront
également désactivés, et le CPU
stoppera l’exécution d’instructions.
Ces modes ont chacun une consommation différente selon les périphériques laissés en activité.
Un outil de profilage énergétique
s’avère ici très utile pour examiner en
détail les divers modes de basse
consommation. Le profileur de fonction « Function Profiler » permettra,
par exemple, de comparer la
consommation de la tâche qui amène
le système dans le mode basse
consommation lorsque plusieurs
modes de mise en veille existent. La
valeur moyenne et le pourcentage de
la consommation totale sont autant
d’informations utiles pour effectuer
cette comparaison.
Contrôler la tension et
le fréquence du processeur
L’équation théorique donnant la
consommation d’un microcontrôleur
en technologie Cmos est la suivante :
P = f x U2 x k,
où f est la fréquence d’horloge, U la
tension d’alimentation et k une
constante.
Grâce au débogage énergétique, le
développeur peut étudier la consommation en fonction de la fréquence.
Un système passant très peu de temps
en veille à 50 MHz est supposé être
50 % de son temps en veille s’il fonctionne à 100 MHz. Les mesures de
Développement  Application
consommation faites par le débogueur permettront ainsi de vérifier le
comportement attendu et, en cas de
non linéarité par rapport à l’horloge,
de choisir la fréquence assurant la
plus faible consommation.
Une avancée technologique dans le
domaine des MCU permet,
aujourd’hui, de contrôler la valeur
de la tension interne U du cœur de
processeur à partir de l’application
même. Il est ainsi possible pour l’utilisateur de réduire la valeur de la
tension interne VCORE de 1,8 V à
1,2 V si, dans le même temps, la fréquence de fonctionnement est amenée à 4 MHz maximum. Cette technique est absolument identique à
celle utilisée dans les processeurs
pour ordinateur portable ou de
bureau ; la technologie SpeedStep
mise au point par Intel en est un
exemple. La possibilité de contrôler
le paramètre tension dans l’équation
de la consommation est un nouvel
atout important pour intervenir dans
un système afin d’obtenir la plus
faible puissance consommée possible. Reportons nous au calcul théorique : en réduisant la fréquence de
32 MHz à 4 MHz, la consommation
sera diminuée d’un facteur 8 ; si en
parallèle la tension de cœur VCORE
passe de 1,8 V à 2,2 V, alors la puissance consommée est réduite d’un
facteur 18 !
Mieux gérer les interruptions
Voici un autre exemple où il est difficile de s’apercevoir qu’un système
consomme inutilement de l’énergie,
et qui implique cette fois les interruptions.
La figure 5 montre la courbe de
consommation d’un système piloté
par événements qui, à t0, se trouve
en mode inactif avec une intensité I0.
A t1, le système est activé, ce qui fait
passer le courant I1, valeur qui représente la consommation du système
actif et se servant d’un périphérique.
A t2, l’exécution est suspendue par
une interruption de plus haute priorité. Le périphérique en cours d’utilisation n’est pas désactivé, bien que
la tâche ou thread de plus haute
priorité ne s’en serve pas. Au lieu de
cela, d’autres périphériques sont
activés par le nouveau thread, ce qui
augmente le courant et le fait passer
à la valeur I2 entre les instants t2 et t3,
moment où le contrôle est rendu au
thread de plus basse priorité.
La fonctionnalité du système est certainement excellente, ainsi que son
optimisation en termes de vitesse
d’exécution et de taille de code.
Mais au plan énergétique, des efforts
supplémentaires sont possibles. La
zone jaune sur la figure 5 représente
l’énergie économisée si les périphériques inemployés entre t2 et t3 sont
désactivés, ou si les priorités entre les
deux threads sont échangées.
Le débogage énergétique fait donc
découvrir facilement la forte augmentation de consommation correspondant à l’arrivée d’interruption, et
permet d’identifier une anomalie. Un
examen approfondi dans la fenêtre
« Timeline » montre que des périphériques inemployés restent actifs plus
longtemps que nécessaires et donc
consomment de l’énergie. Evidem 5 Diagramme de la puissance consommée
Ici, la zone jaune représente l’énergie économisée si
les périphériques inemployés entre t2 et t3 sont
désactivés, ou si les priorités entre les deux threads
sont échangées.
Consommation de puissance
I2
I1
I0
Temps
t0
t1
t2
t3
t4
ment dans une situation comme
celle décrite ci-dessus, il faudra toujours vérifier si cela vaut la peine de
dépenser des cycles d’horloge supplémentaires pour activer et désactiver des périphériques.
Repérer les conflits
d’initialisation de matériel
Pour éviter les entrées « flottantes »,
une pratique courante de conception
consiste à raccorder à la masse les
broches d’entrées/sorties non utilisées par les microcontrôleurs. Si le
logiciel configure par erreur l’une de
ces broches en tant que sortie
logique à « 1 », un courant pouvant
atteindre 25 mA sera drainé à travers
cette broche. Il est facile de visualiser
cette valeur inexplicablement élevée
sur la courbe de consommation ; il
est aussi possible de retrouver le
code d’initialisation erroné corres-
pondant. Le tout en examinant l’allure de la courbe de consommation
au moment du démarrage de l’application. Une situation similaire se
présente si une broche d’E/S, conçue
comme entrée pilotée par un circuit
externe, est incorrectement configurée en tant que sortie par le logiciel.
Attention aux interférences
dans les circuits analogiques
Implanter des circuits analogiques et
numériques sur une même carte
pose des problèmes bien particuliers.
Le placement-routage de la carte
joue à ce niveau un rôle important
dans le maintien de niveaux de bruit
assez bas pour garantir une acquisition précise des petits signaux analogiques. La conception en signal
mixte exige donc beaucoup d’attention et une grande expertise en développement matériel. Mais la conception du logiciel peut, elle aussi,
affecter la qualité des mesures analogiques. Le fait de programmer
l’exécution de multiples E/S pendant
l’acquisition de mesures analogiques
donne l’occasion à ces nombreuses
lignes numériques de basculer simultanément ; ce qui représente une
bonne opportunité d’introduire du
bruit supplémentaire dans le convertisseur analogique-numérique.
Un débogueur énergétique permet
ici d’examiner les interférences des
signaux numériques et d’alimentation au sein des composants analogiques. Dans la fenêtre « Timeline »,
il est facile d’afficher l’activité d’interruption avec les données de
consommation, et d’étudier la
courbe de consommation juste avant
les interruptions du convertisseur
A/N. Les pics de consommation
parasite au voisinage des conversions A/N peuvent être sources de
bruit et doivent être examinés. Toutes
les données de la fenêtre chronologique étant corrélées avec le code
exécuté, un simple double-clic sur la
valeur suspecte de la consommation
suffit à faire apparaître le code source
C correspondant.
On voit comment la méthodologie
de débogage énergétique analyse en
détail comment le logiciel applicatif
influence la consommation. Grâce à
ces données, il est alors possible
d’envisager une optimisation du
code source afin de minimiser la
consommation du système embarqué. n
L’EMBARQUÉ / N°1 /
31