Un grand microcontrôleur ou beaucoup de petits microcontrôleurs?

Je suis habitué à faire des choses simples et simples avec des microcontrôleurs, relativement parlant. Des choses telles que la conduite de LED, le fonctionnement de moteurs, des routines de base, des interfaces graphiques sur des écrans LCD de caractères, etc., mais toujours une tâche clé avec au plus quelques petites tâches secondaires. Cela m'a relégué aux produits bas de gamme car c'est vraiment tout ce qui est nécessaire dans ces cas.

J'aimerais commencer à concevoir des choses plus complexes, mais le côté supérieur du continuum du microcontrôleur n'est pas quelque chose auquel j'ai été bien exposé. Ainsi, j'ai eu beaucoup de mal à essayer de choisir un microcontrôleur où je ferai beaucoup de tâches simultanément - je ne peux pas dire simplement par un numéro MIPS et un brochage satisfaisant s'il a assez de puissance pour faire ce que je veux faire.

Par exemple, je voudrais contrôler 2 moteurs BLDC avec des routines PI, ainsi que des communications série et USB, une interface graphique et une foule d'autres tâches. Je suis tenté d'avoir juste un microcontrôleur pour chaque moteur, puis un pour les tâches diverses afin que je puisse garantir que le surcoût des choses diverses ne gommera pas le fonctionnement critique du moteur. Mais je ne sais pas si c'est en fait une bonne idée ou une manière naïve de procéder.

Je suppose que ma question est vraiment double:

1. L'approche tout-en-un est-elle une bonne idée lorsque vous devez faire beaucoup de multitâche, ou est-il préférable de segmenter et d'isoler, et

2. Comment savoir intuitivement si le microcontrôleur que je regarde a suffisamment de puissance de calcul pour faire ce dont j'ai besoin en fonction de ma liste de tâches?

J'examine les dsPIC33 modérés jusqu'aux SoC ARM qui exécutent RTOS. Un moyen systématique d'affiner ce dont j'ai besoin m'aiderait beaucoup.

Les réponses à vos questions sont différentes selon votre objectif final. Si vous avez besoin d'une poignée ou moins de ces appareils, vous devez faciliter le développement et ne pas vous soucier du coût des pièces. Si vous voulez en faire un millier ou plus, cela vaut la peine d'analyser vos besoins et de réduire le coût du matériel de l'appareil.

Petites quantités

Si vous effectuez une série unique ou unique de ces appareils, vos efforts de développement vont submerger vos coûts par article, et vous devez vous concentrer sur ce qui sera le plus facile / le plus rapide à développer pour vous, plutôt que sur le coût / taille de la microélectronique.

En général, l'encapsulation peut réduire la complexité et augmenter votre productivité. Si vous avez des exigences difficiles en temps réel, telles que votre contrôle BLDC, les boucles PID, etc., il peut être plus rapide d'utiliser des contrôleurs séparés spécifiquement pour les tâches qui communiquent avec les contrôleurs où vous conservez l'interface utilisateur et d'autres non-réels. tâches de temps.

Donc dans ce cas, la réponse à vos questions est:

L'approche tout-en-un est-elle une bonne idée lorsque vous devez faire beaucoup de multitâche, ou est-il préférable de segmenter et d'isoler, et

L'échelle penche légèrement vers la segmentation et l'isolement. La raison principale est que le débogage d'un système en temps réel peut prendre beaucoup de temps, et garder ces tâches sur leur propre processeur limite les variables que vous devez mesurer ou contrôler lorsque vous essayez de trouver pourquoi quelque chose ne fonctionne pas correctement.

Comment savoir intuitivement si le microcontrôleur que je regarde a suffisamment de puissance de calcul pour faire ce dont j'ai besoin en fonction de ma liste de tâches?

Dans ce cas, la différence de coût entre un processeur 32 bits avec beaucoup de ressources et un processeur 8 bits avec des ressources limitées est faible par rapport au temps que vous allez consacrer au développement. Il n'y a aucune raison d'essayer de déterminer la puissance dont vous avez besoin - obtenez simplement le plus gros processeur que vous pensez pouvoir développer et l'utiliser. Si, à un moment ultérieur, vous devez optimiser les coûts de conception, il est relativement facile de mesurer l'utilisation réelle des ressources du processeur, puis choisissez un processeur bailleur capable de gérer la charge réelle. Jusque-là, utilisez le plus grand et ne vous inquiétez pas de trouver le "meilleur ajustement".

Production de masse

Si vous prévoyez de fabriquer un grand nombre de ces appareils, une analyse minutieuse entraînera des économies de coûts importantes. De manière générale, un microcontrôleur plus gros coûtera moins de deux microcontrôleurs capables de remplacer le microcontrôleur unique, bien qu'il existe certainement des exceptions en fonction des tâches spécifiques requises. À ces quantités, le coût du matériel sera probablement beaucoup plus élevé que le coût de développement, vous devez donc vous attendre à passer plus de temps à analyser vos besoins et à effectuer le développement que si vous n'en faisiez que quelques-uns.

