De bonnes approches pour implémenter plus d'une fonction critique dans le temps à l'aide d'un microcontrôleur?

Quelle est la philosophie ou l'approche adoptée pour mettre en œuvre des fonctions hautement critiques dans le temps dans les microcontrôleurs, le cas échéant?

Je travaille sur un projet impliquant la sortie d'une forme d'onde carrée précise de fréquence variable. Je l'ai fait en utilisant une minuterie et une fonction d'interruption. Cependant, même pour implémenter cela correctement, j'ai dû calibrer le décalage pour le nombre de cycles d'horloge pris pendant la routine de service d'interruption. J'imagine que cette précision serait perturbée par la présence d'une autre forme d'onde de ce type (par exemple, la fréquence devait être changée en même temps). Avoir un microcontrôleur chacun, pour chaque fonction critique de temps semble inutile.

Prenons un autre exemple, de l'implémentation d'une fonction d'horloge (comme dans hh: mm: ss). Je ne peux pas imaginer que chaque micro-contrôleur / ordinateur de haut niveau possède une puce d'horloge en temps réel dédiée uniquement pour garder une trace de l'heure. Cependant, j'ai du mal à imaginer qu'il soit mesuré avec précision à l'aide du processeur de base, qui est occupé à entretenir une pléthore de fonctions qui arrivent à des intervalles asynchrones entre-temps. J'imagine que le comptage du temps aurait des erreurs de décalage, qui changent en fonction des fonctions en cours d'exécution.

Existe-t-il un processus ou une approche de conception pour contenir ou donner une tolérance à la précision réalisable? Ou est-ce que quelqu'un a des conseils ou des suggestions sur où je pourrais trouver plus d'informations à ce sujet?

Pour produire des ondes carrées précises, utilisez le matériel. La plupart des microcontrôleurs ont des générateurs PWM intégrés qui peuvent le faire. Vous définissez la période et l'heure sur des cycles d'horloge, et le matériel fait le reste. Pour la changer en une nouvelle fréquence, écrivez la nouvelle période dans le registre de période et la moitié de la période dans le registre de cycle de service.

Quant à l'horloge temps réel perdant du temps en raison d'une autre charge du processeur, elle ne fonctionne pas de cette façon, sauf si elle est très mal écrite. Généralement, le matériel serait utilisé pour créer une interruption périodique qui est un multiple de quelques secondes, et le micrologiciel se divise davantage à partir de là. Cela fonctionne quelle que soit l'occupation du processeur, car l'interruption s'exécute à tout moment. Tant que la routine d'interruption prend une petite fraction des cycles globaux, la majeure partie du processeur est toujours appliquée à la tâche de premier plan.

Il existe également des moyens de garder le temps en interrogeant à des intervalles quelque peu inconnus. Vous avez le matériel qui compte, et chaque fois que vous vous mettez à jour l'horloge, vous le mettez à jour en fonction du nombre total de ticks écoulés. Tant que cette routine est exécutée suffisamment souvent pour que le compteur utilisé ne passe pas entre les exécutions, aucun temps n'est perdu.

Le mot-clé ici est "support matériel". Pour tout problème sérieux, vous aurez besoin de matériel de support dans le µC. Le périphérique intégré le plus courant est le circuit de minuterie qui fonctionne de manière relativement précise et sans interférence avec d'autres opérations du processeur.

En s'appuyant sur cela, vous pouvez avoir de nombreuses fonctions exécutées avec un timing à moyen terme aussi précis que la source d'horloge de votre contrôleur.

Mais: comme vous l'avez peut-être déjà expérimenté, en plus de la précision à moyen ou à long terme, il y a aussi toujours une gigue de synchronisation impliquée dans la gestion logicielle des événements matériels (y compris des choses comme le dépassement de la minuterie). Cela est dû à différents états d'exécution possibles au moment où un événement se produit, ce qui entraîne des retards variables jusqu'à ce que la réponse réelle à l'événement puisse se produire.

