Pourquoi exécuter du code à partir de la RAM?

Je viens de rencontrer des macros pour que mon compilateur de microcontrôleur force (ou suggère) qu'une fonction soit exécutée à partir de la RAM.

https://siliconlabs.github.io/Gecko_SDK_Doc/efr32mg1/html/group__RAMFUNC.html#gac6abbc7f869eec9fb47e57427587c556

http://processors.wiki.ti.com/index.php/Placing_functions_in_RAM

https://www.iar.com/support/tech-notes/linker/controlling-placement-of-the-section-where-__ramfunc-functions-reside-ewarm-5.x--6.x/

https://community.nxp.com/thread/389099

Dans quels cas est-ce utile? Pourquoi ne serais-je pas toujours exécuté à partir de la RAM si l'avantage est uniquement une vitesse accrue? Cela entraîne-t-il généralement une consommation de courant plus élevée?

En plus de la vitesse et d'autres fonctionnalités que d'autres ont déjà mentionnées, l'exécution de code à partir de la RAM peut être utile dans les chargeurs de démarrage où vous devez reprogrammer le flash de votre micro - vous ne pouvez pas exécuter le code à partir du flash que vous êtes en train d'effacer et reprogrammation.

Je n'ai pas regardé la fiche technique de ce micro. Cependant, il est souvent le cas dans cette situation que la récupération à partir de la RAM est plus rapide que la récupération à partir du flash à partir de laquelle la mémoire du programme est implémentée.

L'avantage du flash est que de grandes quantités peuvent être relativement bon marché. Les fabricants de microcontrôleurs mettent donc parfois beaucoup de mémoire flash sur une puce, puis fournissent un espace RAM plus limité à partir duquel le code peut s'exécuter. Cela permet de copier des routines critiques dans la RAM, puis de les exécuter à partir de là.

Le commutateur du compilateur auquel vous faites référence fonctionne probablement avec l'éditeur de liens et marque la section de flash à copier dans la RAM par le code d'exécution du compilateur qui s'exécute à partir de la réinitialisation. Différentes implémentations varieront selon les détails.

Lorsque vous souhaitez exécuter en RAM car c'est plus rapide, c'est généralement parce que la RAM est de la SRAM sur puce. Il s'agit d'une ressource rare, que vous voudrez probablement pour les données qui nécessitent un accès en lecture / écriture.

Son utilisation pour le code lorsque vous déjà avez le code ROM / flash signifie que vous avez besoin une quantité X de flash et un montant supplémentaire de X de RAM.

Il nécessite également une étape de copie supplémentaire au démarrage ou lorsque vous souhaitez l'exécuter, bien qu'il soit généralement insignifiant.

Traditionnellement, cela est résolu avec un cache d'instructions, mais dans un microcontrôleur, il peut être plus judicieux de conserver le SRAM interne générique, car vous n'utilisez pas de microcontrôleur parce que vous voulez la vitesse d'exécution la plus rapide.

Il y a aussi un problème de fiabilité - le code s'exécutant dans la ROM réelle est difficile à modifier par du code bogué.

En plus de toutes les bonnes réponses:

Pourquoi ne serais-je pas toujours exécuté à partir de la RAM si l'avantage est uniquement une vitesse accrue?

Parce que dans un système embarqué, vous n'avez généralement pas la quantité de RAM requise. Par exemple, un STM32 ayant 32 Ko ou RAM et 512 Ko d'EEPROM. Pour pouvoir exécuter un programme entier en RAM, vous auriez besoin d'une taille de RAM supérieure à l'EEPROM.

D'autres réponses ne semblent pas avoir beaucoup discuté de la consommation d'énergie, ce que vous avez spécifiquement demandé.

La réponse est qu'elle dépend quelque peu du microcontrôleur, mais souvent l'exécution à partir de la RAM peut réduire la consommation d'énergie car elle nécessite moins d'énergie pour lire les instructions de la RAM que de la mémoire flash.