L'approche tout-en-un est-elle une bonne idée quand il faut faire beaucoup de multitâche, ou est-il préférable de segmenter et d'isoler?

L'approche tout-en-un sera généralement moins coûteuse sur la durée de vie du projet que plusieurs processeurs. Cela nécessitera plus de temps de développement et de débogage pour s'assurer que les différentes tâches n'entrent pas en conflit, mais une conception logicielle rigoureuse limitera presque autant que le ferait un matériel séparé.

Comment savoir intuitivement si le microcontrôleur que je regarde a suffisamment de puissance de calcul pour faire ce dont j'ai besoin en fonction de ma liste de tâches?

Vous devrez comprendre les tâches que vous souhaitez effectuer et le nombre de ressources qu'elles nécessitent. Supposons que ce qui suit était vrai:

Vos routines BLDC PI consommeront X cycles de temps de processeur 100 fois par seconde, et chacune a besoin d'environ 50 octets de RAM pour le fonctionnement, 16 octets d'EEPROM pour le réglage et 1k flash pour le code. Ils auront chacun besoin de 3 périphériques PWM à 16 bits dans le microcontrôleur. Vous devrez peut-être spécifier la gigue, qui aura des exigences spécifiques de latence d'interruption.

Vos routines USB et série consommeront Y cycles de temps de processeur au besoin, 2 Ko de RAM, 64 octets d'EEPROM et 8 Ko de flash. Il faudra des périphériques USB et série.

Votre interface graphique consommera Z cycles de puissance de processeur 30 fois par seconde, et aura besoin de 2 Ko de RAM, 128 octets d'EEPROM et 10 000 Flash. Il utilisera 19 E / S pour les communications avec l'écran LCD, les boutons, les boutons, etc.

Lorsque vous démarrez pour la première fois, il peut être difficile de comprendre ce que sont réellement X, Y, Z, et cela changera un peu en fonction de l'architecture du processeur. Cependant, vous devriez être en mesure de comprendre, dans une estimation approximative, la quantité de RAM, eeprom et flash dont votre conception aura besoin, et de quels périphériques vous avez besoin. Vous pouvez choisir une famille de processeurs qui répond à vos besoins en matière de mémoire et de périphériques et dispose d'un large éventail d'options de performances au sein de cette famille. À ce stade, pour le développement, vous pouvez simplement utiliser le processeur le plus puissant de la famille. Une fois que vous avez mis en œuvre votre conception, vous pouvez facilement passer de la famille en termes de puissance à une option à moindre coût sans changer votre environnement de conception ou de développement.

Après avoir fait suffisamment de ces conceptions, vous pourrez mieux estimer X, Y et Z. Vous saurez que les routines BLDC PI, bien qu'elles s'exécutent souvent, sont assez petites et nécessitent très peu de cycles. Les routines USB et série nécessitent beaucoup de cycle, mais se produisent rarement. L'interface utilisateur nécessite fréquemment quelques cycles pour trouver des modifications, mais nécessitera souvent de nombreux cycles pour mettre à jour un affichage, par exemple.

Je séparerais la commande du moteur et j'aurais un microcontrôleur séparé qui comprend PWM (peut-être un PIC18) pour chacun des deux moteurs BLDC, car la commande PI est une tâche isolée une fois démarrée et une fois que vous écrivez le code, vous peut l'utiliser sur les deux micros. Vous pouvez les reconnecter au microcontrôleur principal via une interface comme I²C, et télécharger les paramètres du contrôle PI à partir de là si vous le souhaitez. Cela vous permettrait de les modifier dans votre interface graphique.

Je voudrais ensuite exécuter tout le reste dans le microcontrôleur principal, comme un PIC24 (un PIC32 est probablement exagéré, en fonction des tâches que vous avez répertoriées). De plus, les PIC24E les plus rapides peuvent fonctionner presque aussi vite qu'un PIC32.

Lors du choix d'un microcontrôleur, j'évalue d'abord la quantité de mémoire flash et de RAM dont j'ai besoin, puis je regarde la longueur des mots et la vitesse du processeur. Pour ces derniers, la condition la plus difficile à respecter est souvent l'interruption la plus rapide que vous attendez. Si vous émettez un son à 16 kHz, par exemple, et que vous avez une interruption toutes les 62,5 µs, vous feriez mieux d'avoir un microcontrôleur avec un temps d'instruction dans les dizaines de nanosecondes, ou vous ne pourrez pas le réparer et en obtenir d'autres travail effectué.

Il existe une approche semi-formelle que vous pouvez utiliser pour vous aider à générer votre réponse. Je recommande fortement de lire le chapitre 2 de "Designing Embedded Systems" de White, dont la plupart sont disponibles sur Google Books .

Ce chapitre traite de la conception des architectures système et propose une approche semi-formelle de la meilleure façon d'encapsuler les tâches. Bien que le chapitre porte essentiellement sur un système de contrôleur, il s'étend facilement à plusieurs contrôleurs. Il vous aidera à voir quelles ressources doivent être partagées et à choisir votre niveau d'encapsulation pour chaque tâche.

