Exécuter des instructions à partir de la RAM dans un microcontrôleur convivial pour les amateurs

Un de mes projets gagnerait grandement à pouvoir exécuter un programme qui n'est pas stocké dans le microcontrôleur (mais qui est plutôt stocké sur une carte SD).

Donc, je cherche un appareil qui me permettra de charger le code de la carte SD dans la RAM puis d'exécuter le code depuis la RAM. Actuellement, je n'ai que le programmeur fourni avec le PicKit2, donc je préfère rester avec les PIC.

Quelqu'un sait-il lesquels, le cas échéant, les PIC peuvent le faire? Si aucun PIC n'est capable de cela, alors quels sont les différents micro-contrôleurs qui fonctionneraient pour cela? De préférence ceux qui sont disponibles dans un package compatible avec la maquette.

Il y a quelques PIC qui vous permettent d'ajouter de la mémoire de programme externe. Je n'ai jamais fait cela mais les notes d'application AN869 et AN778 ont plus d'informations sur la façon d'implémenter la mémoire externe.

Une autre option à considérer est d'utiliser un langage interprété pour vos programmes stockés sur la carte SD. De cette façon, le processeur n'exécute pas le code machine lu sur la carte, il le traite simplement comme des données.

Cette approche vous donne de la flexibilité au détriment de la vitesse.

Il y a beaucoup d'options à choisir: Enquête auprès des interprètes / compilateurs de haut niveau pour les microcontrôleurs

Comme cela a déjà été dit, les PIC (autres que le PIC32) ne peuvent pas le faire. Vous devrez probablement aller vers les plus gros processeurs de toute famille ou vers un processeur avec un bus de mémoire externe car la plupart des microcontrôleurs ont des ressources RAM très limitées.

Les processeurs MSP430 peuvent exécuter du code à partir de leur espace RAM, mais vous aurez besoin de quelque chose comme le F5438 avec 16 Ko d'espace RAM - exécuter du code en 128 octets n'est pas vraiment une option!

Si un processeur possède un bus externe, vous pouvez mettre de la RAM dans l'espace de code. Vous devrez peut-être ajouter une logique supplémentaire pour mapper la RAM en deux régions de mémoire si l'architecture du processeur ne permet pas d'écrire des données dans la mémoire d'exécution.

J'ai exécuté du code à partir de la RAM dans un système basé sur 8051, mais cela signifiait que la RAM devait être mappée dans l'espace mémoire EXTERNE pour la programmation, puis de nouveau dans l'espace CODE pour l'exécution. Le programme chargeur / moniteur a géré la commutation et le chargement des banques de mémoire. Veuillez ne pas demander le code - je l'ai fait il y a environ 30 ans et il est perdu depuis longtemps (et écrit en PL / M-51)

Aucun PIC bas et moyen ne peut s'exécuter à partir de la RAM en raison de son architecture de mémoire.

Tout processeur ARM doit s'exécuter à partir de la RAM. Bien qu'ils aient tendance à être dans des packages smd, il existe un certain nombre de modules de taille «DIP» sur lesquels le microcontrôleur est déjà chargé. Jetez un œil au mbed ou au LPCXpresso par exemple. Ces deux versions sont fournies avec un chargeur de démarrage ou, dans le cas du LPCXpresso, une interface de débogage avec des compilateurs gratuits.

Si vous préférez rester avec de simples micros 8 bits, envisagez peut-être quelque chose de la gamme freescale HCS08. Ceux-ci peuvent s'exécuter à partir de la RAM et une version limitée du code du compilateur ID et C codewarrior est disponible gratuitement.

Je suis assez sûr que le MPS430 devrait également être capable de le faire, mais je ne l'ai jamais fait moi-même.

L'hélice charge son programme à partir d'un stockage externe.

Je me souviens avoir lu un chargeur de démarrage pour AVR qui re-flasherait la puce avec un fichier .hex (vraisemblablement) à partir d'une carte SD. Je ne trouve pas la source d'origine, mais cette recherche Google révèle quelques hits intéressants. Oui, je sais que c'est AVR et non PIC, mais vous pourriez trouver cela utile si la chose PIC ne fonctionne pas.

