Comment déterminez-vous la quantité de mémoire flash / RAM dont vous avez besoin pour un microcontrôleur?

24

Supposons que vous démarrez un projet intégré avec des fonctionnalités connues. Lorsque vous sélectionnez un microcontrôleur, comment sélectionnez-vous la quantité de RAM dont vous avez besoin?

Utilisez-vous une carte de développeur et codez-vous d'abord votre projet, puis voyez la quantité de mémoire que vous avez utilisée, puis sélectionnez un microcontrôleur approprié qui correspond à cette mémoire?

Choisissez-vous simplement un microcontrôleur costaud pour un prototype, puis réduisez-le après avoir un produit fonctionnel?

Choisissez-vous simplement quelque chose dont vous êtes sûr qu'il suffira et si vous manquez d'espace, passez simplement à une densité de mémoire plus élevée sinon, vous gardez simplement le microcontrôleur existant?

Qu'est-ce qui est considéré comme une bonne pratique?

— efox29
source

Il me semble qu'il devrait être possible, d'un point de vue théorique de l'information, d'estimer les besoins en RAM à un ordre de grandeur près (style de raisonnement dimensionnel), à partir de la spécification de la tâche. Hmmm ...

— Lyndon White

Si vous utilisez des bibliothèques, vous pouvez rechercher leur empreinte mémoire. Avec votre propre code, vous devez aller avec l'expérience. Comparez le nouveau projet aux anciens et déterminez si vous vous attendez à ce qu'il soit plus grand ou plus petit.

— jwsc

20

Personnellement, pour les projets de loisirs, j'ai tendance à utiliser le microcontrôleur le plus puissant de la famille avec la bonne empreinte. Je développe ensuite le PCB, écris du code et réalise un prototype.

Cela a l'avantage que je connais assez bien le petit nombre de microcontrôleurs, donc je peux rapidement prototyper sans avoir à lire toute une fiche technique. J'ai également des tableaux de répartition et des modèles de code pour eux.

Si cela fonctionne et que j'en fais plus d'une poignée, j'achète le microcontrôleur le moins cher qui a les bons périphériques et suffisamment de mémoire pour tout ce que j'ai codé précédemment. Cela peut être gênant si les registres internes changent (se produit sur le PIC) ou si l'un ou l'autre microcontrôleur a des périphériques supplémentaires qui doivent être désactivés pour faire fonctionner le code.

Cependant, à des fins de production, cela vous permettrait de raser une bonne quantité de chaque unité.

— David
source

Pour mes projets personnels, j'ai tendance à utiliser une approche similaire. Cette même méthode se glisse aussi dans le bureau avec moi. Ce n'est pas faux, cela fonctionne, mais existe-t-il de meilleures façons, etc. Appréciez l'entrée!

— efox29

Il y aura certainement de meilleures façons dans un "vrai" environnement, attendons d'autres réponses!

— David

Soit. Développer dans un grand bac à sable et couper plus tard. Le temps que vous économiserez couvrira plus que les 4 $ supplémentaires que vous dépensez par microcontrôleur pour développer. Cela fonctionne pour plus que des trucs de passe-temps - et en fait, c'est encore plus important. Imaginez 12 personnes attendant un passage à un contrôleur plus grand au lieu d'un seul !!

— Scott Seidman

13

Bien sûr, pour un seul prototype fait maison, il peut être une bonne recommandation de commencer par le plus puissant de tous les micros compatibles et de le réduire ensuite.

Cependant, si vous voulez gagner un devis, vous devez indiquer à votre client un prix avant d'avoir l'argent pour mettre en œuvre quoi que ce soit.

Par conséquent, la bonne pratique consiste à noter une sorte de spécification avant de commencer la programmation. Vous savez ce que vous voulez faire et vous devez noter comment vous allez le faire.

Ce «comment» comprend également la réflexion sur la conception d'un logiciel, la réponse à des questions telles que:

