Pourquoi cela semble-t-il correct sur un microcontrôleur mais n'est généralement pas souhaité sur un microprocesseur?

Il est également indésirable sur un microcontrôleur pour la même raison: il gaspille de l'énergie.

Ai-je raison de penser que l'ATmega tourne en fait à 100%

Correct.

et que parce qu'il est si peu alimenté, il ne cause pas de problèmes de chaleur évidents?

Correct. Cependant, si vous exécutez votre microcontrôleur sur batteries, vous devez réfléchir sérieusement à ne pas gaspiller d'énergie. Sur un processeur minuscule comme AtMega328P, cela ne causera pas de problèmes de chaleur, mais cela réduira certainement la durée de vie de la batterie.

Tous les processeurs, qu'il s'agisse de centrales de bureau ou de minuscules microcontrôleurs, utilisent les mêmes méthodes:

1- Réduisez la vitesse d'horloge ou la tension.

2- Arrêtez le matériel inutile.

3- Aller dormir et se réveiller sur un événement (c'est un cas particulier d'arrêt du matériel inutile, dans ce cas le processeur est arrêté).

Dans l'AtMega328P, vous pouvez également l'implémenter. Vous pouvez utiliser une horloge plus lente si vous n'avez pas besoin de toute la puissance impressionnante du cœur 8 bits, vous pouvez arrêter les périphériques inutiles ... et le plus important est le mode veille.

Vous devriez lire le manuel pour plus de détails, car il existe plusieurs modes de veille qui diffèrent par les latences de réveil, les périphériques qui restent en ligne et capables de réveiller le processeur, si les données RAM sont conservées ou perdues, etc. Mais fondamentalement l'idée est: en mode veille, le processeur est arrêté donc il utilise beaucoup moins d'énergie. Lorsqu'une interruption se produit, cela réveille le CPU et il traite l'interruption.

Bien sûr, vous devez utiliser le mode veille approprié et le configurer correctement pour que le périphérique qui a besoin de réveiller le processeur (par exemple, une minuterie ou une interruption GPIO) ne soit pas arrêté. Si tout est arrêté, vous devrez utiliser NMI ou même Reset pour le réveiller, dans ce dernier cas en le redémarrant.

Si votre application ne fait qu'attendre les interruptions, comme:

• Interruption de changement de broche (PCI) pour détecter une pression sur un bouton ou un signal entrant

• Timer

• Données reçues par UART ou USB

• etc

Ensuite, vous n'avez pas besoin de faire tourner la boucle principale.Après avoir tout configuré au démarrage, vous démarrez la boucle principale avec une instruction "aller en veille".L'instruction suivante s'exécutera après le réveil du processeur, traitera toutes les interruptions en attente et retournera à la boucle principale.Ensuite, la boucle principale peut, si nécessaire, faire quelque chose sur les événements reçus, s'ils n'ont pas été entièrement gérés par le code d'interruption ... puis se rendormir.

Même si vous n'utilisez pas de piles, un courant de veille faible peut alimenter l'alimentation par le secteur pour éviter les cycles et gaspiller beaucoup moins d'énergie.

Sur un microcontrôleur (plus précisément, sur une carte Arduino Uno utilisant le microcontrôleur ATmega 328P), j'utiliserais normalement une boucle infinie pour vérifier les entrées, etc. (dans Arduino land, c'est normalement la fonction loop ()). Si je laisse cette fonction vide cependant, cela ne pose aucun problème.

Modèle de programmation classique, ayant une boucle principale…

Sur un ordinateur de bureau / ordinateur portable avec un processeur Intel i7, etc., si je exécutais une boucle infinie similaire (sans rien à faire, ou très peu à faire), cela épinglerait le processeur à ~ 100% et ferait généralement tourner les ventilateurs, etc. ( un délai pourrait être ajouté pour éviter cela, par exemple).

… il se peut que nous écrivions différentes boucles principales.

Cette même boucle principale serait également une mauvaise pratique sur un microcontrôleur, car cela fait également fonctionner le processeur de celui-ci à pleine charge - ce qui consomme de l'énergie. Ne faites pas cela, surtout si vous êtes sur batterie.

Les cœurs de processeur modernes ont des mécanismes de synchronisation. Cela permet aux gens d'implémenter quelque chose comme "laisser l'exécution de cette boucle dormir jusqu'à ce qu'une ms se soit écoulée, ou jusqu'à ce que cette condition ait changé".