Comme d'autres affiches l'ont noté, vous ne pouvez pas exécuter à partir de la RAM sur un PIC 8 ou 16 bits, car ils utilisent une architecture Harvard (code séparé et espaces de données). Qu'il soit pratique ou non de charger un programme sur une carte SD et de le flasher dans la mémoire de code dépend de la fréquence à laquelle vous allez le faire.

Si vous essayez de créer un environnement dynamique comme un système d'exploitation qui superpose constamment des programmes, alors non. Mais dans mon cas, j'ai un programme qui charge les pilotes selon les besoins sur une carte SD de 2 Go. Le PIC24FJ256GB110 a un minimum de 10 000 cycles d'effacement / écriture. Même si cela était fait cinq fois par jour, le flash durerait au moins 5 ans et demi.

(Remarque: le chiffre de 10 000 est un minimum. L'endurance typique des cycles d'effacement / écriture peut être cinq fois supérieure - donc si vous faites du développement, vous pouvez probablement re-flasher un processeur 140 fois par jour - toutes les 3 1/2 minutes pendant huit heures - et cela pourrait encore durer un an.)

À mon école, nous avons utilisé des processeurs HC11 ou HC12 avec RAM externe pour charger et exécuter des programmes sur ... mais j'ai oublié le nom des cartes / kits :( Dans tous les cas, les microcontrôleurs Freescale HC (S) traitent la RAM et la ROM de manière identique , afin que vous puissiez charger du code dans la RAM et l'exécuter.

En prenant une file d'attente blalor, la meilleure solution pourrait être d'ajouter simplement un bouton sur votre carte qui peut reflasher le PIC à partir des données stockées sur une carte SD que vous insérez avec un chargeur de démarrage. Je ne peux pas imaginer ce qui ne serait pas le genre de code ne conviendrait pas sur les plus grands PIC; si vous avez des données statiques (graphiques, texte, son), conservez-les sur un stockage externe.

Vous ne pouvez probablement pas allouer de RAM, mais pour votre application, vous pourriez avoir un petit chargeur en flash qui peut ensuite lire les données de la carte SD dans le reste du flash. J'ai utilisé cette approche avec une puce flash contrôlée par SPI pour permettre au firmware d'être chargé à partir d'une liaison sans fil, puis installé une fois qu'il a été reçu complètement; Je ne peux penser à aucune raison particulière pour laquelle cela ne fonctionnerait pas avec une carte SD, bien qu'un chargeur de démarrage compatible SD puisse prendre de la place.

Un bon nombre de microcontrôleurs vous permettront de faire cela, cela ne ressemble pas à la photo. ce que vous voudriez faire, c'est d'avoir un chargeur de démarrage qui utilise spi pour lire à partir de la carte sd, copiez le programme, qui veut probablement être un nom de fichier connu ou codé en dur, probablement dans le répertoire racine, analysez ce fichier dans ram puis branchez sur le programme en bélier. Les contrôleurs basés sur ARM vous permettront certainement de faire quelque chose comme ça.

Une alternative serait d'avoir le chargeur de démarrage lire la carte sd sur spi et au lieu de copier sur ram et de graver sur une partie du flash. Vous voulez probablement avoir un bouton si vous appuyez sur le bouton lors de la mise sous tension ou de la réinitialisation, puis chargez le nouveau programme à partir de la carte SD, sinon si la signature ou la somme de contrôle semble bonne sur cette partie chargeable du flash, puis sur la branche de démarrage de cette partie du flash. Ou peut-être que si la carte SD est présente, chargez-la, sinon branchez-vous sur la partie chargeable du flash. Peut utiliser cette méthode avec les bras et les avr, peut-être même avec des images, mais mon expérience avec les images est datée. msp430 Je suppose aussi. Fondamentalement, si vous pouvez reprogrammer des parties du flash à partir desquelles vous exécutez, à partir du processeur du microcontrôleur lui-même,