J'apprends les systèmes embarqués sur le processeur ARM9 (SAM9G20). Je suis plus familier avec la programmation procédurale à usage général. Ainsi, ce que je fais, c'est parcourir la fiche technique et apprendre ce que registres qu'il existe et comment les manipuler.
Ma question est la suivante: comment savoir quand l'ordinateur est réinitialisé? Je sais qu'il existe un contrôleur de réinitialisation qui gère les réinitialisations. Un registre appelé registre d'état ( RSTC_SR ) stocke la source de la réinitialisation. Dois-je continuer à lire périodiquement ce registre?
Ma solution est de stocker le nombre de réinitialisations dans le FRAM (ou de commencer par le mettre à 0), une fois qu'une réinitialisation se produit, je compare cette variable avec la valeur du registre dans ma fonction principale. Si la valeur du registre est plus élevée, il est évidemment réinitialisé. Cependant, je suis sûr qu'il existe un moyen plus optimisé (peut-être en utilisant des interruptions). Ou est-ce que c'est comme ça que ça se fait habituellement?
4 Réponses :
Une solution simple consiste à exploiter la structure de votre code. De nombreuses bases de code pour embarqué prennent cette forme:
int main(void)
{
// setup stuff here
while (1)
{
// handle stuff here
}
return 0;
}
Vous pouvez exploiter le fait que le code ci-dessus while (1) n'est exécuté qu'une seule fois au démarrage. Vous pouvez y incrémenter un compteur et le sauvegarder dans un stockage non volatile. Cela vous dirait combien de fois le microcontrôleur s'est réinitialisé.
Un autre exemple est sur Arduino, où le code est structuré de telle sorte qu'une fonction appelée setup () est appelée une fois, et une fonction appelée loop () est appelée en continu. Avec cette structure, vous pouvez incrémenter la variable dans la fonction setup () pour obtenir le même effet.
Que faire s'il y a une réinitialisation entre l'ISR de réinitialisation et le pointeur où main est appelé? Si des réinitialisations se produisent, c'est un endroit très probable pour eux.
Vous n'avez pas besoin de vérifier périodiquement, car chaque fois que la machine est réinitialisée, votre programme redémarrera depuis le début.
Ajoutez simplement des vérifications au code de démarrage, c'est-à-dire au début de main () , si nécessaire. Si vous voulez comprendre des choses comme la fréquence de la réinitialisation, alors c'est plus difficile car généralement (pas d'expérience avec les SAM, je suis un type STM32) les minuteries embarquées, etc., seront également réinitialisées. . Le mieux serait une sorte d'horloge indépendante du monde réel, comme un RTC dont vous pouvez interroger et enregistrer la valeur. Veuillez cependant considérer si vous en avez vraiment besoin.
peut-être même avant main () - beaucoup de code et éventuellement des interruptions peuvent s'exécuter avant main, ce qui peut lui-même forcer une réinitialisation. Idéalement avant toute interruption ou tout code susceptible de provoquer une réinitialisation ou de rester bloqué et de forcer un chien de garde.
@Clifford Je supposais en quelque sorte une plate-forme sensible qui ne sort pas de la réinitialisation avec des interruptions particulières activées. Quels micros font ça?
Aucun. Ce n'est pas ce que j'ai suggéré. Le code de démarrage qui s'exécute avant main effectue l'initialisation standard de la bibliothèque, y compris les E / S et la synchronisation qui peuvent utiliser des interruptions.
Une façon de faire cela est d'exécuter le code en mode débogage (si vous avez un débogueur pour le SAM). Après une réinitialisation, le compteur de programme (PC) pointe vers l'adresse de début de votre code.
C'est une sorte de réponse au titre de la question, mais le corps de la question est un peu plus détaillé, et ce n'est pas une réponse à cela, je pense.
Vous pourriez être vrai, mais pour moi, il n'est pas clair si l'objectif est de consigner l'état de réinitialisation ou simplement de `` voir '' si une réinitialisation se produit. Et pour la seconde, je pense que ma réponse est un moyen facile d'atteindre cet objectif.
Chaque fois que votre processeur démarre, il est par définition sorti de réinitialisation. Le registre d'état de réinitialisation indique la source ou la raison de la réinitialisation, comme la mise sous tension, la minuterie de surveillance, la baisse de tension, les instructions du logiciel, la broche de réinitialisation, etc.
Il ne s'agit pas de savoir quand votre processeur s'est réinitialisé - c'est implicite par le fait que votre code a redémarré. Il s'agit plutôt de connaître la cause de la réinitialisation.
Vous n'avez pas du tout besoin de surveiller ou de lire l'état de réinitialisation si votre application n'en a pas besoin, mais dans certaines applications, c'est peut-être un diagnostic utile, par exemple pour maintenir un décompte des diverses causes de réinitialisation, car cela peut indiquer le stabilité de votre logiciel système, de son alimentation ou du comportement des opérateurs. Idéalement, vous voudriez enregistrer la cause avec un horodatage en supposant que vous disposez d'une source RTC appropriée suffisamment tôt dans votre démarrage. Le moment des réinitialisations est souvent un diagnostic utile où le simple fait de les compter peut ne pas être.
Tout décompte de la cause de la réinitialisation doit avoir lieu au début du démarrage de votre code avant que les interruptions ne soient activées (car une interruption peut elle-même provoquer une réinitialisation). Cela peut vous obliger à implémenter les compteurs dans le code de démarrage avant que main () ne soit appelé dans les cas où le code de démarrage pourrait activer des interruptions - pour la prise en charge de stdio ou du système de fichiers par exemple.
Vous sauriez que le système a été réinitialisé lorsque le code de démarrage de votre système est appelé.
Je lis dans la fiche technique (13.4.3) qu'il est possible de gérer ISR en fonction de certains types de réinitialisations.
Vous devez étudier ce qu'est une réinitialisation, tout d'abord, pour que tout cela ait un sens. Lors de la réinitialisation, tout le matériel, tous les registres et le compteur de programme sont restaurés pour s'exécuter à partir de la fonction programmée au vecteur de réinitialisation (l'adresse 32 bits écrite à l'adresse 0 d'un ARM). C'est la définition d'une réinitialisation.
@SirJoBlack: 13.4.3 se réfère uniquement à la broche NRST qui peut être configurée comme une broche de réinitialisation à une broche d'interruption - si elle est configurée comme une interruption, ce n'est pas vraiment une réinitialisation - bien que le gestionnaire d'interruption puisse émettre une réinitialisation. Vous pouvez ensuite l'utiliser pour compter ou enregistrer la broche de réinitialisation affirmée, mais il existe d'autres sources de réinitialisation qui ne seraient pas comptées. Je ne suis donc pas sûr que cela aide.
Le SAM9G20 est classé par Atmel / Microchip comme un MPU plutôt que comme un "micro-contrôleur" . Il a une MMU, et exécute généralement sa ROM de démarrage, puis un bootstrap, puis U-Boot, puis Linux après une réinitialisation.