Si vous écrivez simplement une fonction qui lit le résultat ADC dans une variable, fait des calculs dessus, puis écrit le résultat dans PWM, et si vous utilisez un compilateur décent avec une optimisation activée, les données critiques seront probablementfinir dans un registre que vous le vouliez ou non.Ce n'est vraiment pas si différent de configurer DMA juste pour que vous puissiez récupérer un emplacement mémoire et faire la même chose.

Là où j'utiliserais DMA pour ce genre de chose, c'est si j'allais faire quelque chose comme récupérer plusieurs échantillons ADC par cycle du contrôleur (ce que je fais souvent) - le DMA économise beaucoup par rapport à la surcharge d'unISR pour collecter les données d'un ADC.

Ma question est, puisque je dois mettre le résultat de la conversion dans le processeur pour être traité de toute façon, ne puis-je pas simplement le stocker directement dans les registres du processeur sans impliquer du tout DMA ou SRAM et le processus est immédiat?

Non, ce n'est pas possible dans un Cortex-M4. De plus, vous ne voudriez pas que cela soit possible. Pour clarifier pourquoi: Si vous écrivez votre programme en "non assemblé", alors vous allez utiliser un compilateur. Les compilateurs respectent généralement l'ABI ARM qui leur permettra d'utiliser des registres pour le traitement des données. Ce que vous suggérez entraînera le compilateur et l'ADC à utiliser le même emplacement à des fins différentes en même temps. Votre programme se comportera mal. Vous n'aurez aucun moyen de dire à un compilateur qu'un certain registre est interdit.

Bien sûr, ne pas impliquer le DMA est beaucoup plus lent:

ADC_result -> CPU -> SRAM -> CPU -> enfin traité.

Ce n'est ni tout à fait correct ni incorrect. C'est spécifique à l'application. Une interruption peut charger le résultat ADC du registre de données ADC directement dans un registre CPU si la fonction utilise uniquement ces données localement et est "courte". il est possible que les données ne soient jamais stockées dans SRAM.

Maintenant, que vous utilisiez DMA ou une interruption pour transférer vos données, les interruptions sont certainement plus faciles à comprendre du point de vue du flux de données. En outre, les interruptions vous permettent de répondre échantillon par échantillon, ce qui peut être nécessaire pour votre application. L'inconvénient est que cela vous oblige à absorber les frais généraux liés à l'entrée et à la sortie d'une interruption. Cela peut être important pour votre application ou non.

Si vous devez faire autant de traitement, que ce temps est précieux et que vous ne pouvez pas vous permettre d'opérer sur un échantillon à la fois, DMA peut vous sortir de cette contrainte.DMA vous permet d'amortir les coûts d'entrée / sortie d'interruption sur de nombreux échantillons (en fonction de votre délai).De plus, il existe certains algorithmes mathématiques qui sont beaucoup plus efficaces lorsqu'ils sont exécutés sur des tampons plutôt que échantillon par échantillon lorsqu'ils arrivent.Encore une fois, cela dépendra de votre application.

À moins que vous ne précisiez les exigences de vos applications, il est impossible de dire quelle est la meilleure approche.

Il y a trois événements qui comptent ici:

1. Début de la conversion ADC
2. Fin de la conversion ADC
3. Date limite de mise à jour du cycle de service PWM

Votre début de conversion doit être déclenché par le matériel. Il semble que votre PWM le fasse déjà.

Vous devez effectuer le traitement entre la fin de la conversion et la date limite. La meilleure façon de procéder est que la fin de la conversion déclenche une interruption du processeur. Votre ADC devrait pouvoir le faire. Dans l'ISR, le CPU peut effectuer le traitement et mettre à jour le cycle de service.

Si vous écrivez du code C, vous n'avez pas à vous soucier de la SRAM et des registres. Lisez simplement le résultat ADC dans une variable entière. Voici un pseudo-code:

  void ADC_EOC_ISR (void)
{
    uint16_t adc_result = * ADC_RESULT_REG_ADDR;
    uint16_t new_duty_cycle_value = compute_new_duty_cycle (adc_result);
    * PWM_DUTY_CYCLE_REG = new_duty_cycle_value;
}

uint16_t compute_new_duty_cycle (commentaires uint16_t)
{
    ... // Traitez ici
}
 

La méthode exacte pour accéder au résultat ADC et aux registres de cycle d'utilisation PWM dépend du MCU que vous utilisez et des fichiers d'en-tête / pilotes fournis.

L'utilisation de DMA transforme votre problème hard realtime (traiter l'échantillon avant que l'échantillon suivant ne soit écrasé) en un problème soft realtime (traiter les échantillons plus rapidement qu'ils ne s'accumulent dans le tamponet avant que le tampon ne soit plein).

Les problèmes de temps réel difficiles sont ennuyeux à gérer, vous avez généralement besoin d'une source d'interruption synchrone avec l'ADC (soit une interruption "conversion terminée" de l'ADC, soit une interruption de minuterie périodique qui démarre également la conversion ADC), ce qui signifie quevotre CPU passera beaucoup de temps à entrer et sortir des gestionnaires d'interruptions.

Cela peut être une conception valide si l'horloge ADC est suffisamment lente pour que le gestionnaire d'interruption se termine avant l'arrivée de l'interruption suivante, et c'est l'interruption de priorité la plus élevée (donc les autres gestionnaires d'interruption n'arrêtent pas le traitement des données), mais c'est uncompromis d'ingénierie: la conception basée sur DMA est plus simple, donc à moins que le retard et la gigue aient besoin d'être étroitement contrôlés, c'est probablement le meilleur choix.

Je suis presque sûr que vous n'avez pas besoin de faire ce que vous voulez (et à la place de consommer le résultat ADC directement dans l'interruption comme le suggère @AdamHaun), mais une astuce qui fonctionne généralement est d'utiliser les registres FPU .Vous devrez vérifier la documentation de votre compilateur, mais avec la plupart des compilateurs que j'ai vus, si vous n'utilisez aucun calcul flottant dans votre code, le compilateur ne touchera pas les registres FPU (D0-D15), et vous pouvez utiliserles vous-même comme stockage temporaire rapide.