Par conséquent, la ligne de fond est la suivante: pour tout ce qui a des exigences de gigue à grande vitesse ou presque nulles, le support matériel est essentiel. De nombreux périphériques matériels sont inclus dans la plupart des µC, comme les UART et c, et plus le µC est puissant et coûteux, plus le matériel de support est généralement intégré. Si votre µC ne fournit pas le matériel dont vous avez besoin, vous devrez en effet envisager du matériel externe dédié pour la tâche.

Faites-en autant que vous le pouvez avec le matériel, en particulier pour les fonctions hautement critiques. Tous les microcontrôleurs ont des minuteries / compteurs spécialement créés pour compter et chronométrer les événements.

Mis à part cela, c'est vraiment une question très large. Il n'y a donc pas de bonne réponse.

La seule vraie réponse est l'expérience. Essayez-le, profilez-le, insistez-y, corrigez-le. Vous devez identifier les zones de code à forte utilisation. 20% des logiciels exécutés 90% du temps, signifie que chaque instruction supprimée, améliore les performances.

Une bonne conception a toujours équilibré le matériel, les logiciels et la mémoire. Cela s'applique à tous les microprocesseurs, mais surtout aux microcontrôleurs. Maximisez-en un ou utilisez-le de manière inefficace et vous aurez un mauvais produit. Comme les densités de silicium ont augmenté, de plus en plus de fonctionnalités sont incluses dans le matériel des microcontrôleurs. Mais plus de fonctionnalités signifie plus d'attentes. Doublez la mémoire intégrée et vous ajouterez une fonctionnalité qui l'utilisera.

Tous les ISR ont une surcharge, qui dépend des registres utilisés par l'ISR. Si la latence pour enregistrer l'état de la machine est importante par rapport à la maintenance de l'ISR pour les fonctions hautement critiques, votre conception peut ne pas être évolutive. D'où le consensus général des réponses pour utiliser le matériel.

L'utilisation d'interruptions logicielles peut réduire le gonflement de l'état de la machine ISR.

// Timer0 ISR
Temp = Temp + 1
if (Temp == 150)
    call Inc_Seconds()

Tous les registres pour Inc_Seconds () doivent être poussés, lorsqu'ils ne sont utilisés qu'une fois tous les 150 cycles.

// Timer0 ISR
Temp = Temp + 1
if (Temp == 150)
    _Software_Interrupt
...
// Software_Interrupt ISR
    call Inc_Seconds()

Désormais, la latence n'est atteinte qu'une fois tous les 150 cycles.

Si vous implémentez une horloge en temps réel en hh: mm: ss, est-ce important si elle est à 50 ms. Personne ne détecterait l'erreur. Ce n'est certainement pas une préoccupation opérationnelle en temps réel.

Quant aux événements qui doivent se produire en même temps. Le doivent-ils? S'ils le doivent, la conception matérielle doit s'en occuper. Sinon, un compromis logiciel doit avoir lieu. Si vous ne pouvez pas définir deux bits à la fois, définissez un bit. L'instruction suivante définit l'autre. Précision d'un cycle d'horloge sur les processeurs RISC. Je dirais que c'était assez bon.

Pour la forme d'onde carrée, vous devez utiliser un périphérique PWM qui est PLLed avec votre XTAL en utilisant une sorte de compteur pour savoir quand faire un cycle (pour régler la fréquence peu). Chaque fiche technique vous indiquera comment procéder :)

Pour garder le temps , oui, vous aurez besoin d'un RTC pour le faire de manière précise, sauf si vous optez pour des opcodes assembleur et auteur afin que vous sachiez à la main le calendrier d'exécution exact de chaque instruction dans n'importe quel chemin d'exécution. Cela apportera probablement un nouvel éclairage sur la déclaration éprouvée «goto est considéré comme nuisible».