Elle offre une variété de points de vue à considérer, dont je montre ci-dessous, mais il existe de nombreuses manipulations utiles. Bien sûr, cela n'a pas beaucoup de sens en soi, mais j'espère que cela vous encourage à consulter le chapitre.

Quant à "comment savoir si j'ai suffisamment de contrôleur", ma préférence est de mettre autant de puissance que possible dans mon bac à sable de conception, puis de déterminer le nombre de ressources que je peux réduire une fois que la conception est bien façon. La différence de prix entre un microcontrôleur de 10 $ et un microcontrôleur de 3 $ à des fins de prototypage pourrait bien être des semaines de réoutillage et de manipuler vos pouces en attendant de nouvelles pièces, tandis que la conception peut toujours bouger si vous avez suffisamment de puissance.

Je travaille sur un système qui correspond à peu près à ce que vous décrivez - moteurs, E / S, écran, 3x UART + SPI + I2C fonctionnant sur un Coldfire 52259 (micro de milieu de gamme 32 bits ~ 80 MHz) et ce n'est pas trop difficile, bien que L'architecture logicielle est importante - nous avons beaucoup de choses en cours d'exécution sur le matériel et les interruptions (tout ce que le matériel peut gérer seul, nous l'exécutons en matériel et service avec des interruptions), laissant la boucle main () pour faire tout le ménage.

Personnellement, je n'aime pas la plupart des RTOS que j'ai vus, au bas de l'échelle, ils gonflent un projet, ajoutent une autre chose à apprendre et vous obtiendrez de meilleures performances du matériel en faisant des choses directement (en utilisant les fonctions matérielles disponibles + les interruptions) plutôt que de le simuler avec un logiciel.

Au sommet, ces jours-ci, il semble y avoir si peu de marge entre un MCU suffisamment complexe et puissant pour vraiment bénéficier d'un RTOS et quelque chose (SoC) qui exécute simplement Linux embarqué.

Cependant, dans ce cas, je dirais qu'il est utile d'utiliser de petits micros bon marché pour gérer les fonctions critiques (contrôle moteur EG où le chronométrage ou l'arrêt à une limite est critique) sous la commande du CPU principal "cerveau", donc vous ne vous fiez pas sur un système d'exploitation "non temps réel" pour faire quelque chose en temps opportun.

Tout le monde a une meilleure réponse, mais j'ai un petit mot à ajouter qui peut être utile. Cela peut être un peu décalé et j'aimerais l'ajouter en tant que commentaire, mais il existe une règle de 50 répétitions :(

La réponse courte est que cela dépend, voir ci-dessus mais pourquoi ne pas penser aux avantages du processeur aussi.

Pourquoi ne pas penser aux avantages des petits processeurs. C'est, après tout, une question sur les processeurs. Pour les tâches mathématiques et certaines tâches non itératives, plusieurs processeurs peuvent produire un boost logarithmique. La règle d'Amdahl stipule qu'un coup de pouce peut être obtenu de$\frac{1}{((1-p)+\frac{p}{s})}$mais cela vient. P est le pourcentage du calcul qui peut être divisé et s est l'accélération (dépend du nombre d'opérations, du matériel, etc.).

Bien sûr, le coût, la facilité de mise en œuvre; etc. sont importants et encore plus importants à considérer également.

La réponse peut dépendre des détails d'implémentation. Certaines tâches sont plus faciles à implémenter de manière propre et robuste sur des microcontrôleurs séparés. La consommation d'énergie peut également être un facteur à prendre en compte - en règle générale, un seul micro-ordinateur gérant plusieurs tâches nécessitera moins d'énergie que plusieurs micro-ordinateurs gérant des tâches uniques.

La "puissance" est secondaire pour savoir si vous pouvez remplir vos contraintes en temps réel.

Si vous avez deux sorties PWM et que les deux doivent commuter en même temps, vous devez avoir le parallélisme nécessaire en place pour pouvoir le faire. Si vous avez un contrôleur PWM dédié qui prend en charge le timing exact, cela fonctionnera, même avec un microcontrôleur assez petit, tandis qu'une solution basée sur GPIO sera massivement complexe même si beaucoup de puissance de calcul est disponible.

Pour la plupart des protocoles, les MCU modernes ont des implémentations intégrées des parties du protocole qui ont des contraintes en temps réel, donc si vous pouvez trouver un MCU qui a les périphériques requis et a la vitesse CPU requise pour gérer les flux de données (c'est-à-dire que les exigences en temps réel dur dégénèrent dans une condition douce en temps réel du formulaire "sera capable de lire à partir du FIFO avant qu'il ne soit plein, et plus vite qu'il ne se remplit"), ce serait le choix optimal.

Si une telle solution n'existe pas, vos options sont soit de déplacer les fonctions vers des contrôleurs séparés, en utilisant une solution CPU + FPGA (par exemple FPGA avec noyau ARM dur), soit une solution FPGA pure (en option avec un CPU souple, en fonction des exigences de complexité).