C'est fondamentalement au cœur de tout système d'exploitation multi-tâches - et fondamentalement tous les systèmes d'exploitation qui méritent ce nom le sont maintenant. Sur les microcontrôleurs, vous trouverez souvent des RTOS (systèmes d'exploitation en temps réel), qui garantissent à quel point vous pouvez être sûr que l'exécution de quelque chose a commencé après tant de nanosecondes, car c'est typique du cas d'utilisation. des microcontrôleurs, alors que sur les ordinateurs de bureau et les processeurs de serveur, vous trouverez généralement des systèmes d'exploitation multitraitement simultanés à part entière qui offrent moins de garanties de synchronisation, mais offrent un ensemble beaucoup plus large de fonctionnalités et d'abstraction d'environnement matériel et logiciel.

Je ne connais pas assez bien l'environnement d'exécution Arduino pour faire des déclarations qualifiées à ce sujet, je recherche ceci au moment où j'écris: Arduino ne semble pas conçu pour cela - il s'attend vraiment à ce que vous tourniez simplement occupé. Comme il n'a pas de fonctionnalité "yield", le "ménage" qu'il effectue entre les appels à votre boucle ne peut pas être appelé lorsque vous utilisez la fonction intégrée delay . Pouah! Mauvaise conception.

Ce que vous feriez dans une conception tenant compte de la puissance et / ou de la latence, vous utiliseriez un RTOS pour votre microcontrôleur - FreeRTOS est assez populaire, pour la série ARM Cortex-M, mbed a beaucoup de traction, je personnellement comme ChibiOS (mais je ne pense pas que ce soit un bon choix lors du passage des croquis Arduino), la Fondation Linux pousse Zephyr (sur lequel je suis en conflit); vraiment, il y a une multitude de choix, et le fabricant de votre microcontrôleur prend généralement en charge un ou plusieurs via leurs IDE.

Pourquoi cela semble-t-il correct sur un microcontrôleur mais n'est généralement pas souhaité sur un microprocesseur?

Ce n'est pas vraiment OK, c'est un modèle de conception inhabituel, en fait, pour les microcontrôleurs, qui font généralement les choses à intervalles réguliers ou réagissent à des stimuli externes. Il n'est pas habituel que vous vouliez "utiliser autant de CPU que possible" sur un microcontrôleur en continu.

Il y a des exceptions à ce modèle, et elles existent aussi bien dans le MCU que dans le monde des processeurs serveur / bureau; quand vous savez que vous avez pratiquement toujours par exemple données réseau à traiter dans une appliance de commutation, ou lorsque vous savez que votre jeu pourrait déjà pré-calculer un peu de monde dont vous pourriez ou non avoir besoin dans quelques instants, vous trouverez ces boucles de rotation. Dans certains pilotes matériels, vous trouverez des "verrous de rotation", ce qui signifie que le processeur interroge en permanence une valeur jusqu'à ce qu'elle ait changé (par exemple, le matériel est configuré et peut être utilisé maintenant), mais il s'agit généralement d'une solution d'urgence uniquement, et vous devrez expliquer pourquoi vous faites cela lorsque vous essayez d'obtenir un tel code sous Linux, par exemple.

Ai-je raison de penser que l'ATmega fonctionne en fait à 100% et que, du fait de sa faible puissance, cela ne pose pas de problèmes de chaleur évidents?

Oui. L'ATMega n'est pas, selon les normes modernes, de faible puissance, mais il est suffisamment faible pour que la chaleur ne devienne pas un problème.

Ai-je raison de penser que l'ATmega fonctionne en fait à 100%, et que parce qu'il est si peu alimenté qu'il ne cause aucune chaleur évidente des problèmes?

Oui, il fonctionne normalement à 100% tout le temps, mais sa puissance est si faible qu'il ne chauffe pas de manière significative.

Sur un ordinateur de bureau / ordinateur portable avec un processeur Intel i7, etc. si j'ai utilisé un boucle infinie (sans rien à faire, ou très peu à faire) il épinglerait le processeur à ~ 100% et généralement faire tourner les ventilateurs, etc.