Avez-vous besoin d'un système d'exploitation? Laquelle? De quelles ressources a-t-elle besoin?
Voulez-vous avoir une architecture en couches? Cela nécessite des interfaces, qui peuvent consommer de la RAM
Quelles bibliothèques sont déjà disponibles et utiles / nécessaires pour votre objectif, et de combien de mémoire ont-elles besoin (une bonne documentation de bibliothèque répond à cela sur la base d'au moins une génération de référence)?
Quelles structures et variables devez-vous implémenter pour vos propres pilotes et votre application?

La somme de toutes ces valeurs vous donne une estimation approximative. Jusqu'où vous pouvez faire confiance, cela dépend du niveau de détail de votre analyse, et cela dépend de votre expérience :-)
Ajouter une marge d'au moins 30..50% de votre estimation est sûrement une bonne idée.

Une fois que votre produit est terminé et que vous avez environ 80 à 90% de RAM utilisée, vous pouvez être sûr que votre sélection était correcte, du moins en ce qui concerne la RAM.

— micro
source

2

Re: "80..90% de RAM utilisée". La pratique standard consiste à garantir que vous n'utilisez qu'une utilisation maximale de 50% dans le processeur et la mémoire pour pouvoir prendre en charge les futures mises à niveau et corrections de bogues.

— Dunk

1

@Dunk: dépend de l'entreprise. Dans le secteur automobile, 80% de toutes les ressources (CPU, RAM, Flash) de SOP sont communément acceptées. Dans, par exemple, l'électronique grand public bon marché, cela peut être encore plus: quelle est la probabilité d'avoir une mise à niveau dans un système avec une durée de vie de seulement 2-3 ans?

— micro

@Dunk: Je peux me tromper, mais il semble que vous soyez habitué aux logiciels de bureau avec une mémoire dynamique et toutes les incertitudes qui vont avec. La grande majorité des applications intégrées allouent tout statiquement. Aucune fuite de mémoire garantie. Ensuite, vous pouvez utiliser exactement 100% et être bien pour toujours tant que vous ne le modifiez pas. Bien sûr, cela ne fonctionne que si vous avez une pile distincte de votre RAM de travail ou si vous savez exactement comment la pile se comportera à tout moment. C'est une bonne idée de laisser un peu d'espace pour cela, mais 10-20% est assez suffisant pour ce que j'ai fait.

— AaronD

Le plus gros problème dans les logiciels intégrés est les pointeurs escrocs, les dépassements de tampon, la division par zéro et des choses comme ça. Certains MCU peuvent lever des exceptions dans le matériel, semblables à des interruptions, mais tout ce que j'ai utilisé continuera joyeusement comme si de rien n'était. Il y aura un résultat quelconque, mais ce n'est probablement pas ce que vous attendiez, et vous devrez donc vérifier cela. Certaines choses, comme le dépassement / dépassement arithmétique, sont faciles à vérifier et à corriger immédiatement; d'autres choses, comme les pointeurs voyous, peuvent passer complètement inaperçues jusqu'à ce qu'une fonction qui a fonctionné pendant des années décide de sauter.

— AaronD

3

Que vous souhaitiez viser un objectif de 80% ou un objectif de 50% dépendra de votre client. Avec une spécification fixe et seulement des corrections de bugs nécessaires, 80% est très bien. Spécifications peu fiables, fluage des fonctionnalités attendues et une marge suffisamment grande pour vous permettre de payer le supplément pour plus de marge. Une fois, nous avons fini par acheter 2x autant de micro-contrôleurs que nous avions besoin et avons sélectionné ceux qui overclockeraient suffisamment pour nous donner les performances dont nous avions besoin, ce qui était beaucoup moins cher qu'une nouvelle conception de PCB pour une puce plus puissante.

— Mark Booth

3

Si seulement il était possible de coder d'abord votre système embarqué puis de construire le matériel. Cela faciliterait la vie de chacun. Malheureusement, cela signifie également que vos délais sont dépassés. En règle générale, le matériel doit être conçu bien avant la fin du logiciel, car les pièces matérielles ont souvent de longs délais.

Ainsi, les développeurs de logiciels embarqués devront généralement estimer les besoins en mémoire et en CPU de leur programme. Votre première étape devrait être d'essayer de convaincre les gars du matériel de vous donner le microcontrôleur / CPU le plus puissant avec le plus de RAM possible. Cela fonctionne rarement parce qu'ils ont leurs propres objectifs, mais de temps en temps, vous avez de la chance.

Si cela ne fonctionne pas, la prochaine chose à faire est de concevoir un logiciel de haut niveau et de décomposer les modules en fonctionnalités. Vous devez ensuite estimer les lignes de code pour chaque fonction pour chaque module du système. Vous pouvez ensuite utiliser une formule pour convertir des lignes de code en une estimation approximative de la mémoire de code. Vous enquêteriez également sur les besoins en mémoire inhabituels (comme les grands tableaux) et ajouteriez une estimation pour y répondre. Ajoutez ensuite un pourcentage en plus de ce total pour couvrir tout ce que vous avez manqué. Doublez ensuite cela afin de répondre à l'exigence d'utilisation typique de 50%.

Oui, cela prend du temps. Oui, il est nécessaire de parcourir tous les cerceaux car le changement de matériel est vraiment difficile après sa construction.

— Tremper
source

Où peut-on trouver la formule pour convertir des lignes de code en mémoire de code?

— EasyOhm

Celui-ci dépend de la langue et du compilateur que vous utilisez. Si vous utilisez Assembler, une ligne équivaut à peu près à un mot de mémoire (quelle que soit la taille de mot de votre puce). Si vous utilisez C, cela peut prendre environ 3 à 5 mots par ligne et si vous utilisez C ++ ou quelque chose de plus complexe, cela peut être beaucoup plus. La meilleure chose à faire est de compiler quelques programmes écrits dans ce langage et de comparer les lignes de code à la mémoire de code pour obtenir une moyenne.

— Dakkaron

2

Généralement, les fournisseurs de microcontrôleurs mettent une gamme de mémoire dans leurs appareils qui convient aux applications typiques. Donc, si vous n'avez besoin que de quelques broches d'E / S et d'un SPI dans un périphérique à faible encombrement, il est peu probable que vous trouviez quoi que ce soit livré avec 500 Ko de Flash et 64 Ko de RAM. Avec des appareils plus grands, qui sont plus proches des packages SoC, même les plus petits sont presque certainement assez gros, à moins que vous ne prévoyiez de procéder à des calculs sérieux tels que le traitement d'image.

Dans un environnement professionnel, la clé pour choisir le bon microcontrôleur est d'utiliser des données historiques. Vous aurez un enregistrement des autres projets que vous avez développés et vous saurez quelle mémoire et autres ressources de silicium sont nécessaires pour implémenter chaque fonctionnalité. Vous saurez ce que le produit est censé faire et vous aurez donc une bonne liste de fonctionnalités et pourrez calculer rapidement et avec précision les ressources que le microcontrôleur devra fournir. Essayer de deviner les besoins en ressources à partir d'une spécification de conception initiale (développée au début du projet lorsque le moins d'informations sur le système est disponible) n'est pas fiable dans le meilleur des cas et seuls des ingénieurs très expérimentés, qui ont construit une base de données historiques dans leurs propres têtes, aura tout type de succès dans l'utilisation de cette méthode.

De nombreuses entreprises ont adopté une approche «agile» à la fois des logiciels et de la conception électronique, ce qui implique de créer une «bibliothèque» de petites cartes fonctionnelles (par exemple, des cartes RS-485, des cartes ADC, etc.) ainsi que des cartes de plate-forme génériques qui hébergent les microcontrôleurs. , de manière similaire à l'utilisation d'un kit de développement et de plug-ins. Un produit peut ensuite être prototypé rapidement (en quelques heures) en sélectionnant et en connectant le jeu de cartes requis pour les fonctionnalités. Le logiciel est également assemblé à partir de modules de bibliothèque et peut être porté et testé rapidement. Une fois que la taille de la partie spécifique au matériel du code est connue, il suffit généralement de sélectionner la plus petite partie qui contiendra cela. L'exception étant celle mentionnée ci-dessus où la fonctionnalité de l'appareil implique le big data ou des algorithmes très complexes. Cette méthode fournit un

(Un autre avantage de l'approche Agile est qu'elle permet le développement logiciel et électronique en parallèle, la conception elctronics étant un exercice d'intégration du jeu de cartes de fonctionnalités et de la réalisation de la compatibilité électromagnétique et d'autres tâches difficiles en même temps que le Un logiciel d'application est en cours de développement sur les assemblages protoype. Un certain portage et intégration sont encore nécessaires, mais cela se fait lorsque les logiciels et l'électronique sont disponibles.)

— Tarte au chien maléfique
source