Une utilisation typique consisterait à exécuter une fonction «veille» de faible puissance à partir de la RAM, avec la mémoire flash hors tension. Non seulement la consommation d'énergie est réduite, mais si le microcontrôleur doit se réveiller rapidement (par exemple en réponse à une interruption externe), il n'y a pas de retard pendant la remise sous tension de la mémoire flash.

Certaines pièces, comme certaines de la gamme Atmel SAM, ont une RAM spéciale à très faible puissance qui peut être utilisée à cet effet. Cela permet de charger une petite quantité de code dans la RAM spéciale, tandis que la majeure partie de la RAM disponible et de toutes les autres mémoires est mise hors tension et le microcontrôleur entre en mode veille profonde.

Outre les avantages de vitesse potentiels mentionnés par d'autres, le code RAM est également dynamique et peut être modifié à la volée par un code personnalisé dans le FLASH selon les besoins.

Cela peut être aussi simple que de modifier quelques paramètres ou peut être des routines de gestionnaire entières téléchargées à distance.

L'exécution de code à partir de la RAM est beaucoup plus rapide que son exécution à partir de la mémoire flash. La plupart des processeurs sont fortement optimisés pour un accès RAM le plus rapide possible, et même la mémoire flash la plus rapide n'atteint qu'une fraction de la vitesse de la RAM.

Cependant, gardez à l'esprit que le déplacement du code du flash vers la RAM prend également du temps. Si le code n'est exécuté qu'une seule fois, vous n'avez besoin de le lire qu'une seule fois, et par conséquent, vous perdriez réellement du temps pour le copier en RAM au lieu de l'exécuter directement. Si le code est exécuté occasionnellement (donc le copier dans la RAM augmenterait l'exécution la deuxième fois qu'il est appelé), mais le système est généralement inactif, alors vous exécuteriez ce code plus rapidement en le copiant dans la RAM, mais personne ne s'en soucie, car le système a assez de temps à consacrer.

De telles optimisations ne valent donc la peine que si le code est exécuté fréquemment et que vous l'avez mesuré comme un point d'étouffement du système.

D'un autre côté, la RAM doit conserver activement les données stockées, contrairement à la mémoire flash, de sorte que la consommation électrique totale augmente si la RAM doit rester active. Ceci n'est cependant pertinent que si la RAM n'est pas du tout utilisée du tout, mais la plupart des systèmes modernes utiliseront - d'une manière ou d'une autre - la RAM disponible et donc la maintiendront déjà active.

Il y a deux raisons très courantes d'exécuter du code à partir de la RAM:

1. Certains microprocesseurs ne peuvent pas s'exécuter à partir du flash pendant la programmation du flash - bien que beaucoup puissent le faire tant que le code est dans un bloc différent du flash en cours d'écriture. Les écritures Flash peuvent reprogrammer l'application (cas du chargeur de démarrage), ou lorsque la mémoire flash est utilisée pour stocker des informations de programme non volatiles (configuration, étalonnage, etc.)

2. Sur de nombreux microprocesseurs, la RAM est beaucoup plus rapide que le flash. Pour ces périphériques, de petites routines à vitesse critique peuvent être exécutées à partir de la RAM, bien que la RAM soit généralement beaucoup plus courte que le flash.

Un autre cas d'utilisation pour la sécurité d'exécution RAM uniquement contre les bitflips aléatoires. Nous utilisons ce modèle sur notre petit cubesat car la carte mère de l'ordinateur a un ram ECC qui tolère les bitflips dus au rayonnement. L'ensemble du système d'exploitation est chargé dans ram car un disque virtuel au démarrage s'exécute complètement dans un environnement ECC.

Le flash n'est pas protégé par ECC (cartes micro SD standard standard) mais nous avons d'autres méthodes pour vérifier la corruption (images multiples, sommes de contrôle, etc.)