Plus un CPU est cadencé rapidement, plus il consomme de puissance, car chaque fois qu'un niveau logique change, il doit charger les capacités des transistors dans les grilles. Les processeurs modernes sont conçus pour fonctionner aussi vite que possible - en fait plus vite que possible. Même après avoir rendu les transistors aussi petits que possible, en utilisant la tension la plus basse possible et en appliquant un énorme dissipateur thermique, ils ne peuvent toujours pas fonctionner assez vite pour satisfaire le `` besoin de vitesse '' de l'utilisateur du PC. Ils comptent donc sur le fait que le système d'exploitation et les programmes d'application passent le plus clair de leur temps à attendre que des choses se produisent (entrée utilisateur, matériel périphérique, etc.)

Si vous essayiez d'exécuter tous les cœurs d'un i7 en continu à la fréquence maximale, il fondrait. Pour éviter cela, les cœurs inutilisés sont mis hors tension, et lorsque la vitesse maximale n'est pas requise (c'est-à-dire la plupart du temps), les cœurs actifs fonctionnent à une fréquence inférieure. Lorsqu'il est inactif, le système d'exploitation ne se contente pas d'exécuter une boucle occupée exécutant continuellement des instructions, mais met le processeur dans un état ralenti ou arrêté pendant qu'il attend des interruptions, etc. Diverses parties du processeur peuvent également être mises hors tension lorsqu'elles ne sont pas utilisées.

L'ATmega peut également être mis en modes de faible puissance et les périphériques individuels désactivés lorsqu'ils ne sont pas nécessaires. Si l'horloge système est modifiée à une fréquence inférieure telle que 32,678 kHz et que tous les périphériques inutiles sont désactivés, elle peut fonctionner (lentement) sur seulement quelques μA - non pas pour réduire la température, mais pour durer plus longtemps sur une petite batterie.

Il est également possible d '«overclocker» de nombreuses puces Atmega.J'ai utilisé un ATmega1284p (évalué pour 20 MHz max à 5 V) à 30 MHz et cela a bien fonctionné, mais il est devenu assez chaud.

Cela dépend du fait que votre système ATmega fonctionne avec une alimentation secteur murale ou de petites piles.

En fonctionnant hors du courant alternatif (via une alimentation de verrue murale), la puissance consommée par le processeur à 100% utilisant la boucle de rotation est inférieure au plancher de bruit de la variation de votre facture d'électricité.La dissipation thermique est probablement trop petite pour nécessiter un dissipateur thermique ou un ventilateur, sauf dans un environnement super isolé.Peut-être mesurable avec un thermomètre infrarouge.

Fonctionnant avec de petites batteries, une boucle de rotation Arduino fera une différence significative dans la fréquence à laquelle vous devez remplacer ou recharger ces batteries.Peut-être des heures contre des mois.Un problème sérieux si l'accès à votre système embarqué est difficile.Une solution courante consiste à utiliser une sorte de mode veille temporisé à faible consommation d'énergie dans la boucle infinie, ou un mode veille plus une interruption de réveil depuis une source externe.

Sur un microprocesseur contemporain, vous allez probablement écrire une interface utilisateur graphique qui fait votre travail. L'interface graphique a sa ou ses propres boucles d'événements où des éléments tels que les clics de souris, les redessins, etc. sont traités. La plupart de vos fonctionnalités seront situées à l'intérieur d'un gestionnaire d'événements qui est délégué par la boucle d'événements principale.

Ainsi, si à l'intérieur d'un tel gestionnaire d'événements vous démarrez une boucle infinie, vous allez interrompre le traitement habituel des événements, car il dépend de votre retour à la boucle d'événements après une période assez courte pour que l'interface utilisateur reste sensible. Au moins, votre propre application ne répondra plus si vous avez une boucle infinie (les clics de souris ne font rien, les graphiques ne seront plus mis à jour).

Le multitâche en tant que tel (et donc les autres processus) n'en souffrira normalement pas, car d'autres processus seront néanmoins basculés par le noyau du système d'exploitation.

Ce n'est donc pas «mal» d'avoir une boucle infinie sur un microprocesseur, mais c'est contre les normes d'expérience utilisateur, du moins pour les applications graphiques. Pour une application console cependant, vous pourriez bien avoir une boucle infinie sans dommage, disons par exemple si vous voulez calculer pi jusqu'à 1 million de chiffres (et enfin mettre le résultat sur la console) ou quelque chose de similaire, car l'utilisateur est normalement ( dans le pire des cas) préparé pour les applications console qui mettent presque une éternité à produire leurs résultats.