Habituellement, la décision concernant le microcontrôleur est un équilibre entre:

1. Caractéristiques spéciales (faible consommation d'énergie, par exemple)
2. Temps de développement.
3. Coût des marchandises en production.

Si le temps de développement court a plus de priorité que le coût des marchandises, optez pour le contrôleur plus musclé. Vous pouvez effectuer une optimisation des coûts plus tard dans le cadre d'une étape distincte. L'optimisation prématurée des coûts [sic] gâche souvent les projets.

Si vous êtes déjà dans la phase d'optimisation des coûts, vous partez d'un produit fonctionnel. La première version non optimisée sert de prototype pour la version optimisée. La première version élimine les exigences.

En relation: Comment choisir une plate-forme MCU?

Avant de commencer à travailler sur le projet, comment savoir quelle taille et quelle puissance de microcontrôleur est nécessaire pour le projet?

Vous ne pouvez pas savoir. Et c'est un gros problème. Si vous choisissez un microcontrôleur trop petit, vous risquez de manquer de ressources (mémoire / broches / registres / autres fonctionnalités) et ces ressources peuvent être difficiles à estimer avec précision jusqu'à ce qu'il soit trop tard. Mais si vous choisissez un microcontrôleur trop volumineux, vous payez pour des ressources que vous n'utilisez pas, ce qui augmente le coût du système.

Vous pouvez parfois faire une estimation éclairée de la quantité l'application aura besoin ... si vous faisiez des calculs FFT par exemple, vous pouvez calculer la quantité exacte de mémoire dont les échantillons auront besoin. Mais il est plus difficile de déterminer de manière fiable la quantité d'espace de code objet dont le logiciel aura besoin, jusqu'à ce qu'il ait été écrit.

Une bonne protection contre le manque de mémoire de code est de sélectionner une famille de microcontrôleurs qui est évolutif sur plusieurs prix / performances différents. C'est un gros argument de vente des ARM , Microchip PIC , Atmel AVR et autres micro évolutifs. Au fur et à mesure que vous développez votre logiciel, vous pouvez passer d'un système de développement plus grand à un système cible plus petit, ce qui réduit le coût final du produit final.

Évolutif signifie que tous les microcontrôleurs de cette famille ont (principalement) le même jeu d'instructions et (principalement) les mêmes registres. Ainsi, un logiciel écrit pour l'un fonctionnera sur un autre de la même famille. (Le code PIC Microchip ne fonctionnera pas sur un ARM, mais si vous apprenez le PIC14, il est facile de passer au PIC12 ou au PIC16.)

Si vous ne construisez qu'un prototype unique , plutôt qu'une gamme complète de produits de production, votre meilleure option est de vous en tenir à un système de développement un peu plus grand que ce dont vous pensez avoir besoin, mais qui a de la place pour se développer.

Un facteur important est la taille de vos variables les plus souvent utilisées. Si vous utilisez principalement des variables 8 bits et que vous n'avez besoin que d'accéder à des ports 8 bits, vous pouvez probablement vous en tirer avec un MCU 8 bits.

Cependant, si vous avez beaucoup de 16- variables de bits, et même juste quelques longs 32 bits, alors vous allez devoir regarder un MCU 16 bits (ou même 32 bits) car accéder aux variables 16 bits avec un MCU 8 bits prend beaucoup de temps de code.

Et si vous prévoyez d'utiliser des variables à virgule flottante, je suggère fortement un MCU 16 bits ou 32 bits.

Même si vous n'avez pas le Il est temps d'écrire une grande partie du code que vous devrez utiliser, je suggère d'en écrire une partie à l'avance et de le compiler pour les microcontrôleurs que vous utilisez. La plupart des fabricants de microcontrôleurs ont des versions gratuites de leurs compilateurs, peut-être limitées par la taille du fichier de sortie, ou en limitant la quantité d'optimisation.

Idéalement, avant de concevoir une nouvelle carte, vous effectuez un projet de validation de principe en utilisant soit une carte de développement (ou une carte disponible dans le commerce), soit une carte restante de l'un de vos projets précédents.

Habituellement, les MPU 32 bits sont souvent plus rapides en raison d'une fréquence plus élevée, mais aussi en raison de leurs capacités ou de certaines «astuces» qu'ils peuvent faire.

Comme l'a dit @tcrosley, un MCU 32 bits peut en ajouter deux Entiers 32 bits en une seule fois, tandis qu'un MCU 8 bits devra atteindre cet octet par octet. Les nombres à virgule flottante nécessitent au moins 16 bits et leurs calculs sont plus complexes, ce qui signifie beaucoup de travail pour le MCU 8 bits. Un MCU 32 bits peut faire le calcul matériel, donc encore une fois, en une seule fois. Une des astuces peut être de faire quatre ajouts de variables 8 bits à la fois. Chargez quatre valeurs 8 bits dans le registre, et ajoutez des valeurs 8 bits à chacune d'elles.

Mais ce n'est pas tout.
Regardez également attentivement la périphérie matérielle, qui n'est pas forcément plus puissant sur les MCU 32 bits!
Une expérience:

Dans mon université, nous avons construit un oscilloscope composé d'un PIC18F2550 (8 bits, 10 bits ADC, USB), un ampli-op pour réaliser plusieurs plages de tension et quelques bouchons de résistances &. Il s'agissait d'un oscilloscope très simple et très bon marché pour les écoles avec un taux d'échantillonnage de ... Je suppose qu'il était d'environ 50 kHz. Le transfert a été effectué via CDC pour une grande compabilité.

Lorsque microchip a proposé ses microcontrôleurs PIC32, cela semblait prometteur. Le prix était presque le même, 120MInstructions / s au lieu de 12, USB haute vitesse au lieu de pleine vitesse. Le dernier point était intéressant car le débit était le facteur limitant du PIC18, et les benchmarks de micropuces ont montré un débit USB remarquablement plus élevé.

Enfin, il s'est avéré que le PIC18 faisait tout le travail USB dans le matériel, tandis que le PI32 semble faire plus dans le logiciel - dès que le PIC32 a plus de travail à faire, le débit a chuté. Par conséquent, nous n'avons pas pu réaliser un oscilloscope plus rapide avec PIC32.

(Je n'étais pas impliqué dans cela - donc je ne connais pas les détails)

Eh bien, avant de vraiment commencer à coder, vous devez d'abord faire des recherches sur ce dont vous aurez besoin pour réaliser un projet. Cela fait partie du travail.

Si vous êtes déjà familier avec les microcontrôleurs, faites des recherches pour savoir si un uC 8 bits est suffisant ou non. Cela dépend de la complexité, si elle sera étendue ou non (comme d'un LCD monochrome à LCD couleur), est-ce à long terme, faut-il une faible consommation d'énergie, une faible utilisation de la mémoire, etc. / p>

J'ai dû faire des recherches pour savoir quel ARM uC je devais choisir et aussi quel compilateur (basé sur le prix et la popularité). Dans ma situation, il était important de vérifier la disponibilité des périphériques.

Un simple oui ou non n'est donc pas possible. Alors, bienvenue dans le monde de l'ingénierie :)

Un mot fournit la réponse - EXPÉRIENCE.

Jusque-là, vous essayez des choses et apprenez à acquérir de l'expérience.

Gardez également à l'esprit qu'il existe des tâches que vous pouvez définir sur n'importe quel MCU et qui peuvent tomber à plat sur leur visage si la mauvaise approche de conception est utilisée pour les algorithmes. Il y a longtemps, j'ai codé le micrologiciel pour un MCU 8 bits 4,9 MHz qui utilisait des algorithmes intelligents et qui était capable de surveiller le raccroché / décroché et de détecter l'état de la sonnerie en filtrant le signal de tension de sonnerie ~ 20Hz sur les 28 lignes téléphoniques simultanément puis signaler cet état à une station de commande centrale tout en exécutant un écran LCD et en utilisant une interface utilisateur assez complexe hors des tonalités DTMF détectées. Des trucs amusants.